敏捷开发

一、敏捷开发理解

敏捷开发，大致从如下两个方面理解：

• 敏捷。即整个项目迭代中遵循快的节奏，采用“小步快跑”的方式进行项目管理
• 开发。敏捷开发的侧重点依然是[开发]，即快速形成产品。

敏捷开发宣言：

个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。
ps: 敏捷开发宣言的深层含义： 去文档化，去流程化，高效的沟通

二、敏捷开发实践

• 大项目敏捷。将大项目拆分成几个小型需求，各自跟进进度。
  
• 每天站立会。每个人花30s~1min 同步昨天做了什么工作，今天要做什么工作，是否需要其他人帮助解决某个问题。这样差不多10人的团队也不会超过10-15分钟

ps:站会迟到时，给迟到加一点处罚，让迟到者意识到自己耽误了大家的时间

• 结对编程。两个技术实现上耦合性很大的两位开发人员，可以结对编程，随时交流各自的进度、有问题时及时[纠正]；也可以一位新人+一位有经验的[老人] 一起结对编程，可以促进新人的成长和代码质量。
  
• 总结会议。每次迭代后，团队成员有个交流会，总结各自的经验和教训。

ps：团队成员也可以一起进行一些体育锻炼

• 大型的新项目，当前端页面不稳定，后端实现接口/功能不稳定时，切忌过度自动化。如果项目一开始就实现自动化，后期测试中，很可能为[自动化]所累，自动化不仅因为代码不稳定需要大量的维护成本，而且发现不了深层次的问题。ps:目前大型新项目中，不会依赖甚至不会设计自动化用例，这样反而有了更多时间才思考测试用例的深度和广度；等项目上线后，将测试用例自动化就好了。
• 项目排期时，切忌开发负责人根据自己的[水平]来评估团队其他开发人员的预期开发时间，对于测试也一样。
• 详细前期，约定好最为高效的沟通方式。一般地，面对面交流>电话沟通>及时消息>邮件。敏捷团队中的成员，最好能坐在一起进行[封闭式]开发，如果条件做不到，那么需要事先约定好类似需求需要产品人员做确认，需求变更等等[紧急]问题时，团队成员均接受的方式。
• 测试人员尽可能早进入测试。抱着[有问题早发现]的心态，测试人员应该尽早去测试开发的代码。如果可以，建议开发人员可以按模块开发完成的先后顺序，分别提测，当然了，提测的模块必须具有可测性。
• 敏捷开发的适当文档化。项目中的重要文档，如需求文档、接口文档、测试用例等，仍然需要形成文档，以便于项目的长期性维护。项目不断迭代中，肯定有人员的流失，新同学的加入，和其他团队的合作，此时文档可以让新同学尽快融入项目，完成项目交接，让其他团队成员利用文档更好合作。有句话说敏捷跟文档是对立的，其实更好的理解是敏捷中可以适当简化文档，但决不可没有文档。
• 高效应对需求变化。每当需求变化时，如何让团队成员快速达到对新需求的一致理解，并付诸行动，才是敏捷开发的重点。

参考：

https://www.qcloud.com/community/article/766331?fromSource=gwzcw.93748.93748.93748

http://blog.csdn.net/caowenbin/article/details/8457510

http://blog.csdn.net/alvanchen/article/details/5749872

http://blog.csdn.net/ysjian_pingcx/article/details/51302548

https://www.zhihu.com/question/19645396