这是我的方法论，在所谓敏捷之前，先教会团队如何走路，如果按照一个正常的软件开发流程来做事。
=======================
1，开发过程中注意要遵守以下流程，没有任何例外。负责feature的开发人员应该从接手任务第一天开始，每天更新project status report。
开始阶段：风险评估，技术难点研究，通过邮件或者会议，确定需求分析；
设计阶段：研究设计文档，小组设计评审，具体任务分派，截止时间确认；
编码阶段有：Daily Project status report, 每日代码审查；
收尾阶段应该有：Group code review；需求文档校验；测试计划及结果；项目总结。
2，如果任务比较复杂，问题比较棘手，自己研究了半天时间没有很好的解决方案。请马上联系我或者咨询组里其他同事；如果组内同事也解决不了，再求助Onshore team。先发邮件说明问题，紧急任务马上搭建会议保证及时沟通。
3，项目流程方面，如果需要有例外情况，比如不写什么文档，不做测试不评审，请事先通知我或者项目负责人。
4，在开始阶段对最后整体实现效果有大致理解，可以预估技术难点所在，并且实现进行研究和求助。对于项目可能有的需求变化有一定的预估和计划。在项目开始阶段或者空闲阶段应该研究技术难点。
5，允许犯错，但是要确保同样错误不要再次出现，从问题中吸取经验教训。
6，每天的工作都应该有结果产出，代码或者是文档。学习应该有文档总结，项目应该有流程设计文档/代码/测试文档，项目进度有每日进度报告。每行代码在checkin之后的当天时间， 都应该有两个人review通过。
7，代码review原则：不要在下午三点半以后还checkin代码（可以留到第二天上午），如果有例外，应该通知reviewer留出审查时间。
代码应该直观易懂，不要额外解释，不用过多注释说明。代码格式应该符合English正常语法格式，或者遵照以前onshore同事代码样式。每行代码必须能解释清楚，根据哪个需求来的。对于Peer review和Group review中发现的问题，必须逐条回复（改或不修改），确保没有遗漏，Group review需要填写正式review结果文档。
8，在你写代码之前，确保自己已经：a）了解所使用技术的大致用法。b）读过这项技术的大体教程或者代码实例，可以用最简单的能体现设计意图的代码完成大部分功能点。c）以前没有遇到的新项目的设计方案，确保设计方案与我沟通过，由我负责技术决策。
请避免以下情况发生
1) 将就完成，马马虎虎，不求甚解。– 在写代码之前问问自己，真的清楚知道在为什么需求编写什么模块的代码么？
2) 需求不清楚，也不与onshore沟通澄清，在任务不清楚的时候就开始动手编码。
3) 没有设计讨论，自己觉得没有问题，直接开发。有问题，不做优先级和风险评估，先开发了再说。
4) 代码不是每天checkin，累积三五天；需要checkin的时候，一次加入大量代码修改。或者checkin以后不作代码评审。不注释，命名不规范，不关注静态分析或者调试中出现的异常log信息。
5) 代码写完了，就认为是项目完成了，没有设计评估没有文档没有测试。
6) 只有最后阶段才说明有问题，在开始时不考虑如何技术实现或者觉得不会有问题，不做风险评估。
7) “我觉得没问题，但是也没有检查代码和需求。”“代码为什么好用？不知道；出问题的root cause？不知道”“这段代码干什么用？别人就这么写，我不知道，没研究过”“这个技术上肯定实现不了，没法做”
