【Scrum】敏捷软件开发——团队（6）

2023-02-15 本文已影响0人 NumLock

十五、做计划

逐步完善计划

逐渐完善计划有非常多的优势

1）它可以最大限度地减少时间上的投资

2）它允许在最佳时机做决策——我们应推迟做决定，直到有一天，每个人都对项目有了更深入的了解

3）它允许我们改变路径——变化是必然的

4）它可以帮助我们避免落入相信计划的陷阱

不要用加班来赶计划

加班是项目严重问题的一个征兆

极限编程的规则很简单——你不能连续加两周班

1、历经挫折后才会明白

加班对速率的提升只能持续一个星期，后面逐渐下降，直到第四个星期，已经出现严重下滑

2、达到目标

按照可持续步调工作可以完成更多，胜过高速冲刺然后再恢复的方式

1）以可持续步调工作可以使你保留一些能量供真正需要的时候使用

2）它给我们留出更多保持创造性的空间

3）不要再说我们的大脑每天六个小时后就枯竭了

4）它值得一试

3、如果不加班，怎么办

加班是一个流行的工具，因为它便宜、简单、偶尔有效

项目中充满热情的人越多，团队就越有可能每天都充满能量

PO是关键，PO需要传达一个引人注目的产品愿景，让开发这个产品的团队满腔热情的工作

定时的短休，番茄工作法，每半小时左右就需要休息，如果不休息，你就会累，会精神不集中，会容易犯错，变得急躁，并出现意外

如果可能，支持改变范围

PMI铁三角

作为向Scrum转型的一个部分，项目关键的干系人、开发人员以及产品负责人需要学会把改变范围作为第一选择

1、考虑其他选择

1）牺牲质量？

降低质量是短视的，快速前进的最好方式是在开发过程中保持系统的高质量

尝试牺牲质量会导致一个更长的计划

2）增加资源？

向一个延迟的项目中增加人手，只能使它更滞后，项目越后期，增加资源越没用

3）延长期限？

可以解决问题，但是大多数情况，从商业角度看非常困难

虽然更改最后期限对开发团队来说是一个不错的、易于实施的选择，但它并不总是可行的

但是一旦可行，直接选它

4）调整范围？

丢弃一些需求，PO会失望，但不是世界末日

需要说服PO明白，完美的预测是不现实的

从商业的角度看，调整范围往往比延长期限好接受

2、项目环境是关键

不建议总是把缩小范围作为首选，但它往往更可行

如果一个产品必备功能不能够按时交付，有必要考虑延期交付

区别对待估算和承诺

1、用正确的数据来做

好的估算，需要知道两件事：工作的规模、团队的能力

速率：每个Sprint会完成产品Backlog的一些事项，把这些事项的故事点或者理想人天的估算做一个简单的加和，就是速率

首先尽量多收集以往Sprint的速率数据，接下来，利用这些排列好的速率来找到一个范围，得到置信区间，使用这个置信区间来预测我们按照给定日期可以提供多少功能

2、从估算到承诺

团队速率的置信区间

我们可以承诺从最高和最低箭头中间的某个值，这是一个最现实、最准确的承诺

建议先从靠近最高慢慢接近低点

3、历史估算是承诺的基础

1）团队从来没一起工作过

最好的解决办法是在做出承诺前，运行至少一个Sprint，并计算速率

计算初始速率只是第一步，可以使用直觉，把它变成一个范围，或许上下幅度25%

也可以基于其他团队来计算偏差，但团队最好有历史数据

2）团队规模频繁变动

停止改变团队，团队稳定有巨大的好处