目前分類:Scrum and XP的實戰經驗 (65)

瀏覽方式: 標題列表 簡短摘要
14 . 我們怎樣做測試
 
藉由把測試人員放到Scrum團隊中來提高品質
 
14-2-1  
 

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

14 . 我們怎樣做測試
 
 
這是最困難的部份。我不確定是否它是Scrum中,最難的一部份。還是它在軟體開發中,通常也是最困難的部份。
 
在不同組織之間,測試可能是差異最大的部份。它依賴你有多少測試人員,有多少自動化,哪些型態的系統(只是伺服器+網頁應用程式?)發佈週期的長短,軟體的關鍵性(blog伺服器 v.s 飛行控制系統)等等。

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

13 我們如何結合Scrum和 XP 
 
漸進式設計
這意味著一開始設計就要保持簡單,然後持續去改進它。而不是一開始就試圖要所有的事情都正確,然後就凍結它。
 
我們這點上做的相當好,也就是,我們花了可觀的時間去重構,改進現有的設計。並且我們很少花時間去大規模的預先設計。當然,有時我們也會搞砸了。例如,允許一個搖搖欲墜的設計"陷入"的太深,導致後來的重構變成是一個大工程。但是整體來說,我們還相當滿意。

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

13 我們如何結合Scrum和 XP 
 
 
Scrum和XP結合後,可以帶來很多好處,這點是無須爭議的。網路上,我看到大部分的資料都支持這個論點,所以我不用再花時間去爭論為什麼。
 
好的,我注意到一件事。Scrum著重在管理以及組織的實踐。而XP大多著重於實際的編程實踐。那是為什麼它們可以一起運作的很好 - 它們解決不同領域的問題,並且互補對方的不足。

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

12. 我們如何做發佈計畫和處理固定價格的合約
 
 
估算速度
好的,所以我們對於最重要的故事,已經有了一些粗略的估算。 下一步就是估算每個Sprint平均的速度。

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

12. 我們如何做發佈計畫和處理固定價格的合約
 
 
有時候,一次只規劃一個Sprint要做的事情是不夠的,我們需要提前做更多計畫。尤其是處理固定價格的合約,我們必須事先規劃,否則我們將會有無法準時交付的風險。
 
對我們來說,發佈計畫是試圖去回答這樣的問題:"最晚是什麼時候,我們才能交付這個新系統的1.0版本"。

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

11. Sprint之間的休息時間
 
 
在實際生活中,你不能總是在衝刺。你需要在衝刺之間休息。如果你都是在做衝刺,你的效果可能只是像在慢跑。
 
這也適用於生活,不只是 Scrum!例如,如果我生活中沒有鬆懈的時間,本書就不會出現(更不用講第二版,或是我其他的書籍,文章,和視頻等等。)鬆弛對於生產力和個人福祉兩者來說,是超級重要的!如果你是行事曆老是滿檔的人,試試看這個:打開你的行事曆,每週凍結半天,寫下 ”鬆弛” 或是 ”不可預定” 或是其他。不要事先決定你在那個時候要做什麼,看看會發生什麼事 :o)

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

10. 我們如何做Sprint回顧
 
 
在團隊間散播所學到的教訓
在Sprint回顧會議中,所得的資訊通常是極度有價值的。團隊很難集中火力,是因為銷售經理強押開發人員,在銷售會議上充當技術專家? 這是非常重要的資訊。是否其他團隊可能也有相同的問題? 我們是否應該教育產品經理更多有關於產品的知識? 因此讓他們自己可以做銷售支持(sales support)。
 

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

10. 我們如何做Sprint回顧
 
 
為什麼我們堅持所有團隊都要做回顧會議呢?
有關回顧最重要的事情,就是確保回顧會發生。
 

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

9. 我們怎樣進行Sprint的展示
 
 
Sprint展示(有些叫它Sprint review)是Scrum中重要的一部份,但是人們都低估它。
 
"哦! 我們真的需要去展示嗎? 沒有啥好東西可以展示"

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

8. 我們怎麼進行每日會議
 
 
我們每日會議都按照書中進行。它們每天會在同一個地方,同一時間進行。在剛開始的時候,我們都是在一間單獨的房間中,舉行Sprint規劃會議(在那個時候,我們還使用電子板的Sprint backlogs)。然而,現在我們都在任務板前面舉行每日會議,沒有什麼能比它有更好的效果。
 
我們通常都是站著舉行會議,因為它可降低會議時間超過15分鐘的風險。

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

7. 我們如何安排團隊的座位和空間
 
 
設計的角落
我發現到,大部分最有趣和最有價值的設計討論,通常自然而然發生在任務板前面。
 

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

6. 我們怎麼撰寫Sprint backlogs 
 
 
你們已經走了這麼遠啊? 喔,幹得好。
 
現在我們已經完成Sprint規劃會議,並告訴大家我們下一個閃閃發光的新Sprint是什麼。接著是時候,讓Scrum master建立Sprint backlog。當Sprint規劃會議結束後,和第一次每日會議前,並需要把Sprint backlog給建立完。

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

5 我們如何溝通我們的Sprints
 
 
讓整個公司知道我們現在做什麼,這是非常重要的事情,否則其他人會抱怨。甚至更糟的事,會對我們做的事情做出錯誤的假設。
 
我們會使用"Sprint訊息頁"來處理這件事。  

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

技術性的故事
 
這裡有個很複雜得問題: 技術性的故事。或者非功能性項目,或者你想怎麼稱呼它都行。
 
每當某些人提到”非功能性需求”, 我就不禁咯咯地笑. 聽起來好像這個東西不是個功能 :o)
 

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

把故事拆解成更小的故事
 
故事不應該太小或是太大(以評估的角度來看)。如果你有一堆0.5故事點數的故事,你可能會是微觀管理的受害者。另一方面,若是你有 40 故事點數的故事,則代表你有高度風險會只做完一部分的故事而已。那對你公司是沒有價值的,並增加管理上的負擔。進一步來說。如果你們所評估的速度是 70,可是有兩個高優先順序的故事是 40,那這個規劃就非常困難。你可能有兩種選擇:承諾不足,意味你只選擇一個;或過度承諾,意味你選擇都做。
 
我發現多數大的故事可以拆解成小的故事。只要確認小的故事依然能有商業價值即可 
 

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

釐清故事內容
 
當團隊會自豪地,在Sprint展示會議中展示一個新的功能,最糟糕的事是產品負責人皺著眉頭,並說:“是的,看起來不錯,但是那不是我要的。” 
 
你如何確認產品負責人和團隊有相同的認知呢?或是團隊中每個人對故事有相同的理解呢?嗯,你可能無法確定。但是有一些簡單的方式,可以幫忙找出最明顯的誤解。最簡單的方式就是確保故事中,所有的欄位都被填寫(或是更具體地說,對於那些有高優先順序,需要在這個Sprint中完成的故事,都需要填寫)。

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

使用計畫紙牌來做時間規劃
 
估算是一項團體活動,每個團隊成員通常都要參加所有故事的估算,為什麼大家都要參加呢?
 
•    在規劃的時候,我們通常都不知道誰要負責實作故事中的哪個部份。
•    每個故事要求好幾人參加,並且要包括不同類型專長的人(使用者介面設計、程式撰寫、測試等等) 。

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

“做完”的定義
 
這一點是非常重要的,產品負責人和團隊必須同意,要對“做完”有一致的定義。
 
非常重要!
 

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

我們為什麼要使用索引卡
 
大部分Sprint的規劃會議,會花很多時間在討論產品backlog中故事的細節。要去評估它們,排定優先順序,釐清它們,以及進一步分解它們等等。 
 
那我們是怎麼做這些事情呢? 
 

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

1 234

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

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

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

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

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼