前些天對需求討論確定后開始制定計劃安排。
根據最近對agile的一些體會我這次制定計劃是這樣的：

1、根據需求的功能點定義，把需求縱向切割成一個個較為獨立的story，然后把這個story歸入到計劃中。
解釋：對于一個story來說，所有的分析、設計、實現都是由一個開發者來完成的。當然在開始實現前對于一般的設計都是要一起討論的
這時候story可以確立的基本屬性有：title（標題）description（描述）

2、我把story收集好之后，根據需求的復雜度和優先級作了一個初步的分析，然后再和資深的developer做一次溝通，大概預估以下每個story需要花費的時間，然后根據老大給我的時間要求把story分成了兩個iteration
這時候可以確定的story屬性有：Iteration（迭代周期）  Priority（優先級） Release（發布版本） Status（狀態） PlanSize（計劃時間）

3、當我確定了在當前迭代周期需要完成的story之后，我就會在開發小組內部召開一個小討論，羅列出這個迭代周期內有哪些功能需要完成，然后由大家自己選擇感興趣的story
在選擇story的同時可以經過討論確立的屬性有：developer（開發者）

至此一個迭代發布版本的粗略計劃，一個迭代周期的詳細計劃就已經出來了。

but，當我把這個計劃提交給我老大的時候，他們提出了幾個問題：
1、一個功能縱向開發，如何知道開發者每天的工作任務，如何知道他現在是在做設計和還是在做開發
2、以前的開發是有一個專門負責實現設計和后臺接口實現，一個專門負責調用接口和前臺實現，這樣由一個人開發后，有些人可能會在模型和接口的實現上因為經驗不足而造成失誤
3、讓一個人獨立開發一塊功能，是不是破壞了項目組內部的協作機制，是否會讓開發者感覺到他是孤獨的
4、如何考察一個開發者的工作是否飽和？

對于上面的問題，我經過思考和討論后給出了這樣的回答：
1、每天都會由我發起一個簡短的狀態了解，了解每個story的進度，是在分析，是在設計，設計還是在實現了我都會對story做一個記錄
2、一個人縱向開發也許會經驗不足造成接口不夠全面，但是由于是他一個人開發，他可以方便的根據自己需求來修改接口。而且兩個人在橫向開發時會有一些溝通交流問題而造成成本增加。（實際上在完全的agile中是由兩個人結隊開發，而且通常的組合是一個經驗豐富的帶一個經驗少的）
3、在功能開發時，無論是分析，設計，還是實現發現問題都可以立即舉手進行討論。可以說只要有問題就是團隊一起解決的。
4、這其實是只如何對開發者進行工作量考核了，我覺得從敏捷的角度來看考核的問題比較簡單，就是你最終實現的完整功能（因為只有完整的功能才能給產品帶來價值）所花費的時間和預期時間的差值。比如說一個story預期是6點（兩點為一天）完成，結果你用3點就做完了，那么你的考核點就是+3，但是這還沒完，當測試后發現這個功能點出現一次bug，你的考核點就要扣除1點，這樣最終的考核點就是2點。

經過和老大的討論之后，他們覺得以功能story來分配的方法和以前已工作任務來分配的方法是有些難以控制的，但是還是同意我開始在項目組試行（這里要贊一下我老大的開明態度）

最后提一下我用于agile項目管理的工具，相信很多人都猜到了，就是mingle

下篇預告：mingle使用小記    時間：2007-9-11