`
nathan09
  • 浏览: 144929 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
文章分类
社区版块
存档分类
最新评论

【读书笔记】AgilePPP——敏捷宣言及12条原则

 
阅读更多

人的力量

•过程和技术对于项目的结果只有次要的影响,首要的影响是人。
•如果项目要取得成功,必须构建起具有合作精神、自组织的团队。
•凝聚在一起的软件团队是最强大的软件开发力量。

敏捷宣言

•人和交互 > 过程和工具
•可以工作的软件> 面面俱到的文档
•客户合作 > 合同谈判
•随时应对变化> 遵循计划

人和交互 >过程和工具

•沟通能力比技术能力更重要
•从小、免费工具入手,直到不能胜任再引入大工具
•团队构建比环境的构建更重要

可以工作的软件> 面面俱到的文档

•没有文档的软件是灾难,但过多的文档比过少的文档更糟。
•团队应维护一份系统原理和结构方面的文档,短小且主题突出,一二十页,仅论述系统最高层结构和概括的设计原理。
•对新成员来说,最好的文档是代码和团队。
•直到迫切需要且意义重大时才编制文档。

客户合作 > 合同谈判

•成功的项目需要定期且频繁的客户反馈。
•最好的合同是那些为开发团队和客户的协同工作方式提供指导的合同,而不是试图去规定项目范围的细节和固定成本下的进度。
•表现为一种和谐、淡定。而不是浮躁。在我看来,任何进度、成本的估算,都包含浮躁在里面。

随时应对变化> 遵循计划

•确保计划灵活,并适应商务和技术的变化
•计划不能考虑得太远,因为随时会变。
•较好的计划策略:为下周做详细计划,为下3个月做粗略计划,再以后就做极简略计划。

12条原则

•1.尽早、持续的交付有价值的、客户满意的软件。
–初期交付的功能越少,最终质量最高
–交付的越频繁,最终的质量越高
–在项目刚开始几周内就交付一个具有基本功能的产品
•2.接受变化
–不惧怕变化
–努力保持软件灵活性来应对变化
–通过原则、模式、实践来保证软件足够灵活
•3.经常交付可工作的软件,时间间隔越短越好。
•4.在整个项目周期,业务人员和技术人员必须朝夕工作在一起。
•5.围绕人构建项目,提供环境和支持,信任他们能完成工作(以人为本)
•6.最高效的沟通是面对面交谈。
•7.可以工作的软件是进度的主要度量标准。
–度量标准不是所处的开发阶段、已经编写的文档总量、代码的数量
•8.提倡可持续开发,保持稳定的开发速度
–不允许自己过于疲惫
–不会借用明天的精力来在今天完成多一点工作
•9.不断追求卓越技术和良好设计
–保持软件干净、整洁
–编写高质量代码
•10.简单——尽量减少工作量
–不构建华而不实的系统
–采用和目标一致的最简单的方法
–不看重对明天将出现的问题的预测
–不会对将出现的问题做过早的防卫
•11.自我组织的团队
–任务是分配给整个团队的,而不是某个人,由团队确定解决问题的最好方法
–团队成员共同解决项目中所有问题,每个成员都具有项目中所有方面的参与权
–不存在某个人对架构、需求、测试负责的情况,整个团队共同承担这些职责。
•12.每隔一定时间,团队都要总结如何更有效率,然后做出相应的调整。

常见做法

•把Scrum和XP结合起来,使用Scrum实践来管理多个使用XP实践的团队


分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics