《敏捷迭代开发管理者指南》读书笔记

这是一本关于迭代开发的各个流派的一个总结式读本. 可以让你在最短的时间内了解各个敏捷开发方式是如何实现迭代开发的.

==============我是读书笔记的分割线===================
拒绝固定需求文档的理由:
客户或用户不能明确知道他们要什么
他们很难陈述他们的需求和知识
他们想要的许多细节只能在开发过程中逐步展现
细节对于他们来说过于复杂
当他们看到产品的开发, 会改变他们的初衷
外部的(竞争)压力导致需求的变更或者增强

敏捷需求:从我们的已经产生的高级需求列表中, 挑选出20%最具有架构意义, 最具有风险以及最具有价值的条目

由于存在比较高的变化率, 这成为敏捷与迭代开发的动机的核心

短小的迭代导致对完成, 能力与结束有一种快捷和反复的感觉. 这些心理学因素对于个体成就感和构建团队信心至关重要, 这同样也构建了团队中客户信心--他们看到早期的可视化的过程, 朝着他们关心的方向发展.

研究表明在提高生产率方面, 时间箱带来好处的一个原因就是专注.

心理学认为结束日期为三周之后, 比在三个月之后设立的可视里程碑, 专注的效果更好

通过在为期两周的时间箱迭代, 团队可承担可管理的复杂度, 做他们力所能及的工作, 同时也可以在可能突破最后期限内的情形下, 他们有能力缩小工作范围.

瀑布型的方法只适应于非常直接, 缺少变化的项目.

瀑布模型的开发方式, 将高风险和困难的元素推迟到项目最后, 而对于迭代开发方式来说, 则是通过风险驱动的迭代, 使最困难和最具风险的元素尽早地出现并解决.

scrum的一个关键理念是强调经验型过程, 而不是规定性的过程.

系统开发有着非常巨大的不确定性和复杂性. 以至于它必须通过经验型的过程控制模式来管理.

晨会的第三个问题: 是什么阻碍了目标的实现?

增加的两个问题:
有没有任务添加到Sprint待办事宜中?
相对于团队中的其他成员, 你是否学到了一些东西或者做出了一些新的决定(技术, 需求...)

晨会最好在一块白板前召开, 白板用于开会的记录报告的所有任务和障碍

scrum的价值观:
承诺: 团队承诺实现规定的迭代目标
专注: 团队需要排除干扰, 专注于规定的迭代任务
公开: 公开产品待办事宜, 使工作以及优先级都可以被看到
尊重: 强调整个团队的责任, 而不是寻找替罪羊
勇气: 管理者应该有勇气制定计划并进行相应的指导.

XP
xp的独到之处在于, 除了代码和测试, 它不需要其他详细工件, 但也不排斥其他工件

xp不是黑客式的边写边改, 而是摒弃了大部分的文档开销, 更强调代码生产力和口头沟通.

极限编程中的"极限"表示的是要将软件开发中的优点演绎到极致, 也就是说如果是好的实践, 就应该最大限度的发挥它们的作用.

测试是好的实践, 于是所有代码编写单元测试
代码审查是好的实践, 那么实时的进行代码审查, 并且在整个开发过程中通过结对来进行代码审查.
对所有开发人员的代码进行频繁的集成是一项好的实践, 那么用一台专门的机器, 进行自动, 7*24不停的进行持续集成.
短期迭代是好的实践...
客户更多的参与是好的实践...
沟通是好的实践...

XP鼓励用最简单的方式记录需求

XP故事不是用例或者场景, 它们通常描述特征

XP中口头沟通是首选, 故事卡的目的不在于细化故事, 而是略记一个大概, 作为其他文档的参考, 一般情况下将卡片看成沟通提示.

避免文档可以通过现场客户来进行弥补, 但并不反对文档, 只是将其看成一种开销, 希望通过更多的时间进行编程

编写测试的实践将影响构思, 澄清和简化设计.

TDD使开发者具有成就感: 我编写测试, 然后我取得测试的成功, 这种满足感驱使着实践.

当迭代无法在时间箱内完成, 延长周期是一种错误的认识, 更好的做法是取消这次迭代, 或者简化一些目标, 并分析这次失败的原因是什么.