課前閱讀，課中討論

Oct. 11 19:20~20:41

 

今年在北科兼任的「敏捷與精實軟體開發」課程，上課方式和去年做了一點小修改。Teddy一直希望學生可以多讀一點「書面資料」，去年透過指定閱讀資料，然後撰寫心得或上台報告來驗收閱讀成果。上台報告效果還可以，但是撰寫心得報告這種方法不好。學生寫的「心得報告」含金量與可讀性通常不高，還要花時間一篇、一篇去改，到底是在訓練學生的理解度還是在訓練老師的耐心？這種「透過書面溝通」的方式效率太差，今年改成每次下課前都指定一個閱讀作業，然後下次上課先花10分鐘作一個很簡短的測驗練習，之後再來討論文章的內容。

以10月8日上課為例：

1. 課程進度是Scrum，請學生閱讀的文章是〈The Scrum Primer〉。
2. 上課先讓學生發問對於文章內容的問題，都沒問題之後開始10分鐘的測驗。
3. 測驗結束之後，請兩位學生到黑板畫出他們閱讀文章之後所理解的各項Scrum活動，以及參與這些活動的角色。
4. 接著請其他同學幫忙補充是否有遺漏的內容，讓這個「Scrum流程圖」更加完成。
5. 然後請另外兩位同學上台，負責解釋黑板上透過全班同學所合力完成的「Scrum流程圖」。這時候台下的同學每一個人都要提問一個問題，讓台上這兩位同學負責回答。在這個過程中，原本的「Scrum流程圖」可能會因為問答的過程加以修改。
6. 在問答的過程中，Teddy主要負責促進這個過程順利進行。如果有同學提問的問題過於模糊，幫忙釐清提問的內容。讓全班同學透過討論的過程來了解、熟記Scrum各項活動的用途。只有在全班同學都無法回答問題的時候，Teddy才出面解釋。

***

在上課之前這學期已經講過從Waterfall到敏捷、敏捷開發精神、XP的十二個實務作法，對於敏捷開發已有基礎的知識。經過討論過後，只有對於Product Backlog Refinement Workshop的目的與舉辦時間比較不清楚。有同學認為：「應該在retrospective meeting之後舉辦」，但有同學就質疑「如果在retrospective meeting之後舉辦，為什麼不乾脆就直接在sprint planning meeting舉辦就好了？」在討論的過程中Teddy發現同學對於Product Backlog Refinement Workshop活動的目的不是很清楚，因此補充了幾點：

1. 這個活動是一種up-front design（順便解釋一下up-front design與big up-front design的差別），目的是讓product backlog隨時有1~2個sprint的項目（story）符合definition of ready的標準。這個活動可以避免PO在sprint planning meeting所帶來的story準備不足，當下團隊才忙著釐清許多問題，甚至有些外部相依性的問題無法在當場釐清，影響sprint的進行。
2. 常見的Product Backlog Refinement Workshop舉辦方式有兩種，一是在sprint中期舉辦，二是採用Just in Time的方式，有需要隨時可以舉行。
3. Product Backlog Refinement Workshop討論接下來1~2個sprint的內容，Sprint Planning Meeting（Part 1）討論這個sprint的內容，兩者不同。
4. 如果有舉辦Product Backlog Refinement Workshop，通常Sprint Planning Meeting Part 1會進行的比較快。
5. 有些團隊對外相依性的工作很少，但story異動的幅度可能很高，因此Product Backlog Refinement Workshop所討論的story，經常到了下個sprint的時候又被其他優先權更高的項目給取代了。如果經常遇到這種狀況，有些團隊也會選擇不開Product Backlog Refinement Workshop，但Sprint Planning Meeting Part 1就會花費比較多的時間來討論。

***

讓學生事先花個幾個小時閱讀，上課時再透過討論、對話、問答的形式，和傳統老師拼命講解投影片趕進度相比，希望可以加深學習效果，增強學生日後「自行覓食」的能力。唯一的缺點就是這種方式需要花費的時間比較多，相對來講「塞」給學生的內容就比較少。但從value-driven的角度來看，也許讓學生培養閱讀、思考、比較、判斷、分析的能力，會比趕進度來的重要。

對學生而言，人生還長，只要具備「自行覓食」的能力，以後有的是機會慢慢吃到飽。

***

友藏內心獨白：閱讀真的很重要。