Scrum印记之糟糕的回顾会

                                                Scrum印记之糟糕的计划会

敏捷转型已三月有余，是否仍然有些力不从心。

        尽管我们深知传统瀑布模式的种种诟病，对闭塞的环境环深恶痛绝，对快速有效的沟通心怀渴望。种种美好的愿望，还请佯装淡定，既然习惯已成，根深蒂固且发芽开花，若奢望敏捷全套方法搬用往往事与愿违。

           

        一个糟糕的Sprint计划会。

        Scrum master同学在一个雾霾横行的下午，在内部聊天工具里给Team发了一条简单的信息，希望大家参与Sprint计划会。然后会话的窗口从此凄冷无比，五分钟过去了，十分钟过去了，始终无人问津。Master拿着笔记本叫着产品经理先去会议室了，其他人陆陆续续、半推半就的来了，就这样还缺少了一名仅有的测试。硬着头皮进行的回顾会如坐针毡，魂魄早已飘远。其实master早该有所察觉，召集大家参与职责以外的内容是多么的痛苦，工程师是多么希望每天都能戴着耳机闷头敲着键盘，清净悠闲。

           

        尽管道理字面上我们都认为正确，但当真和实际利益、惰性交错时往往道理挫败的体无完肤。我想或许当事者还没有那么痛，还不能完全的体会敏捷的益处。非“兴言永往，触目恸心”不可也，master务必使得此类同学深切感受到你帮助后的卓越，以及切实有效地带来显著效果。切忌立竿见影的渴望，人非机器，情感需要渗透。       

青山不厌千杯酒,白日唯消一局棋。切勿马上下结论，尤其当众直白的说短处，更是要不得。

或许我们可以把计划会拆分成小范围的活动，往往可以更加事半功倍。

        计划会一般在迭代开始前进行。前期master可以先行制定迭代的任务量，先行进行具体展开。拆分后的User story只需召集相关的几个人参加，地点可就选在工位前，有一块大白板即可。Scrum master 、产品、对应研发和测试必须参加。先对user story进行需求梳理，从一个个散列的概念聚合贯穿成一条业务主线，然后拆分出可以度量的Item。最后对每个Item进行架构整理，工时评估。这样就形成了微缩版的迭代。当面对Team里的“习惯性排斥者”时，评估时可多邀请几位骨干、架构师、测试一起参与，众目睽睽之下很难参杂太多个人情感，往往事半功倍。化整为零的拆分，却是意外的收获。

        故事还在继续，期待我们在精益化管理的道路上可以落地生花。

            

Jan 27,2015