敏捷精灵日记12

[敏捷精灵日记]

• 拥抱变化（Embrace the change）

无论是多么明智，多么正确的决定，也有可能在日后发生改 变。因此，团队要能够充分理解我们的利益干系人（Stakeholder）和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数“唯一不变 的是变化”。团队更要信任利益干系人（Stakeholder）做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风 险，实现团队最大化利益，理解这是适应市场变化的必然行为。而在接受变化的同时，我们应该积极的向利益干系人（Stakeholder）和客户代表反映实 现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定的设计方案 可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会人员也将更加适应，真正拥抱变化。

• 对一个项目开发来说，release (发布）拥抱变化。对于一个sprint/iteration，要拒绝变化。sprint计划前，product backlog都可以变化。

• ScrumMaster需要对团队作出承诺，让团队感受到有人全心全意关注其工作，在任何情况下提供保护和援助。
• ScrumMaster使团队在Sprint过程中免受干预
• 教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标
• 在影响Scrum正常实施的众多因素中，在sprint过程中加入新需求，大部分人都很难很难抵御这样的诱惑，是scrum的第一杀手。
• 在一个Sprint执行过程中，如果遇到一些问题导致Sprint的原始目标不能实现，此时需要及时地 调整目标。如果不愿意调整目标，任意延长sprint的时间，就严格违反了Sprint的Time-Box特性，以后大家再遇到问题时，会自然而然的想再 延长Sprint，那么Sprint快跑的意义也就不存在了。
• 从另外一个角度讲，如果急于看到结果而压缩sprint的时间，可能得到一定的效果，但总体上会消耗的更多的资源，让团队疲惫不堪，造成生产力低下。