敏捷開發(fā)知識體系樣本

SUBJECTTITLE敏捷開發(fā)知識體系總體框架修訂歷史記錄日期版本闡明作者1.0草稿

敏捷開發(fā)知識體系整體框架敏捷開發(fā)知識體系核心敏捷開發(fā)是一種靈活開發(fā)辦法，用于在一種動態(tài)環(huán)境中向干系人迅速交付價值。其重要特點是關注持續(xù)交付價值，通過迭代和迅速顧客反饋管理不擬定性和擁抱變更；它承認個人才是價值最后源泉，強調通過有效個人勉勵，提高團隊工作績效。敏捷開發(fā)知識體系核心是敏捷宣言，它們是敏捷開發(fā)思想和價值觀集中體現(xiàn)。敏捷軟件開發(fā)宣言詳細內容如下：咱們始終在實踐中探尋更好軟件開發(fā)辦法，身體力行同步也協(xié)助她人。由此咱們建立了如下價值觀：個體和互動高于流程和工具工作軟件高于詳盡文檔客戶合伙高于合同談判響應變化高于遵循籌劃也就是說，盡管右項有其價值，咱們更注重左項價值。對的理解敏捷宣言是成功開展敏捷開發(fā)核心，它告訴咱們敏捷是一種相對詞匯，詳細敏捷限度取決去項目團隊上下文，例如復雜項目由于其團隊規(guī)模、技術特點和循規(guī)規(guī)定等，規(guī)定團隊有更嚴格治理流程和工具支持、更規(guī)范文檔和籌劃規(guī)定。但依然可以借助敏捷價值觀和各種實踐解決開發(fā)過程中遇到問題。在詳細敏捷開發(fā)實踐中，咱們必要實事求是地采用適當敏捷實踐，以實用主義為指引思想，面向業(yè)務成果和價值，切不可為了敏捷而敏捷。環(huán)繞著敏捷宣言，敏捷開發(fā)辦法領導者定義了用于指引團隊開展敏捷開發(fā)實踐必要遵循12條基本原則，它們是敏捷開發(fā)實踐總體指南。敏捷宣言遵循12條原則如下：咱們最重要目的，是通過持續(xù)不斷地及早交付有價值軟件使客戶滿意。欣然面對需求變化，雖然在開發(fā)后期也同樣。為了客戶競爭優(yōu)勢，敏捷過程掌控變化。經(jīng)常地交付可工作軟件，相隔幾星期或一兩個月，傾向于采用較短周期。業(yè)務人員和開發(fā)人員必要互相合伙，項目中每一天都不例外。激發(fā)個體斗志，以她們?yōu)楹诵拇罱椖?。提供所需環(huán)境和增援，輔以信任，從而達到目的。無論團隊內外，傳遞信息效果最佳效率也最高方式是面對面交談?？晒ぷ鬈浖沁M度首要度量原則。敏捷過程倡導可持續(xù)開發(fā)。負責人、開發(fā)人員和顧客要可以共同維持其步調穩(wěn)定延續(xù)。堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。以簡潔為本，它是極力減少不必要工作量藝術。最佳架構、需求和設計出自自組織團隊。團隊定期地反思如何能提高成效，并依此調節(jié)自身舉止體現(xiàn)。注：以上敏捷宣言遵循原則摘自敏捷宣言簡體中文版官方網(wǎng)站敏捷開發(fā)管理實踐隨著敏捷開發(fā)運動開展，如圖所示，敏捷踐行者逐漸發(fā)展出兩類敏捷開發(fā)最佳實踐：敏捷開發(fā)管理實踐和敏捷開發(fā)工程實踐。敏捷開發(fā)管理實踐泛指用于指引敏捷團隊進行敏捷開發(fā)實踐開發(fā)辦法和流程，業(yè)界應用最廣敏捷開發(fā)管理實踐涉及：（詳細實踐列表將依照團隊工作成果，恰當變化，并包括簡樸描述。）Scrum：極限編程（XP）：OpenUP：精益開發(fā)（Lean）：動態(tài)系統(tǒng)開發(fā)(DSDM)：特性驅動開發(fā)：敏捷開發(fā)工程實踐敏捷開發(fā)工程實踐泛指用于指引敏捷團隊進行敏捷開發(fā)過程中各種工程化最佳實踐，業(yè)界應用最廣敏捷開發(fā)工程實踐涉及：（詳細實踐列表將依照團隊工作成果，恰當變化，并包括簡樸描述。）項目管理：迭代開發(fā)風險價值生命周期多級項目規(guī)劃完整團隊每日站立會議任務板燃盡圖需求管理：需求訂單業(yè)務流程草圖用例驅動開發(fā)顧客故事架構：演進架構演進設計基于組件架構設計開發(fā)：結對編程測試驅動開發(fā)重構代碼規(guī)范測試：單元測試并行測試測試管理變更管理：持續(xù)集成自動構建團隊變更管理在敏捷開發(fā)知識體系其他章節(jié)，將詳細描述每種敏捷開發(fā)管理實踐和工程實踐，為了以便閱讀，咱們將采用統(tǒng)一方式描述其中詳細內容。其中，敏捷開發(fā)管理實踐描述重要涉及如下重要某些：辦法定義和特性闡明辦法中包括重要角色辦法中包括重要活動和最佳實踐辦法中包括重要輸入輸出工件辦法工作流程闡明而敏捷開發(fā)工程實踐描述將重要涉及如下重要某些：最佳實踐定義和特性闡明如何應用最佳實踐闡明案例闡明敏捷開發(fā)核心價值觀和原則敏捷軟件開發(fā)宣言2月，17位在當時被稱之為“輕量級辦法學家”軟件開發(fā)領域領軍人物匯集在美國猶她州滑雪勝地雪鳥（Snowbird）雪場。通過兩天討論，“敏捷”（Agile）這個詞為全體約會者所接受，用以概括一套全新軟件開發(fā)價值觀。這套價值觀，通過一份簡要扼要《敏捷宣言》，傳遞給世界，宣布了敏捷開發(fā)運動開始。敏捷軟件開發(fā)宣言咱們始終在實踐中探尋更好軟件開發(fā)辦法，身體力行同步也協(xié)助她人。由此咱們建立了如下價值觀：個體和互動

高于流程和工具

工作軟件

高于詳盡文檔

客戶合伙

高于合同談判

響應變化

高于遵循籌劃也就是說，盡管右項有其價值，咱們更注重左項價值。注：以上敏捷軟件開發(fā)宣言摘自敏捷宣言簡體中文版官方網(wǎng)站敏捷開發(fā)核心價值觀敏者，疾也。對外來刺激做出迅速、機靈反映；捷者，獵也。以最短途徑去追趕和實現(xiàn)目的。敏捷開發(fā)核心理念就是以最簡樸有效方式迅速達到目的，并在這個過程中及時地響應外界變化，做出迅速調節(jié)。敏捷開發(fā)第一條價值觀就是“以人為本”，強調“個體（人）”及“個體”間溝通與協(xié)作在軟件開發(fā)過程中重要性。這個順序不是偶爾而為之，敏捷開發(fā)將注重個體潛能激發(fā)和團隊高效協(xié)作作為其所推崇第一價值觀。敏捷開發(fā)第二條價值觀就是“目的導向”。同其她眾多管理理論和模型同樣，敏捷開發(fā)認同目的導向是成功核心，由于沒有目的也就無所謂成功。敏捷開發(fā)價值觀中清晰地闡明，軟件開發(fā)目的是“可工作軟件”，而不是面面俱到文檔。而遺憾是，諸多軟件項目已經(jīng)在紛繁文檔之中迷失了自己目的。敏捷開發(fā)第三條價值觀就是“客戶為先”。雖然敏捷開發(fā)強調第一價值觀是“以人為本”，但敏捷宣言締造者們并沒有忘掉客戶，相反她們真正理解客戶需求、懂得如何與客戶合伙。敏捷價值觀里強調“客戶為先”即不是簡樸把客戶當作“上帝”、簡樸推崇“客戶至上”，客戶規(guī)定什么、咱們就做什么；也不是把客戶當作“談判桌上對手”甚至“敵人”，去斗智斗勇。敏捷價值觀里中把客戶當成了合伙者和伙伴，把自己使命定位為“協(xié)助客戶獲得競爭優(yōu)勢”。敏捷開發(fā)第四條價值觀就是“擁抱變化”。人們常說“世界上唯一不變就是變化”，大多數(shù)人也相信事實的確如此。而以往諸多軟件項目卻忽視了這一點，或者更精確說是它們不樂意“正視”。它們總是試圖用詳盡籌劃與預先窮舉這些變化，然后又試圖通過嚴格遵循籌劃來控制變化發(fā)生，而成果往往是被不斷涌現(xiàn)變化擊垮。敏捷開發(fā)價值觀中承認變化是軟件開發(fā)一某些、并相信正是客戶在不斷變化其需求過程中明晰了其真正需要。因而敏捷開發(fā)歡迎變化、擁抱變化，并可坦然應對變化，正是這些變化為客戶和項目帶來了價值。最后，咱們還應記住敏捷宣言中最后一條：“盡管右項有其價值，咱們更注重左項價值”——敏捷宣言并未否定或貶損“右項”價值，在敏捷開發(fā)價值觀中承認“流程和工具”、“詳盡文檔”、“合同談判”以及“遵循籌劃”重要性，只是兩相比較，“更注重左項價值”。

敏捷開發(fā)原則

敏捷開發(fā)原則敏捷宣言遵循原則l

咱們最重要目的，是通過持續(xù)不斷地及早交付有價值軟件使客戶滿意。l

欣然面對需求變化，雖然在開發(fā)后期也同樣。為了客戶競爭優(yōu)勢，敏捷過程掌控變化。l

經(jīng)常地交付可工作軟件，相隔幾星期或一兩個月，傾向于采用較短周期。l

業(yè)務人員和開發(fā)人員必要互相合伙，項目中每一天都不例外。l

激發(fā)個體斗志，以她們?yōu)楹诵拇罱椖?。提供所需環(huán)境和增援，輔以信任，從而達到目的。l

無論團隊內外，傳遞信息效果最佳效率也最高方式是面對面交談。l

可工作軟件是進度首要度量原則。l

敏捷過程倡導可持續(xù)開發(fā)。負責人、開發(fā)人員和顧客要可以共同維持其步調穩(wěn)定延續(xù)。l

堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。l

以簡潔為本，它是極力減少不必要工作量藝術。l

最佳架構、需求和設計出自自組織團隊。l

團隊定期地反思如何能提高成效，并依此調節(jié)自身舉止體現(xiàn)。注：以上敏捷宣言遵循原則摘自敏捷宣言簡體中文版官方網(wǎng)站

敏捷開發(fā)原則應用敏捷開發(fā)原則是對敏捷價值觀解釋和實踐，它將敏捷價值觀貫徹到詳細可操作原則之上，嚴格遵循這十二條原則，是敏捷軟件開發(fā)項目得以成功基石。可以說這十二條原則已經(jīng)囊括了軟件項目管理基本流程，并且這些流程足夠詳細：它告訴咱們項目管理第一步就是要明確目的，而軟件項目終極目的就是“不斷地及早交付有價值軟件使客戶滿意”；它提示咱們軟件工程起始點是需求，而需求固有特性就是不斷變化，敏捷開發(fā)過程要“掌控變化”；它強調“可工作軟件是進度首要度量原則”，因而需要以盡量短周期“經(jīng)常地交付可工作軟件”；它注重有關干系人協(xié)調（“業(yè)務人員和開發(fā)人員必要互相合伙”、“負責人、開發(fā)人員和顧客要可以共同維持其步調穩(wěn)定延續(xù)”），注重激發(fā)個人潛能（“激發(fā)個體斗志”），規(guī)定團隊使用最高效溝通方式（“面對面交談”）；它推崇技術變革所具備強大能量（“堅持不懈地追求技術卓越和良好設計”）；它強調精益生產(chǎn)（簡潔為本），規(guī)定項目采用“自組織”團隊管理模式，并指出“定期總結反思”，是校準團隊行為、最后達到目的有效途徑。成熟敏捷開發(fā)團隊，完全可以不再需要任何附加冗余流程（工程技術流程除外），而成功完畢軟件開發(fā)和交付。固然，敏捷開發(fā)團隊也可以以這十二條原則為基本，進一步細化敏捷項目管理流程、環(huán)節(jié)、和辦法工具，以便這些原則可以更好被團隊理解和執(zhí)行。對以上所有原則嚴格遵守將大大提高敏捷項目成功也許性。重要敏捷開發(fā)管理實踐敏捷開發(fā)管理實踐描述模板辦法定義和特性闡明辦法中包括重要角色辦法中包括重要活動和最佳實踐辦法中包括重要輸入輸出工件辦法工作流程闡明敏捷開發(fā)辦法之ScrumScrum辦法定義和特性闡明術語Scrum來源于橄欖球活動，在英文中意思是橄欖球里爭球。在橄欖球比賽中，雙方前鋒站在一起緊密相連，當球在她們之間投擲時，她們奮力求球。1995年，在奧斯汀舉辦OOPSLA'95上，薩瑟蘭和施瓦伯初次提出了Scrum概念，并在隨后幾年中逐漸將其與業(yè)界最佳實踐融合起來，形成一種迭代式增量軟件開發(fā)過程和敏捷項目管理辦法，并在敏捷聯(lián)盟（AgileAlliance）形成后受到了更多歡迎。Scrum是一種靈活軟件管理過程，它提供了一種經(jīng)驗辦法，可以協(xié)助你駕馭迭代，實現(xiàn)遞增軟件開發(fā)過程。這一過程是迅速、有適應性、自組織，它發(fā)現(xiàn)了軟件工程社會意義，使得團隊成員可以獨立地集中在創(chuàng)造性協(xié)作環(huán)境下工作。Scrum采用了經(jīng)驗辦法，承認問題無法完全理解或定義，關注于如何使得開發(fā)團隊迅速推出和響應需求能力最大化。因而，Scrum一種核心原則就是承認客戶可以在項目過程中變化主意，變更她們需求，而預測式和籌劃式辦法并不能容易地解決這種不可預見需求變化。Scrum是一種涉及了一系列實踐和預定義角色過程框架。任何軟件開發(fā)過程框架都可以由最基本三個要素構成：角色（人）、活動及其輸入輸出工件。Scrum框架重要涉及如下內容：角色；產(chǎn)品負責人（ProductOwner）；Scrum主管（ScrumMaster）；團隊成員；活動；沖刺規(guī)劃會議（SprintPlanMeeting）；每日站立會議（ScrumDailyMeeting）；沖刺復審會議（SprintReviewMeeting）；沖刺回顧會議（SprintRetrospectiveMeeting）；工件；產(chǎn)品訂單（ProductBacklog）；沖刺訂單（SprintBacklog）；燃盡圖（BurndownChart）；新功能增量。下面咱們就從角色、活動和工件三個維度對整個Scrum過程進行簡樸簡介。Scrum辦法中包括重要角色Scrum定義了許多角色，依照豬和雞笑話可以分為兩組，豬和雞。一天，一頭豬和一只雞在路上散步。雞看了一下豬說：“嗨，咱們合伙開一家餐館怎么樣？”。豬回頭看了一下雞說：“好主意，那你準備給餐館起什么名字呢？”。雞想了想說：“餐館名字叫火腿和雞蛋怎么樣？”?！拔也贿@樣以為”，豬說，“我全身投入，而你只是參加而已”?！柏i”角色：是全身投入項目和Scrum過程人，重要涉及代表利益干系人產(chǎn)品負責人，同項目經(jīng)理類似Scrum主管和開發(fā)團隊。產(chǎn)品負責人（ProductOwner）：代表了客戶意愿，這保證Scrum團隊在做從業(yè)務角度來說對的事情。同步她又代表項目全體利益干系人，負責編寫顧客需求（顧客故事），排出優(yōu)先級，并放入產(chǎn)品訂單（ProductBacklog），從而使項目價值最大化人。她運用產(chǎn)品訂單，督促團隊優(yōu)先開發(fā)最具價值功能，并在其基本上繼續(xù)開發(fā)，將最具價值開發(fā)需求安排在下一種沖刺迭代（Sprint）中完畢。她對項目產(chǎn)出軟件系統(tǒng)負責，規(guī)劃項目初始總體規(guī)定、ROI目的和發(fā)布籌劃，并為項目贏得驅動及后續(xù)資金。Scrum主管（ScrumMaster）：負責Scrum過程正的確施和利益最大化人，保證它既符合公司文化，又能交付預期利益。Scrum主管職責是向所有項目參加者講授Scrum辦法，對的執(zhí)行規(guī)則，保證所有項目有關人員遵守Scrum規(guī)則，這些規(guī)則形成了Scrum過程。Scrum主管并非團隊領導（由于她們是自我組織），她重要工作是去除那些影響團隊交付沖刺目的障礙，屏蔽外界對開發(fā)團隊干擾?！癝crum主管是保證Scrum成功牧羊犬”。開發(fā)團隊：負責找出可在一種迭代中將產(chǎn)品待開發(fā)事項（沖刺訂單）轉化為功能增量辦法。她們對每一次迭代和整個項目共同負責，在每個沖刺中通過實行自管理、自組織，和跨職能開發(fā)協(xié)作，實現(xiàn)沖刺目的和最后交付產(chǎn)品。普通由5~9名具備跨職能技能人（設計者，開發(fā)者等）構成?！半u”角色：并不是實際Scrum過程一某些，但是必要考慮她們。敏捷辦法一種重要方面是使得顧客和利益所有者參加每一種沖刺評審和籌劃并提供反饋。顧客：軟件是為了某些人而創(chuàng)立！就像“如果森林里有一棵樹倒下了，但沒有人聽到，那么它算發(fā)出了聲音嗎”，“如果軟件沒有被使用，那么它算是被開發(fā)出來了么？”。利益所有者（客戶，提供商）：影響項目成功人，但只直接參加沖刺評審過程。經(jīng)理：為產(chǎn)品開發(fā)團隊架起環(huán)境那個人。如圖3.4所示為Scrum辦法中重要角色。圖3.AUTONUM\*ArabicScrum辦法中重要角色Scrum辦法中包括重要活動和最佳實踐Scrum作為軟件開發(fā)過程框架，它包括重要最佳實踐涉及如下幾種方面。迭代式軟件開發(fā)：通過將整個軟件交付過程提成各種迭代周期，協(xié)助團隊更好地應對變更，應對風險，實現(xiàn)增量交付、迅速反饋。兩層項目規(guī)劃（Two-LevelProjectPlanning）：基于遠粗近細原則和項目漸進明細特點，通過將概要項目整體規(guī)劃和詳細近期迭代籌劃有機結合，協(xié)助團隊有效提高籌劃精確度、資源管理能力和項目準時交付能力。整體團隊協(xié)作（WholeTeam）：通過關注保持整個團隊可持續(xù)發(fā)展工作節(jié)奏、每日站立會議和自組織工作分派，實現(xiàn)團隊高效協(xié)作和工作，實現(xiàn)提高整個團隊生產(chǎn)力目。持續(xù)集成：通過進行更頻繁軟件集成，實現(xiàn)更早發(fā)現(xiàn)和反饋錯誤、減少風險，并使整個軟件交付過程變得更加可預測和可控，以交付更高質量軟件。Scrum活動重要由沖刺規(guī)劃會議（SprintPlanMeeting）、每日站立會議（SprintDailyMeeting）、沖刺復審會議（SprintReviewMeeting）和沖刺回顧會議（RetrospectiveMeeting）構成。Scrum倡導所有團隊成員坐在一起工作，進行口頭交流，以及強調項目關于規(guī)范（Disciplines），這些有助于創(chuàng)造自我組織團隊。沖刺規(guī)劃會議：沖刺開始時，均需召開沖刺規(guī)劃會議，產(chǎn)品負責人和團隊共同探討該沖刺工作內容。產(chǎn)品負責人從最優(yōu)先待開發(fā)事項中進行篩選，告知團隊其預期目的；團隊則提出在接下來沖刺內，評估預期目的可實現(xiàn)限度。沖刺規(guī)劃會議普通不超過8小時。在前4個小時中，產(chǎn)品負責人向團隊展示最高優(yōu)先級產(chǎn)品，團隊則向她詢問產(chǎn)品訂單內容、目、含義及意圖。而在后4小時，團隊則籌劃本沖刺詳細安排。每日站立會議：在沖刺中，每一天都會舉辦項目狀況會議，被稱為Scrum或“每日站立會議”。每日站立會議有某些詳細指引原則：會議準時開始。對于遲到者團隊經(jīng)常會制定懲罰辦法（例如罰款、做俯臥撐、在脖子上掛橡膠雞玩具等）。歡迎所有人參加，但只有“豬”類人員可以發(fā)言。無論團隊規(guī)模大小，會議被限制在15分鐘。所有出席者都應站立（有助于保持會議簡短）。會議應在固定地點和每天同一時間舉辦。在會議上，每個團隊成員需要回答三個問題：今天你完畢了那些工作？明天你打算做什么？完畢你目的與否存在什么障礙？（Scrum主管需要記下這些障礙）沖刺復審會議：普通4個小時，由團隊成員向產(chǎn)品負責人向其她利益有關人展示Sprint周期內產(chǎn)品開發(fā)狀況，并決定下一次Sprint內容。沖刺回顧會議（RetrospectiveMeeting）：每一種沖刺完畢后，都會舉辦一次沖刺回顧會議，在會議上所有團隊成員都要反思這個沖刺。舉辦沖刺回顧會議是為了進行持續(xù)過程改進。會議時間限制在4小時。如圖3.AUTONUM\*Arabic所示表達Scrum辦法中重要活動和交付件。圖3.AUTONUM\*ArabicScrum辦法中重要活動和交付件Scrum辦法中包括重要輸入輸出工件產(chǎn)品訂單：產(chǎn)品訂單（ProductBacklog）是整個項目概要文檔，它包括已劃分優(yōu)先級別、項目要開發(fā)系統(tǒng)或產(chǎn)品需求清單，涉及功能和非功能性需求及其她假設和約束條件。產(chǎn)品負責人和團隊重要按業(yè)務和依賴性重要限度劃分優(yōu)先級別，并作出預估。預估值精準度取決于產(chǎn)品訂單中條目優(yōu)先級和細致限度，入選下一種沖刺最高優(yōu)先級別條目預估會非常精準。產(chǎn)品需求清單是動態(tài)，隨著產(chǎn)品及其使用環(huán)境變化而變化，并且只要產(chǎn)品存在，它就隨之存在。并且，在整個產(chǎn)品生命周期中，管理層不斷擬定產(chǎn)品需求或對之做出變化，以保證產(chǎn)品合用性、實用性和競爭性。.沖刺訂單：沖刺訂單（SprintBacklog）是大大細化了文檔，用來界定工作或任務，定義團隊在Sprint中任務清單，這些任務會將當前沖刺選定產(chǎn)品訂單轉化為完整產(chǎn)品功能增量。沖刺訂單在沖刺規(guī)劃會議中形成，其包括不會被分派，而是由團隊成員簽名認領她們愛慕任務。任務被分解為以小時為單位，沒有任務可以超過16個小時。如果一種任務超過16個小時，那么它就應當被進一步分解。每項任務信息將涉及其負責人及其在沖刺中任一天時剩余工作量，且僅團隊有權變化其內容。燃盡圖：燃盡圖（BurndownChart）是一種公開展示圖表，縱軸代表剩余工作量，橫軸代表時間，顯示當前沖刺中隨時間變化而變化剩余工作量（可以是未完畢任務數(shù)目，或在沖刺訂單上未完畢訂單項數(shù)目）。剩余工作量趨勢線與橫軸之間交集表達在那個時間點最也許工作完畢量。咱們可以借助它設想在增長或減少發(fā)布功能后項目狀況，咱們也許縮短開發(fā)時間，或延長開發(fā)期限以獲得更多功能。它可以展示項目實際進度與籌劃之間矛盾。新功能增量：Scrum團隊在每個沖刺周期內完畢、可交付產(chǎn)品功能增量。Scrum辦法工作流程闡明在Scrum項目管理過程中，普通產(chǎn)品負責人獲取項目投資，并對整個產(chǎn)品成功負責。她會協(xié)調各種利益干系人，擬定產(chǎn)品訂單中初始需求清單及其優(yōu)先級，完畢項目商業(yè)價值分析和項目整體規(guī)劃，并任命適當Scrum主管開展項目工作。如圖3.7所示表達Scrum辦法全景圖。圖3.AUTONUM\*ArabicScrum辦法全景圖在Scrum軟件開發(fā)項目中，每個沖刺就是一種為期30天迭代。在每個沖刺開始時，產(chǎn)品負責人和Scrum主管通過召開沖刺規(guī)劃會議和“兩層項目規(guī)劃”最佳實踐，制定沖刺訂單（類似于迭代籌劃），明確將在本次沖刺中實現(xiàn)需求清單，相應工作任務和負責人。在每個沖刺迭代中，團隊強調應用“整體團隊協(xié)作”最佳實踐，通過保持可持續(xù)發(fā)展工作節(jié)奏和每日站立會議，實現(xiàn)團隊自組織、自適應和自管理，高效完畢沖刺工作。在每個沖刺結束時，團隊都會召開沖刺復審會議，團隊成員會在會上分別展示她們開發(fā)出軟件（或其她有價值產(chǎn)品），并從產(chǎn)品負責人和其她利益干系人那里，得到反饋信息。在沖刺復審會議之后，團隊會自覺召開沖刺回顧會議，回顧整個項目過程，討論那些方面做得好，哪些方面可以改進，實現(xiàn)軟件交付過程持續(xù)、自發(fā)改進。敏捷開發(fā)辦法之Lean軟件開發(fā)

基于ToyotaLean生產(chǎn)概念

減少揮霍

無用功能

20%功能往往可以提供80%價值，你需要是這樣一種流程。

變來變去

如果浮現(xiàn)需求變來變去狀況，那么是你太早文檔化需求；如果浮現(xiàn)專門測試和修復階段，那么是你測試得太晚。

跨越邊界

組織邊界普通會增長超過25%成本，是減少響應時間和妨礙溝通隔離帶減少揮霍辦法

延遲決策

拋棄那種以為只有具備完整規(guī)約之后才干開發(fā)想法。

消除依賴

系統(tǒng)架構應當容許在任何時間增添任何功能。

保持也許

把代碼當成驗證機會–同步使代碼易于變更。

在最后一刻才做出決策

做決策之前盡量多理解信息。Lean軟件開發(fā)原則消除揮霍

價值流圖完整解決方案構建質量

基本規(guī)程持續(xù)驗證

延遲決策

保持也許迅速交付

排隊理論

關注學習

產(chǎn)品&流程尊重個人

團隊伙伴

優(yōu)化整體

系統(tǒng)思考Set-baseddesign敏捷開發(fā)辦法之極限編程(XP)XP(eXtremeProgramming)極限編程核心實踐*SmallReleases

*Refactoring

*Testing/Test-drivenDevelopment

*PairProgramming

*SustainablePace/40-hourWeek

*TeamCodeOwnership

*CodingStandards/Conventions

*SimpleDesign

*Metaphor(e.g.，chalkboardapp)

*PlanningGame

*ContinuousIntegration/Build

*On-siteCustomer

StoryCardsSummarizeRequirements

PrototypeUIsandUInavigation

Stand-UpMeetings

WorkspaceEnvironment

IterationCompleteness

ArchitecturalSpike

敏捷開發(fā)辦法之OpenUP*OpenUP是一種精益統(tǒng)一過程，它在構造化生命周期中采用迭代和增長辦法。OpenUP強調注重實效、敏捷哲學，將關注重點放在軟件開發(fā)協(xié)作本性上面。它是一種不約束工具和拘泥于典禮開發(fā)過程，可以被擴展到非常廣泛項目類型之中。

*OpenUP將項目劃分為迭代：有籌劃、有時限迭代操作，普通以周為單位。迭代使團隊注重以一種可預見方式向涉眾發(fā)送增長式價值。迭代籌劃定義了在迭代期間應當完畢哪些工作，其成果是一種可以演示構造。OpenUP團隊將自組織如何實現(xiàn)迭代目的以及提交成果。團隊定義和“牽引”工作條目列表中任務。OpenuP采用迭代生命周期（組織微增量是如何被應用）來得到一種穩(wěn)定、復合系統(tǒng)需要構造，從而逐漸向迭代目的邁進。

*

OpenUP將項目生命周期分為四個階段：啟始、精化、構建和產(chǎn)品化。項目生命周期為涉眾和團隊成員提供可見度和決策點。這將更有效進行管理，并且容許您在恰當時間做出與否繼續(xù)決定。項目籌劃定義了生命周期，咱們得到最后成果是一種發(fā)布應用程序。IBM?Rational?統(tǒng)一軟件過程(RUP)*是基于軟件開發(fā)最佳實踐構建軟件開發(fā)框架

*是基于Web，包括模板、指南、工具向導及在線協(xié)助等可裁剪知識庫

*推薦迭代增量式開發(fā)

*在RUP辦法論中：

需求使用用例來表達

以架構為中心

項目管理是面向風險

關注基于技術風險進行需求俳優(yōu)、當前強調商業(yè)優(yōu)先級

*OpenUP和AgileUP都是敏捷實例

重要敏捷開發(fā)工程實踐敏捷開發(fā)工程實踐描述模板最佳實踐定義和特性闡明如何應用最佳實踐闡明案例闡明迭代式開發(fā)迭代開發(fā)，也稱迭代式開發(fā)，在軟件開發(fā)領域，指每次按照相似開發(fā)方式開發(fā)軟件某些，或前期開發(fā)并不詳盡軟件，通過重復多次開發(fā)，逐漸增長軟件某些，逐漸補充完善軟件，最后達到最后軟件。其中每次重復開發(fā)叫做一次迭代。需要闡明是，狹義迭代開發(fā)和狹義增量開發(fā)是不同。狹義迭代開發(fā)中，每次迭代解決范疇是不變，這與數(shù)學中迭代算法相似；狹義增量開發(fā)中，每次開發(fā)是增量地擴大范疇。在當前大量軟件開發(fā)實踐中，軟件規(guī)模都比較大，不也許一次迭代范疇就能覆蓋軟件所有，多數(shù)迭代解決范疇是需要增長，而在業(yè)界書面材料上，有“迭代增量式開發(fā)"、“迭代化增量開發(fā)”，“迭代式增量開發(fā)”等提法。在敏捷開發(fā)領域，為簡便計，采用“敏捷迭代開發(fā)”提法。因而在敏捷迭代開發(fā)中，每次迭代解決范疇是可以增長，也可以保持不變，甚至可以縮減范疇。在敏捷軟件開發(fā)中，敏捷迭代開發(fā)需滿足3個條件：1，迭代時間長度，也稱為迭代周期，是有短迭代周期規(guī)定，普通，敏捷迭代周期不超過8周，推薦迭代周期是2周到4周。2，迭代產(chǎn)物是可運營軟件。3，獲得迭代反饋，并解決反饋，反饋作為迭代開發(fā)中至關重要一種方面，必要得到足夠注重。歸納以上，敏捷迭代開發(fā)是指每次按照相似開發(fā)方式短期開發(fā)軟件某些，或前期開發(fā)并不詳盡軟件，每次開發(fā)結束獲得可以運營軟件，以供各方干系人觀測，獲得反饋，依照反饋適應性進行后續(xù)開發(fā)，通過重復多次開發(fā)，逐漸增長軟件某些，逐漸補充完善軟件，最后開發(fā)得到最后軟件。迭代開發(fā)長處：1、減少風險，在進行大規(guī)模投資之前就可以進行核心風險分析2、得到初期顧客反饋，各次迭代為各方干系人提供了一種機會以對進行中又可運營軟件進行評論、反饋，同步可以對將來開發(fā)趨勢產(chǎn)生影響。每次迭代都能回顧了一種可以表白各方需求決定以及開發(fā)團隊對這些需求理解軟件版本，可以決定如何修改項目方向或是劃分剩余需求優(yōu)先順序。3、對過程測量是通過對實現(xiàn)評估（而不但僅是文檔）來進行，更加直觀，更加體現(xiàn)顧客價值。4、可以自然解決變更，迅速適應新狀況。迅速開發(fā)周期，可以通過后續(xù)迭代來糾正前期迭代誤解、失誤，在迭代之間自然、平滑解決變更。5、可以對局部實現(xiàn)進行布置，建立團隊交付能力信心。關于敏捷迭代開發(fā)幾種問題：1，迭代時間長度與否每個迭代都可以調節(jié)？敏捷開發(fā)迭代周期選取和項目類型、復雜度、敏捷規(guī)?；薅汝P于，敏捷開發(fā)講究固定節(jié)奏，建議按照固定節(jié)奏開發(fā)，因而某個迭代遇到特殊狀況，盡量保證迭代時間窗不變，在不得以狀況下可以調節(jié)迭代周期長度。2，敏捷開發(fā)時，上個迭代結束后與否可以安排一段緩沖期后，再開展下個迭代嗎？敏捷開發(fā)講究固定節(jié)奏，強烈不建議安排緩沖期，有關任務可以安排在下個迭代中。3，與否可以將原瀑布生命周期階段作為迭代？例如將需求分析階段改稱為需求迭代，迭代目的產(chǎn)物就是需求規(guī)格闡明書。這種做法不符合敏捷開發(fā)辦法。敏捷迭代目的產(chǎn)物應當是可運營，不能僅僅出文檔。持續(xù)集成英文是Continuousintegration持續(xù)集成是指當代碼提交后，立即啟動自動編譯、自動布置和自動化測試來迅速驗證軟件，從而盡快地發(fā)現(xiàn)集成錯誤。持續(xù)集成要素：統(tǒng)一代碼庫自動編譯自動布置自動測試每次代碼遞交后都會在持續(xù)集成服務器上觸發(fā)一次集成保證迅速集成，集成總時間長度不超過開發(fā)人員一種休息間隙。持續(xù)集成原則：1.所有開發(fā)人員需要在本地機器上做本地編譯，然后再提交版本控制庫中。2.需要有專門集成服務器來執(zhí)行集成,每天可以執(zhí)行多次集成。3.每次集成爭取都要100%通過，如果集成失敗，立即修復，修復失敗集成是優(yōu)先級最高事情。4.每次成功集成都可以生成可運營軟件。多級項目規(guī)劃：多級項目規(guī)劃定義：多級項目/產(chǎn)品規(guī)劃，在軟件開發(fā)領域，是指以迭代開發(fā)為基本，形成多層次、逐漸細化項目或產(chǎn)品籌劃。這些層層有關項目/產(chǎn)品規(guī)劃涉及：項目/產(chǎn)品愿景、項目/產(chǎn)品路線圖、版本發(fā)布籌劃、迭代籌劃、每日實現(xiàn)（DailyScrums）。角色、產(chǎn)出物和其她闡明：1、項目/產(chǎn)品愿景：項目Stakeholder、項目/產(chǎn)品負責人將參加并構成工作組，她們負責闡述項目重要性、給出項目成功失敗核心原則以及項目整體層面“完畢”定義。形成項目愿景某些工具，涉及愿景盒子（VisionBox）、業(yè)務收益矩陣（BusinessBenifitsMatrix）、項目范疇矩陣（ScopeMatrix）、滑動器（Slider）、成本收益矩陣（Cost/BenefitMatrix）等。最后，項目愿景需要使用盡量簡要文檔固定下來，并保證項目團隊成員都能理解。該文檔需要涉及：問題、機會描述和理由（描述項目重要性）；項目價值；項目如何和組織戰(zhàn)略目的達到一致；解決方案綜述；項目包括核心功能；項目必要服從技術和約束條件；項目范疇；項目核心時間線；項目收益分析；項目和其她項目依賴性；項目有關風險以及如何消除。2、項目路線圖：項目/產(chǎn)品路線圖重要描述為了達到產(chǎn)品愿景而需要交付核心功能和特性，這些特性基本處在Epic和特性層面，不涉及UserStory。它從時間維度來表述對愿景支持和實現(xiàn)。當項目/產(chǎn)品需要發(fā)布各種版本時，項目路線圖就非常重要，否則，它和發(fā)布籌劃相似。項目/產(chǎn)品路線圖由項目負責人和項目經(jīng)理維護，并保持變化。普通，會形成路線圖文檔或幻燈片，使用大圖標顯示重要里程碑、包括功能和發(fā)布日期等，讓所有項目/產(chǎn)品有關人員都清晰產(chǎn)品各個組件也許發(fā)布日程。3、版本發(fā)布籌劃：版本發(fā)布籌劃由團隊成員和項目/產(chǎn)品負責人共同制定，并通過版本發(fā)布籌劃會議討論通過。它涉及了當前版本需要交付、達到一致核心功能，并通過優(yōu)先級排序，可以包括Epic和UserStory。支持版本發(fā)布籌劃某些概念為故事點、迭代、團隊速率和優(yōu)先級排序。普通，項目/產(chǎn)品負責人提出本次版本發(fā)布目的，團隊成員依照目的和功能特性重要性對故事進行排序，并根據(jù)團隊速率決定本次發(fā)布需要包括故事點。前幾次版本發(fā)布使用估算值，其精確度隨著項目/產(chǎn)品時間持續(xù)而逐漸精準。版本發(fā)布籌劃是具備適應性且可調節(jié)籌劃，會隨著項目演進而變化。4、迭代籌劃：迭代籌劃是對版本發(fā)布籌劃再次細化，同樣由團隊成員和項目/產(chǎn)品負責人共同制定，并通過迭代籌劃會議討論通過。迭代會議負責2件事情：依照當前狀態(tài)擬定與否需要對版本籌劃作出更新；為當前迭代制定迭代籌劃。支持迭代籌劃某些概念為拆分Epic和UserStory、任務、任務估算。在迭代會議上，成員一方面依照當前項目變化對發(fā)布籌劃進行更新，然后依照更新后、重新排序過故事制定當前迭代需要完畢故事，并對這些故事進行詳細任務拆分。成員在認領完任務后，會對任務實現(xiàn)時間做出估算，估算值需要詳細到這些估算信息可以以便任何成員追蹤任務進度。5、每日實現(xiàn)：每日實現(xiàn)是團隊成員完畢任務詳細過程，它根據(jù)任務估算值并依照任務最后實現(xiàn)狀況更新該值。在敏捷辦法中，使用每日站立會議來報告進度，通過15分鐘站立形式，團隊成員報告故事或者任務完畢、未完畢狀態(tài)，而解決層面問題則在會議之后解決。注：完整多級項目規(guī)劃包括如上5個層面，僅包括版本發(fā)布籌劃、迭代籌劃有時也被稱為2級項目規(guī)劃。完整團隊-閆建偉敏捷開發(fā)最佳實踐--完整團隊近來幾年，以SCRUM為代表敏捷開發(fā)思想在軟件開發(fā)界悄然興起，大量實踐表白，敏捷開發(fā)大大提高了軟件開發(fā)效率和軟件質量，協(xié)助軟件公司提高了效益同步也減少了成本。據(jù)調查，在歐美軟件公司已有近半數(shù)公司開始使用軟件開發(fā)，在國內多家公司也悄然興起。如果您開發(fā)團隊還在面臨需求時時多變、開發(fā)周期過長、軟件質量低下等難以解決問題，那么從老式意義開發(fā)團隊向敏捷開發(fā)團隊轉型已是事在必行。當前比較符合敏捷開發(fā)思想開發(fā)模式有XP極限編程、RUP、Lean和Scrum，其中最流行當屬Scrum開發(fā)辦法。下面筆者將結合自己親自參加各種Scrum開發(fā)模式團隊經(jīng)驗，談一談如何構建一只符合Scrum開發(fā)思想完整團隊。一方面對比一下Scrum團隊與老式開發(fā)團隊區(qū)別。1、Scrum團隊中不再有老式意義上產(chǎn)品經(jīng)理、項目經(jīng)理、開發(fā)經(jīng)理，而是引入了ProductOwner、ScrumMaster和Scrum團隊等新角色，團隊中普通會包括各種職責成員，例如由需求設計、開發(fā)和測試人員共同構成團隊。2、老式開發(fā)團隊普通是項目經(jīng)理下達工作內容，而Scrum團隊倡導自我管理，按照興趣和能力挑選任務。3、從前開發(fā)團隊普通是接到任務后分頭工作、獨立完畢，而當前Scrum團隊需要互相配合工作，互相協(xié)作完畢任務。4、老式開發(fā)過程中，普通是經(jīng)歷一種大時間段開發(fā)過程才完畢一次產(chǎn)品發(fā)布，而Scrum開發(fā)過程中，產(chǎn)品是迭代增量發(fā)布，普通是在每個Sprint結束時交付可發(fā)布軟件。下面我來簡介一下Scrum團隊完整性某些體現(xiàn)。1、Scrum團隊職責完整性在一種原則SCRUM團隊中分為3種角色，分別是ProductOwner、ScrumMaster和Scrum團隊。她們職責如下：ProductOwner需要擬定產(chǎn)品功能和完畢時間，并對產(chǎn)品收益負責，需要依照市場需求擬定產(chǎn)品功能優(yōu)先級。ProductOwner重要工作是依照市場需求擬定產(chǎn)品功能，將其列入ProductBacklog中，并為這些功能擬定優(yōu)先級。ProductOwner角色普通由市場部門人員來擔任。ScrumMaster負責監(jiān)督整個Scrum項目進程，調節(jié)項目籌劃，保證開發(fā)團隊成員能力可以勝任開發(fā)，促使團隊中不同角色可以進行充分溝通和交流，并負責為項目進程掃清障礙，保障每日開發(fā)進度及某些尋常開發(fā)管理工作。ScrumMaster普通由開發(fā)組組長擔當。Scrum團隊，普通由5-10個全職成員構成，團隊成員橫跨各種職能，普通涉及開發(fā)、需求、測試人員，人們在弱化分工，每個人都參加設計、開發(fā)與測試中，這也是團隊職責完整性一種體現(xiàn)。2、Scrum團隊素質完整性一方面，要具備很強集體協(xié)作精神。敏捷開發(fā)倡導一種重要思想就是集體協(xié)作，雖然個人能力再強，不懂得集體協(xié)作，這種人也不是敏捷開發(fā)團隊所需要。另一方面，Scrum團隊成員需要詳細良好溝通能力。敏捷開發(fā)中最強調就是溝通，最有效溝通方式就是面對面交流，那種只會埋頭工作而溝通能力不強員工，在敏捷開發(fā)團隊里也是吃不開。第三，Scrum團隊成員必要能積極積極接受新事物，要具備創(chuàng)新能力。敏捷開發(fā)與老式開發(fā)模式最大優(yōu)勢就是擁抱變化，面對時時變化客戶需求，那些不能及時轉變思維、墨守成規(guī)成員是不能勝任。最后，Scrum團隊成員要具備極強自我管理能力和積極積極精神。自我管理是敏捷開發(fā)團隊中不可或缺素質，那些工作時只會被別人引導而不能積極自我管理人也是不適合。3、Scrum溝通完整性Scrum團隊除了尋常工作之外，有三個重要會議也是要堅持，這三個會議召開好壞，直接影響到Scrum開發(fā)過程效果。這三個會議分別是Sprint啟動會、每日站立會議和Sprint回顧。一方面來簡介一下Sprint啟動會,這個會議重要目是要依照ProductOwner制定產(chǎn)品或項目籌劃在Sprint開始時做準備工作，普通是由ProductOwner依照市場前景和商業(yè)價值制定一種排好序客戶需求列表，這個列表就是ProductBackLog。當Sprintbacklog擬定后，ScrumMaster帶領ScrumTeam去分解這些功能點，細化成Sprint一種個任務.這些任務就是細化來實行這些功能點活動.SprintPlanning這個階段需要控制在4個小時。

另一方面，每日站立會議，顧名思議是每天開站會。這個會議是讓團隊成員可以面對面在一起，同步當前工作進度和狀態(tài)。普通每個成員需要輪流回答“昨天我做了什么”、“今天籌劃做什么”和“遇到了哪些困難”三個問題。這個會議普通要嚴格控制在10分鐘左右，不適當過長。最后，在一種迭代周期結束時候，要召開迭代回顧會。這個會議一方面要演示本迭代完畢工作內容，需求、開發(fā)和技術人員要做有關評審工作，由ProductOwner來擬定完畢了哪些功能，哪些工作還沒有完畢。此外，整個團隊還要回顧本迭代內哪些工作完畢好，繼續(xù)發(fā)揚和保持下去，哪些工作完畢不好，需要進行什么樣改進。這三個會議是Scrum開發(fā)過程中不可缺少重要構成某些，一定要持續(xù)將這些會議堅持下去，才干真正體會到敏捷開發(fā)帶來好處。ATDD(驗收測試驅動開發(fā))-劉曙光ATDD定義：AcceptanceTDD是測試驅動開發(fā)核心理念一種擴展，是指在用測試驅動開發(fā)實現(xiàn)某個詳細功能之前，將會一方面編寫功能測試或驗收測試，從系統(tǒng)功能角度驅動開發(fā)過程。ATDD是一種團隊行為及過程，ATDD周期包括挑選故事，給故事寫測試，實現(xiàn)測試以及最后實現(xiàn)故事這四個環(huán)節(jié)。1、挑選顧客故事：迭代開始前籌劃會議，這個會議中，客戶會決定下一種迭代該做哪些故事，及給故事排優(yōu)先級。普通狀況下可先選取較高優(yōu)先級顧客故事。2、為故事寫測試：在為故事編寫測試時候，客戶是最適合寫驗收測試人，而對于實際狀況由于客戶參加度和技能問題，可行方式是由客戶、開發(fā)人員、測試人員共同參加編寫驗收測試，給故事擬出一系列測試。在編寫測試用例時只關注完畢故事必要要做幾件事情，形成簡樸清單，后來在詳細實現(xiàn)故事或者驗收測試時在細化測試，添加更多細節(jié)，討論各某些如何工作，擬定客戶對界面與否有特別規(guī)定等。依照功能類型，相應測試可以是一組順序操作，或者是一組輸入及相應輸出。此外在故事實現(xiàn)過程中還難免會發(fā)現(xiàn)原有測試外新測試，合理做法是，在征求客戶意見后，咱們應當把新驗收測試加入到清單中。3、自動化測試：在完畢驗收測試編寫后，就需要把驗收測試轉化成可執(zhí)行驗收測試，這時候，團隊常會引入某些相對成熟測試框架及商業(yè)化自動化測試工具。這些框架和工具普通可化分為API級別功能測試（如采用Fit和FitNesse框架）和自動化GUI測試（如可采用核心字驅動框架和商業(yè)自動化工具等），團隊可以依照開發(fā)應用及團隊自身狀況選取使用其中一種或組合使用。API級別功能測試，使團隊可以在不牽涉UI層狀況下測試業(yè)務邏輯。而自動化GUI測試在實際應用中，團隊所采用自動化測試框架（普通需要團隊自行開發(fā)）針對GUI測試成熟度特別重要，良好框架可通過測試用例、界面對象、數(shù)據(jù)分離，大大減少由于頻繁界面變化而對已有自動化腳本影響。4、實現(xiàn)故事：實現(xiàn)新功能，讓新加入驗收測試通過。ATDD自身并不會限制實現(xiàn)功能方式，但是使用ATDD人普通傾向與在實現(xiàn)過程中采用TDD方式。這樣在代碼層面，采用TDD辦法以測試驅動方式編寫代碼。在軟件特性和功能層面，使用ATDD辦法以測試驅動方式構建系統(tǒng)，這兩個不同層面上結合使用測試驅動，既能保證軟件內部質量同步能保證開發(fā)出軟件能滿足對的功能需求。結對編程-高航前言：在敏捷軟件開發(fā)各種實踐中，結對編程（PairProgramming）是特別有爭議，特別是在國內軟件公司或團隊，幾乎看不到有真正實踐、施行，并帶來效果。相比于其她敏捷軟件開發(fā)辦法火熱及它們帶來成效，結對編程可以說備受冷落。它看上去很美，但想要成功實踐，可謂障礙重重。那么實用為王，咱們是不是可以秉承結對編程先進核心理念和思想，而將它實踐框架加以改造，讓它更適合咱們工作流程和習慣，最后成功實踐并提高研發(fā)效率和質量呢？于是有了下面一種變形、可實踐結對編程辦法。老式結對編程定義及特性：兩位程序員形成結對小組，肩并肩地坐在同一臺電腦前合伙完畢同一種設計、同一種算法、同一段代碼或同一組測試。結對編程可以看作是一種敏捷化代碼檢查（CodeReview），其最后目的是提高軟件產(chǎn)品質量。代碼檢查工作是公認提高軟件產(chǎn)品質量重要活動之一，但在實踐中，成功應用也并不多見，因素是老式代碼檢查辦法只能在某個功能完全開發(fā)完畢后才進行檢查，效率不高。而更大問題是，檢查人對被檢查人代碼所實現(xiàn)業(yè)務功能并不十分清晰，因此只能檢查代碼格式、語法與否規(guī)范，對實現(xiàn)邏輯與否滿足業(yè)務需求往往無法檢查。這導致了諸多公司和團隊代碼檢查都流于形式。結對編程就解決了這一問題，它不需要代碼都寫完才開始檢查，而是在兩個人互相協(xié)作過程中，實時進行多次交叉檢查，大大提高了效率，并且由于兩人同步完畢設計和代碼，對業(yè)務需求也都理解，因此檢查時可以驗證代碼與否滿足了需求、與否符合業(yè)務邏輯。但是，老式結對編程模式也有某些顯而易見問題導致其難以實踐，例如人們緊張兩個用一臺電腦做同樣一件事情，是不是揮霍了人力資源？兩個人個性、習慣、水平都不同，在對等地位上同步做一件事情會不會產(chǎn)生沖突和矛盾？她們之間溝通和協(xié)作會順暢嗎？會不會感到不自在？新結對編程定義及特性：兩位程序員形成結對小組，每人一臺電腦，坐在臨近工位上，兩人合伙完畢一組功能（可以是兩個或各種獨立模塊）設計、代碼實現(xiàn)。但對于某一種模塊來說設計和代碼是分開，一種人負責設計，另一種人負責寫代碼，對于其她模塊則反之。當某個功能階段性完畢后，由其設計人員對代碼進行檢查。當前，諸多敏捷開發(fā)倡導者們都在積極尋找可實踐結對編程變形體，以打破結對編程這種看上去很美，摸上去扎手狀況。而上述這種形式新結對編程，也是咱們幾經(jīng)摸索總結出來一種可實踐結對編程形式，并在產(chǎn)品團隊中成功應用。它繼承了結對編程核心理念，讓代碼檢查更加高效、進一步。也在兩人合伙模式上，更適應實際工作狀況和工作習慣，以做到真正可實踐、可應用。下面詳細簡介這種新結對編程內容。1、角色與參加形式：在可實踐結對編程中，參加人是開發(fā)人員，她們兩個人形成一種小組，臨近而坐，在詳細某個功能或任務上，兩個人所扮演角色是有承辦關系，一種是設計者、另一種是開發(fā)者，一種是審查者、另一種是被審查者。而在在總體上，兩個人關系又是平等，由于設計與開發(fā)、審查與被審核對于兩個人來說是互相。這樣就避免了某些結對小組中兩人在協(xié)同工作中會產(chǎn)生沖突與矛盾。2、重要活動與工作流程：這里咱們舉例來說，兩個開發(fā)人員甲和乙，形成結對編程小組，共同負責兩個功能A和B。工作開始，甲進行A設計工作，并給出設計文檔(關于設計文檔闡明請見“題外話”)。乙進行B設計工作，并給出設計文檔。兩人設計工作完畢后，互相閱讀對方設計文檔并進行交流，兩人要保證對對方設計內容理解清晰，并指出對方文檔中描述不本地方讓其修改，最后保證設計內容是清晰明確，并且甲、乙兩人對A、B功能設計都熟悉明確并思想一致。接下來開始代碼開發(fā)工作，甲按照乙設計文檔開發(fā)功能B，乙按照甲設計文檔開發(fā)功能A。代碼開發(fā)工作進行到某個段落后，甲對乙開發(fā)功能A代碼進行審查，檢查代碼格式和規(guī)范以及代碼實現(xiàn)與否符合甲設計業(yè)務邏輯，如有問題，則請乙進行修改并復查，乙同樣反之對B進行審查，最后達到代碼開發(fā)完畢，A、B兩個功能都進行過多次審查和修改，并且甲、乙兩人都確認兩個代碼是合格，并符合業(yè)務需求。這樣，功能A、B設計和代碼實現(xiàn)就是有甲、乙共同協(xié)作完畢，兩人共同對兩個功能負責，并且兩人對兩個功能設計和實現(xiàn)都清晰，更為重要是甲、乙兩人工作是互相并行配合，不會產(chǎn)生沖突，更為容易推廣施行。3、額外好處：按照可實踐結對編程模式完畢軟件開發(fā)，不但高效完畢了代碼檢查，提高了軟件質量，還帶來了某些額外好處：1、每個模塊至少兩個人熟悉，這樣在有人請假時候均有backup，不會導致嚴重耽誤工作進度。如果有人要離職，交接工作普通也會非常輕松，幾乎沒有什么需要特別交接。2、進行結對兩個開發(fā)人員互相閱讀設計文檔和代碼實現(xiàn)，實際也是一種互相學習過程，因此結對編程也起到了某些知識傳播、培訓作用。題外話：關于敏捷開發(fā)中設計文檔，說某些題外話。敏捷開發(fā)與老式瀑布型開發(fā)一種很重要區(qū)別就是：在研發(fā)活動中各環(huán)節(jié)流轉承辦時，瀑布型開發(fā)是以文檔為主，思想交流與溝通為輔。而敏捷開發(fā)是以思想交流與溝通為主，文檔為輔。因此在瀑布型開發(fā)中，對設計文檔格式和規(guī)范等規(guī)定比較高。而敏捷開發(fā)中設計文檔，只是要描述清晰設計思想，并作為一種輔助手段，將核心內容存留作為根據(jù)即可，不需要規(guī)范模板?？梢砸勒赵O計者習慣，以最高效形式描述清晰設計內容，并且清晰明確即可。在結對編程實踐中，所涉及到設計文檔書寫，都是以此種方式進行。擬定沖刺籌劃-袁斌、錢嶺兩位專家請將這某些整頓成為一種最佳實踐：敏捷規(guī)劃，如何，多謝！-DJ袁斌：“擬定沖刺籌劃”草稿：沖刺會議目：Scrum團隊和產(chǎn)品負責人（ProductOwner）共同決定在接下來沖刺周期內目的以及哪些功能和任務需要完畢。沖刺會議參加最重要角色：Scrum團隊，產(chǎn)品負責人以及ScrumMaster沖刺會議重要輸入工件：ProductBacklog、團隊能力沖刺會議重要輸出工件：SprintBacklog沖刺會議重要流程闡明：沖刺會議最重要參加人員是Scrum團隊，產(chǎn)品負責人以及ScrumMaster，同步感興趣管理層或者客戶代表也可以參加。整