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 条评论。