读《学习敏捷构建高效团队》笔记2

第3章 敏捷原则

如果我问人们想要什么，他们肯定会说想要更快的马（而不是汽车）。   --亨利 · 福特

 

3.1　敏捷软件开发的12条原则

1. 最优先要做的是尽早、持续地交付有价值的软件，让客户满意。

2. 欣然面对需求变化，即使是在开发后期。敏捷过程利用变化为客户维持竞争优势。

3. 频繁地交付可工作的软件，从数周到数月，交付周期越短越好。

4. 在团队内外，面对面交谈是最有效、也是最高效的沟通方式。

5. 在整个项目过程中，业务人员和开发人员必须每天都在一起工作。

6. 以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好。

7. 可工作的软件是衡量进度的首要标准。

8. 敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够共同、长期维持其步调，稳定向前。

9. 坚持不懈地追求技术卓越和良好的设计，以此增强敏捷的能力。

10. 简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。

11. 最好的架构、需求和设计来自自组织的团队。

12. 团队定期反思如何提升效率，并依此调整自己的行为。

 

3.1客户总是对的吗

“按我现在说的做，而不是按我之前说的做”

大家明白一个事实：一年半前需要的软件并不是现在需要的软件。

有一些变数是在项目初期就可以发现的，还有很多变化在项目开始的时候是不可能就见到的。为了考虑到这些变化，团队应当在项目中的很多时间点快速的改变自己的方向。“预先指定大计划”的瀑布式开发方法限制了团队响应这些变化的灵活性。

 

3.3交付项目

如果团队能将交付价值动作首要目标，将变化看作是项目的好事，并且频繁交付软件，那么这个团队与客户就可以一起工作，在开发的过程中及时调整。团队开发出来的软件不一定与刚开始计划的一样，但这是好事情，因为最终开发出来的软件就是客户最需要的软件。

欣然面对需求变化，即使是在开发后期。敏捷过程利用变化为客户维持竞争优势。很多成功的敏捷实践者初识这条原则就遇到了很多困难。欣然面对变化说起来简单，但是在项目热火朝天的进行的时候，如果团队要处理需要大量工作的变化，开发人员可能会有情绪，特别是在老板不顾及工作量，要求不改变截止时间的情况下。这个坎可能很难过，特别是在团队因为项目延期而遭到抱怨的情况下。但是跨过了这个坎，收获也很大，因为欣然面对需求变化是敏捷工具箱中最有力的工具之一。

欣然面对需求变化的第一步是尝试从客户的角度看问题。

频繁地交付可工作的软件，从数周到数月，交付周期越短越好。欣然接受变化的同时不引入混乱的关键，在于频繁发布可工作的软件。团队通过迭代将项目分割至定期的截止时间。在每一轮迭代中，团队都要发布可工作的软件。在每一轮迭代结束的时候，团队都有一个可以展示给客户的演示，还有一个回顾会议来回顾本轮迭代的过程以及探讨在本轮迭代中吸取的教训。

 

要点回顾：

• 敏捷开发宣言随附的 12 条原则让敏捷实践者对实践和方法有了具体的方向和认识。

• 敏捷团队在项目中尽早地获得客户反馈，并且持续发布根据反馈意见改进的软件，从而让客户满意（原则 1）。

• 敏捷团队把变化看作是项目中正面且健康的发展过程，从而拥抱变化（原则 2）。

• 通过设置时间范围的迭代来频繁交付可工作的软件，敏捷团队不断地调整项目，从而给客户带来最大价值（原则 3）。

 

3.4沟通和合作

现在回到之前各个团队纠结的问题：到底应该写多少文档？对于敏捷团队来说，答案是够项目开发用就行。具体要写多少文档取决于团队本身情况。

在团队内外，面对面交谈是最有效、也是最高效的沟通方式。敏捷实践者明白，文档只不过是另外一种沟通的形式。

在整个项目过程中，业务人员和开发人员必须每天都在一起工作。程序员需要了解软件要解决的业务问题。他们了解的方式就是与业务人员交谈，观察他们工作，分析他们的产出。需要这些信息的程序员恨不得每一个业务人员都可以全天候的解答问题。他们等待解答的时间越长，项目进展就越慢。最有效的方法是让他们在项目完整周期内每天坐在一起工作。

 

要点回顾：

• 过于详尽的文档会增加需求含糊以及团队成员之间误解和沟通不畅的风险。

• 敏捷团队最有效的沟通方式是面对面交谈，并且只依赖项目所需的最少文档（原则 4）。

• 开发人员每天与业务用户一起工作，这样他们可以交付最大的价值（原则 5）。

• 敏捷团队中的每一位成员都对项目有责任感，并且为项目的成功与否负责（原则 6）。

 

3.5项目实施--推进项目

坚持不懈地追求技术卓越和良好的设计，以此增强敏捷的能力。不停的寻找设计和代码问题，一旦发现问题，立即将其修复。

 

要点回顾：

• 沟通项目进度最有效的方法就是把可工作的软件交付到用户手中（原则 7）

• 保持团队最高生产效率的方法就是：保持可持续的开发节奏，不要逞强，不要匆忙赶工，避免加班（原则 8）。

• 设计良好并很好实现的软件可以最快交付，因为这种软件修改起来很容易（原则 9）

 

3.6项目和团队的持续改进

最好的架构、需求和设计来自自组织的团队。

 

要点回顾：

• 敏捷团队避免开发不必要的特性以及过于复杂的软件，保证给出的解决方案尽可能简单（原则 10）。

• 自组织的团队对项目的所有方面都负有共同的责任：从产品构思到项目管理到项目的设计和实现（原则 11）。

• 敏捷团队在每一轮迭代结束的时候和项目结束的时候会花时间总结过去，讨论总结经验，提高开发软件的能力（原则 12）。

 

现在就可以做的事

1. 如果你现在正在开发一个项目，那么在开始编写代码之前首先与团队坐在一起，花 15分钟讨论一下你们正在开发的特性。你能不能发现对于同一项特性的分歧？

2. 列出你现在正在开发的特性。尝试通过价值和开发难度的维度组织这些特性。

3. 花几分钟列出你和你的团队会创建和使用的所有文档。看看能不能找出一些团队开发代码实际上并不需要的文档？

4. 下一次加班到很晚的时候，思考一下加班的原因是什么。能不能想出一些做法，让你和你的团队避免加班？截止时间是不是太勉强了？是不是在最后一刻加进了额外的工作？

5. 首先要明白加班是有问题的，然后花时间去了解导致加班的原因是什么，这是解决问题的第一个步骤。

 

教练技巧

1. 帮助团队意识到超长时间的工作并不能带来更多的代码。实际上这样开发的代码量会更少，而且质量也会受影响。

2.  与团队成员单独坐在一起讨论工作。哪些事情激励了成员？哪些事情让他们感到沮丧？他们作出决策的依据是什么？

3. 让每一位团队成员选出对自已影响最大的三条敏捷原则，既可以是正面影响也可以是负面影响。人们会很惊讶地发现在团队中的其他同事选了不同的原则。这有助于帮助大家找到共同点。

4. 以大家共有的原则作为起点，找到最适合团队思维方式的一组实践。

 

读《学习敏捷构建高效团队》笔记1