【Side Project】線上程式教學敏捷流程導入-以技術主管角色進行Twitter程式開發專案
這次再次與AlphaCamp合作改善教案與專案流程。試著導入敏捷開發流程在原本學期三進行的Twitter開發專案中。
藉由導入敏捷開發流程在專案中，主要是因為AC發現學員即使學有所成離開AC後，有些同學到業界實際工作仍感受到無法適應，所以為了讓學員能夠到業界之後，能真正掌握參與專案的執行技巧與協同合作，因此才有這一次的導入合作。
這次在兩週的專案過程中，總共分為3次sprint check，分別對應一個sprint中的sprint planning, sprint refinement, 和sprint demo的流程。這樣修改sprint流程主要也是配合AC Twitter專案只有兩週時間的緣故。
sprint check 1: Sprint Planning + 部分refinement
第一階段我期望同學們能充分地去了解需求內容，細節化需求任務，評估每項需求任務的時程:
- 首先要充分了解需求內容。
(1)可以從 AC 提供的 user story 與 figma 的 mockup 去分析，做出相對應的系統分析文件(system analysis)，列表化要實作的功能以及確認模組架構與流程。
(2)並補充與強化 user story 中的每一個 story 的 acceptance criteria(acceptance criteria是該story測試通過的條件，不單只是自動測試的部分)，以及最終整個需求可以deliver的definition of done(DoD) 的定義。 - 接著細節化與評估每個可分派單人負責實作的項目出來。
(1) 可以先透過系統設計(system design)的相關方法與工具，比如UML（用圖形繪製）來繪製flowchart, component/class diagram，甚至state machine(可以是針對用戶或者一篇文章的生命週期)，以及與資料庫相關的database ERD, schema，還有前後端溝通的API文件等；P.S. 這些文件是為了小組之間順利溝通，不是為了文件而文件!
(2)然後任務的拆解越小化越好，能夠越independent的任務就盡量不要與其他任務相依，避免造成相互等待的狀況，且每個任務的實作時間最好不要超過3天，若實作時間超過3天，代表該任務單一定可以再拆解的更細。 - 任務時程的評估，可以採用敏捷中Scrum開發流程的story points評估的方式，
(1)確認團隊所有人對於該項任務的相對所花費時程的認知。
(2)並在scrum planning需求討論完畢後，確認任務的領取與相對時程，使用電子化(trello or notion)或實體化的scrum board來透明化任務，以便清楚知道目前某項任務的進度，方便進行團隊的隨時討論。
sprint check 2: Refinement
第二階段我們要確認任務的執行是否 on schedule，以及任務是否需要調整與重新釐清 (在 scrum 中叫做 refinement 或者 grooming)。
- 首先確認團隊成員手上執行的任務，是否是符合目前需求的。確認是否符合acceptance criteria的描述，以及最終defintion of done中的定義：
(1) 是否清楚任務的目標? 是否task完成的時間是足夠的? 重新安排tasks執行的 priority。
(2)需要對需求做調整嗎? 可否刪減一些不必要的完成項目，就能完成最小化可交付的產品(MVP)?
(3)若時間不夠，有沒有其他解決的辦法(workaround)? 或者其他可支援的resources? - 然後確認是否團隊成員有人進度超前，可以跨功能的支援其他可以先完成的事情。比如:
(1) 協助QA角色: 幫助團隊成員中已完成的tasks，先協助其跑自動與手動測試，包含確認其驗收條件(acceptance criteria)是否符合，列出可能的已知issues。
(2)協助PM與設計角色: 確認task完成是否符合user story以及app的畫面是否match當初的mockup設計。
(3)協助前後端coordinator角色: 如果是前後端分離的專案，協助確認前後端是否已經清楚的完成串接程序；若是原本前端角色可否協助後端先產出假資料(mock server)；若是後端角色可否協助前端設計出更符合頁面結構的API資料，供其方便串接。
此時是專案的中段，我們需要在進度上，我們能不能滿足時程。
sprint check 3: Demo
最後一個階段，是交付可執行化產品前的準備，確認能否順利deliver給我們的用戶(評審與助教)。
- 上版前的準備:
(1)確認交付的產品是否符合當初所定義的definition of done。是否符合最小化可交付的產品(MVP)。
(2)列出已知的issues，設定priority，並確認哪些issues是必定需要修正的(P1)，哪些是可以先忽略的。
(3)確認前後端要負責部屬的相關設定；比如後端要負責production資料庫的設定，以及heroku上config的設定；前端確認api跨域請求呼叫的問題，非同步呼叫在production上是否延遲，或者是否有cache的問題等。 - Demo
(1)準備一個完整的，依照user story所定義的所有features，正向流程的示範。(所謂正向流程是依照user story選定一條單一個role(user or admin)能從頭到尾跑完的過程(不需要reset user或資料)，並最能呈現出目前已完成功能特色的最大呈現，且過程要盡量簡短，並說明其有價值或者值得點出得特點。)，也就是tell a story to your stakeholders.
(2)提出過程中所遇到最困難的問題，並且團隊是如何解決的?
(3)說明目前系統有計畫完成但未完成的部分，並說明預計如何在最後48小時內完成?
這次的Twitter專案敏捷流程導入，最後收到的效果是好的。大家透過兩週詳細的敏捷流程安排，能夠較為確實掌握整個團隊的進步，並提前做好規劃與應變。進而最終能有較好的產品完成率與團隊間的成長。
然後也同時完成教學平台上，同步與非同步的概念釐清教學與文案的修改。
https://github.com/ivanchiou/ac_async_workshop
這是開放的教案，大家可以試著去練習釐清非同步的概念。之後會持續定義幾項初學者比較容易不清楚的5個方向，包含:
1.計算機(電腦)概論: 為什麼要寫程式讓電腦幫我們處理事情?
2.物件導向的概念中對應到Javascript的地方。
3.Multi-thread的問題產生的deadlock，與非同步(multi-task)間的概念釐清。(非同步的部分已在上述教案修改做部分解釋)
4.資料庫在系統中所扮演的角色。
5.為何需要docker / kubernetes / aws等微服務的系統架構? (devops概念)
或許未來這些不單只是能成功apply在成人程式教學上，或者兒童的程式教學上也可以以此方向套用。