目前分類：Scrum and XP的實戰經驗 (65)
- Oct 29 Thu 2015 21:31
Scrum 和 XP 的實戰經驗(2nd) - Ch14-2
- Oct 27 Tue 2015 23:29
Scrum 和 XP 的實戰經驗(2nd) - Ch14-1
14 . 我們怎樣做測試
這是最困難的部份。我不確定是否它是Scrum中，最難的一部份。還是它在軟體開發中，通常也是最困難的部份。
在不同組織之間，測試可能是差異最大的部份。它依賴你有多少測試人員，有多少自動化，哪些型態的系統(只是伺服器+網頁應用程式？)發佈週期的長短，軟體的關鍵性(blog伺服器 v.s 飛行控制系統)等等。
- Oct 19 Mon 2015 20:08
Scrum 和 XP 的實戰經驗(2nd) - Ch13-2
13 我們如何結合Scrum和 XP
漸進式設計
這意味著一開始設計就要保持簡單，然後持續去改進它。而不是一開始就試圖要所有的事情都正確，然後就凍結它。
我們這點上做的相當好，也就是，我們花了可觀的時間去重構，改進現有的設計。並且我們很少花時間去大規模的預先設計。當然，有時我們也會搞砸了。例如，允許一個搖搖欲墜的設計"陷入"的太深，導致後來的重構變成是一個大工程。但是整體來說，我們還相當滿意。
- Oct 12 Mon 2015 23:08
Scrum 和 XP 的實戰經驗(2nd) - Ch13-1
13 我們如何結合Scrum和 XP
Scrum和XP結合後，可以帶來很多好處，這點是無須爭議的。網路上，我看到大部分的資料都支持這個論點，所以我不用再花時間去爭論為什麼。
好的，我注意到一件事。Scrum著重在管理以及組織的實踐。而XP大多著重於實際的編程實踐。那是為什麼它們可以一起運作的很好 - 它們解決不同領域的問題，並且互補對方的不足。
- Oct 05 Mon 2015 22:14
Scrum 和 XP 的實戰經驗(2nd) - Ch12-2
- Oct 04 Sun 2015 21:07
Scrum 和 XP 的實戰經驗(2nd) - Ch12-1
12. 我們如何做發佈計畫和處理固定價格的合約
有時候，一次只規劃一個Sprint要做的事情是不夠的，我們需要提前做更多計畫。尤其是處理固定價格的合約，我們必須事先規劃，否則我們將會有無法準時交付的風險。
對我們來說，發佈計畫是試圖去回答這樣的問題："最晚是什麼時候，我們才能交付這個新系統的1.0版本"。
- Sep 23 Wed 2015 22:43
Scrum 和 XP 的實戰經驗(2nd) - Ch11
11. Sprint之間的休息時間
在實際生活中，你不能總是在衝刺。你需要在衝刺之間休息。如果你都是在做衝刺，你的效果可能只是像在慢跑。
這也適用於生活，不只是 Scrum！例如，如果我生活中沒有鬆懈的時間，本書就不會出現（更不用講第二版，或是我其他的書籍，文章，和視頻等等。）鬆弛對於生產力和個人福祉兩者來說，是超級重要的！如果你是行事曆老是滿檔的人，試試看這個：打開你的行事曆，每週凍結半天，寫下 ”鬆弛” 或是 ”不可預定” 或是其他。不要事先決定你在那個時候要做什麼，看看會發生什麼事 :o)
- Sep 13 Sun 2015 08:35
Scrum 和 XP 的實戰經驗(2nd) - Ch10-2
10. 我們如何做Sprint回顧
在團隊間散播所學到的教訓
在Sprint回顧會議中，所得的資訊通常是極度有價值的。團隊很難集中火力，是因為銷售經理強押開發人員，在銷售會議上充當技術專家？ 這是非常重要的資訊。是否其他團隊可能也有相同的問題？ 我們是否應該教育產品經理更多有關於產品的知識？ 因此讓他們自己可以做銷售支持(sales support)。
- Sep 13 Sun 2015 08:29
Scrum 和 XP 的實戰經驗(2nd) - Ch10-1
- Sep 03 Thu 2015 21:17
Scrum 和 XP 的實戰經驗(2nd) - Ch9
9. 我們怎樣進行Sprint的展示
Sprint展示(有些叫它Sprint review)是Scrum中重要的一部份，但是人們都低估它。
"哦！ 我們真的需要去展示嗎？ 沒有啥好東西可以展示"
- Aug 30 Sun 2015 21:25
Scrum 和 XP 的實戰經驗(2nd) - Ch8
8. 我們怎麼進行每日會議
我們每日會議都按照書中進行。它們每天會在同一個地方，同一時間進行。在剛開始的時候，我們都是在一間單獨的房間中，舉行Sprint規劃會議(在那個時候，我們還使用電子板的Sprint backlogs)。然而，現在我們都在任務板前面舉行每日會議，沒有什麼能比它有更好的效果。
我們通常都是站著舉行會議，因為它可降低會議時間超過15分鐘的風險。
- Aug 24 Mon 2015 23:02
Scrum 和 XP 的實戰經驗(2nd) - Ch7
- Aug 23 Sun 2015 20:06
Scrum 和 XP 的實戰經驗(2nd) - Ch6
6. 我們怎麼撰寫Sprint backlogs
你們已經走了這麼遠啊？ 喔，幹得好。
現在我們已經完成Sprint規劃會議，並告訴大家我們下一個閃閃發光的新Sprint是什麼。接著是時候，讓Scrum master建立Sprint backlog。當Sprint規劃會議結束後，和第一次每日會議前，並需要把Sprint backlog給建立完。
- Aug 19 Wed 2015 23:10
Scrum 和 XP 的實戰經驗(2nd) - Ch5
5 我們如何溝通我們的Sprints
讓整個公司知道我們現在做什麼，這是非常重要的事情，否則其他人會抱怨。甚至更糟的事，會對我們做的事情做出錯誤的假設。
我們會使用"Sprint訊息頁"來處理這件事。
- Aug 17 Mon 2015 20:56
Scrum 和 XP 的實戰經驗(2nd) - Ch4-13
技術性的故事
這裡有個很複雜得問題： 技術性的故事。或者非功能性項目，或者你想怎麼稱呼它都行。
每當某些人提到”非功能性需求”, 我就不禁咯咯地笑. 聽起來好像這個東西不是個功能 :o)
- Aug 16 Sun 2015 22:29
Scrum 和 XP 的實戰經驗(2nd) - Ch4-12
把故事拆解成更小的故事
故事不應該太小或是太大(以評估的角度來看)。如果你有一堆0.5故事點數的故事，你可能會是微觀管理的受害者。另一方面，若是你有 40 故事點數的故事，則代表你有高度風險會只做完一部分的故事而已。那對你公司是沒有價值的，並增加管理上的負擔。進一步來說。如果你們所評估的速度是 70，可是有兩個高優先順序的故事是 40，那這個規劃就非常困難。你可能有兩種選擇：承諾不足，意味你只選擇一個；或過度承諾，意味你選擇都做。
我發現多數大的故事可以拆解成小的故事。只要確認小的故事依然能有商業價值即可
- Aug 13 Thu 2015 20:17
Scrum 和 XP 的實戰經驗(2nd) - Ch4-11
釐清故事內容
當團隊會自豪地，在Sprint展示會議中展示一個新的功能，最糟糕的事是產品負責人皺著眉頭，並說：“是的，看起來不錯，但是那不是我要的。”
你如何確認產品負責人和團隊有相同的認知呢？或是團隊中每個人對故事有相同的理解呢？嗯，你可能無法確定。但是有一些簡單的方式，可以幫忙找出最明顯的誤解。最簡單的方式就是確保故事中，所有的欄位都被填寫(或是更具體地說，對於那些有高優先順序，需要在這個Sprint中完成的故事，都需要填寫)。
- Aug 10 Mon 2015 17:15
Scrum 和 XP 的實戰經驗(2nd) - Ch4-10
使用計畫紙牌來做時間規劃
估算是一項團體活動，每個團隊成員通常都要參加所有故事的估算，為什麼大家都要參加呢？
• 在規劃的時候，我們通常都不知道誰要負責實作故事中的哪個部份。
• 每個故事要求好幾人參加，並且要包括不同類型專長的人(使用者介面設計、程式撰寫、測試等等) 。
- Aug 10 Mon 2015 17:04
Scrum 和 XP 的實戰經驗(2nd) - Ch4-9
- Aug 05 Wed 2015 20:51
Scrum 和 XP 的實戰經驗(2nd) - Ch4-8
我們為什麼要使用索引卡
大部分Sprint的規劃會議，會花很多時間在討論產品backlog中故事的細節。要去評估它們，排定優先順序，釐清它們，以及進一步分解它們等等。
那我們是怎麼做這些事情呢？
