Volatility?波動 Uncertainty?不確定性????Complexity?復雜 ??Ambiguity ?模糊

Vision???愿景?Understanding 理解?????Clarity ?清晰?????Agility?敏捷

??十二大原則

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

2.?欣然面對需求變化，即使在開發(fā)后期也一樣。為了客戶的競爭優(yōu)勢，敏捷過程掌控變化。

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

4.?業(yè)務人員和開發(fā)人員必須相互合作，項目中的每一天都不例外。

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

6.?不論團隊內(nèi)外，傳遞信息效果最好效率也最高的方式是面對面的交談。

7.?可工作的軟件是進度的首要度量標準。

8.?敏捷過程倡導可持續(xù)開發(fā)。責任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。

9.?堅持不懈地追求技術(shù)卓越和良好設(shè)計，敏捷能力由此增強。

10.?以簡潔為本，它是極力減少不必要工作量的藝術(shù)。

11.?最好的架構(gòu)、需求和設(shè)計出自自組織團隊。

團隊定期地反思如何能提高成效，并依此調(diào)整自身的行為表現(xiàn)。

??四大價值觀 4大宣言

個體和互動 高于 流程和工具
工作的軟件 高于 詳盡的文檔
客戶合作 高于 合同談判
響應變化 高于 遵循計劃

?

??3 大角色

Product Owner?（PO）PO是了解客戶需求以及相關(guān)商業(yè)價值的團隊角色，作為客戶代表，定義產(chǎn)品功能，決定產(chǎn)品發(fā)布的內(nèi)容和日期，對產(chǎn)品的投入產(chǎn)出負責。根據(jù)市場變化對需要開發(fā)的功能排列優(yōu)先順序，合理調(diào)整產(chǎn)品功能和迭代順序。

Scrum Master (SM)?敏捷教練SM 將幫助團隊消除任何阻礙團隊生產(chǎn)力的障礙，SM的角色是培訓和激勵團隊成員。他起到教練的作用。

Development Team?（Dev.Team）開發(fā)團隊由關(guān)鍵開發(fā)者或架構(gòu)師等5-9人組成，他們各有職責但又是多面手，能獨當一面又能互相支持。他們在敏捷開發(fā)在不斷的組織和管理屬于自己的工作，由此產(chǎn)生的協(xié)作力將優(yōu)化團隊的整體效率和能力。

?

??5 個會議

1.產(chǎn)品梳理會：30min.拆分歷史，分析并排列用戶故事，經(jīng)過分析將不明確和待完善的地方加以完成，以免將這些殘余問題留到迭代計劃會上。

2.迭代計劃會 Sprint Planning Meeting，1-2h。選擇本次迭代的目標并給出工作量估算。

3.每日站會 Daily Scrum Meeting

會議主要討論三個問題：

- ???????昨天做了什么?

- ???????今天將要做什么?

- ???????有需要幫助的地方嗎?

4.迭代評審會 Review Meeting

5.迭代回顧會 Retrospective Meeting

??構(gòu)建敏捷文化（目標）：文化→價值→原則→實踐→工具

??

優(yōu)化我們的思維和行為模式，減少不必要的時間浪費，提高產(chǎn)品的市場滿意度：MVP

MVP?- minimum viable product，最小可行產(chǎn)品

以最簡易的產(chǎn)品形式進入市場試錯，多犯錯、早犯錯，然后根據(jù)錯誤對產(chǎn)品進行快速迭代。以最小的時間成本和金錢成本去試錯，從而換取在市場中的快速成長的機會。

做產(chǎn)品的時候，很容易脫離實際的市場，而市場的變化是十分迅速的，一個“完美方案”不應該是在腦子里想出來的，而應該是切合市場，從實際的市場需求和反饋中推演出來的。

?

??Design Thinking（工具）

用戶視角

設(shè)計思維五大步驟

同理心（Empathize）——?研究用戶的需求

定義（Define）——?陳述用戶的需求和問題

構(gòu)思（Ideate）——?挑戰(zhàn)假設(shè)并創(chuàng)造想法

原型（Prototype ）——?開始創(chuàng)建解決方案

測試（Test）——?嘗試您的解決方案

??Backlog 管理（工具）需求管理 或 Job 管理方法

???Waterfall PRD 文檔 VS Scrum Backlog

Waterfall PRD傳統(tǒng)的瀑布工作模式使用詳細的需求說明書來表達需求，需求人員負責做需求調(diào)研，根據(jù)調(diào)研情況編制詳細的需求說明書，進行需求評審，評審之后簽字確認交給研發(fā)團隊設(shè)計開發(fā)。在這樣的環(huán)境下，需求文檔是信息傳遞的主體，也是一份契約。然而這種詳細的PRD 文檔有以下5大弊端：

1. 單向的信息傳遞，容易出現(xiàn)理解偏差。

2. 文檔很正式，我們會誤以為它一定是對的，不去質(zhì)疑它，讓我們停止作出判斷。

3. 有了詳細的文檔，我們不會反復討論它，相互確認。

4. 書面文檔不利于團隊共享責任，它扮演了證據(jù)的角色。

5. 編制詳細的、表達準確需求文檔需要花費大量的時間，如果需求變化頻繁，維護成本更高。

Scrum Backlog敏捷使用產(chǎn)品Backlog來管理需求，產(chǎn)品 Backlog 其實就是一個優(yōu)先級排序的需求清單，優(yōu)先級的需求在 Backlog 的最上層。更強調(diào)團隊共享責任，團隊會用10%的時間梳理工作。共同目標是通過討論協(xié)作，正確理解需求之后把這些需求變成客戶真正需要的功能，而不是單向的任務傳遞。

1.?詳盡適當（高優(yōu)先級的比低優(yōu)先級的技術(shù)更詳細。優(yōu)先級越低，細節(jié)越少）

2.?可估算（以故事點或者理想人天形式表達）

3.?演化（根據(jù)用戶的不斷反饋，識別出新條目會被加入Backlog里面

4.?按優(yōu)先級排序（所有條目都是按照優(yōu)先級排序的，最重要、優(yōu)先級最高的條目最先實施，一旦完成，便從 Backlog 移除。紙質(zhì)卡片）

??敏捷會議原則（工具）

ü?明確會議需要達成的目標

ü?明確時間和日程 - 控制時間 40分鐘以內(nèi)

ü?提前通知和準備

ü?討論行動方案，而非問題

ü?會議要得出結(jié)論 - 發(fā)出會議紀要和行動計劃

??

?