目前分類:Scrum (105)

瀏覽方式: 標題列表 簡短摘要
有位網友在 Facebook 問到,  Scrum 團隊中是否一定要有 Scrum Master? 他在 FB 的 po 文如下
 
 
一開始因為上班很忙, 並沒有太多時間想這個問題, 只是很衝忙地找了 Mike Cohn 的文章 po 了上去. 那篇文章的留言其實還蠻精彩的, 很多人給了不少意見. 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在某一場回顧會議中的對話:
 
A: 那個需求每次都很不明確, 所以在之後都要花很多時間釐清
B:  UI mock 花太多時間做了, 我們拿到時都已經很晚了
C: RD 應該對重要部分進行 code review, 否則後面品質好不穩
A: 測試人員太晚進行 performance test, 導致我們後面沒時間 turn system

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

工程師們對於技術的學習, 總是能很快地接受, 並且能夠舉一反三. 但是對於人之間的相處, 反應總是慢半拍, 並且感到怕怕. 所以回顧會議要能執行的好, 還真的不是件容易的事.
 
索引  
 
以下是一些個人小小心得, 跟大家一起分享一下:                                                                                             
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

Scrum Retrospective Meeting 是 Scrum 要進行的其中一項會議. 主要是要來檢討做事方法, 期待讓團隊更有效率.
 
5121009259_057210fd3d_z  
 
在這個過程中, 我觀察到會議往往會有這樣的壞味道, 就讓我們來瞧瞧這些是什麼:
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在 Scrum 的開發流程中, 提到了三個角色: 產品負責人(Product Owner), Scrum Master 和團隊. 在很多文章中, 大多會描述後面兩者要做什麼, 但是對於產品負責人的部分, 卻是介紹的不是很多, 因此很多人不是很清楚他要做什麼.
 
Photo-Nov-24-12-50-23  
 
一般來說, 大家比較熟悉的部分, 就是產品負責人需要撰寫產品需求, 並且對之排出優先順序. 可是就這麼簡單嗎? 事實上, 這樣是不夠的. 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

網路上有人提到, 知名導演和編劇 Andrew Stanton 認為, 我們喜歡聽故事, 是因為我們想肯定自己生命的意義, 而故事讓我們重新確認自己是個什麼樣的人.
 
storytelling1  
 
我們可以藉由聽別人的故事, 肯定別人生命的意義. 再藉由肯定別人的意義, 來肯定自己的意義. 所以故事就會變成了一座橋梁, 將人與人之間連結起來, 讓所有人成為一個由故事和理念組成的共同體.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

 
6235421713_a6a6d948e5_b  
 
Scrum Master 強調要僕人式領導. 也就是說, 他不一定具備正式領導職權, 但具有激勵合作, 信任, 傾聽, 授權和倫理等特徵.
 
Scrum Master 不該強迫團隊去做一些事情. 即使 Scrum 要求該那樣做. 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

Scrum 開發流程中, 第一道關卡就是要進行 sprint planning meeting. 在這個會議中, 你需要找出要做哪些故事, 並且將這個故事拆解成 task. 
 
那要怎麼進行呢? 這裡有篇文章介紹了他們如何進行 sprint planning meeting, 大家可以參考一下.
 
Sprint-Planning  
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

Scrum 藉由頻繁交付, 可以讓你的缺點即早曝露, 因此你可以及早修正. 
 
因此, 有人說, Scrum 是一面鏡子, 他會把你的行為, 一舉一動, 呈現出來給大家看, 所以你才知道你哪裡有問題.  
 
螢幕快照 2015-05-05 下午8.44.34  
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

之前看了Henrik Kniberg 的Agile Product Ownership in a Nutshell 的 video (https://www.youtube.com/watch?v=502ILHjX9EE ), 外加 Daniel Teng 的教誨, 對於 Agile/Scrum 有更深一層的感觸. 以下是整理出來產品負責人 (Product owner) 應該注意的事情:
 
complete-product-owner-title  
 
1. 知道為什麼比知道要做什麼重要
知道客戶為什麼要, 或者他遭遇到什麼問題, 會比只是知道要做什麼功能還重要. 所以你需要花時間去瞭解客戶, 通常你會利用 design thinking, empathy, user journey map 等技巧, 瞭解客戶背後的問題. 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在 Amazon 中, 針對 Scrum: The Art of doing Twice the work in half the time 一書, Bas Vodde  對它寫了一些評論:
 
scrum-jeff-sutherland-cover  
 
在裡面有幾句話寫得非常好, 深深地打動我:

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

這裏有一份產品負責人 (Product Owner) 的檢查清單. 可以讓大家參考需要會什麼東西:
 
CustomerProxyPorductOwner  
 
1. 啟動一個新的產品或是史詩級的故事
     a. 和團隊, 利害關係人, 和顧客一起建立願景

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在 Scrum 裡面, 每當 sprint 結束後, 需要進行回顧會議 (retrospective), 以檢討在這個過程中那些地方需要改進.
 
happy-retro  
 
可惜,我問過很多執行 scrum 的團隊, 大多數的人都不太進行這個會議. 老中會努力工作, 可惜不太懂得改進自己的工作流程, 或者是做事方法. 因此加班時數總是最多, 但是成效卻不見得比別人好.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在敏捷團隊中, 我們會想用視覺化的方式, 來將一些資訊呈現出來, 好讓大家可以很清楚知道專案目前的狀態.
 
常見的道具, 像是 burn down chart 或者 task board, 就是用來顯示目前專案的進度, 以及工作處理的狀況. 
 
可是除了專案的狀態可以視覺化外, 還有人想出了想把成員的心情也給視覺化. 它叫做 Niko Niko calendar. 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

Scrum 中有一個東西叫做產品需求清單 (product backlog), 大家可能不太清楚, 怎樣的 product backlog 內容才是合宜.
 
06fig06  
 
Roman Pichler 和 Mike Cohn 認為一個好的產品需求清單 (product backlog), 應該具備以下特性:
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在實施 Scrum 時, 我們會利用 definition of done, 來定義什麼叫做一個功能做完. 這可以避免大家對於做完的標準有不同解釋, 並且也讓大家在評估時, 會把該做的事情都考慮進去.
 
可是, 有時候問題不是只有出在功能做完沒有共識,  有時候問題是出在這個功能是否已經準備就緒. 如果這個功能沒有被適當的規劃, 而工程師卻開始去實作它, 那將會是一場災難. 因為你可能會做到沒有價值的功能, 或者是花很多時間來釐清需求內容.
 
為了避免這樣的問題發生, scrum 裏就提出了 defintion of ready 這個觀念, 希望在開發這個功能前, 就能確保這個功能是已經準備就緒的.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

什麼是需求呢? 根據維基的定義, 需求是軟體開發時應滿足的功能與非功能要求.
 
在傳統瀑布式的開發中, 我們是靠著產品經理, 或者是系統分析師, 撰寫詳細的需求文件, 然後交給開發人員進一步去做設計.
 
在這過程中, 我想大家一定遇到這些問題:
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

對於需求的處理, 瀑布式和 Scrum 兩者有著截然不同作法, 讓我們看看他們各自如何進行
 
螢幕快照 2015-03-22 下午7.59.15  
 
瀑布式
1. 早期就已經訂定好所有細節.

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

Scrum 開發方法中, 包含三個角色: Scrum Master, 產品負責人(Product Owner), 和團隊. 很多人對於團隊要包含誰, 常常有不同的見解. 那到底正解是什麼呢? 
 
scrum  
 
從 Ken Schwaber 和 Jeff Sutherland 所撰寫的 Scrum Guide 中, 便對這件事情做了說明. 他們把團隊分成了兩類:
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

很多團隊或公司實施 Scrum 並不順利, 明明就是很簡單的 framework, 道理也很清楚, 可是卻做不到 Scrum 所說的境界, 為什麼呢?
 
scrum-1  
 
我想這是因為大家認為 Scrum 就是一種軟體開發流程, 認為只要照著步驟做就好了. 事實上, 這是不對的. 要做好 Scrum, 你必須考慮到組織模式, 以及實施的人們. 缺乏這兩個, 是無法成事的.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

找更多相關文章與討論

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼