个人对软件敏捷开发的理解

　　5月12 号，这一天是汶川大地震的日子！也是我到公司报道的第一天！转眼见：到公司已经快有一年了。。时间过的真是快！

 

　　自从来到公司的第一天，就开始参与项目的会议，首先是需求分析，然后就是做临时页面，写用例等。。还记得当天下午，我到老总的办公室开会，正在听大家讨论需求的问题，突然感觉办公楼一震一震的，还好，不是太强烈，只是让人能感觉的到的那种振动！

 

　　工作这段时间以来，我主要负责产品前台的开发和维护工作（前台java,后台oracle）。我门项目组不大,一共有５个人，其中３个做前台java的开发，２个做后台数据库的开发工作。就应为我们人少！所以走的是敏捷开发的道路！公司主要是自主研发产品的。所以是先开发在卖，然后不断的升级.所以在开发的时候和客户交流的少！主要是内部协调！

 

　　首先：敏捷开发的团队我认为人就不应该多！一般５～６个就够了 ，多了反而会不易管理，造成资源的浪费！

 

　　第二：理解项目的需求，把项目分为几个不同的阶段来做，即分为多次迭代 ，明确每个迭代的目标，在开始一个迭代之前，首先先做评估，包括时间的评估，技术的评估，弄清楚每个功能点大致需要多少时间，哪一些是难点，哪一些是容易的，每个功能点要花多长时间（技术准备的时间，开发的时间，测试的时间）

 

　　第三：功能的用例问题， 在在需求分析的时候,要理清楚每个功能点的大致流程，就是常说的时序图和用来图， 这两个图不一定要画，但是一定要弄明白 ，记在心里！避免业务流程出错！

 

　　第四：先易后难 ，在划分迭代的时候，把简单容易实现的功能放到前面，把比较困难，有技术难度或其他难度的功能放到后面，作为下个迭代的重点。

 

　　第五：团队成员之间应该互相帮助 ，假如一个技术难点或业务的逻辑不容易想清楚的时候，一个人的思考时间是30分钟，如果没有想到解决问题的办法，那么就应该主动和同事沟通，不应该一个人在那苦想，浪费时间也不一定想的出来好办法，还耽误了项目的进度!

 

      第六：团队成员开发的时候要注意代码的质量！ 整个项目应该遵循统一的的命名规范！写出来的代码要考虑逻辑的健全性！可维护性！尽量避免以后代码在测试中出现很多的逻辑或技术上的漏洞！写出来的代码是给别人看的！要让别人容易看懂！这样别人帮你解决问题也能减少理解你的代码的时间。

 

　　第七：在项目稍微空闲的时段，对自己的代码进行review，重新审核一遍 ，能优化的就优化，能重用的就重用，避免重复写代码，不段改进代码的质量，这个时候可以参考设计模式来对自己的代码调证。我觉得设计模式应该是在不断的该进自己的代码中学习，而不是买本书，造着书上的代码写！这样不能真正体会到设计模式的妙处！

 

      第八：每日起立会议 ！就是在每天早上的时候，花5到10分钟对前一天的工作进行总结，并且计划今天的工作任务。确保今天的目标目确！

 

      第九：每周或每半个月开一次项目研讨会 。总结经验和教训！优化开发流程。

 

　好了！先写到这把！以后有新的体会在补上去。。。。。。。。

 

 

 

 

第四点要注意。敏捷要求的是交付最重要、最具有价值的功能，而不是最简单的功能。如果一个项目周边很简单，但是核心很难。你把周边全做了，然后整合不到一起去。最后还是没价值。敏捷要求是每次迭代后，项目理论上已经是一个可以卖的产品了（虽然功能还不全，但是最重要的已经有了）。
没看到单元测试的内容。重构不搞单元测试，弄不好要搞死人的。
第八缺少遇到的问题。今天的事情今天搞。明天的目标明天早上再定。
第九最好在一个迭代完成时做。还有，我没有看到你迭代周期。

第四点要注意。敏捷要求的是交付最重要、最具有价值的功能，而不是最简单的功能。如果一个项目周边很简单，但是核心很难。你把周边全做了，然后整合不到一起去。最后还是没价值。敏捷要求是每次迭代后，项目理论上已经是一个可以卖的产品了（虽然功能还不全，但是最重要的已经有了）。

说的有道理，的确是忽略了这一点！