《Scrum敏捷軟件開發(fā)》是敏捷聯(lián)盟及Scrum聯(lián)盟創(chuàng)始人之一、敏捷估算及計劃的鼻祖Mike Cohn三大經(jīng)典著作中影響最為深厚的扛鼎之作,也是全球敏捷社區(qū)中獲得廣泛肯定的企業(yè)敏捷轉(zhuǎn)型權(quán)威參考。作者花四年時間,把自己近十五年的敏捷實踐經(jīng)驗,特別是近四年中針對各種敏捷轉(zhuǎn)型企業(yè)的咨詢和指導(dǎo)工作,并結(jié)合旁征博引的方式,從更高的思想層次對敏捷與Scrum多年來的經(jīng)驗和教訓(xùn)進行深入而前面的梳理和總結(jié),最終集大成者便是這本令人醍醐灌頂?shù)募炎鳌?br> 《Scrum敏捷軟件開發(fā)》是軟件企業(yè)及其管理團隊成功進行敏捷轉(zhuǎn)型戰(zhàn)略及實施的必備參考書,適合經(jīng)理、開發(fā)人員、教練、ScrumMaster、產(chǎn)品負(fù)責(zé)人、分析師、團隊領(lǐng)導(dǎo)或項目領(lǐng)導(dǎo),是幫助他們成功完成項目,甚至造就敏捷企業(yè)的重要參考。
前 言
這本書不是為那些剛接觸Scrum或敏捷概念的人們而準(zhǔn)備的。有其他書籍、課程甚至網(wǎng)站可以幫助他們。如果你在Scrum方面是新人,可以從其中的一種方式著手。這本書也不是為那些純粹主義者而準(zhǔn)備的(譯者注:純粹主義者指特別執(zhí)著于完美理論闡述的人)。他們其實可以找到很多這方面的博客,來爭辯什么是真正的敏捷或Scrum。這本書為實用主義者而生。寫給那些已經(jīng)開始嘗試Scrum且可能已經(jīng)遇到一些問題的人,以及那些雖然沒有開始但已經(jīng)按捺不住躍躍欲試的人。這些人需要的已經(jīng)不是關(guān)于如何畫一張燃盡圖,或者是在每日站會上如何給出三個問題的答案等入門介紹。他們需要的是一些更加高階的課題--比如如何在企業(yè)或者項目中引入Scrum,并進行推廣,如何幫助人們在項目初期放棄大的設(shè)計,如何在每個Sprint交付可以工作的軟件,經(jīng)理應(yīng)該做什么,等等。如果這些課題你似曾相識,本書正好可以滿足你的需要!
本書借助我過去15年的Scrum經(jīng)驗(特別是最近四年以來的經(jīng)驗),來幫助大家找到這些問題的答案。在最近的四年中,每次我見完一個客戶,就會在晚上回到酒店后整理和記錄他們面臨的難題、他們提出的疑問及我當(dāng)時所給出的建議。然后我會通過回訪或者電子郵件的方式進一步跟蹤這些問題。我只想通過實踐真切地確認(rèn)我的哪些建議能最終解決哪些方面的問題。
在不斷收集這些難題、疑問及建議后,我整理出一些共通的主題。有一些困難是個別客戶及團隊所特有的。其他的則是大家普遍遇到的。這些普遍的共通問題及我所給出的克服這些困難的建議構(gòu)成了本書的基礎(chǔ)。這個思路清楚體現(xiàn)在兩個方面:首先,大部分章節(jié)都包含一個特色小節(jié)"試一試"。它們是我最常用的建議或者是我認(rèn)為在某些場景下非常有益的實踐。其次,大多數(shù)章節(jié)也包含另一個小節(jié)"反對"。我試著在這個小節(jié)中重現(xiàn)我曾經(jīng)在一些與客戶的對話中遇到的典型的反對的意見。當(dāng)你讀到這些反對的聲音時,試著聽聽你的伙伴的意見。我猜你一定曾經(jīng)聽到過很多類似的反對意見。在這些小節(jié)中,你會看到我常用的解決辦法。
關(guān)于讀者的其他假設(shè)
除了假設(shè)你已了解Scrum基礎(chǔ)知識,并且現(xiàn)在打算在公司內(nèi)引入Scrum,或者期望精通Scrum,我還假設(shè)你在公司中有一定的影響力。這當(dāng)然不是說本書只是為總監(jiān)、副總裁和CEO而準(zhǔn)備的。我所假設(shè)的影響力指的只是你在你所在的工作崗位上,不管它具體是什么崗位,你所具有的個人魅力和個人信用所帶來的對同事的影響力。當(dāng)然,一個好的職位會有所幫助。但是我們會看到,成功的Scrum執(zhí)行所需要的影響力通常來自于意見領(lǐng)袖。
本書的結(jié)構(gòu)
四年前當(dāng)我開始寫作本書的時候,我所使用的副標(biāo)題是"起步與優(yōu)化",它們正是我希望能提供幫助的兩個方面。在收集素材及給出建議時,我意識到起步和優(yōu)化Scrum其實是同一件事情。起步所需要的技巧與優(yōu)化所需要的技巧并沒有什么差別。
第I部分是關(guān)于起步的,它包括是選擇小團隊試點還是全面轉(zhuǎn)型,如何幫助人們從意識到需要新的流程逐步轉(zhuǎn)變到渴望變革、再轉(zhuǎn)變到有能力去做這樣的變革,以及如何挑選試點項目和團隊。你不僅可以用本章這部分介紹的基本原理作為起步,也可以用它們來進行優(yōu)化。在這個過程中,涉及到的改進社區(qū)和改進Backlog在第4章介紹。
在第II部分中,我關(guān)注個體及其在導(dǎo)入Scrum的過程中需要做出的改變。第6章描述一些人有可能存在的抵觸情緒。我對這些抵觸的根源進行了分析,對如何幫助人們克服抵觸給出了指導(dǎo)性的意見。第7章和第8章講述了在使用Scrum的項目中存在的新的角色,以及在傳統(tǒng)項目中定義的角色所需要做出的必要的改變,如程序員、測試人員、項目經(jīng)理等。第9章介紹一些技術(shù)實踐,包括持續(xù)集成、結(jié)對編程、測試驅(qū)動開發(fā)等,這些技術(shù)實踐應(yīng)該使用,至少也要做一些嘗試,它們會使每個人的日常工作方式有很多變化。
在第III部分中,我們向外擴展到團隊的話題。我們首先關(guān)注如何設(shè)計Scrum團隊的結(jié)構(gòu),以充分體現(xiàn)Scrum的優(yōu)勢。然后,第11章闡述在Scrum項目中團隊協(xié)作的本質(zhì)。第12章將一起來看在Scrum中領(lǐng)導(dǎo)一個自組織團隊意味著什么。在這一章,我具體針對ScrumMaster、職能經(jīng)理和其他領(lǐng)導(dǎo)者給出一些建議。第13章至第15章通過對Sprint、計劃和質(zhì)量的討論完成第III部分內(nèi)容。
第IV部分,我們進一步擴展到企業(yè)級別的話題。在第17章,我們將進一步研究如何把Scrum擴展到更大的工作范圍,跨團隊的項目中必須要做哪些事等。第18章考慮分布式團隊的更多的復(fù)雜性。然后,在第19章進行更加復(fù)雜的討論,談?wù)勅绾卧谝粋部分使用瀑布式流程的項目中使用Scrum,在有監(jiān)管需求時如何處理。第IV部分以第20章作為結(jié)尾,這一章特別討論Scrum對公司的人力資源、后勤及PMO等部門的影響。
第V部分包含兩章。第21章歸納企業(yè)敏捷轉(zhuǎn)型的各種度量方法。第22章對全書進行小結(jié),并且再次闡明只有持續(xù)改善才能做到真正的敏捷。不論你今天已經(jīng)做得有多好,為了保持敏捷,你下個月必須做得更好!
關(guān) 于 術(shù) 語
像大多數(shù)情況一樣,筆論Scrum比僅僅口頭討論它要難一些。讀者在閱讀時,一不小心就會誤讀一個句子或者脫離語境去理解它。為了避免這樣的問題,我在使用一些術(shù)語時盡量小心并且精確。比如,我使用"開發(fā)人員"這個詞時,我是指在項目中參與開發(fā)的任何一個人。它包括程序員、測試員、分析師、用戶體驗設(shè)計師、數(shù)據(jù)庫管理員等。
術(shù)語"團隊"也有它自己的問題。它當(dāng)然包括開發(fā)人員,但是"團隊"包括ScrumMaster和產(chǎn)品負(fù)責(zé)人嗎?自然,它也取決于語境。當(dāng)我需要精確表達(dá)時,我使用"整個團隊"來指所有的人:開發(fā)人員,產(chǎn)品負(fù)責(zé)人和ScrumMaster。然而盲目地使用"整個團隊"會降低本書的可讀性。所以有時你還是會看到"團隊",通常是在所指含義非常明確的地方。
除Scrum及敏捷團隊外,我也需要一個術(shù)語來專指那些兩者都不是的團隊。在不同的地方,我曾使用"順序式團隊"、"傳統(tǒng)型團隊"和"非敏捷團隊"等術(shù)語,它們每一個之間有細(xì)微的含義差別并恰如其分地用在不同的地方。
本書使用說明
很多書的前言都有這樣的小節(jié)標(biāo)題。但是這些標(biāo)題通常是在說"如何閱讀本書"。閱讀這本書最好的辦法是使用它。不只是停留于閱讀。當(dāng)你遇到"試一試"時,停下來試一下。或者在我有特別建議的地方,記住它們?nèi)缓笤谙乱淮位仡檿h或者計劃會議的時候嘗試用一用。
不必按照章節(jié)的順序閱讀本書。事實上有可能有些章節(jié)你根本沒有必要讀。如果你在計劃方面已經(jīng)沒有問題,或者是沒有分布式團隊,你只是應(yīng)公司的期望要求做得更好而已,盡可以把相關(guān)的章節(jié)全部跳過。但是,我建議每個人都至少通讀前4章并且按照順序閱讀--它們是后面所有章節(jié)的基礎(chǔ)。
第4章介紹"改進社區(qū)"和"改進Backlog"想法。改進社區(qū)是指一組志同道合的個體,他們熱衷于推動企業(yè)的在某一個方面的改進。改進社區(qū)可能由這樣三種人組成:他們熱衷于改進產(chǎn)品Backlog;決定收集相關(guān)的最佳實踐;在團隊間共享。另外的改進社區(qū)有可能包括幾百個熱衷于改進公司測試活動的人。改進Backlog正如其名,是一個排好序的、改進社區(qū)的任務(wù)列表。
我希望改進社區(qū)能使用本書來實施他們的改進Backlog,包括指導(dǎo)及推動轉(zhuǎn)型的企業(yè)轉(zhuǎn)型社區(qū)(ETC)。事實上有些章節(jié)的標(biāo)題被特意地命名以使其能直接進入改進Backlog。例如,第13章的"把文檔轉(zhuǎn)化成討論",第14章的"在當(dāng)前的Sprint中為下一個Sprint做準(zhǔn)備",第16章的"在不同層次上進行自動化",等等。
作為一個有多年經(jīng)驗的Scrum培訓(xùn)師和顧問,我曾服務(wù)于幾百個團隊和公司,我相信Scrum可成功適用于每個公司。有些公司比其他公司可能難一些。有些公司會因為強勢的公司文化而面臨挑戰(zhàn),還有的會因一些頑固的難以變通的人而造成人員損失。在一些幸運的公司,會得到管理層的支持并積極鼓動員工參與。但是,所有這些公司的共同點是,他們都需要實用的、經(jīng)過證明的建議。我寫作本書的目的就是為他們提供這樣的建議。
Mike Cohn,Mountain Goat Software創(chuàng)辦人,以幫助客戶公司成長為卓越軟件開發(fā)組織為己任,專門提供Scrum與敏捷軟件開發(fā)培訓(xùn)。Mike Cohn是敏捷運動兩大公認(rèn)名著(《用戶故事與敏捷方法》和《敏捷估算與規(guī)劃》)的作者。他曾經(jīng)歷任多個軟件開發(fā)公司(從新創(chuàng)公司到《財富》40強)的技術(shù)總監(jiān),曾服務(wù)子BBC(英國國際廣播公司)、Capital One(美國第—投資集團),Electronic Arts(藝電)、Experian(益百利)、Gooqle(谷歌)、Intuit(直覺軟件公司)、Lexis Nexis(律商聯(lián)訊)、Lockheed Martin(洛克希德·馬。⑽④、諾基亞、飛利浦、Sabre、Salesforce.com、西門子、索尼、時代華納、雅虎等客戶。他參與創(chuàng)力了敏捷聯(lián)盟、敏捷項目領(lǐng)導(dǎo)網(wǎng)絡(luò)和Scrum聯(lián)盟。
第Ⅰ部分 啟航
第1章 為什么敏捷轉(zhuǎn)型難(但值得)
第2章 ADAPT模型
第3章 Scrum實施模式
第4章 漸進敏捷
第5章 試點項目
第Ⅱ部分 個體
第6章 克服抵觸
第7章 新角色
第8章 角色轉(zhuǎn)換
第9章 技術(shù)實踐
第Ⅲ部分 團隊
第10章 團隊結(jié)構(gòu)
第11章 團隊協(xié)作
第12章 領(lǐng)導(dǎo)自組織團隊
第13章 產(chǎn)品Backlog
第14章 Sprint
第15章 做計劃
第16章 質(zhì)量
第Ⅳ部分 組織
第17章 擴展Scrum
第18章 分布式團隊
第19章 與其他方法論共存
第20章 人力資源、后勤和PMO
第Ⅴ部分 下一站
第21章 看看進展如何
第22章 沒有終點
因為ETC與Scrum開發(fā)團隊一樣使用Scrum,所以他們也通過Sprint取得進展。每個ETCSprint以計劃會議開始,以評審和回顧會議結(jié)束。這些會議和Scrum開發(fā)團隊的那些會議完全一樣,也經(jīng)常發(fā)生同樣的問題。來自KeyCorp(美國一家大型的金融機構(gòu))的Thomas Seffernick,參加了他所在公司的ETC(也稱敏捷實施團隊)的第一次回顧會議。他回憶了團隊如何犯下許多新Scrum開發(fā)團隊都有的一個共同錯誤——與演示工作中取得的進展相比,他們更愿意談?wù)撚媱潯?br> 因為領(lǐng)導(dǎo)要站著描述他們掃除障礙的計劃,所以第一次敏捷實施(ETC)Sprint評審會議比較痛苦。會中傳遞的信息是清晰的——計劃不錯,但結(jié)果有待證明。此后的評審會議就有變化,結(jié)果成為會議的焦點。(2007,202)
一些ETC舉行每日站會,我認(rèn)為這是一項良好的實踐。但是,我并不認(rèn)為必須像Scrum開發(fā)團隊一定要舉行每曰站會那樣,堅持要求做到這點。因為ETC成員要完成的工作不像開發(fā)團隊要完成的工作那樣緊密地互相交錯,所以每日站會是一件很有價值但非必須的事情。類似地,ETC成員很少是全職的,大多數(shù)人已有其他工作,許多時候,他們待在原來的工作上更有意義。例如,對于一位開發(fā)部門主管,讓他離開自己的崗位而服務(wù)于ETC,與任其留在自己的工作崗位相比,無疑后者更有助于排除企業(yè)的更多困難。
ETC Sprint的長度取決于ETC成員。不過以我的經(jīng)驗而言,兩周是最好的。這也是Ken Schwaber(2007,10)所推薦的Sprint長度。Elizabeth Woodward是指導(dǎo)IBM大規(guī)模實施敏捷的ETC成員之一,她如下描述有關(guān)他們Sprint長度的經(jīng)歷。
我們用過兩周和四周的Sprinto迄今為止,我們看到最成功的是兩周的Sprint。我相信其中的原因在于其“交付物”展示的良好勢頭和對外可見的進展。我們把各個社區(qū)的工作收集到一個簡短的摘要中——封能讓人們在15分鐘內(nèi)讀完的電子郵件。發(fā)起人和產(chǎn)品負(fù)責(zé)人很多成功的Scrum實施都由一個明確的發(fā)起人(sponsor)啟動和推進,發(fā)起人是企業(yè)中負(fù)責(zé)成功轉(zhuǎn)型的資深人士。Salesforce.com非常成功的大規(guī)模轉(zhuǎn)型就由公司的一位共同創(chuàng)始人Parker Harris發(fā)起。作為負(fù)責(zé)技術(shù)的執(zhí)行副總裁,Harris
處在一個絕佳的位置,可以支持這樣的變革——它會顯著改變Salesforce.com開發(fā)組織中每個人的工作方式。
轉(zhuǎn)型發(fā)起人應(yīng)來自企業(yè)正在計劃實施轉(zhuǎn)型的部門級別。Salesforce.com需要公司管理層充當(dāng)發(fā)起人,因為其轉(zhuǎn)型是整個企業(yè)范圍的。如果是部門的轉(zhuǎn)型,那么部門級別的領(lǐng)導(dǎo)是合適的選擇。
發(fā)起人也是ETC的產(chǎn)品負(fù)責(zé)人。這意味著,有時ETC的產(chǎn)品負(fù)責(zé)人是沒什么Scrum經(jīng)驗的人。不過沒有關(guān)系,如同所有的產(chǎn)品負(fù)責(zé)人一樣,ETC的發(fā)起人能夠通過尋求其他ETC成員的幫助來履行這個職責(zé)。作為ETC最資深的成員,發(fā)起人將在轉(zhuǎn)型實施溝通中扮演著重要角色,但他不必是轉(zhuǎn)型愿景中唯一的來源,還有其他人。
開始采用Scrum時,Primavera就了解到強勢發(fā)起人的重要性。BobSchatz和Ibrahim Abdelshafi,當(dāng)時是Primavera的技術(shù)執(zhí)行官,他們?nèi)缦旅枋霭l(fā)起人支持的重要性:
實施敏捷或?qū)嵤┤魏沃卮蟮淖兏铮夹枰芾韺诱嬲\的支持。事情得到解決前道路是崎嶇不平的,盡管有任何問題或失敗,但管理層的支持都能讓變革之路堅持下來。(2005,38)
……