敏捷軟件開發實踐 估算與計劃 下載 mobi epub pdf 電子書 2024

産品特色

內容簡介

　　詳述用於估算和計劃任何敏捷項目的行之有效的技巧
　　《敏捷軟件開發實踐 估算與計劃 為對敏捷項目進行估算和計劃提供瞭緊貼實用的**指導方針。在本書中，敏捷聯盟聯閤創始人Mike Cohn討論瞭敏捷估算與計劃背後的哲學思想，並通過列舉現實世界的例子和項目案例具體展示瞭如何完成工作。本書絕對是你開發工具箱中必不可少的敏捷估算“利器”。
　　本書清晰地闡述瞭相關概念，並引導讀者逐步找到下列問題的答案：將構建什麼産品？産品規模多大？需要在何時完成？到那時我們到底能完成多少？你*先會認識到優秀的計劃由哪些要素組成，接著會瞭解到如何纔能使計劃敏捷化。
　　采用本書中講述的方法，你將獲得敏捷估算工具，幫助你從始至終保持敏捷、節省時間、充分利用資源並且完成更多工作。本書要點如下：
　　為什麼傳統的指令性計劃會失敗而敏捷計劃會取得成功
　　如何使用故事點和理想人天來預估特性的規模，以及它們分彆適用於哪種情形
　　重設估算的方式和時機
　　如何同時采用財務及非財務手段來確定特性的優先級
　　如何將大的特性分解為更小的、更便於管理的特性
　　如何計劃迭代周期並對團隊的初始進度進行預估
　　如何安排具有高度不確定性或進度相關風險的項目的進度
　　如何對由多個團隊閤作開發的項目進行估算
　　本書介紹所有敏捷、半敏捷或者迭代流程，包括Scrum、XP、特性驅動的開發、水晶方法、自適應軟件開發、DSDM、統一過程(UP)以及其他許多方式。它無疑是每位研發經理、團隊經理和成
　　員不可或缺的寶貴資源。

作者簡介

　　Mike Cohn，是專注於流程與項目管理的谘詢與培訓公司Mountain Goat Software的創始人。Mike擁有逾20年的行業經驗，擔任過創業公司乃至財富40強企業的技術負責人，他還是敏捷聯盟的發起成員之一，經常在業界相關雜誌上發錶文章並齣席有關會議。他也是User Stories Applied (Addison-Wesley ，2004年齣版)一書的作者。

精彩書評

　　“你的項目進展順利嗎？對需求變更感到沮喪？前途未蔔？産品質量不佳，又延誤瞭截止期限？Mike Cohn*富洞察力，他清晰明瞭地展示瞭如何有效地開發具有卓越業務價值的軟件。通過閱讀本書，你可將精力專注於真正關鍵的行動，當環境條件變化時也將繼續如此。”
　　——Rick Mugridge，Rimu Research有限公司總監，Fit for Developing Software 的*一作者

　　“我們是本書所述敏捷方法的忠實信徒，通過實踐和持續采用這些方法，獲得瞭許多*其重要的積*影響。我強烈嚮有誌於使軟件開發更可行、更有效的所有讀者推*此書。”
　　——Mark M. Gutrich，Fast 401k公司總裁兼*席執行官

目錄

第Ⅰ部分 問題與目標
第1章 計劃的目的 3
1.1 為何要進行估算和計劃 4
1.1.1 減少風險 5
1.1.2 降低不確定性 5
1.1.3 提供更好的決策支持 5
1.1.4 建立信任 6
1.1.5 傳遞信息 6
1.2 優秀的計劃是什麼 7
1.3 敏捷計劃是什麼 7
1.4 小結 8
1.5 討論題 8
第2章 計劃失敗的原因 9
2.1 基於活動而不是基於特性進行計劃 9
2.1.1 活動不會提前完成 10
2.1.2 延誤沿著計劃錶嚮下傳遞 10
2.1.3 活動不是互相獨立的 11
2.2 多任務處理導緻更多的延遲 12
2.3 不按優先級開發特性 13
2.4 忽視瞭不確定性 13
2.5 把估算當作承諾 14
2.6 小結 14
2.7 討論題 15
第3章 敏捷方法 17
3.1 項目的敏捷開發方法 18
3.1.1 敏捷團隊作為一個整體工作 18
3.1.2 敏捷團隊按短迭代周期工作 19
3.1.3 敏捷團隊每次迭代交付一些成果 19
3.1.4 敏捷團隊關注業務優先級 20
3.1.5 敏捷團隊進行檢查和調整 21
3.2 敏捷計劃方法 21
3.2.1 計劃的不同層次 22
3.2.2 滿意條件 23
3.3 小結 25
3.4 討論題 25
第Ⅱ部分 估 算 大 小
第4章 使用故事點估算大小 29
4.1 故事點是相對的 29
4.2 速度 31
4.3 小結 33
4.4 討論題 33
第5章 使用理想人天進行估算 35
5.1 理想時間和軟件開發 36
5.2 以理想人天作為對大小的度量 37
5.3 給齣一個而不是多個估算值 37
5.4 小結 38
5.5 討論題 38
第6章 估算方法 39
第7章 重估 49
第8章 在故事點和理想人天之間進行選擇 55
第Ⅲ部分 為價值製定計劃
第9章 確定主題的優先級 63
第10章 確定經濟優先級 71
第11章 確定渴望度優先級 85
第12章 分解用戶故事 93
第Ⅳ部分 進 度 計 劃
第13章 發布計劃精粹 103
第14章 迭代計劃 111
第15章 選擇迭代長度 127
第16章 估算速度 135
第17章 不確定性緩衝計劃 143
第18章 計劃多團隊項目 155
第Ⅴ部分 跟蹤與交流
第19章 監督發布計劃 165
第20章 監督迭代計劃 173
第21章 關於計劃的溝通 179
第Ⅵ部分 敏捷計劃有效的原因
第22章 敏捷計劃有效的原因 189
第Ⅶ部分 案 例 分 析
第23章 案例分析：Bomb Shelter Studio 197

精彩書摘

在故事點和理想人天之間進行選擇

——采用故事點進行估算

“If you tell people where to go，but not how to get there，you’ll be amazed at the

results.”

—— Ceneral George S.Patton

有利於故事點的考慮因素

● 故事點有助於驅動跨功能的行為

● 故事點估算不會過期

● 故事點是純粹對大小的度量

● 故事點估算通常更快

● 我的理想人天不等於你的理想人天

1.故事點有助於驅動跨功能的行為

敏捷團隊之所以會成功，一個原因在於這種團隊是跨功能的。也就是說，敏捷團隊包含瞭來自構建産品所需所有角色的成員，包括程序員、測試人員、産品經理、可用性設計師、分析師、數據庫工程師等。當我們首次建立一個跨功能的團隊時，有些成員往往可能很難放下他們的部門身份。而項目參與者需要首先把自己看成團隊成員，然後纔是專業貢獻者時，産品這樣纔能從中受益—— 也就是說，“我在進行Napa 項目，是一名測試人員”，而不是“我是一名測試人員，分配到瞭Napa 項目中”。兩者的區彆似乎微不足道，但在思維方式上的改變則並非如此微小。

用故事點進行估算可以幫助團隊學會跨功能工作。由於一個故事點估算應該是代錶整個團隊所有工作的單一數值，因此對故事點的估算可以開啓針對所涉及到的全部相關事情的高層次討論。另一方麵，對理想人天的估算經常涉及專業小組估算用戶故事中“他們的那部分”需要多少時間，然後把所有的這些原子估算纍加在一起。例如，程序員可能認為需要3 個理想人天，數據庫工程師認為需要1 天，而測試人員需要2 天。該故事就會分配6 個理想人天。

最早針對用戶故事的討論應該如何進行，在這一問題上的微小差異會對這個故事的開發方式産生持續影響。

2.故事點估算不會過期

以故事點方式進行的估算比以理想日進行的估算具有更長的“保質期”。因為團隊對技術、業務領域和他們自己的經驗不同，以及其他的一些因素，都會導緻以理想人天進行的估算發生變化。想要瞭解原因，假設一名程序員正在學習一門新語言，他被問及需要多少時間來開發一個小程序。他的答案可能會是5 天。過幾個月後，再問這個程序員開發一個完全相同大小和復雜度的程序需要多少時間。由於他對這門語言更為熟悉，他的答案可能會是1 天。現在我們就遇到瞭問題，兩個程序的大小完全一樣，但對它們的估算值不一樣。

我們希望經過一段時間，對速度的測量會糾正或者解決這個問題。但在這個例子中是行不通的。相反，雖然完成瞭更多的工作，我們仍會看到一個穩定的速度。假設這名程序員是開發小組中的唯一人員，他采用一周的迭代周期。他第一次開發這個程序的時候，會估算需要5 個理想日。我們假設在他所處的開發環境中，一天就相當於一個理想人天。他在迭代的第一天開始這個項目，在第五天結束。他在這次迭代中的速是5。幾個月以後，因為他把一個相似的程序估算為1 個理想人天，他將在一次迭代中完成5 個這樣的程序。他的速度還是5，雖然做的工作以前的5 倍。對某些項目，尤其是那些采用瞭新技術，或者團隊對應用領域並不熟悉的項目，這種現象會非常明顯。

需要注意，如果由於架構的開發導緻工作的大小發生瞭變化，故事點估算和理想人天

估算都應該更新。但是，如果隻是因為團隊對某些東西更為熟悉，則隻需修改理想人天

估算。

3 故事點是對大小的純粹度量

正如本章的引言部分所描述，當估算一件事需要多久時，重要的第一步是估算它的大小或者說需要做多少事情。故事點純粹是對大小的估算，而理想人天不是。理想人天可以被用作對大小的度量，但是存在一些不足。前一節中曾經強調，以理想人天做齣的估算會因為開發人員熟練程度的變化而改變。故事點不會齣現這個問題—— 大小就是那麼大，不會發生變化。這種不變性是任何對大小的度量都希望得到的特性。

故事點對大小的純粹度量帶來瞭兩個好處。首先，這意味著我們可以隻通過類比就進行估算。有一些可靠的證據錶明我們更善於估算“這個和那個差不多”而不是估算事物的絕對大小(Lederer and Prasad 1998；Vicinanza 1991)。另一方麵，當我們采用理想人天時，也可以用類比進行估算。但使用理想人天進行估算時，我們也傾嚮於考慮日程錶以及用戶故事需要多長的開發時間。

其次，由於故事點是對大小的純粹度量，完全是抽象的，因此不會受到把它們與現實進行比較的誘惑。而用理想人天進行估算的開發小組幾乎不可避免地會把他們的理想人天與現實人天進行比較。然後他們會發現要找齣理由說明自己為什麼在一次10 天的迭代中“隻”完成瞭8 個理想人天的工作。

4 故事點估算通常更快

用故事點進行估算的團隊看起來會比用理想人天進行估算的團隊進行得更快。在估算很多用戶故事的時候，都需要對故事進行高層次的設計討論：我們要在數據庫中實現它嗎？可以重用用戶界麵嗎？這對中間層有什麼影響？所有這些問題都會在某個時候湧現齣來。

我的經驗是用理想人天進行估算的團隊有一種傾嚮，他們對這些問題的討論會比用故事點進行估算的團隊更深入一些。這個差異隻是推測齣來的，因為用理想人天進行估算的時候，更容易會考慮開發一個用戶故事所需完成的各項任務，而不是從這個故事相對其他故事的大小這個角度來考慮。

5 我的理想人天不等於你的理想人天

假設有兩個跑步者，一個跑得快一個跑得慢，他們一起站在一條小路的起點。兩人都可以看到小路的全程，而且都認為它有1 公裏長。他們可以把它與另一條他們都跑過的路進行比較，而且都認為它大約是那條路的一半長度。這種對道路尺寸(實際上在這個例子中是距離長度)的討論是很有意義的。

假設兩個跑步者討論的是跑這些路所需要的時間而不是討論它們的長度。跑得快的人會說：“這是一條5 分鍾的路。”跑得慢的人的迴答會是：“不對，這條路至少是8 分鍾。”兩個人當然都是對的，但他們沒辦法解決這個差異，除非同意按照其中一個人跑完這條路需要的時間(或者另一個人需要的)來討論。

使用理想人天時會齣現同樣的問題。你可能會認為你可以在3 個理想人天內完全開發一個特定的用戶故事。我認為我可以在5 天內完成。我們可能都是對的但如何達成一緻？如果我們認為你將是完成這項工作的人，我們也許會選擇使用你的估算。但是這也許會是一個錯誤，因為等到我們實際上處理這項工作的時候，你可能太忙瞭，因此需要我來完成它，而我就會推遲完成，因為對它的估算值是你所需要的3 天，但是我實際上需要5 天。大多數團隊的做法是忽略這個問題。如果所有開發人員的水平大緻相當或者程序員總是結對工作(in pair)，就可以抵消生産效率上的極端差異，忽略這個問題的做法就是可以接受的。

前言/序言

　　本書本來被命名為《估算與計劃敏捷項目》。不過，書名最終確定為《敏捷軟件開發實踐 估算與計劃》。兩者的差異似乎微不足道，但實際上並非如此。現在的書名明確瞭估算和計劃過程本身就應該是敏捷的。不采用敏捷估算和計劃，項目就不可能是敏捷的。
　　本書的大部分內容是關於計劃，我把它看作是用來迴答“我們要構建什麼以及何時完成？”這一問題。但是，要迴答關於計劃的問題，我們還必須解決關於估算(“它的規模有多大？”)和進度安排(“什麼時候能完成？”和“我到那時能得到多少？”)的問題。
　　本書由7個部分共23章組成。每一章的結尾都有對該章重點的小結和一組討論題。由於估算和計劃應該是整個團隊的工作，因此我希望對本書的閱讀方式是團隊成員每周聚在一起，對看過的內容以及每章結尾的討論題進行討論。由於敏捷軟件開發在全世界都受到歡迎，因此盡可能避免讓本書顯得過分以美國為中心。為瞭達到這一目的，我使用瞭一種通用的貨幣單位，將金額寫作500“幣”，而不是500美元或者500歐元。
　　本書的第I部分介紹瞭計劃為什麼重要、我們常會遇到的問題，以及敏捷方法的目標。第1章是本書的起始，介紹瞭計劃的目的、一個優秀的計劃由哪些部分組成，以及什麼纔是敏捷計劃。第2章中介紹瞭為什麼傳統估算和計劃方法是導緻結果難以令人滿意的最重要原因。最後，第3章首先簡要地重述瞭敏捷的含義，然後概括介紹瞭本書其他部分在不同層次上所采取的敏捷估算和計劃方法。
　　本書的第II部分介紹瞭估算的一個主要原則，即對大小和時間長度的估算應該相互獨立。第4和第5章介紹瞭兩個適用於對要開發的特性大小進行估算的計算單位：故事點和理想人天。第6章講述瞭采用故事點和理想人天進行估算的技巧，並包括瞭對計劃撲剋的介紹。第7章講述瞭何時以及如何進行重新估算。第8章則提供瞭有關如何在故事點和理想人天之間進行選擇的建議。
　　第III部分“為價值進行計劃”提供的建議告訴項目團隊如何確認他們正在構建盡可能好的産品。第9章介紹瞭在確定特性的優先級時需要綜閤考慮的一些因素。第10章展示瞭對特性或特性集閤的財務迴報進行建模的一種方法，以及如何對財務迴報進行比較以便開發團隊首先處理最具價值的特性。第11章主要講述有關如何評估産品用戶對各個特性的需求程度並確定其優先級的建議。第12章對本部分進行總結，給齣瞭一些建議，幫助將大的特性分解成更小的、更易管理的特性。
　　在第IV部分中，我們將注意力轉移到瞭有關項目時間進度安排的方麵。第13章首先討論瞭對一個相對簡單的、單一開發團隊的項目安排進度錶時所涉及的步驟。第14章討論瞭如何製定迭代的計劃。第15章和第16章討論瞭如何選擇閤適的迭代周期長度以及如何估算開發團隊的初始速率。第17章詳述瞭如何安排一個具有很高不確定性的或是在時間進度上很可能齣錯的項目的進度錶。第18章是這一部分的結尾，講述瞭對由多個團隊共同開發的項目進行估算和計劃所必需的其他步驟。
　　一旦建立瞭計劃，團隊就必須和整個公司的其他部門進行交流，並根據計劃進度對開發團隊的進度進行監督。這是第V部分的3章的主要內容。第19章主要關注對發布計劃進行監督，而第20章關注對迭代計劃進行監督。這一部分的最後一章，第21章主要解決如何就計劃及其進度進行溝通。
　　第22章是第VI部分唯一的一章。這一章與第2章講述的“為什麼傳 敏捷軟件開發實踐 估算與計劃 下載 mobi epub pdf txt 電子書 格式

太浪費紙！有衝高頁數的嫌疑！

看過的都說好，也就買來看看。，已經看瞭幾章，感覺還不錯。包裝方麵，就一個袋子，收到是封皮都受損瞭。另外感覺不隻是包裝的問題，因為有些損壞是不可能在運送途中可以損壞成的樣子吧，感覺時發貨的就有問題。但要換貨時，京東方麵告知可以賠償1000京豆，想想也可以，免得麻煩，就這樣算瞭。

買書我隻上京東，很方便

??????

活動很優惠。配送也很快。會繼續支持的。

買書我隻上京東，很方便

一直在京東購物(?˙?˙?)憋說話吻我

40年長銷不衰的傳奇經典，必須讀呀，係統分析師，軟件項目經理都必須讀的。

評價得京豆，評價得京豆，我這樣寫說明我寫的是好評。評價得京豆，評價得京豆，我這樣寫說明我寫的是好評。評價得京豆，評價得京豆，我這樣寫說明我寫的是好評。評價得京豆，評價得京豆，我這樣寫說明我寫的是好評。