敏捷實施流程

#高效的提出本身的需求(idea)

You have an idea, we need a story!

1. 什麼是用戶故事?

定義:用戶故事是從用戶的角度來描述用戶渴望獲得的功能。

2. 一個好的用戶故事包括三個要素：

角色：誰要使用這個功能。

活動：須要完成什麼樣的功能。

商業價值：爲何須要這個功能，這個功能帶來什麼樣的價值。

3. 範式: 做爲一個<角色>, 我想要<活動>, 以便於<商業價值>

舉例：做爲一個「網站管理員」，我想要「統計天天有多少人訪問了個人網站」，以便於「個人贊助商瞭解個人網站會給他們帶來什麼收益。」

好比: 做爲一個KeeeWeee用戶, 我想要"...", 以便於"..."

商業價值: 商業價值包含客觀的價值,好比:Money;也包含隱性的價值.好比:用戶是一種隱性的價值,隱性價值必定程度上可以轉化爲客觀價值.

#No, No, No!

當你孕育好久的設計(想法),拿出來和別人分享的時候,卻遭到了別人赤裸裸,血淋淋的反駁.

"你的想法不行"

"你的想法N年前就有了"

"You Idiot"

...

1. 否定、嘲笑、譴責

沒有人願意分享本身的想法,致使一個創業公司失去了失去了包容創造的環境和創新的能力,你們淪爲苦逼碼農.

負面評價令人消極，成長鬚要鼓勵，別扼殺創造力

2. 局內人和局外人

局內人: 融入他人的想法,積極地尋找他人的優勢

局外人: 旁觀者清; 「若是這裏這麼作，它會發生什麼問題嗎」, 共同尋找更好的方案

3. 咱們該怎麼作??

全力提出想法

不要脫離現實，不帶我的情緒的思考

樂於分享

多人決策，少數服從多數(不要僵化，自適應)

#高效的工做:

1. 開發流程

用戶故事 --> 故事評審 --> 任務拆分+評估 --> 制定迭代計劃 --> 驗收

2. 用戶故事

概化抽象的需求(idea) => 有趣容易理解的故事

3. 故事評審

理解 & 討論: 確保每一個成員可以理解故事

評估: 優先級[客戶參與; Importance] & 完成時間[包含故事點s]

故事點: 理想狀況下一我的一天可完成的任務

評審: 評審這個迭代要進行的故事.

原則: 1. 少數服從多數. 大部分人認爲可作那麼必須作，如反之不作(延後處理);

2.客戶意見, 故事的重要性級別很是高.

4. 任務拆分

開發成員負責把故事拆分爲粒度更小的開發任務[task]，確保一天或兩天可以完成。

何爲合適: 一個功能, 一個接口, 確保能夠測試和驗收. 對於後臺來講多是一個能夠對接的接口; 對於前端來講多是一個測試用例

5. 任務評審

任務估時 & 優先級制定

任務優先級制定原則: 需求優先係數(0~20) * 實現難易度係數(0~1)

6. 迭代計劃

迭代週期如何計算: 開發時間 + 集成時間 + 驗收 + bugs fix

7. 驗收

測試用例

每日驗收

天天下班前兩小時爲固定的測試驗收時間.

測試用例 & bug反饋

迭代驗收 故事完成度評估 迭代完成狀況評估

8. 每日例會

每人彙報內容:

昨日工做內容 & 完成狀況 & 遇到什麼問題

今天的工做