SnippetShare 项目总结连载（一） 好的开发方式“敏捷”

SnippetShare 项目总结连载（一） 好的开发方式“敏捷”

Luo Weifeng 2011-6-25

 

首先，这是个很特殊的时刻，两个人奋战了3.5个白天的JavaEE课程设计终于完工了。 这其中多少坎坷总是值得记录一下。

 

团队: 团队在这里的开发中算是比较成功的一次尝试，一个原则，多交流，协同前进。 因为是小项目，而且只有那么几个人，所以我们放弃了使用svn等管理工具，因为svn等工具在一定程度上减少了成员之间的沟通，而在如此小规模的情况下svn势必不是件好东西。还有很重要的一点就是队友，一个原则: 如果给你的队友一个你能在5分钟完成的任务而他在三天之后还在拖，OK，那么果断放弃这个队友。对，放弃，我们可以允许一个团队中有人搭车，但是不要把任务分给一个从内心抵触开发的人。

 

敏捷：什么叫敏捷，我说不上来，因为我不权威。前面我有总结过失败的项目，那些都是一些让人头大的大项目，而这次我们采用了敏捷的增量开发模型，项目第一次讨论的时候我就坚持不对项目的全部功能做更多的讨论，“只做最简单的功能”。这个不是意味着其他重要的功能不做了，而是增量开发，我们从第一个下午就已经有了一个基本有模有样的系统了，第二天就有一个可以正常运行的系统，后面的部分，因为前面的struct tile等框架很完善，所以能很快的加入功能，记得，从第二天开始，我们两个人的开发，几乎每个早晨或者中午或者下午我们都有两道三个功能开发出来，所以开发的积极性特别的高，我们每次吃饭之前都讨论一下中午要做那两个功能，你做哪个我做哪个，效果特快，每次吃饭之前我们的成果都可以合起来，基本就迭代测试。效果非常的好。

 

文档：关于文档我想说的是，以前的那些大工程都是写上10M的文档，花大部分的时间去搞需求，可是真正做起来，没有一个文档能用的上的，我跟一个实习的老师探讨过敏捷开发文档的事情，而现在的结论是： 不是为了文档，而是为了工程。敏捷不是不写文档，我们在开发的时候只花了个visio图，图画的也很简陋，没有遵循什么规范，我们只是为了理清到底有几个action，有几个form，哪个action需要哪个form提交什么样的数据。酱紫我们的所有文档就完了，这个visio图没有标准确成为我们开始配置structs.conf的一个重要参考。

 

调试：敏捷的概念中有增量开发，循序渐进，每一时刻都有一个完整的系统在你的面前，我们要做的便是不断的添加新功能，不断测试调试。有时候调试是令人纠结的，但是，正是调试才是一个合格的软贱攻城湿最重要的品德，好的攻城湿能非常快速的定位错误，往往能力是常人的好几倍。

 

Review： 每一个探讨过的功能都让彼此做review，有条件的话最好所有的代码在相关的人员里边也要做review， review不仅仅是看哪儿错了，而且能使代码格式能最大程度的保持一致性，而且，很重要的一点，相互学习，相信一句话，每个人都有你值得学习的地方。