对项目的理解



又有好久没有更新博客了，虽然我一直告诫自己，不管有多忙都要找点时间来写博客。
最近主要的精力都投入到项目中，我就说说自己的一些想法吧。

1. 项目的前期是最忙的，投入最大
    当拿到一个需求之后，必须快速做出响应：理解作者意图，澄清不明确点，需求可行性分析，预期增益分析。
    需求分析需要站在系统角度来思考问题，必须要考虑到：对原有软件架构的影响，对原有业务逻辑的影响，内存布局影响，会不会引发性能问题......需求分析过程中，最好做一个原型出来进行验证。
    还有一些人的因素：工作量评估，人力资源评估。
    总之项目前期比纯粹的编码阶段要烧脑多了，对需求和方案分析的越透彻，就会在项目的初期排除一些Bug.
  
2. Workshop  
    每周4下午我们都会用一下午的时间做workshop，效果非常好。
    每个人依次把自己的总结/想法在会议中说出来，然后大家讨论，如果没有解决的问题会后再咨询外部专家。
    每次讨论之后都会发现对项目的理解更深一层，由于每个人都积极参与，所以整个团队也得到了提升。
    俗话说：三个臭皮匠赛过诸葛亮，如果一个团队所有成员都能积极投入，项目风险就会小很多。  
     
3. 文档  
    码农一般是非常抵触文档的。实际上文档是一个梳理思路非常好的方式，在文档中把自己的想法书写出来，配上流程图、状态图、时序图，即方便自己的积累又便于别人的理解。
    文档越详尽、越清晰越好，最好的文档就是一个新人也能根据文档快速的理解方案并写出代码。
  
4. 敏捷开发
    就不详述了，坚持敏捷流程，事实证明非常高效。
  
5. 其它
    投入，如果你真的想去把一个项目做好，晚上做梦都在想。
    建立全局观，不要急于写代码，前期好的设计胜过盲目的编码。
    项目成败是一个团队共同努力的结果，任务均衡分配，理解总体架构，掌控每个人的进度就可以了。