对项目的理解

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Since20140504/article/details/76047997


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

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

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页