拾遗《梦断代码》（并Team Project简单分析）

　　读Inside Steve’s Brain后，内心里溢满的是对Jobs本人的无限崇敬，他光辉耀眼，带领跟随者冲破黑暗。而读《梦断代码》时，感觉这是一艘载着人类梦想的航船，有着强大的风帆和孔武的水手，但终是没能远航。最后搁浅在海滩上，给后来者无限的宽慰和警示。

　　我本人没有太多软件开发经历，但也十分懂得软件开发的艰辛和困难，所以在听到“为什么就是不能像造桥那样造软件”的呐喊时，来着灵魂深处的触动和震撼，宣泄了自己在过去软件开发过程里的所有委屈和无奈，做软件太难。

　　关于Chandler项目本身是否有决策失误，对于我这样的小人物不敢有过多的评论，这里拾遗了一些自己比较有感触的部分，结合眼下自己团队正在进行的Team Project做一下简单的分析。

　　规格说明，这在实现环节里显得非常重要，它将需求——软件开发者的客户提出的目标或愿景——翻译成指挥程序员的详细行军指令。而“根本没在规格说明里写出”这好像是每个遭遇阻碍的软件项目不可避免会遇到的问题。在我们的Team Project中，需求大多都是自己臆想的，只真正调查过2个用户（这显得相当的不足），而如何把调查的用户的需求转化成我们的开发指南，并细化为具体的步骤，再按责任分到dev的手中，显得极为重要，这也就真正体现了团队协作开发的能力。

　　我们的项目是一个时间驱动的软件开发过程，软件的开发周期是2个月。里程碑里的功能在规定时间里未能交付时，要考虑把他们推到下一个里程碑中，虽然会放弃掉部分特性，但至少还能维持一个完整的软件版本。如若是过于执着的企图继续未完特性，只会在规定里程碑里什么都做不出来，不能实现版本交付进而错过收集用户反馈。

　　文中讲到了敏捷软件开发宣言：

　　个体和交互　　胜于　　过程和工具

　　可工作的软件　　胜于　　面面俱到的文档

　　客户协作　　胜于　　合同谈判

　　响应请求　　胜于　　遵循计划

　　其实真正的开发过程，不断涌现的bug和各种不可控的变故会使得我们忘记有一套准则去更好的约束我们的行为，使得努力和付出变得更有意义，或者这篇文章《敏捷开发原则》应该在我们开发过程中定期进行研读。 

　　“这里躺着一个野心勃勃的开源项目。它曾立志超越Outlook，最后却无疾而终。许多程序员以心血养育它，惜乎全不见成效。它是温室中的花儿，有过绚烂的梦想，还未绽放即已枯萎。在那软件的花园中，还有多少会逐次凋零呢？”

　　看到这句话，一方面为其扼腕叹息，但Chandler或许留下了一片繁荣的开源生态系统，而我们之前决定做的“积分交换平台”，同样是一个美好的愿景，同样花费了很多精力去调查和思考（当然没有Chandler的宏大，也没有他们付出的心血更多），卡普尔养活了Chandler和OSAF长达6年，坚持了这么长时间，的确已经难能可贵了，而我们却在旦夕放弃了。

　　现在的项目也是大家在7个项目里公投选出来的，现在基本上了正轨，基本的功能得到了具体验证，现在正在开展我们自己主题的设计，我们现在只能估计一个大概的用户人群，乐观是上百。但要觉得我们简单的feature吸引不了用户，也无可厚非。在软件没有发布之前，谁知道呢，我们会专注把功能实现好，这才是吸引用户的东西。就好像当年Flickr刚刚出来时，不知道是不是有人笑它那简单的照片分享功能到底能吸引多少用户，但它做到了，我们希望我们也能做到。

　　大家又该笑笑了，没关系呀。希望，总是要用的，不然怎么在困难中前进呢。