前些天對(duì)需求討論確定后開(kāi)始制定計(jì)劃安排。
根據(jù)最近對(duì)agile的一些體會(huì)我這次制定計(jì)劃是這樣的：

1、根據(jù)需求的功能點(diǎn)定義，把需求縱向切割成一個(gè)個(gè)較為獨(dú)立的story，然后把這個(gè)story歸入到計(jì)劃中。
解釋：對(duì)于一個(gè)story來(lái)說(shuō)，所有的分析、設(shè)計(jì)、實(shí)現(xiàn)都是由一個(gè)開(kāi)發(fā)者來(lái)完成的。當(dāng)然在開(kāi)始實(shí)現(xiàn)前對(duì)于一般的設(shè)計(jì)都是要一起討論的
這時(shí)候story可以確立的基本屬性有：title（標(biāo)題）description（描述）

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

3、當(dāng)我確定了在當(dāng)前迭代周期需要完成的story之后，我就會(huì)在開(kāi)發(fā)小組內(nèi)部召開(kāi)一個(gè)小討論，羅列出這個(gè)迭代周期內(nèi)有哪些功能需要完成，然后由大家自己選擇感興趣的story
在選擇story的同時(shí)可以經(jīng)過(guò)討論確立的屬性有：developer（開(kāi)發(fā)者）

至此一個(gè)迭代發(fā)布版本的粗略計(jì)劃，一個(gè)迭代周期的詳細(xì)計(jì)劃就已經(jīng)出來(lái)了。

but，當(dāng)我把這個(gè)計(jì)劃提交給我老大的時(shí)候，他們提出了幾個(gè)問(wèn)題：
1、一個(gè)功能縱向開(kāi)發(fā)，如何知道開(kāi)發(fā)者每天的工作任務(wù)，如何知道他現(xiàn)在是在做設(shè)計(jì)和還是在做開(kāi)發(fā)
2、以前的開(kāi)發(fā)是有一個(gè)專門負(fù)責(zé)實(shí)現(xiàn)設(shè)計(jì)和后臺(tái)接口實(shí)現(xiàn)，一個(gè)專門負(fù)責(zé)調(diào)用接口和前臺(tái)實(shí)現(xiàn)，這樣由一個(gè)人開(kāi)發(fā)后，有些人可能會(huì)在模型和接口的實(shí)現(xiàn)上因?yàn)榻?jīng)驗(yàn)不足而造成失誤
3、讓一個(gè)人獨(dú)立開(kāi)發(fā)一塊功能，是不是破壞了項(xiàng)目組內(nèi)部的協(xié)作機(jī)制，是否會(huì)讓開(kāi)發(fā)者感覺(jué)到他是孤獨(dú)的
4、如何考察一個(gè)開(kāi)發(fā)者的工作是否飽和？

對(duì)于上面的問(wèn)題，我經(jīng)過(guò)思考和討論后給出了這樣的回答：
1、每天都會(huì)由我發(fā)起一個(gè)簡(jiǎn)短的狀態(tài)了解，了解每個(gè)story的進(jìn)度，是在分析，是在設(shè)計(jì)，設(shè)計(jì)還是在實(shí)現(xiàn)了我都會(huì)對(duì)story做一個(gè)記錄
2、一個(gè)人縱向開(kāi)發(fā)也許會(huì)經(jīng)驗(yàn)不足造成接口不夠全面，但是由于是他一個(gè)人開(kāi)發(fā)，他可以方便的根據(jù)自己需求來(lái)修改接口。而且兩個(gè)人在橫向開(kāi)發(fā)時(shí)會(huì)有一些溝通交流問(wèn)題而造成成本增加。（實(shí)際上在完全的agile中是由兩個(gè)人結(jié)隊(duì)開(kāi)發(fā)，而且通常的組合是一個(gè)經(jīng)驗(yàn)豐富的帶一個(gè)經(jīng)驗(yàn)少的）
3、在功能開(kāi)發(fā)時(shí)，無(wú)論是分析，設(shè)計(jì)，還是實(shí)現(xiàn)發(fā)現(xiàn)問(wèn)題都可以立即舉手進(jìn)行討論。可以說(shuō)只要有問(wèn)題就是團(tuán)隊(duì)一起解決的。
4、這其實(shí)是只如何對(duì)開(kāi)發(fā)者進(jìn)行工作量考核了，我覺(jué)得從敏捷的角度來(lái)看考核的問(wèn)題比較簡(jiǎn)單，就是你最終實(shí)現(xiàn)的完整功能（因?yàn)橹挥型暾墓δ懿拍芙o產(chǎn)品帶來(lái)價(jià)值）所花費(fèi)的時(shí)間和預(yù)期時(shí)間的差值。比如說(shuō)一個(gè)story預(yù)期是6點(diǎn)（兩點(diǎn)為一天）完成，結(jié)果你用3點(diǎn)就做完了，那么你的考核點(diǎn)就是+3，但是這還沒(méi)完，當(dāng)測(cè)試后發(fā)現(xiàn)這個(gè)功能點(diǎn)出現(xiàn)一次bug，你的考核點(diǎn)就要扣除1點(diǎn)，這樣最終的考核點(diǎn)就是2點(diǎn)。

經(jīng)過(guò)和老大的討論之后，他們覺(jué)得以功能story來(lái)分配的方法和以前已工作任務(wù)來(lái)分配的方法是有些難以控制的，但是還是同意我開(kāi)始在項(xiàng)目組試行（這里要贊一下我老大的開(kāi)明態(tài)度）

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

下篇預(yù)告：mingle使用小記    時(shí)間：2007-9-11