【腦殘遊記之我也懂Scrum】sprint 4

今天要邁入非常複雜的一個步驟，就是工作規劃會議。

產品負責人(Product Owner, PO)會列出他的需求，簡單的描述一個需求需要達到的目標，稱為一個User Story，並評估每個User Story的重要性，在工作規劃會議之初，提出這個sprint希望做到的User Story。

而小組則根據Story的困難度及重要性來挑選這次sprint要做的項目，這個過程會由PO跟團隊進行溝通協調，如果評估時程無法做完某一項長時間但PO又覺得很重要的項目時，可以降低該項目的需求以減少開發時間，或是再將該項目細分小項，先做其中優先、重要的項目。

選完之後，小組成員則會對各個Story給予故事點數，這個點數除了說明這項目的困難度以外，也能用來做為下次評估能做的Story的依據。若這次能做完20個點數的Story，下次做35點做不完，那久了就能拿捏每個sprint的負荷量。

另外，評分是有固定分數小卡的，若分數差距太大，顯見Story大到無法精確評估，或是組員的工作量差異太大，都需要再重新定義拆解User Story的。

評分完，成員各自將Story拆解成實際的工作項目(task)並填上預估完成時數，這些task就會進到之後的Daily Meeting。

內容過程十分繁複。我朋友一開始也玩得很開心，但誇張的來了，朋友的小組接了Avatar系統，可是組內的美術是2D美術，並不擅長做模型，鑑於「小組對於一項User Story進行討論研究並實作出來，小組成員能提出自己的想法有參與感，是一件非常有成就感的事情」這個原則下，2D美術學著拉模型，這是什麼情形？

幾次下來發現不對勁，改了，「這個Story我們接，你們組的誰誰誰來配合幫忙」，小組仍舊是小組，有著互動良好的參與感，只是有時會「配合」別組，配合而已，不礙事的。最好是！Daily Meeting的時候，SM無法掌握自己小組成員的工作進度。造成跨組合作的情形，不是分組錯誤，就是Story有問題。

User Story原本只需簡單描述，由小組成員完成內容實作，可是往往胖子跟白頭翁無法接受成品，因此User Story越寫越詳細，差點沒直接把工作項開出來，最終還是喪失了前面提的原則，控制欲強，就不要用這麼依賴團隊創造的方法啊，莫名奇妙。

到最後，這個會議也消失了，直接用指派的了。至此，所有的會議算是消滅了，只剩一個Daily Meeting還存在，但荒謬的就在這裡，看似回到了原點，主管指派工作，不需討論、不需參與感、不需瞭解各組狀況及專案進度、不需檢討，但實際上並不是。

小組以奇怪的模式生存著，各專業別的組長分派工作，SM召開Daily Meeting，小組成員間既沒合作關係，卻要花時間聽彼此的工作進度，每天。就只為了胖子要掌握各人工作狀況，有這麼難掌握、變化多端，要天天檢視嗎？荒謬、扭曲。也有可能為了胖子不為人知的神聖理由，沒人知道。

下一次，最後一堂，來聊聊頑強的Daily Meeting。

【課後複習】工作規劃會議中，小組根據PO提出的User Story，評估其實作的可能性做為這個sprint的工作內容，與PO的溝通能研保彼此對品質的認知。評分的步驟不僅檢視Story，也能成為未來小組工作量的評量。