敏捷开发方法在设计管理中的应用002-一些概念澄清

Posted 2021-04-25 Time-cost 设计运营管理

我们最近一直在探讨将敏捷开发方法用于设计管理的可能性。
上一期我们介绍了一个室内设计团队，利用敏捷开发方法完成一次室内设计成果提交的过程。

后来有更多的团队加入到一起Scrum的活动中，甚至还有一个写作有关新冠病毒与城市规划论文的团队也跟我们一起Scrum，可见Scrum的管理框架适用范围是很宽广的。

我们发现大家对Scrum的方法，还是存在一些困惑，这一期，我们根据最近参与Scrum的设计师的反馈，澄清一些概念，以便将来大家能够更好地在设计工作中开启Scrum的管理框架。

01 团队

Scrum的团队必须是紧密协作的设计师。在软件开发领域，有个术语叫做 “布鲁克斯定律”。这个定律是1975年由弗雷德·布鲁克斯(Fred Brooks)在《人月神话》这本书提出，这本书对软件行业的项目管理产生了重要影响。简单地说，布鲁克斯定律认为：

“为一个延误的IT项目增加人员，将导致更严重的延误”。

有相关研究得出结论，紧密合作的团队最佳人数是7人以下。所以Scrum的开展，应该是在设计公司类似于“组”这个层级。

在冲刺的过程中，所有人都是全情投入的。这就意味着，同一个Scrum团队中，只能有一个冲刺在进行中。如果有的团队有两个冲刺同时开展，这其实意味着，这个团队需要拆分成两个。

02 冲刺成果

Scrum的正式名称是“迭代式增量开发”，在软件开发中，冲刺提交的成果就是可发布或是潜在可发布的一组功能——这些概念对设计师而言都太拗口，弄不清楚也不用太纠结。放到设计管理中，冲刺交付的成果就是一次设计成果汇总。这个成果汇总可以是：

• 提供给甲方的阶段性设计汇报。例如：第一次概念方案提交。

• 提供给其他专业的初始资料。例如：初步设计开始之前提交给结构和设备专业的资料图。

• 本专业的阶段性成果。例如，确定总图算量的成果汇总，包括总图，各单体标准层选型，指标计算表格等。

03 不可更改的要素

任何管理的目标都是需要按时保证质量完成某项任务。需要在确定的节点之前，那么冲刺中也不能全是变量，必须有要素要确定下来。
冲刺开始之前必须确定以下要素：

• 开始和结束的时间

• 需要完成的任务

这两组要素确定之后，才能开始冲刺，一旦冲刺开始，就不能再变更这两组要素。

从这个要求中我们能够推导出对冲刺划分的要求和标准：

• 冲刺过程中不能有外部意见参与。否则完成时间不可控。

• 需要明确任务完成的标准。如何判断一个任务结束？只能是队长说达标了，就结束。否则完成时间不可控。

如果在某个冲刺中间需要同甲方沟通，那么这个冲刺的划分就不合理，正确的做法是以跟甲方沟通的时间节点为界，将这个冲刺分解为两个。

鲲鹏团队的第一个冲刺中，我们就遇到了这样的问题，中间跟甲方交流了一次，导致工作反复，燃尽图倒着走了一段。在第二个冲刺中，鲲鹏团队就将冲刺结束时间设定到了同甲方交流之前。

燃尽图在2月19日发生了逆转

甲方沟通的成果本来就应该是系统的，否则片段性的成果很可能会传递片面信息。误导甲方，给设计团队造成更多的返工。将冲刺结束时间定为跟甲方沟通的节点，也就有助于让沟通的媒介(也就是冲刺成果)形成完整的体系，提供全面信息。跟甲方沟通之后，再由队长收集整理反馈信息，制定下一次冲刺的目标和计划。

04 冲刺的合理跨度

从以上分析，我们还可以推断出，一个冲刺合理的跨度是一周到三周。太短了无法形成系统化，有条理的成果；太长了要不是甲方忍受不了寂寞，要不就是设计师面临巨大的风险——如果跑偏，会偏得太久。

05 任务

为了顺利完成冲刺需要提交的设计成果，当然需要将这个大的任务分解成为较小的任务。分解到什么程度合适呢？
最基本的原则就是

• 一个任务只能由一个队员执行

• 同一个队员可以拥有多个任务

• 任务需要有明确的完成标准。(做到什么样子，算是完成了)

有参与Scrum的设计师队长问我，一个任务为什么不能交给两个人来执行？
因为如果我们发现是这个任务引起了整个冲刺失败的风险，我们无法判断究竟是哪个队员出了问题，也就不好及时纠正了。

06 故事点

故事点就是任务的工作量。
为什么不用面积为设计任务计量？我当然知道很多设计公司都用建筑面积计量，其实大家也都清楚，设计任务的工作量跟面积之间没有必然联系。随便几个问题就能把面积计量问晕：

• 设计一个1000平米的会所工作量就比设计一栋1万平米的住宅工作量小？

• 如果一个任务是做总图，如何计量？

• 有人负责外立面细节设计，如何计量？

为什么不用工时？还得从人类的构造谈起，人类大脑的设计，本身就不适合绝对值的预测和估计，但是对相对值的预测要好很多。例如，让人估计一个广场宽多少米，很难弄准，但是却很容易说出，这个广场大约是旁边那栋建筑的一倍宽。
为了说明人类对于绝对数预测有多不靠谱，Scrum框架的发明者萨瑟兰在他的书里写到：

法国萨特尔大教堂用了57年才建成。我可以百分之百地确定，当建造教堂的项目刚刚开始启动时，石匠肯定对主教说：“最多用25年，可能15年就建好了”

所以我们对设计师总是延误的原因就能够理解了，估算的方法不对。

故事点就是相对值，可以用来对工作量进行快速估值。
故事点适合用斐波那契数列，也就是1,2,3,5,8,13,21……
因为要人判断一个任务究竟是5个故事点还是6个，会很纠结，但是在5和8之间选择就要容易多了。斐波那契数列每个值都是前面两个数值之和，可以让人看到明显的差别，方便判断。

其实，为了让工作量估值更直观，还可以用服装的标记XXS,XS,S,M,L,XL,XXL, 每个尺码对应一个斐波那契数字即可。

我们的项目运营管理工具Time-cost用了工时计量，是因为Time-cost不是用来预测。而是用来记录工作量，当然，我们还加上了时薪的维度。

07 故事点的作用

Scrum团队可以共同讨论之后，给每个任务定出故事点。冲刺开始后，我们每天统计任务的剩余故事点，就能知道冲刺的进度了。
在带领 好似飞行 Scrum的过程中，我就发现有两个队员负责的任务故事点相加后，差异特别大。我就问了他们的负责人，这两个设计师的水平是不是差不多的，得到了肯定的回答。如果这样我们就能判断，这个冲刺的任务分解不合理，一般情况下，两个水平差不多的设计师，在同样时间内能够完成的工作量应该也是差不多的。
在我提出这个问题之后，好似飞行 调整了任务分配，让两个设计师负责了一致的工作量。

另外，除非有非常特别的原因，任务与任务之间的故事点差异也不应该太大。如果同一个冲刺中，有的任务故事点是1，而同时还有任务故事点是89，那也说明任务分解不合理。
在互联网行业中，还有以任务数量作为工作量计量单位的习惯，也就是说，他们认为，一个好的队长，应该能够将冲刺中的每一个任务都拆解得差不多大小。

08 站立会议

Scrum强调信息共享，每个成员都需要知道整个冲刺和团队的状况，知道冲刺需要达成的目标，也需要明白自己的任务和其他人任务之间的关系。每个队员都要及时知道整个团队的工作进度，看看周围是否还有需要帮助的同伴。
所以Scrum过程中产生的信息，一定要及时分享给所有队员。
每天10分钟的站立会议，是信息共享的重要机制。为了简短有效，每个队员需要站着讲，只说三件事：

1. 我昨天干了什么。

2. 我今天准备干什么。

3. 需要什么支持

09 主动性

Scrum强调主动性。Scrum标准的做法是把分解后的任务，写在即时贴上面，贴到看板上，让队员上去自己领取。
这个理念也适合设计师。所有设计师都更有理由高质量完成自己领取的任务。

10如果没有顺利完成

如果在冲刺截至日期到来之时，所有任务都完成了，冲刺就顺利结束。
当然，计划总有不能实现的时候。
如果冲刺时间到达时，还有任务没有完成。冲刺就算是失败。没有完成的任务，可以单独做一个冲刺，重新制定计划，将其完成；也可以同新增的任务一起进入下一轮冲刺。
如果冲刺中途出现了意外，例如甲方换领导了，那就直接停掉冲刺，也算是冲刺失败。

如果对Scrum不熟悉，可以回头看看我们前面的两篇内容：

为了帮助设计师抑制IT行业敏捷迭代的工作方式，我们继续征集设计师团队，跟我们一起来Scrum，有意向的设计师队长，请同我们的客服联系。timecostppg
之前几个设计团队的Scrum过程和经验我们已经做了详细记录，一个叫做 “冲啊Scrum”的小程序正在开发中，第一个测试版本很快就会发布，欢迎设计师们报名尝鲜。

欢迎在留言中给我反馈，我们共同来决定后边的讨论内容

---

Time-cost

设计公司运营管理智能工具

您可以在这里分析项目数据，

评定员工绩效，

量化公司运营状态，

让公司的经营决策更加及时准确

客服微信