一、白板和白板笔
- 需求阶段和客户讨论问题时分析、设计、客户在这里自由交流大家对问题的看法
- 在项目分析和设计阶段用来进行头脑风暴，是设计的最重要的工具。白板上画的可以是UML图，但也可以是项目团队能够理解的任意图形，或者就是简单的线条、图形都可以
- 无处不在的讨论，任何时候对需求的理解和对设计的讨论都在白板上进行
一般公司里面经常会出现白板笔太久没用水用光的时候，所以我一般都要提醒后勤人员买好充足的笔，用完笔以后要盖好盖子。
二、卡片和图钉
- CRC是除了白板以外第二重要的设计工具，这种卡片在中国很难买到，所以一般用文摘卡代替，CRC的重要作用在于可以进行角色扮演，验证设计的准确性。CRC的前面分别写责任和协作，背面可以进行备注。卡片一定要硬的，方便传递，有质地感，有一定的厚度，这是因为：
- 在CRC的扮演过程中，举起一张硬卡片和一张软软的纸感觉不同
- 在撕卡片的时候，要有声音有感觉，表示我们对需求的更改是非常欢迎的，不是说些下来的东西就完全算数了
- 在需求过程中，卡片需要在客户、程序员、分析人员之间传递，纸片太软
- 客户需要根据价值把卡片按优先级分堆，决定我们的迭代和发布，纸片不方便，容易遗漏和混淆，不太正式
- 故事卡可能一部分可能移到下一个迭代，不能在墙上贴了一段时间就变得破破烂烂
- 用户故事卡，我会定制一个泥印，直接盖在空白的用户故事卡上，这个卡片在需求阶段可以任意传递、撕毁、重写、合、分裂，卡上有故事卡编号、优先级、风险评估和当前的迭代序号，用户故事卡订在一个大家都能看到的离开发位置较远的墙壁上
- 任务卡，任务卡从故事卡分裂而来，用图钉钉在开发员的电脑旁边
- 编码卡，主要纪录需要实现的测试，需要注意的事项，等等，开发人员不断增加条目、划去条目，是对一个人物而言的备忘录和todolist
三、大坐标纸（长的直尺、各种颜色的笔）
我通常会在项目的进行过程中记录各种度量，这包括有效代码增长率、测试代码增长率、功能测试通过率、故事卡完成率、测试覆盖率（具体工具在后面介 绍），悬挂在比较高的位置，大家一眼能够看到的地方。另外每个迭代的每个理想天都会检查每个人任务完成的情况，延迟、提前、原因、重新估计时间、剩余实 践，根据不同情况用不同的颜色表达，画在一张大白纸上，不够的话可以慢慢接长，贴在显而易见的墙壁上。
工作进度是一个交流问题，重在交流和整体感觉，而不是具体的数据。客户、老板、项目开发人员、管理人员各位都希望知道现在进行的情况，开发人员也需 要对项目中其他人员地进行情况有所了解，所以最好把这些东西放在最显而易见的地方。每个相关人员都可以一眼感觉到项目的“温度”。
一般来说，我检查和度量的时间是在一个理想天，也就是3-4天的时间，一般采用的工具是JavaNCSS ，我有编写一个小小的工具，利用Javancss计算出源代码的统计信息，按照时间为横轴，画出增长的曲线，然后手工画到墙上的大纸上。一些例子：
- 产品代码增长率，这个增长率应该在项目前期比较高，且比较稳定，如果某段时间的增长率出现异常情况，可能在设计或实现过程中碰到了 某些问题。在项目后期应该逐渐降低（但不意味着故事完成增长率的下降，相反体现在故事增长率和测试增长率的相对提高），这是我们对重用的一个期望。代码增 长率也是项目管理人员比较关心的问题。
- 单元测试代码增长率，一直保持在比较稳定的增长率，不同阶段和产品代码的增长之间保持一个相对比率，例如从1：1到1.5：1到2：1
- 代码覆盖率，用clover可以很方便地生成，CLover的历史信息和增长信息特别有用，当然还需要手工摘录最重要的几条曲线
- 用户故事完成率，这是客户需关心的东东，只有所有的用户故事完成，才能号称迭代正确完成，不然写了多少代码读是没有意义的
- 功能测试增长率和Bug密度，功能测试反应的未通过的bug，这个最好是分界面、WEb曾或者数据库层、模型层，统计在不同模块的密度，这个 Bug率最好加上估计的时间，例如1小时、2小时，半天等等。功能测试没有100%通过是正常的，但是必须纪录BUg的相对密度。
至于开发人员的进度模板，这个就比较复杂了，不同的项目也有所调整，我曾经用XPPlanner产生过报表，但太灵水了，所以不得已用excel画 的，每1理想天更新一次，这是很重要的一个掌控工具，一个迭代周期内必须尽早估计到可能需要的延迟、客户需求变化的调整、一些人提早或落后需要开发人员之 间相互调剂等等，据说2003年生产力奖的XPOne非常好，但没有评估版本，我每次只能用手工做。
这个象20个人的团队大约要花上3-4个小时左右，所有人都要参加，要充分交流分析体现或落后的原因、要及时调整后面的估计，同时尽量让每个人发表 自己的意见，例如可能需要交换任务，重新调整任务的时间、加入新的任务、把某些任务延迟到后一个迭代、解决本天内的一些新发现的公共问题等等。当然，最后 还是要抄到墙上去。
四、小桌子（香烟、绿茶、咖啡或水果）
工作一段时间，2个小时左右，开发人员可以三两成群地在小桌子（或者是吸烟区）旁边抽烟、喝茶、咖啡或者水果，交流相互的心得、讲讲笑话、谈谈碰到 的问题。很多问题就在这里面谈出来、解决、得到线索等等，团队的气氛经常就是在这个时候变得慢慢融洽。 在XP和其他敏捷软件开发团队里面，交流和反馈不是一个空洞的概念，所有的工具（例如SCM）、纪律、度量、工作方式、环境都有为这个目的服务，交流的畅 通是需要花费大量的时间、精力和很多习惯才能慢慢形成的，不是轻而易举就能达到的。这是一个无论怎么强调都不为过的重点。
Wiki和issuetrack
wiki
为什么用Wiki的原因，主要的问题是WIKI的形式比较自由，能够充分发挥想象力，不需要非常正式，但是又容易在开发的过程中积累起很有意义的思 考、文档和模式。总而言之，是非常利于不拘形式的自由的交流。Wiki的简单和目前很多WIKI的可扩展性，使得我们能够把Wiki和其他软件，例如 Issuer，CVS等方便地结合起来。Wiki软件和Eclipse的结合可以产生很多对项目开发有益的想法和帮助，虽然这一块目前还不时有很多公司在 做，但我觉得一些小小的结合就能产生很好的交流效果和文档组织。
我是Snipsnap的老用户，所以项目开发的时候还是用SnipSnap，SnipSnap的好处是使用简单，配置方便，涉及到项目开发的具体应 用，通用词汇表的建立、概念的交流、工作方式的讨论我喜欢在Wiki上进行，Wiki也是一个项目知识库实现的最佳方式，包括项目所需要的配置说明、项目 用到的书籍、文章和相关的讨论。第二个Wiki是Fitness，这是做功能测试最好的工具之一。
关于Wiki，我自己有项目管理中的新想法，不过很多相关的产品都不是开源的，太贵，所以目前还没有应用起来，等我自己了，呵呵
IssuerTracker
Jira,这是我少数选用的商业产品，举我自己的感觉，这是Issuer里面No.1的产品，可惜和XP的项目计划偏差较大，对于时间估计和流程配 合不够流畅。使用Jira的原因是它是面向开发人员的一个tracker工具，在开发阶段它的表现要胜于其他跟踪系统，它的灵活性和新近的插件机制也能够 方便我更好的扩展。
测试工具
JUnit,这个没什么好说的，当然用法上自然是最偏向于KentBeck的用法。用Cactus测试感觉不是很方便。由于struts已经不用了，用JUnit就能够测试Webwork的Action，所以Web层我基本上已经不测了。
Clover，虽然TDD的覆盖率肯定是非常高的，但很多项目不做TDD的，我自己有一个小小的工具，自己用用还可以，但项目中没办法用， JCoverage是开源的，红工厂也有产品，但是我没用过
用户测试，目前我在第二个小项目中用Fit和Fitnesse，但没有在大项目使用的经验。以前是自己写excel到数据库转换，用JUnit测的，比较麻烦
IDE
IDE，最早用的JBuilder，后来用的NetBeans，在后来就是IDEA，当初被IDEA的refactoring功能之强大震撼，但有一次KentBeck在UMLChina聊天的时候说起Eclipse，自此就没有变过。吸引我的原因有很多，例如：
- KentBeck为什么推荐IDEA和Eclipse，而不推荐JBuilder，呵呵
- EricGamma领导下做的，那还会有错？，哈哈
- free.我已经被Borland公司的人搞得不行了
- 界面风格，当初的SWT表现还是非常优异的
- Eclipse的重构支持不弱于IDEA
- Eclipse对于程序员intention的理解稍稍弱于IDEA，但确实也在不断进步
- Eclipse很早就有内建的Ant和JUnit集成
- Eclipse的CVS集成简直让WinCVS变成一场恶梦。能够让敏捷编程的配置管理策略非常容易地实现起来。CVS能够真正成为团队协作的一个基石。Eclipse的CVS集成也让CVS和其他版本控制软件之间的区别变得不是那么重要。
- 第一个完全构造在微核心上的开发工具，做程序的好这一口，相信好的结构和体系有好的程序。
综合起来，Eclipse的很多设施方便XP的很多规则执行，而且又是免费的，没理由不用呀
版本管理和构建
CVS，当然CVS有很多的问题，例如没有事务呀，不支持属性呀，不支持移动和重命名呀，但CVS是世界上用得最多的版本控制工具，那么多大小项目 在用，那么多产品总是先在CVS上实现，再移植到其他软件上。又是免费的。CVS最重要的特点当然是non-lock方式的开发。Subversion可 能会是我的下一个选择。
CVS上我偶尔用的是CVSSTAT，但最近Fisheye异军突起，可惜是要钱的。
构建：当然首先是ANT，一直想看看Maven，但好像太复杂了，试了一段时间，现在还是ANT，然后是集成构造的管理，我一开始就用的是CC，就 没有再去想AntHill。CC除了可以用Email和Web通知之外，还可以用Jabber通知，我刚在用Jabber的eclipse插件，还没有什 么感觉。实际项目中还是以Email为主。
CASE工具
画图工具：我好像很少画图，除了在白板上，倒是写文章的时候经常用Rose，画出来的图很漂亮，适合放在杂志上面或者放在网页上.设计文档里面的图 基本上也是用visio画的，但通常很少，一般是针对整个项目核心的一些结构和设计。当然项目后期有的时候需要很多的图，我一般用Rose或者用 JRefactory逆向出来。
数据库
数据库：数据库总是需要两个的，一个是production的，另外一个是workspace的， production的可不是我说了算，如果要我推荐那就是SAPDB和Postgres了，当然Oracle和SQLServer是主流，我们也没办法 的，但最近一个项目还在用Sybase。
workspace的数据库是开发用的，如果我没有用Hibernate之类可以方便移植的数据库，那就只能是production数据库了。但最 近一个项目就出现问题了，某公司当初是用Oracle开发的，但现在去买要花20万，一开始不想花这个钱，用SAPDB，不行,时间上也来不及了。如果是 用ORM的，我一般现在用MYSQL
扫一扫
293
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
