potian的软件开发常用工具箱

我说说自己开发一个Java程序常用的工具箱（仅为个人习惯）：

准备篇


1。白板（白板笔）。
1)需求阶段和客户讨论问题时分析、设计、客户在这里自由交流大家对问题的看法
2)在项目分析和设计阶段用来进行头脑风暴，是设计的最重要的工具。白板上画的可以是UML图，但也可以是项目团队能够理解的任意图形，或者就是简单的线条、图形都可以
3)无处不在的讨论，任何时候对需求的理解和对设计的讨论都在白板上进行

一般公司里面经常会出现白板笔太久没用水用光的时候，所以我一般都要提醒后勤人员买好充足的笔，用完笔以后要盖好盖子。

2卡片（和图钉）
1） CRC是除了白板以外第二重要的设计工具，这种卡片在中国很难买到，所以一般用文摘卡代替，CRC的重要作用在于可以进行角色扮演，验证设计的准确性。CRC的前面分别写责任和协作，背面可以进行备注
2） 用户故事卡，我回去定制一个泥印，直接盖在空白的用户故事卡上，这个卡片在需求阶段可以任意传递、撕毁、重写、合、分裂，卡上有故事卡编号、优先级、风险评估和当前的迭代序号，用户故事卡订在一个大家都能看到的离开发位置较远的墙壁上
3） 任务卡，任务卡从故事卡分裂而来，用图钉钉在开发员的电脑旁边
4） 编码卡，主要纪录需要实现的测试，需要注意的事项，等等，开发人员不断增加条目、划去条目，是对一个人物而言的备忘录和todolist

3．大坐标纸（长的直尺、各种颜色的笔）

我通常会在项目的进行过程中记录各种度量，这包括有效代码增长率、测试代码增长率、功能测试通过率、故事卡完成率、测试覆盖率（具体工具在后面介绍），悬挂在比较高的位置，大家一眼能够看到的地方

另外每个迭代的每个理想天都会检查每个人任务完成的情况，延迟、提前、原因、重新估计时间、剩余实践，根据不同情况用不同的颜色表达，画在一张大白纸上，不够的话可以慢慢接长，贴在显而易见的墙壁上

4、小桌子（香烟、绿茶、咖啡或水果）
工作一段时间，2个小时左右，开发人员可以三两成群地在小桌子（或者是吸烟区）旁边抽烟、喝茶、咖啡或者水果，交流相互的心得、讲讲笑话、谈谈碰到的问题。很多问题就在这里面谈出来、解决、得到线索等等，团队的气氛经常就是在这个时候变得慢慢融洽。

本来我有些照片，但现在一下子找不到了

第2个卡片我想是否可以用便笺本，那种随处可以买到黄色便笺，写下内容，随意可以贴到办公桌前，墙壁上。

第3部分对我来说感觉非常新鲜，能否稍微展开讲述一下？

卡片一定要硬的，方便传递，有质地感，有一定的厚度

1。在CRC的扮演过程中，举起一张硬卡片和一张软软的纸感觉不同
2。在撕卡片的时候，要有声音有感觉，表示我们对需求的更改是非常欢迎的，不是说些下来的东西就完全算数了
3。在需求过程中，卡片需要在客户、程序员、分析人员之间传递，纸片太软
4。客户需要根据价值把卡片按优先级分堆，决定我们的迭代和发布，纸片不方便，容易遗漏和混淆，不太正式
5。故事卡可能一部分可能移到下一个迭代，不能在墙上贴了一段时间就变得破破烂烂

第3项有点难以实施吧！有现成的自动化统计工具吗？
毕竟是工作进度的一个直观的体现。很有意义！

对于第3部分而言，这又是一个交流问题，重在交流和整体感觉，而不是具体的数据

客户、老板、项目开发人员、管理人员各位都希望知道现在进行的情况，开发人员也需要对项目中其他人员地进行情况有所了解，所以最好把这些东西放在最显而易见的地方。每个相关人员都可以一眼感觉到项目的“温度“

一般来说，我检查和度量的时间是在一个理想天，也就是3-4天的时间，一般采用的工具是JavaNCSS ，我有编写一个小小的工具，利用Javancss计算出源代码的统计信息，按照时间为横轴，画出增长的曲线，然后手工画到墙上的大纸上。一些例子

1。产品代码增长率，这个增长率应该在项目前期比较高，且比较稳定，如果某段时间的增长率出现异常情况，可能在设计或实现过程中碰到了某些问题。在项目后期应该逐渐降低（但不意味着故事完成增长率的下降，相反体现在故事增长率和测试增长率的相对提高），这是我们对重用的一个期望。代码增长率也是项目管理人员比较关心的问题。

2。单元测试代码增长率，一直保持在比较稳定的增长率，不同阶段和产品代码的增长之间保持一个相对比率，例如从1：1到1.5：1到2：1，

3。代码覆盖率，用clover可以很方便地生成，CLover的历史信息和增长信息特别有用，当然还需要手工摘录最重要的几条曲线

4。用户故事完成率，这是客户需关心的东东，只有所有的用户故事完成，才能号称迭代正确完成，不然写了多少代码读是没有意义的

5。功能测试增长率和Bug密度，功能测试反应的未通过的bug，这个最好是分界面、WEb曾或者数据库层、模型层，统计在不同模块的密度，这个Bug率最好加上估计的时间，例如1小时、2小时，半天等等。功能测试没有100%通过是正常的，但是必须纪录BUg的相对密度。

至于开发人员的进度模板，这个就比较复杂了，不同的项目也有所调整，我曾经用XPPlanner产生过报表，但太灵水了，所以不得已用excel画的，每1理想天更新一次，这是很重要的一个掌控工具，一个迭代周期内必须尽早估计到可能需要的延迟、客户需求变化的调整、一些人提早或落后需要开发人员之间相互调剂等等，据说2003年生产力奖的XPOne非常好，但没有评估版本，我每次只能用手工做。

这个象20个人的团队大约要花上3-4个小时左右，所有人都要参加，要充分交流分析体现或落后的原因、要及时调整后面的估计，同时尽量让每个人发表自己的意见，例如可能需要交换任务，重新调整任务的时间、加入新的任务、把某些任务延迟到后一个迭代、解决本天内的一些新发现的公共问题等等。

当然，最后还是要抄到墙上去

在XP和其他敏捷软件开发团队里面，交流和反馈不是一个空洞的概念，所有的工具（例如SCM）、纪律、度量、工作方式、环境都有为这个目的服务，交流的畅通是需要花费大量的时间、精力和很多习惯才能慢慢形成的，不是轻而易举就能达到的。这是一个无论怎么强调都不为过的重点。

potian
我有点很难受！
“妒忌”这种环境！
或许，这是我所梦想的一个开发环境吧！
无论如何，我还是很羡慕这种环境的存在。或许，今晚我会在梦中与potian描写的环境中吧！
愿我做个好梦！

[robbin，为了完整性，我在这个帖子也跟上]
Wiki
我是Snipsnap的老用户，所以项目开发的时候还是用SnipSnap，SnipSnap的好处是使用简单，配置方便，涉及到项目开发的具体应用，通用词汇表的建立、概念的交流、工作方式的讨论我喜欢在Wiki上进行，Wiki也是一个项目知识库实现的最佳方式，包括项目所需要的配置说明、项目用到的书籍、文章和相关的讨论

第二个Wiki是Fitness，这是做功能测试最好的工具之一

关于Wiki，我自己有项目管理中的新想法，不过很多相关的产品都不是开源的，太贵，所以目前还没有应用起来，等我自己了，呵呵

IssuerTracker
Jira,这是我少数选用的商业产品，举我自己的感觉，这是Issuer里面No.1的产品，可惜和XP的项目计划偏差较大，对于时间估计和流程配合不够流畅。

为什么用Wiki的原因，我在另一个帖子已经有些说明，主要的问题是WIKI的形式比较自由，能够充分发挥想象力，不需要非常正式，但是又容易在开发的过程中积累起很有意义的思考、文档和模式。总而言之，是非常利于不拘形式的自由的交流。
Wiki的简单和目前很多WIKI的可扩展性，使得我们能够把Wiki和其他软件，例如Issuer，CVS等方便地结合起来。

Wiki软件和Eclipse的结合可以产生很多对项目开发有益的想法和帮助，虽然这一块目前还不时有很多公司在做，但我觉得一些小小的结合就能产生很好的交流效果和文档组织。

使用Jira的原因是它是面向开发人员的一个tracker工具，在开发阶段它的表现要胜于其他跟踪系统，它的灵活性和新近的插件机制也能够方便我更好的扩展何时佩。

JUnit,这个没什么好说的，当然用法上自然是最偏向于KentBeck的用法。用Cactus测试感觉不是很方便。由于struts已经不用了，用JUnit就能够测试Webwork的Action，所以Web层我基本上已经不测了。


Clover，虽然TDD的覆盖率肯定是非常高的，但很多项目不做TDD的，我自己有一个小小的工具，自己用用还可以，但项目中没办法用， JCoverage是开源的，红工厂也有产品，但是我没用过


用户测试，目前我在第二个小项目中用Fit和Fitnesse，但没有在大项目使用的经验。以前是自己写excel到数据库转换，用JUnit测的，比较麻烦