[AKA]珠三角技术沙龙第 5 期胜利完成
Zoom.Quiet
http://py.kingsoft.net/ktrac/wiki/100123TechSalon
录像紧张编辑中,本周应该可以上线;
欢迎大家就如何更好的在日常工作中使用 Trac 来协调开发进行多方面探讨!
2010/1/19 LaiYonghao <lanp...@gmail.com>:
> hi, all, 珠三角技术沙龙第 5 期确认信已经发送，为防止同时 bcc 给太多导致邮件被分派到垃圾邮箱，特在这里也发一下。
> 因为座位充足，所以本期报名的朋友都可以前来参加沙龙活动。
> ========================
> 欢迎参加 1 月 23 日（星期六）珠三角技术沙龙第 5 期，本期参加人数约 100 人。
>
> 时间：2010 年 1 月 23 日（周六）下午 1:30 至 5:30 （重要：比以往提前一个小时）
> 地址：广州市天河区科韵路16号广州信息港E栋网易大厦一楼博学堂
> 交通：天河软件园交通发达，附近的公交站有学院站、科韵路站、员村四横路口站、程介村站，其中后面两个下车后走到网易大厦的路径比较曲折，敬请先查看地图或向路人问路。
> 地图：http://tinyurl.com/yjpdez4 （打开地图后可以看到招商银行，银行背后即是网易大厦）
>
> 赞助
> 场地赞助：网易广州
> 奖品赞助：GeekCook（http://geekcook.taobao.com/）
>
> 讲师和课题
> 《基于 RoR 的 REST API 设计与twitter/facebook API 分析》
> 伍少坤 ，专业是 GIS，现任 Kude Labs 的软件工程师，从事 Web Application 的开发，将近 4年的 Ruby on
> Rails 经验，一直努力将 REST 的思想应用于项目中。
> 个人对 Open Source 十分感兴趣，在 Github 上维护两个开源的 Javascript 小插件，同时关注 Ruby on
> Rails，Ajax，Javascript 等技术。
>
> 《KTRAC ~ 珠海金山怎么用trac》
> Zoom.Quiet，周琦， 男，金山软件，过程改进经理，纯种Pythoner，自由软件原教旨主义者，尝试使用Pythonic体验感化国人主动进入自由软件世界体验/学习/再创作。
> Trac 是号称不干扰己有工作流程的任务管理平台,在金山我们则是用Trac 来建立新的流程;当然Trac 天然的敏捷内在是我们深入定制她的动力!
>
> 更多：http://blog.laiyonghao.com/2010/01/programming-tech-party/442
>
> 致礼
> 技术沙龙组委
>
>
>
> --
> 赖勇浩的编程私伙局：http://blog.laiyonghao.com
> twitter: http://twitter.com/laiyonghao
--
http://zoomquiet.org 人生苦短? Pythonic!
KM乃是培育可催生自学习型组织的文化氛围! (KM=Knowledge Management=知识管理)
Tinyfool
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool
Zoom.Quiet
> 不错不错，zq大妈的录音我刚才一直在听（现在还没听完，买了菜，洗了碗，饭都快做好，可见之罗唆），之前就接触过trac，不过没用起来，第一印象很好。最近刚想拾起来，就看到你的录音了，只是没时间等你的录像，可惜了。
>
是也乎，是也乎，就是 Trackinks 那儿，怎么也无法和现场同学们很好的互动，
增补详细体验在:
http://py.kingsoft.net/ktrac/wiki/100123TechSalon
usage 7-zip to replace WinRAR/WinZip; You can get the truely Freedom 4 software.
Jianfei Wang
想问zq一句，如果对python/ruby不存在偏爱、从头开始选一个项目管理系统，会优先考虑trac还是redmind？
对于trac的担忧：中文（用户不够友好）、配置繁琐、插件功能太多会耗费管理精力、对于多svn管理似乎有问题？
redmind似乎从一开始就在解决trac的这些问题，但只有一个开发者、还不太出名让我又有些犹豫……
我的经历：本机安装、试用过简单的trac（裸的）；redmind至今只试用过别人架设好的……
机械唯物主义
2010/1/25 Jianfei Wang <fra...@gmail.com>:
Tinyfool
Zoom.Quiet
> 正在听录音。最近也在考虑架一个项目管理/bug跟踪系统。
> 想问zq一句，如果对python/ruby不存在偏爱、从头开始选一个项目管理系统，会优先考虑trac还是redmind？
>
不许Trac 有多少问题，
仅仅一个 TracLinks 将代码和任务自然关联起来就值得认真使用了！
> 对于trac的担忧：中文（用户不够友好）、配置繁琐、插件功能太多会耗费管理精力、对于多svn管理似乎有问题？
其实祼的就非常非常足够用了，
俺搞的这么多插件，不过是为了堵各种不想用Trac 的人的嘴...
多SVN 就比较好解决了,合并成一个仓库不就好了?
--
http://zoomquiet.org 人生苦短? Pythonic!
一个人如果力求完善自己,就会看到:"为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!"
Jianfei Wang
还是 Trac 哪，
不许Trac 有多少问题，
仅仅一个 TracLinks 将代码和任务自然关联起来就值得认真使用了！
呵呵，真是立场坚定啊～
多SVN 就比较好解决了,合并成一个仓库不就好了?
嗯，合并到一个svn技术上问题应该不大，会尝试
好在我这儿需求也不是太急迫，打算春节好好研究下trac再下结论。
还有一问：
项目同时还需要一个文档管理工具，考察了moinmoin。那么如果引入trac，可否用一个trac来同时做文档管理呢？还是把两者分开，trac/moinmoin各司其职？请教zq相关使用经验/体验～
Zoom.Quiet
> 2010/1/25 Zoom.Quiet <zoom....@gmail.com>
>>
>> 还是 Trac 哪，
>> 不许Trac 有多少问题，
>> 仅仅一个 TracLinks 将代码和任务自然关联起来就值得认真使用了！
>
> 呵呵，真是立场坚定啊～
http://py.kingsoft.net/ktrac/wiki/100123TechSalon
>> 多SVN 就比较好解决了,合并成一个仓库不就好了?
> 嗯，合并到一个svn技术上问题应该不大，会尝试
>
> 好在我这儿需求也不是太急迫，打算春节好好研究下trac再下结论。
>
> 还有一问：
> 项目同时还需要一个文档管理工具，考察了moinmoin。那么如果引入trac，可否用一个trac来同时做文档管理呢？还是把两者分开，trac/moinmoin各司其职？请教zq相关使用经验/体验～
>
这也是俺一直的痛哪!
- 文档?
- 文档管理?
- 一般默认是指项目文档吧?
- 那么一般中国开发团队中的项目文档是什么?!
- 写一次永远没人用的立项说明书?
- 写一次永远没人用的市场前景分析?
- 写一次永远没人用的测试计划?
- 写一次永远没人用的项目计划?
- ...
- 反正 CMM 那堆东西如果是文档的话,没有人反对吧,不过管理这种东西来作什么?
- 如果一个实效团队,关注:
+ 不断更新的里程碑计划
~ 使用 Trac 路线图呗
+ 随时从任何渠道收集到的需求
~ 使用 传票呗
+ 关键代码的实现思路和协同协议
~ 使用 Doxygen 直接和代码结合哪
+ 部署时依赖的配置
~ 使用 TracWiki 呗
- 当然,总得有面子工程的Office 文档要进行管理,那么主要矛盾是:
- 只有ftp/bbs/SMB体验的产品人员和开发经理文档管理习惯的矛盾
- 项目文档的Office 修订版本和SVN版本仓库的不一致性矛盾
综合以上,建议:
- 不要妄想改进适合非程序员的文档习惯
- 文档管理的概念其实没有什么团队是完备的,提供一个空间,用权限保证,约定一个目录是撰写中的,一个是正式的,正式的文档要走流程评审,就好
(类似截屏的配套文档管理规范什么的...)
- 真正的开发用文档,尽量:
- 和代码结合
- 和传票结合
- 和维基结合
--
http://zoomquiet.org 人生苦短? Pythonic!
金山常年招聘Py/C++人才! http://is.gd/6hXIL 简历直投俺就成;-)
Xpol Wan
Xpol Wan
机械唯物主义 : linjunhalida
个人觉得非常非常重要的一点：
为什么要把写文档和写程序分离开来？
写程序之前，要整理思路，整理需求，整理设计，而这些整理工作，是通过写文档的过程来完成的。
在写文档之前，可以随便打打草稿，而写文档，是把这些草稿具体细化为设计。然后才谈得上写程序。
写程序的时候发现思路不对，这个时候，再回去通过修改文档的方式整理思路和修改设计。
总之，文档不是产品，而是过程的产出。
还有，开发程序要面向需求，在写程序前先写文档，描述清楚到底做的是什么软件，然后开发起来就事半功倍了。
而在以上逻辑下，用trac的tickets整理需求，然后分析需求，写wiki文档，
再具体开发，开发完毕commit，对应到tickets，然后tickets fixed，milestone的tickets fix完毕，产品的开发就告一段落。
这是我对trac的理解，不知道大家有什么看法？
2010/2/2 Xpol Wan <xpo...@gmail.com>:
机械唯物主义 : linjunhalida
2010/2/2 机械唯物主义 : linjunhalida <linjun...@gmail.com>:
Xpol Wan
Xpol Wan
Zoom.Quiet
> trac用的挺爽的。
> 个人觉得非常非常重要的一点：
> 为什么要把写文档和写程序分离开来？
> 写程序之前，要整理思路，整理需求，整理设计，而这些整理工作，是通过写文档的过程来完成的。
> 在写文档之前，可以随便打打草稿，而写文档，是把这些草稿具体细化为设计。然后才谈得上写程序。
> 写程序的时候发现思路不对，这个时候，再回去通过修改文档的方式整理思路和修改设计。
>
> 总之，文档不是产品，而是过程的产出。
>
> 还有，开发程序要面向需求，在写程序前先写文档，描述清楚到底做的是什么软件，然后开发起来就事半功倍了。
>
> 而在以上逻辑下，用trac的tickets整理需求，然后分析需求，写wiki文档，
> 再具体开发，开发完毕commit，对应到tickets，然后tickets fixed，milestone的tickets fix完毕，产品的开发就告一段落。
>
> 这是我对trac的理解，不知道大家有什么看法？
>
非常经典的有个性的开发流程,这当然也是 Trac 可以支持的,但不是提倡的~其实Trac 不提倡任何什么最佳流程,只有你的团队用的爽的才是最好的!
以上描述可以说充分发挥了 传票的wiki 本质,通过可以和代码自然绑定的一个事件记述和分析以及完成过程都记录在统一的媒介中完成了开发过程的统一!
- 产品->创立传票,说明原始需求
- 项目->完善传票,共同分析,制定开发计划
- 技术->理解传票,分解开发任务,并用传票进行开发追踪
- 测试->根据传票,检出代码,针对性测试
- 运维->参考传票,部署对应版本,完善运营文档
一切都围绕着有头有尾的一个个独立任务进行,明确,而且可并行
但是,其中有些问题是一般团队无法容忍的:
- 产品/客服 等等非开发成员,无法忍受非 Office 的编辑界面,对于零散的,随着任务的传递不断完善的传票正文,感觉复杂无法理解!
- 项目经理 等等非一线管理人员,无法忍受非 Office/Project 样的统计报表,他们只需要从整体把握进度和人力分配,不关心具体任务的实现的!
- 技术/测试/运维,比较容易接受和享受传票为核心的全程追踪,但是面对经常性的优先/需求/指标的随意变更,没有任何防御手段,长此以往,就回到通讯靠吼的原始状态了
当然 Trac 体系对以上中国团队经典体验都有对策的,只是要大智慧和心力以及机缘才可能完备:
- 通过插件,或是VB宏,自动同步在 产品/客服中流传的可怕的 Excel 文档到对应传票的相关字段,定制"友好的报表"给它们看,以便逐步感化
- 通过插件,或是VB宏,将团队整体人力和进度情况,展示到专用页面(比如:MMV)或是可怕的Excel报表,以便逐步感化
- 通过一致性的已知/处置中/己完成
的kanban式图表,通告所有成员,将技术/测试/运维的工作量等展示,并确保所有人看的明白,以此带入敏捷的时间盒概念,用单位时间内合格的功能点,来代替没谱时间内尽可能多的功能点,这种质量观念...
......是也乎,是也乎,不过,依然是困难重重哪>..
> 2010/2/2 Xpol Wan <xpo...@gmail.com>:
>> 最近在公司完成redmine 0.9.0-RC在Unbutu 9.10+ Apache + Passenger + Mysql + Windows
>> LDAP（域帐号认证）上的配置和测试。
>> 配置过程中也有一些坎坷，不过都解决了，如果你准备上redmine欢迎讨论交流。
>> 这个周末准备正式上线。
>> （之所以选择redmine是因为个人偏好ruby，基本能读懂rails程序）
>>
>> Best Regards!
>>
>> Xpol Wan
>>
>>
>> 2010/1/25 Jianfei Wang <fra...@gmail.com>
>>>
>>> 正在听录音。最近也在考虑架一个项目管理/bug跟踪系统。
>>> 想问zq一句，如果对python/ruby不存在偏爱、从头开始选一个项目管理系统，会优先考虑trac还是redmind？
--
http://zoomquiet.org 人生苦短? Pythonic!
Zoom.Quiet: Time is unimportant, only life important!
机械唯物主义 : linjunhalida
寻找优秀的解决方案不是难事，把优秀的解决方案推行出去，
在一个没有爱的团队里面无疑困难重重。这个时候就考验自己的软实力了。
如何说服对方，旧的方案没有新的方案有效率？尤其在新方案有一段磨合期的前提下？
还是大妈的方案有可行性: 逐步感化
以及在最初的时候就把握住，不要让他们投入windows的怀抱。。。
这就是开发团队的标准作业方式，老板可以做excel，PPT美观呈现，同级别的还是乖乖的遵循开发流程吧。。
2010/2/2 Zoom.Quiet <zoom....@gmail.com>:
徐建忠
机械唯物主义 : linjunhalida
trac里面的ticket，我想要把它拆分成几个小的ticket，需要new tickets，然后在里面加上parent ticket的ID。
然后有什么方法可以展示一个串起来的图呢？
还有就是这样的树状关系的标准呈现方式是应该是咋样的呢？
2010/2/3 徐建忠 <xui...@gmail.com>:
Zoom.Quiet
> 一个小问题：
> trac里面的ticket，我想要把它拆分成几个小的ticket，需要new tickets，然后在里面加上parent ticket的ID。
> 然后有什么方法可以展示一个串起来的图呢？
> 还有就是这样的树状关系的标准呈现方式是应该是咋样的呢？
金山使用自个儿的 MMV 支持这一情景:
http://trac-hacks.org/wiki/TracMileMixViewPlugin
并配合一个小技巧,
子传票的标题用使用 <#父传票号>子传票标题
的格式,就可以在 MMV 里程碑视图中看到对应的传票关系;
http://py.kingsoft.net/ktrac/mmv/mmv_view/seed:%E7%A7%8D%E5%AD%90
KM乃是培育可催生自学习型组织的文化氛围! (KM=Knowledge Management=知识管理)
Zoom.Quiet
录像经过大家的支招,使用 ffmpeg 批量完成 转换,先发布在啄木鸟空间:
http://www.woodpecker.org.cn:9081/classes/PearlRiverDelta-tech-salon/100123-TeachSalon-5-Gz/mv/
请赖总统一发布在以往的系列视频中吧...
一个人如果力求完善自己,就会看到:"为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!"
Zoom.Quiet
> 2010/1/25 Zoom.Quiet <zoom....@gmail.com>:
>> 俺的记要加说，录音，发布在:
>> http://py.kingsoft.net/ktrac/wiki/100123TechSalon
>>
>> 录像紧张编辑中,本周应该可以上线;
>
> 录像经过大家的支招,使用 ffmpeg 批量完成 转换,先发布在啄木鸟空间:
重新,进一步转换成开源视频格式 ogv 再次发布:
http://www.woodpecker.org.cn/share/classes/PearlRiverDelta-tech-party/100123-TechParty-5-Gz/ogv/
更小,更加顺畅...
MTS格式憾事经验分享在:
http://wiki.woodpecker.org.cn/moin/ZoomQuiet/2010-02-03
--