刚接触敏捷时，感觉挺好，当实际执行时，却是半敏捷半传统的路数，毕竟要实行真正的敏捷需要超强的队员，对口的研发环境，以及普遍的认可度。敏捷在国内已推行多年，实施起来难度还是很大，应该说很多团队都不算是真正的敏捷。既然不算，我给X团队写的一篇方案，自当书面文档，当然据我所知也没有实行推动起来，毕竟每个团队都有自己的现状。
内容大致如下，也算是对我之前的两个团队敏捷实施的总结吧，虽说实施效果有时候也走样，毕竟也是个经历。
大前提 : 要求全员整体参与产品的研发过程，从需求，设计，到开发测试等等。
准备阶段
分析原始需求，整理大体流程，画原型图/为提高全员对需求的理解程度，可全员参与，初步分析出数据结构，搭建开发环境等开发过程中所必备的技能，各岗位角色安排到位。确定整体迭代过程，及第一迭代的内容。测试可确定测试计划。
每日站会，内容只涉及昨日工作内容，今天准备做什么，目前有什么问题。切忌深入讨论细节问题，占用大家大量时间。
看板，工作完成后，主动更新看板，将工作进度时刻暴露在外，大家心中有数，一旦工作进度无法保证，可协调其他队员帮助完成或移至下迭代开发。
开发习惯的问题，开发节奏较快，要求大家尽量保持良好的习惯，好的注释，变量命名，日志输出，面对面交流等等，一切提高效率的做法都应该被提倡。
迭代按两周一个周期。
迭代
迭代首日，开迭代计划会，人员，全员参与，包括开发，测试，产品，业务等相关干系人。内容，由产品业务人员讲解本迭代内容，全员讨论需求存在的问题，记录有歧义内容。全员评估本迭代需求任务复杂度，确定工作量。基于现有情况可确定本迭代能否完成。各开发人员认领需求，并复述需求内容，确保与产品要求一致，开发拆解需求为具体任务，并确定工作量。会后录入系统中，统一管理。测试人员可离场编写本迭代测试案例。
周二至下周三周四，是实质开发阶段，开发前不着急编码，需要有一定的设计识别过程，较复杂的情况，需要评审过后再开工。
开发完成做好单元测试，更新任务状态并口头通知测试、产品人员测试。验证功能。
测试在此期间编写完案例，开展测试，并与产品业务讨论下迭代需求内容。
中间可穿插半天讲解下迭代需求，提前熟悉内容。
周三周四可部署稳定版本，全面测试，并修复bug。若上迭代遗留bug影响关键流程的，马上解决，其余可按时间安排修复。
周五，上午迭代验收会，开发确保全部功能开发完成，不要遗漏功能。下午迭代回顾会，回顾本迭代流程中存在的问题及可改进的地方，再下迭代中完善。
迭代过程中若需求有变动，工作量不大的可动。大的需要评估，移到下迭代或某个周期内完成。
集成测试，全部迭代结束后，安排一段时间做系统性测试，测试，产品，用户均可参与进来。
投产演练，为确保上线顺利，上线周期及一旦上线失败后的还原措施，都需要在此阶段不断尝试，以防在正式投产时出现意外。
敏捷实施具体某一个迭代，还是传统瀑布开发，从需求分析，概要设计，再到开发测试。两种过程相辅相成，切不可割裂开来。
