对Daily Scrum的理解与看法

在Scrum里的每日站立会议是一个最吸引众人目光的仪式，大部份人一听到Scrum，脑海中就会浮现一群人站在白板前回报进度的画面。

然后有学过的人都知道每个团队成员必须回答3个问题：
1.从上一次Daily Scrum到现在我做了什么?
2.接下来我要做什么?
3.我遇到了什么障碍无法前进?

这个例会大概也是我听过最多人抱怨的会议，通常会议时间要在15分钟内结束，每个人要回答的问题又都一样，对很多人来说，成为一种类似专案进度汇报的例行公事似乎非常合理…XD

我参与过很多次的传统瀑布流专案进度汇报会议，不带杯咖啡进去真的很容易睡着，还好现在有了智慧型手机可以刷FB…(大误)。

以我的理解，专案进度汇报会议是比较偏单向的，资讯从一方流向另一方：让团队或PM(或PM的老板)得到最新讯息，接下来PM(或PM的老板…XD)可能会依专案的状态进行一些工作项目跟资源上的调度，目的是控制好专案进度，以免造成延迟。

但Daily Scrum的本质不太一样，我倾向这样描述它：

类似系统开机时的自检，紧接着载入要执行的工作项目，并检视周边支援设备是否有异常，如有则必须优先排除以让工作顺利进行。

1.从上一次Daily Scrum到现在我做了什么?
2.接下来我要做什么?
3.我遇到了什么障碍无法前进?

这3个问题形成了一个大致上以天为单位的Feedback loop。藉由频繁的系统自检，如果整个开发工作出了问题，比较容易地在问题发生初期就解决它。

举例来说：负责需求分析的同事认为他前一天承诺的工作已经结束可以进行下一个需求分析，但另一个准备接手开发的同事并不是这样想的，他还需要厘清一些细节，而这些细节必须有另一位同事协助。在Daily Scrum短短的15分钟里充分揭露这些资讯，就能在结束后进行有效的后续讨论。

Joey 91:
call for help + I can help + I’m interested + something is different from our expected

2018.1.20 以上是我原本发在FB的一篇感想文，之后在准备内训教材时，觉得有些值得补充的地方，所以整理成这篇文章发在部落格。(话说好久没发文了…XD)

以积极的个人来建构专案，给予他们所需的环境与支援，并信任他们可以完成工作。
面对面的沟通是传递资讯给开发团队及团队成员之间效率最高且效果最佳的方法。
团队定期自省如何更有效率，并据之适当地调整与修正自己的行为。

这是12条敏捷宣言中的其中3条，Daily Scrum不就正好对应到这3条原则吗? 对管理层来说，专案的Transparency很重要，故专案管理的手段常见定期的团队专案进度汇报会议，但以敏捷的精神来说，Daily Scrum无疑是更灵活的方式，而且不仅仅如此，如同91在FB的回应，团队成员会逐渐学习到承诺、责任与互相信任，从Working Group升华成为真正意义上的Team。

学习敏捷只看具体实践常会让人感到困惑，唯有深入原则与价值观才能真正理解与认同敏捷。