May 26 00:58~02:30; 13:00~13:42
四月Teddy跑去葡萄牙、西班牙「考察」了十幾天，回國後忙著上課沒時間寫部落格。五月家裡有些事要處理，所剩的其他時間都拿來寫程式，也沒心思寫部落格文章。眼看五月即將結束，本月份部落格「產能」少的可憐，還是想辦法擠點東西出來。
Teddy在北科資工所兼任五年「軟體生命週期管理」課程，今年是最後一次教這門課，明年春天改教「軟體架構」。衝著最後一年特別紀念，今年改了新的上課方式，先用一半的時間講BDD/TDD，再用另一半時間講Scrum。以往教Scrum會請學生跑3~4個sprints開發一個專案，今年原本也是計畫如此，但今年修課的全部學生在實驗室做計劃的時候都已經在跑Scrum，在課堂上再跑另一個Scrum專案意義不大，於是幾個禮拜前決定用其他的方式來介紹Scrum。
這禮拜四上課前一天傳了〈Daily Scrum〉pattern給學生，請他們先把這個pattern讀過。禮拜四上課Teddy告訴學生如何用pattern的角度來理解Scrum，先從大家都很熟悉的Daily Scrum這個活動開始。
***
步驟1：找結構
Teddy把〈Daily Scrum〉pattern印出來，給學生20~30分鐘的時間，用筆圈出pattern的六大元素：
- Name
- Context
- Problem
- Forces
- Solution
- Resulting Context
***
步驟2：找問題
找出 〈Daily Scrum〉pattern六大元素之後，優先思考Daily Scrum要解決什麼問題。以下是 〈Daily Scrum〉pattern原文中對於problem的描述：
The team makes progress in a Sprint by finishing Sprint Backlog Items, but given the complexity of the work, the characteristics, size and quantity of tasks change frequently — sometimes minute by minute.
Teddy請學生練習把problem改寫成一個問句。下圖是學生所整理出來的各種problem問句，經過學生投票之後選出票數最高的描述為—Problem：如何在最短的時間內理解需求並揭露可能發生的阻礙？
***
步驟3：找解法
接下來請學生找出 〈Daily Scrum〉pattern的解法，以下是 〈Daily Scrum〉pattern原文中對於solution的描述片段，只要看Therefore之後第一個粗體字的句子就好—Solution：Have a short meeting every day to replan the Sprint. Strictly time-box the meeting to keep focus on the daily plan and to avoid robbing time from development。
***
步驟4：修正問題
現在把剛剛整理好的problem-solution拿出來一起看，請學生判斷一下剛剛整理的problem有對應到solution嗎？
Problem：如何在最短的時間內理解需求並揭露可能發生的阻礙？
Solution：Have a short meeting every day to replan the Sprint. Strictly time-box the meeting to keep focus on the daily plan and to avoid robbing time from development。
經過一番討論之後，學生整理出第二版的problem：
Problem(v2)：如何有效率地重新計畫Sprint？
***
步驟5：找Forces
下一個步驟請學生把forces找出來。剛剛才發現忘了拍學生找出來的forces，只有把forces寫在黑板的照片…Orz。
直接講結論，經過投票之後留下三點forces
Forces：
- Alternative solutions, needed but unknown knowledge, hidden tasks, misunderstood requirements, requirements requiring further elaboration, dependencies among developers, or problems in the form of blockages may emerge in the team's day-to-day work.
- Too much re-planning and re-estimating wastes time and suffocates developers. But too little re-planning and re-estimating leads to blockages that cause delays or obsolete plans that no longer represent reality.
- An individual may need to bring up an issue to the team. But it may be difficult to find an opportunity to do so. In particular, issues continue to be impediments until they are fixed.
***
步驟6：解法是否有呼應Forces
把剛剛整理出來的結果重新整理一下，接著請學生判斷solution是否有呼應這三點forces？
Problem：如何有效率地重新計畫Sprint？（How to keep your Scrum plan up-do-date?）
Forces：
- Alternative solutions, needed but unknown knowledge, hidden tasks, misunderstood requirements, requirements requiring further elaboration, dependencies among developers, or problems in the form of blockages may emerge in the team's day-to-day work.
- Too much re-planning and re-estimating wastes time and suffocates developers. But too little re-planning and re-estimating leads to blockages that cause delays or obsolete plans that no longer represent reality.
- An individual may need to bring up an issue to the team. But it may be difficult to find an opportunity to do so. In particular, issues continue to be impediments until they are fixed.
Solution：Have a short meeting every day to replan the Sprint. Strictly time-box the meeting to keep focus on the daily plan and to avoid robbing time from development。
第一個force說很多事情做了之後才會知道，所以即使團隊已經舉辦了sprint planning meeting，當sprint開始執行時，sprint backlog的內容就已經過期了。Solution建議每天舉辦一個會議來重新計畫，所以呼應了第一個force。
第二個force說太多重新計畫與重新估算會讓開發人員受不了，但太少也不行。Solution建議每天舉辦一次固定時間（15 分鐘）的會議，呼應了第二個force。
最後一個force說開發人員想提出議題討論，但很難找到合適的機會。例如大家都很忙，不好意思中斷所有人的工作，因此導致問題拖比較久才提出來（有開週會的團隊應該會有這樣的經驗，有人禮拜一、二就發現問題，但一直等到禮拜五開週會的時候才提出來）。藉由每天舉辦Daily Scrum，這個force也被關照了。
***
回答常見問題
姑且不看Context與Resulting Context，光是從Problem、Forces、Solution就可以回答一些常見有關Daily Scrum的問題，例如：
- Daily Scrum一定要站著嗎，能不能坐著、趴著、躺著：Daily Scrum的預設版本是一種站立會議（Standup Meeting），其目的是為了呼應第二點force。如果你的Daily Scrum採用坐著甚至是趴著也可以達到相同的目的，也沒有什麼不可以（但請先思考一下為什麼預設方式會建議用站著，並確定感變形式之後原本的force真的還是有被關照到而不是讓force失去平衡）。
- Daily Scrum一定要在實體Task Board（Scrum Board）前面嗎，能不能用電子Task Board：Scrum的Task Board是一種視覺化的計畫（或重新計畫，re-planning）工具，敏捷開發有一種說法：「Low tech, high touch. High tech, low touch.」。藉由在實體Task Board上移動task，以及作為一種information radiator（訊息發射器），實體Task Board很成功扮演者plan和re-plan的角色。同樣地，如果你確定改用電子Task Board之後原本的force仍然獲得平衡，也並無不可。
- 一定要同步式的Daily Scrum嗎，能不能用非同步的方式進行Daily Scrum：同步或非同步的議題和第三與第一個force有直接的關係。標準版Daily Scrum要求舉辦會議需要在同一時間、同一地點、固定長度。團隊在相同時間聚在一起，除了提供一個儀式性的活動讓大家有機會可以提出各自的議題，面對面溝通也可以比較快速做出許多決定。但是，有些團隊分散在不同地點、不同時區，有可能不容易到一個大家都方便的Daily Scrum時間。在這種情況之下，使用電子系統，用非同步的方式更新自己的狀態以及想要提出的議題，也是常見的方式。但還是老話一句，原本Daily Scrum形式想要面對的forces在採用新的形式之後這些force是否依舊被照顧得好好的。如果沒有，就必須考慮改變之後的做法是否合適，或是要再套用其他pattern把沒平衡好的force好好地照顧一下。
***
Scrum是一種流程框架，身為一個框架自然有很多可以讓人 上下其手 自行調整的空間。調整不是問題，因為每個公司、專案、團隊都不同，也就是說套用Scrum的情境（context）不一樣，自然會衍生出不同運行Scrum的形式（solution）出來。在調整的過程中，抽象的來說要注意調整後的做法是否還是符合Agile與Scrum精神。具體一點來看，原本Scrum設計的活動、角色與工件所要關注的作用力（forces），在調整新的做法之後「宇宙原力」是否依然保持著平衡 （觀察resulting context）。平衡性越高，解決方案就越合適（fit）每個人所處的情境。
***
友藏內心獨白：還有很多pattern可以練習喔。
沒有留言:
張貼留言