敏捷学习笔记

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

发表评论


注意 - 你可以用以下 HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>