一、敏捷宣言
1.個體和互動 高于流程和工具(Individuals and interactions over processes and tools)
2.工作的軟件 高于詳盡的文檔(Working software over comprehensive documentation)
3.客戶合作 高于合同談判(Customer collaboration over contract negotiation)
4.響應變化 高于遵循計劃(Responding to change over following a plan)
二、12 條敏捷原則
1.我們最重要的目標,是通過持續不斷地及早交付有價值的軟件使客戶滿意。
2.歡迎需求變化,即使在開發后期也一樣。善于掌控變化,幫助客戶獲得競爭優勢。
3.經常地交付可工作的軟件,相隔幾星期或幾個月,傾向于采取較短的周期。
4.業務人員和開發人員必須每天在一起工作。
5.激發個體的斗志,以他們為核心搭建項目。提供他們所需的環境和支持,相信他們能夠 達成目標。
6.在團隊內部,傳遞信息效果最高效的方式是面對面的交談。
7.可工作的軟件是進度的首要度量標準。
8.敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
9.對技術精益求精,對設計不斷完善,將提高敏捷能力。
10.以簡潔為本,極力減少不必要工作量。
11.最好的架構、需求和設計出自于自組織的團隊。
12.團隊定期地反省如何能提高成效,并由此調整團隊的行為。
三、SCRUM 兩個角色
Scrum Master(不是項目經理,沒有分配任務的權力,沒有考核的權力,沒有下命令的權力)
1.幫助團隊鏟除一切阻礙,讓團隊可以順利完成沖刺目標
2.幫助團隊最大化生產力
3.使用技術手段幫助團隊變得更加高效,比如:引入自動化腳本,單元測試,持續集成等敏 捷實踐
4.協助團隊和 PO 更好的進行協作
5.保證 Scrum 實踐的正確推行 Product owner(PO)產品的負責人,需求負責人,
6.需求決策:哪個需求重要,哪個需求不重要,需求的優先級如何排列,在某次發布中要發 布哪些需求是他來拍板的
四、三個文件
1.Product backlog 產品待辦列表: 排序的列表,包含所有產品需求,PO 決定產品待辦列表 的內容、可用性和優先級。
2.Sprint Backlog 待辦事項列表,(相當于 WBS),來源于產品待辦列表,更具體
3.燃盡圖是反映進度狀態,也可以預測未來趨勢
五、四個會議
1.計劃會議(明確目標、細化任務) 1)決定完成哪些任務 2)如何完成
2.每日立會(定時、定點、人齊、會短、高效)
1)一個簡短的團隊會議,由團隊的所有成員在每天固定的時間和地點進行
2)查看項目進展,在會議中作計劃,協調每日活動,還可以報告和討論遇到的障礙
3)任務板能夠幫助團隊聚焦于每日活動之上,要在這個時候更新任務板和燃盡圖。
4)會議上每個成員需要回答 3 個問題: 1你昨天做了什么? 2今天計劃做什么? 3是否遇到了障礙,需要其他人的幫助?
3.評審會(展示驗收)
1)小組向產品負責人展示和驗收迭代工作結果。
2)產品負責人給出評價和反饋。
3)評審會上發現的問題或改進將被累積到產品待開發項,也不會馬上或在下一個迭代中開 發,而是由優先級排序決定何時開發。(無需提變更請求)
4.回顧會議(經驗總結,識別改進)
1)回顧團隊在流程、人際關系以及工具方面做得如何。
2)團隊識別出哪些做得好,哪些做得不好,并找出潛在的改進事項為改進制定計劃。
六、敏捷術語和概念
1.敏捷項目范圍不固定,而時間和成本是固定的
2.敏捷使用自上而下的估計
3.敏捷文檔通常勉強夠用
4.敏捷有利于適應,而傳統的管理方法有利于預期
七、產品路線圖(Product Roadmap) - 提供功能發布里程碑的高級概述。
八、項目章程對于敏捷項目和傳統項目都很重要,必須在敏捷項目開始時創建。
九、帕累托原則:也稱為 80-20 規則指出,對于敏捷項目,80%的最有用的功能可以在 20%的努 力中完成,強烈建議關注“20%”
十、參與式設計:通過積極讓利益相關者參與設計過程來確保結果符合預期的設計方法。 用戶故事描述用戶渴望得到的功能。
十一、一個好的用戶故事包括三個要素:
1.角色:誰要使用這個功能。
2.活動:需要完成什么樣的功能或目標。
3.商業價值:為什么需要這個功能,這個功能帶來什么樣的價值。
十二、通常按照如下的格式來表達:
英文:As a
中文:作為一個<角色>, 我想要<活動>, 以便于<商業價值>
十三、3C:卡片(Card)、對話(Conversation)和確認(Confirmation)。
1.卡片(Card):用戶故事一般在小卡片上寫著故事的簡短描述,工作量估算等。
2.交談(Conversation):用戶故事背后的細節來源于和客戶或者產品負責人的交流溝通。
3.確認(Confirmation):通過驗收測試確認用戶故事被正確完成。
十四、用戶故事的六個特性- INVEST:
- I dependent(獨立的)
- N egotiable(便于溝通的)
- V aluable(有價值的)
- E stimable(可估計的)
- S mall(短小)
- T estable(可測試的)
>>本文地址:
注:本站稿件未經許可不得轉載,轉載請保留出處及源文件地址。
申請試聽課程