文档首页 > > 理论实践> 持续规划与设计>

拥抱变化,但不是随意变化

拥抱变化,但不是随意变化

分享
更新时间:2021/02/27 GMT+08:00

拥抱变化

敏捷宣言说,响应变化(Embrace the change)高于遵循计划;敏捷原则说,欢迎对需求提出变更,即使在项目开发后期;要善于利用需求变更,帮助客户获得竞争优势。

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

敏捷宣言还说:个体和互动高于流程和工具;客户合作高于合同谈判。

敏捷团队Sprint的规则,是事先与PO约定好的,等同于合约。如果只是固守规则,拿合约与PO谈判,坚持拒绝Sprint内的变更,于情于理都说得过去,却容易将PO推到团队的对立面。这是很多理工男容易犯的毛病。

保持与客户、包括内部客户的互动与沟通,而不是僵化地利用流程规则,一味地拒绝变化。文中的沟通过程是一个经典案例,开诚布公,以拥抱变化的态度,站在PO的角度,摆事实讲道理,说明两种方案的优势利弊,最终将决策权交给PO。

如何应对在Sprint中插入客户非常重视的需求?

第一个办法是要等结束当前这个Sprint后,在下一个Sprint里面首先做的这个需求。第二个办法是立刻结束当前的Sprint,重新计划下一个Sprint,然后马上开工,把需要修改的这个功能放在首位去做。但第二个办法会带来很多潜在的问题,例如,一旦结束当前的Sprint,那我们在这个Sprint中已经做的一些工作就半途而废了,白白浪费了很多时间;而更重要的是,大家的士气会受到打击,工作效率肯定会受到影响!而这是无法估算的。

拥抱变化的要点

  1. 对一个项目开发来说,一定要拥抱外部变化。但对一个Sprint/冲刺,却要有条件的拥抱变化,只为更好地提高效率。
  2. Scrum Master需要对团队做出承诺,让团队感受到有人全心全意关注其工作,在任何情况下提供保护和援助,使团队在Sprint过程中免受打扰。
  3. Product Owner要思考如何实现投资回报最大化,以及如何利用Scrum达成目标,不要轻易打破团队开发节奏。
  4. 在影响Scrum正常实施的众多因素中,在Sprint过程中加入新需求,是Scrum的第一杀手。
  5. 在一个Sprint执行过程中,如果遇到一些问题导致Sprint的原始目标不能实现,此时需要及时地调整目标。如果不愿意调整目标,任意延长Sprint的时间,就违反了Sprint的Time-Box特性,那么,Sprint冲刺的意义也就不存在了。
  6. 反之,如果急于看到结果而压缩Sprint的时间,可能得到一定的效果,但总体上会消耗更多的资源,让团队疲惫不堪,生产力低下。

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

分享:

    相关文档

    相关产品