2008/9/11 小楼听雨 <xlty.0512在gmail.com>:
好哪!先握个手, 俺也在折腾以 Trac 为中心的统一支持平台,

> - 基础
>   所需要组件(在http://trac-hacks.org都能找到):
我们同时也进行了一些原创插件的设计和使用,,,
陆续分享在:...
http://trac-hacks.org/wiki/TracChineseTranslation

>    1. Trac 0.11.1 这个是必须的了
现在都在 0.12b 上迁,因为前面的版本,都没有完善的i18N 支持,,,

>    2. BatchModify 0.2.0 ticket批量修改工具
嗬嗬嗬,这个没有折腾过,得体验一下,,,

>    3. BreadCrumbsNavPlugin 0.1 最近访问的页面链接
>    4. ComponentsListMacro 在wiki上列出所有的components
>    5. PrivateWikis 1.0.0 基于path的wiki权限管理(trac-hacks上的不能工作, 需要修改一下,
> 需要patch请联系我)
嗯嗯嗯! 一般深度的维基使用,直接在公司的 MoinMoin 上了,
以上几个TracWiki 的增强,得体验了,,,

>    6. TicketBox 0.11.1 在wiki上列出tickets, 可以用来动态生成报告
>    7. TicketValidator 0.1 ticket字段验证, 比如close状态时, 某个字段不能为空
嗯嗯嗯,这方面,我们是自个儿使用 jQuery 进行验证的,看来有必要进行插件的标准化,,

>    8. TracAddCommentMacro 0.3 wiki comment插件
>    9. TracCustomRoadmap 0.4 custom roadmap
增强 路线图? 这得小心点,,,

>   10. TracDiscussion 0.6 论坛
>   11. TracFullBlogPlugin 0.1 博客
这两个是混淆Trac 的任务导向行为吧,建议甭用,,

>   12. TracMacroPost 0.2 wiki comment 依赖
>   13. TracTags 0.6 tag组件, 页面右下角显示tag, 可以形成tag云
Tags 是个好主意,但是对使用者要求太高,,,,

>   14. TracTocMacro 11.0.0.3 Title of Content, 用来形成简洁的wiki页面index
这个也有几种相关扩展, TOC 是最简单实用的,,,

>   15. TracWysiwyg 0.2 所见即所得wiki编辑器
这是俺最痛恨的!就不安装!原先的简单 富编辑器也隐了! 就要求写纯文字,维基不会就学习!

>   16. TracXMLRPC 1.0.0 用来支持eclipse mylyn插件的rpc接口
>   17. Ticket-clone 顾名思义, 用来克隆ticket
这两个不用了吧,,,, Ticket ~ 传票,应该是神圣的,不可复制的,,,唯一的!

>   18. Testingworkflow 测试工作流
这方面,我们使用 Bitten 进行外部的集团化测试,,

> - 用途
我们用 Trac基本覆盖整个软件开发过程:
需求|缺陷管理->版本管理->配置管理->集成管理->发布管理! 就是文档管理无法简单嵌入
 |             |        |        |        +-- 和我们的运维系统通过0.12
的工作流评审,对FTP进行权限自动处理,进行联合,完成部署
 |             |        |        +-- 通过Bitten 和CCNET 等等CI系统联合
 |             |        +-- 配置文件入仓库,和Ticket 通过changeset 和传票号绑定
 |             +-- 内置和SVN的干活,而且可以自然和外部code.google 仓库,或是 Hg 等等分布式仓库多级联合
 +-- 配置合理的扩展字段,
   约定产品/客服部成员使用的规范,习惯后,这就是共同的 GTD 任务池了,,,
    \-- 当然为了非开发人员的使用,发现无法快速适应Ticket 的自由风格后:
      0. 开发了 TTT 插件~可以自定传票的模板,根据传票类型自动填入文本框
      1. 进一步的,针对经常提交相似传票的成员,开发了 MTT 插件~可以随手建立"我的任务模板"而且可以自动选择好相关的各种字段

+ 对于SSO,Trac 天然支持 LDAP 非常爽直!
+ 对于整体的项目管理,我们另外开发有系列项目状态统计插件,比如说:
  MMV ~ 里程综合视图,可以将指定里程碑的传票,分析出 如附件那样儿的 Scrum Sprint 综合视图,
    其中的耗散图,是针对相关传票的 due(工作量)的累计,,,
+ 对于任务的关联,我们约定了简单的方式:
 - 在标题中注明父传票号,比如说: <#1035>对开通的Trac 实例进行汉化
   使用 框出父传票的TracLink 这样,就可以通过 相应的插件,看出任务的关联关系了,,,
等等等等,,,,
总之,使用Trac ,坚定的使用Trac, 令我们越发的有信心,可以打造出最吻合现状的合用平台,,,,

另外,发觉使用Nginx 通过 WSGI 来带 Trac 效率稳定,,,都不错
>   * 任务管理
>         * 增加ticket timing控制字段(开发人员实际用时, PM估计用时, 开发人员估计用时)
>         * 启用测试工作流
>         * 自定义扩展Priority中的Delay属性
>           * 增加
>            * Urgent
>            * Middle Term
>            * Long Term
>         * 自定义扩展Type属性(New, Bug, Improvement)
>           * 增加
>            * Ondemand Feature
>            * Discussion Feature
>         * 自定义各种形式的report
>           * Running Task(正在做的任务)
>           * Under Testing(等待测试区)
>           * Urgent Delay(紧急Delay的任务)
>          * 自定义components
>           * 增加
>            * 命名: PM
>            * 其他必须的component
>   * 需求管理
>     * 新需求形成需求ticket, Component=PM的为项目需求, Priority=Urgent/Middle Term/Long
> Term为讨论优先级
>     * 讨论通过需求ticket即刻被分解形成任务tickets
>     * 需求管理报告
>       * Discussion(等待讨论的需求)
>   * Wiki
>     * 管理系统需求, api文档
>     * 项目的knowledge base
>   * Blog
>     * 通知
>     * 新闻
>     * team成员原创的技术文章
>   * Discussion
>     * 五花八门forum
>     * 八卦信息



-- 

http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''
-------------- 下一部分 --------------
A non-text attachment was scrubbed...
Name: 2008-09-12-002445_853x546_scrot.png
Type: image/png
Size: 367412 bytes
Desc: 不可用
URL: <http://www.zeuux.org/pipermail/zeuux-python/attachments/20080912/3ebca066/attachment-0001.png>