搞笑談軟工

2015年2月21日星期六

2014北海道考察之旅Day8-B札幌舊都廳

Feb. 10 11:56~12:28

離開札幌計時台，徒步走到附近的札幌舊都廳。每次到日本看到舊都廳的磚紅色建築就會想起台灣的總統府。舊都廳一樓展示許多北海道的開拓史，沒想到北海道是在明治維新時代才正式被日本中央統治。

舊都廳二樓主要展示北海道與世界各國交流的成果，還有日本要求俄國歸還北方四島的宣傳品。

準備離開舊都廳，再欣賞一下漂亮的建築外觀。

***

友藏內心獨白：這也可以算是紅樓嗎？

2015年2月20日星期五

以Scrum的精神養貓

Feb. 19 19:10~19:39

養貓隻後才知道「躲貓貓」的真義啊挑眉質疑。

認養Eiffel至今邁入第四個 ~~sprint~~ 禮拜，剛好遇到農曆新年。Eiffel剛來的前兩天非常怕人，總是躲在意想不到的異次元空間不敢出來。後來慢慢願意給人觸摸，Teddy也花了很多時間陪牠。到第二周時，Teddy已經達成在觸摸後讓Eiffel自己跳上Teddy大腿上撒嬌的成就。

無奈後來天氣變化，Eiffel眼睛流淚需要點眼藥水。對於沒養過貓的Teddy而言，幫貓點眼藥水還真是個大難題。前幾次ㄧ直無法順利點到眼藥水，後來參考網路上的做法，硬是把Eiffel抓起來包在毛巾裡面，才順利點到眼藥水。不過，從此之後在Eiffel的眼中Teddy成了大壞蛋，看到Teddy就離的遠遠的，Eiffel深怕被抓起來包在毛巾裡面。

***

之前花了幾十小時好不容易建立起的信任關係，就因為點眼藥水而消失殆盡。一周後帶Eiffel回診，順便打第二劑的預防針。回家之後更慘，Eiffel更生氣，警戒心變得更重。

怎麼辦？貓是挺有個性的寵物，聽不懂人話（至少Teddy家裡這一隻目前還聽不懂），也不知道你的種種「粗暴行為」其實是為了牠的健康著想。只能發揮愛心、耐心，相信久而久之貓會明白貓奴主人的心意。

***

昨晚在PTT的貓板上看到有人提到，在養貓5年之後，他家的貓終於自動跳到主人的身上撒嬌。5年可不是一段短的時間，但只要不離不棄，每天餵食、換水、清貓砂、陪玩，再孤僻的貓還是有被感化的一天。

突然覺得，這和導入Scrum不是很像嗎？iterative and incremental；inspect、adapt and transparency，全都派的上用場啊。

***

友藏內心獨白：5年是幾個sprint？

2015年2月19日星期四

開發團隊的技能（上）

Feb. 16 23:00~23:58

學會看電視的技能。

昨天介紹比較容易理解的〈開發團隊的責任〉，接下來介紹開發團隊的技能。《Essential Scrum》書中提到開發團隊所需的技能有10種，今天是大年初一，考量到新年期間鄉民們應該不想動太多腦筋，分三天慢慢講完這10種能力。

Self-Organizing：有別於傳統的管理模式，Scrum團隊成員自行決定達成sprint目標的最好方法，不需要主管或專案經理來指揮與分派工作。這裡Teddy要補充一點，在Daily Scrum中，團隊成員自行認領工作並不等於「自我管理」，因為許多Scrum團隊的成員並沒有「自行決定達成sprint目標的最好方法」，只是形式上讓大家自由認領工作，實際上則是有些人很辛苦的總是認領比較困難的工作，有些人總是柿子挑軟的吃。自我管理的能力，Teddy覺的是團隊成員必須但不易修練的技能。
Cross-Functionally Diverse and Sufficient：Scrum要求組織跨職能開發團隊，這樣的團隊可以完成product backlog的工作項目，並產生符合DoD（Definition of Done）的高品質的軟體。團隊成員的多樣性，又可分成：
- Cross-functionally diverse：團隊成員擁有不同的技能（UI/UX、程式實作、測試、資料庫、前端、後端等）與不同的背景。
- Diverse perspectives：多樣化觀點，包含對於事情的詮釋能力、採取的策略、心智模型、偏好。
- Better outcomes：更快速的解法、更好的解法、非常好的創新能力。
T-Shaped Skills：T型人是指擁有多種技能（multi-skills）的人，這種人有一種主要的專長（T的垂直線），對於主要專長要追求技術的深度。同時，也必須具備至少一種以上的次要專長（T的水平線），以增加自己能力的廣度。因為開發團隊需要合作，用最好的方法來達成sprint目標。如果每個人只有一種專長，當同性質工作太多或有人需要協助的時候，人力調度安排就可能變成工作瓶頸。藉由培養T型人的能力，團隊成員可以更好的實踐自我管理，也可以拓展個人的能力多樣性。

***

友藏內心獨白：這三點都很難啊。

2015年2月18日星期三

開發團隊的責任

Feb. 16 21:25~22:00

紅包要這麼大包才算盡責任 XD。

今天是農曆除夕，先祝鄉民新年快樂，來年技術、嘴砲功力，最重要的是薪水更上一層樓。

前兩天介紹完〈Product Owner的責任〉與〈Product Owner的技能〉，接下來兩天分別介紹開發團隊的責任與開發團隊的技能。《Essential Scrum》書中提到開發團隊應負擔以下主要責任：

Perform Sprint Execution：執行sprint所排安的工作，包含設計、建構、整合、測試等，以便在sprint結束時產生潛在可交付產品。
Inspect and Adapt Each Day：關於這一點書中提到開發團隊成員每天必須參加Daily Scrum，共同檢視進度並且調整今日的計畫，以便讓團隊朝向sprint目標前進。廣義來說，隨時檢視與調適前進方向，是整個Scrum團隊，包含開發團隊、PO、ScrumMaster的行事原則。
Groom the Product Backlog：梳理product backlog，又稱為product backlog refinement workshop。這一點是開發團隊與PO的共同主要責任。
Plan the Sprint：參加sprint planning meeting。
Inspect and Adapt the Product and Process：這一點也很簡單，就是參加sprint reivew與retrospective。前者是產品需求的回饋，後者是流程的回饋。

***

相較於PO與ScrumMaster，開發團隊的責任相對來講就明確很多。簡單的說就是把產品做出來、參加所有的Scrum活動，包含Daily Scrum、Sprint Planning、Product Backlog Refinement Workshop、Sprint Review、Retrospective。

***

友藏內心獨白：責任明確但做好卻不易。

2015年2月17日星期二

Product Owner的技能

Feb. 16 17:00~17:52

快出來見客了，每天躲在家裡怎麼知道客戶需求？

昨天談了〈Product Owner的責任〉，今天繼續介紹《Essential Scrum》這本書提到PO所應具備的技能。

Domain Skills：PO帶領開發團隊實現產品的願景，如果PO不熟悉產品的領域知識，則很難期待他可以將產品願景良好的傳遞給團隊。除了具備領域知識以外，PO也必須理解，實現願景的道路並非完全清晰可見、暢通無阻，必須時時調整方現以便因應外在變化。
People Skills：PO是客戶代言人，必須與stakeholder和團隊維持良好的關係。要擺平各方人馬並不是件容易的事，有時候不同的stakeholder，或是團隊成員，對於產品各有不同且互相衝突的意見。此時PO就要從中協調與磋商，並讓大家建立共識。

PO也必須要具備強大的激勵技能。當遭遇到困難與挑戰的時候，PO要提醒大家「勿忘初衷」，激發大家對於產品的熱情。

Decision Making：PO承擔產品成敗責任，必須被充分授權以便可以做出決策。此外，PO也必須願意承擔這樣的重責大任，而不是把做決策的權利與義務交給上層主管負責（不要變成Boss-Centered Design；BCD）。
Accountability：能力越大，責任就愈大。PO負責產品成敗，必須承當資源被合理使用或被濫用的結果。PO也必須要負起梳理與調整product backlog的責任，有時甚至要勇敢做出取消已完成功能的決定。

還有一點很重要，也經常被誤解的點，就是PO、ScrumMaster、開發團隊，三者合在一起稱為Scrum Team。PO與開發團隊還有ScrumMaster之間是「我們」的關係，而不是「我們-他們」的關係。在負起產品成敗大責的情況下，PO必須尊重且信任開發團隊與ScrumMaster，大家一起朝向相同的目標前進。

***

友藏內心獨白：跟船長好像。

2015年2月16日星期一

Product Owner的責任

Feb. 15 20:04~23:01

有定期收看「搞笑談軟工」的鄉民應該知道在Scrum裡面，Product Owner（PO）需要負責專案成敗，以及決定product backlog item（PBI）的順序。但除此之外，PO還有其他責任嗎？今天讓我們看一下《Essential Scrum》這本書所提到PO所應負擔的主要責任有哪些。

Manage Economics：軟體開發不能不考慮經濟因素，XP也將此因素列為14個原則之ㄧ（請參考〈談談XP（2上）：Principle〉）。在Scrum框架中，PO要負責考慮三個不同層級的經濟因素：
- Release-Level Economics：在產品釋出的層級，PO必須在產品開發的生命週期內持續地決定產品的範圍、釋出日期、經費、品質等。例如，如果原本預計12個sprint要釋出產品，但是只要在多做2個sprint，很有可能可以幫公司多接到1000萬的案子。在這種情況下，要不要延後上市的時程？又例如，同樣的案子，到了第9個sprint的時候發現競爭對手的產品即將在2周後上市，這時候要不要決定提前上市？又或者，在每一個sprint結束時PO可以評估專案是否依然有價值，要繼續資助專案開發。
- Sprint-Level Economics：簡單的說，就是要採取value-driven的開發模式，確定團隊優先開發對客戶而言價值較高的需求。
- Product Backlog Economics：負責持續調整product backlog items的優先順序。
Participate in Planning：參與各種計畫會議，例如release planning與sprint planning。
Groom the Product Backlog：梳理product backlog，又稱為product backlog refinement workshop。
Define Acceptance Criteria and Verify That They Are Met：在撰寫story的同時，PO也需要定義驗收條件，並且確定開發團隊有滿足這些條件。實務上驗收條件可以由PO獨力撰寫完成，或是交由PO與團隊在product backlog refinement workshop一起合作撰寫。
Collaborate with the Development Team：PO應該持續與團隊保持密切的合作，而不是只有sprint的開頭和結尾與團隊見兩次面。關於這一點請參考〈產品負責人與團隊的互動（上）〉以及〈產品負責人與團隊的互動（下）〉。
Collaborate with the Stakeholders：對開發團隊而言，PO是stakeholder的代言人，PO必須與他們合作，盡可能地收集最接近使用者真正需要的需求，以便於將此需求傳達給開發團隊。