1. 理念篇 敏捷的核心思想还是打破原来瀑布式开发模式中，按部就班的开发流程。简化流程，简化管理，简化规则。一切以交付为准。
2. 首先需要改变管理者和开发的思维方式。以精益，敏捷的理念持续改进，敏捷是一个持续集成的过程，在多个迭代中，归纳总结在本迭代中出现的问题，及时改进。
3. 敏捷的目标管理：
目标分解为1-2天任务
主动认领，主动负责，自管理
分项技术经验，共同承担风险
主动协作
4. 治大国若煮小鲜，管理的三条原则，管理必须简单且及时、流程必须简单且被执行、规则必须简单且被执行。
5. 一个优秀软件的目标：交付最好的系统，而非最复杂的系统。
根据对2W多款的软件调查，从未被客户使用的软件特性达到45%，很少使用的特性有17%。这很能说明目前大多数的软件的功能开发是不合理的，甚至是存在严重的性能浪费，所以在同客服的沟通很重要。
当我们碰到质量、进度、资源冲突的时候，能改变的只有项目的范围，要敢于摸客户的底牌。
提供客户最大质量的特性，而不是最大的特性。
一定要严厉防止过度开发。
6. 需要尽早的，持续交付有价值的软件使客户满意。即及早上线试用版，并反馈客户的最新需求。
7. 建立自动化测试方案
8. 管理者职责：从原来的管理式转变了辅助式。
建立秩序、控制范围、能力布局、资源协调、关键决策、重大问题解决。
9. 建立全面的培训体系
10. 出现问题，通过面对面的沟通方式，企业管理过去式沟通、现在是沟通、未来还是沟通。面对面沟通时三大要素影响力的比率是：文字7%，声音38%，肢体语言55%。
1. 测试人员是软件健康程度信息的提供者，不是质量保证者的想法，构建二级安全网，将问题阻拦在开发阶段。
12. 及时回溯。在一个迭代完成后，回溯在本迭代中出现的问题。
12.1 数据展现：本版本开发的一些数据，如story的完成程度，数据、图标
12.2 问题反馈：如每个strotyd的完成程度，出现的问题。归纳出得票最多的几个问题
12.3 头脑风暴：帮助团队整理思路，从全局看问题，权限团队可以承受的方案。聚焦TOP5问题，作为持续改进的方向。
12.4 快速闭环：增强整体团队的信心
实践篇：
13. 短期迭代：控制好每个迭代的进度。可通过project等工具。
14. 及时重构：随着代码的增长，重构的难度会越来越大，要及时偿还在迭代中由于各种原因导致的技术债务。
15. 建立良好的架构：架构解耦，在前几个迭代中实现和验证架构，尽早稳定架构。深淘滩，低做堰。
16. 建立每日构建失败体系
17. 提交代码前必须做本地构建
18. 每次发布的必须都是可以工作的软件，都是目标交付件的组成部分，都可以进行showcase。
19. 敏捷在工程实现上要求更严格，通过短周期迭代、结对编程、TDD、持续集成、每日站会、客户验收等反馈手段使问题尽早暴露。
20. 源代码也是设计 代码应该具备自解释能力，能够清晰的表达实现思路
0 条评论。