既然都身處於隕石開發中了，何不嘗試跑個 Scrum 呢？
最後一天了，不說小故事了XD
在我第一天的文章中就有提到了，或許**「沒有制度」**就是我們這種隕石開發的制度，沒有人知道要做什麼，需求沒有 Deadline，需求無法確定以及業主至上的觀念，這些事情在這段隕石開發上常常見到。導致團隊中的大家只能邊做邊抱怨，但也沒有看見改善的一天。
但是單純抱怨，什麼也不會改變（單押 x1）
某個時刻，突然有**「既然沒有制度，那就帶著大家創造一個制度吧！」**的想法出現，反正目前隕石開發的方式就是沒有規則，倒不如大家一起樹立一個規則，至少要能夠一步步解決眼前的問體。於是，我回頭參考接案時期中的 PM 是如何管理一個專案的並且採用什麼模式以及哪些工具。後來發現幾個案子上 PM 都是採用敏捷開發中的 Scrum 方式，因此，我也稍微研究了一些大神 Scrum 的文章，嘗試看看能不能把這個模式帶入團隊中。
這篇文章主要會提到一些我身為一個 iOS 工程師帶著大家嘗試跑 Scrum 的一些感想，而不會是 Scrum 技術文。我相信有許多大神的 Scrum 文章都是長年的經驗的結晶，很值得大家或是團隊成員參考的。
當時在搜尋 Scrum 的時候，馬上看見了 《什麼是Scrum？不是工程師也能懂的Scrum入門介紹！》 這篇文章，而在文章中的一句話深深吸引著我：
你可以把 Scrum 說成一個合作的模式、專案管理的流程，或是另一種說法：
「在一段期間，完成一堆任務的工作方式。」
而我認為的 Scrum 在最理想的情況下，我應該會得到下列幾個好處：
而我認為其中的回顧與檢討可能是最重要的點，因為我相信無論是什麼開發方式都只是一種形式，我們應該要能夠彈性調整它。我相信不是所有團隊都能百分之百能套用當前的開發模式，而是透過一步步調整成團隊適合的模式。
確認需求後再開工
在每次 Sprint 開始之前，都會例行性的開一次會議，藉由這次會議大家可以列出當次任務進度，並且讓工程師們列出實現的細項，同時如果有問題也能夠在這個會議中提出，無論是任務上的問題或是時程上的問題都能提出討論。而整個會議的結果就是希望在會議結束後團隊能夠全力衝刺。
在 《當一個 Scrum Master 是一個怎樣的體驗？》 中有說到這個點：
透過 Scrum 可以讓當初不清楚的使用者需求、無根據的預估工作時間和無限制需求的亂象可以被攤在陽光下檢視和討論，才有機會透過 Scrum process 來管理和改善
減少工程師閱讀（吸收）負擔
在隕石開發時間，常常收到當週的需求都是一份 Google 試算表，雖然是表格式的方式，一行為一個任務，但是上面總是列了一些不必要的資訊，導致在查看的時候眼花撩亂，加上因為是表格式的方式，在查找一個任務的時候總是要清楚描述是在哪個試算表中的在第幾行／列。
後來我將這些任務和需求通通整理在 Asana 這個工具上（絕非工商，因為公司剛好有帳號），透過這種條列式的顯示方式我們能夠清楚的看見當週任務、Bug、待處理項目等等的區塊。並且把要處理的任務分配給處理對象，同時也會把相關資訊和所需文件貼在任務中的描述（例如：Zeplin 設計圖，API 文件）方便工程師閱讀。
透過這種方式可以讓工程師只打開這個 Asana 就能確認當週進度以及所被分配的任務，而任務中的所需資料也都在該任務中看得到，讓工程師能夠專心在處理開發上。而需求問題反應時也在任務下的留言區反應即可，最後在任務完成時也只需要打勾標記即可。
靈活調整任務清單，考量優先順序
而最常見的例子就是需求變動，而在發生變動時，我們需要評估是否能夠加到本期清單中，而不是直接塞到清單中。我們需要斟酌考量這個任務的優先順序，斟酌考量是否要排進本次進度或是下一期的進度中。同時，有了這個 Asana 的表也能比較好向上頭表達目前任務狀況，以及我們的考量點，例如：如果要做這個的話，什麼功能會被拿掉或延後處理等等。
在 《當一個 Scrum Master 是一個怎樣的體驗？》 中有提到一個有趣的點：
通常絆腳石是你不能說名字的那個人
在推行 Scrum 時，公司高層和文化的支持也是十分重要，因為通常公司推展 Scrum 或是敏捷開發會失敗，通常絆腳石是你不能說名字的那個人
是誰？抱歉我不能說
回顧檢討上次進度，調整為更好的模式
每次 Sprint 結束後也會開會討論上一次 sprint 的成果，並且檢討一下有沒有什麼需要修正調整的，無論是管理方式、時程規劃、模式調整等等。就是希望能夠匯集大家的想法，提出一個對這個模式可以改善的方式。就像我前面說的，不是每一個團隊能夠完美套到這個模式之中，因此，每個人提出不同看法，修改成團隊適合的模式，讓大家能夠更習慣在這個模式之中，並且專心在其工作崗位上。
30 天的鐵人賽終於完賽了，不知不覺參加到第三年了。
今年的鐵人賽對我來說也是個大挑戰，畢竟帶著正職發文，加上每一篇文對我來說也是我嘔心瀝血，踩過無數坑洞的作品，也希望讀者們在閱讀完成之後都能夠學會文章中的技術。
而最後一篇打算寫 Scrum 的原因很簡單：「遇到了問題，就是要解決」，抱著這個心態，我在最近這一陣子看了許多 Scrum 相關的文章，也決定在第 30 天寫一篇開發模式相關的文章，畢竟我們隕石開發就是在開發模式這塊出了一個大麻煩。所以，身為一個工程師也應開去思考如何解決這個困難。
雖然整個 Scrum 模式 run 起來也不太 Scrum，身份也在 Scrum master 與 Developer 模糊不定。但是至少帶著團隊跑了這種模式之後，解決了一些我們隕石開發中不樂見的問題，並且透過每次檢討修正成屬於我們團隊的模式。
話說維基百科中提到 Scrum 的一點蠻好笑的：
Scrum當中定義了許多角色。按照對開發過程的參與情況，這些角色被分為兩組，即豬組和雞組。這個分組方法的由來是一個關於豬和雞合夥開餐館的笑話[5]：
一天，一頭豬和一隻雞在路上散步。雞對豬說：「嗨，我們合夥開一家餐館怎麼樣？」豬回頭看了一下雞說：「好主意，那你準備給餐館起什麼名字呢？」雞想了想說：「叫『火腿和雞蛋』怎麼樣？」「那可不行」，豬說：「我把自己全搭進去了，而你只是參與而已。」
然後在 Daily Standing Meeting 中有提到：
歡迎所有人參加，但只有「豬」可以發言。
突然不想當工程師了 QQ，原來我是豬 ?
iThome鐵人賽
看影片追技術