先看下面的流程圖:

一. 前期準備階段

有很多人不太重視前期的準備, 或者不太在意這方面的事情. 還有一個問題, 前期的準備要準備到什麼程度?

在我這裡, 前期要做好三件事: 需求分析工作, 資料分析工作, 概要開發方案

需求分析: 這部分就是我們的專業需求人員所要處理的事情. 主要負責把本次版本中的功能分析清楚.我們一直強調一點, "需求要明確", 不允許在需求文件中出現類似"跟XXX一樣"等這種含混不清的字眼. 一般來講, 分析到此業務的背景, 解決的問題, 使用者的操作場景, 有這些資訊有可以了.

資料分析: 尤其在我們的計價軟體中, 定額庫是不可缺少的東西. 他是你程式能夠執行的前提.對於資料如何製作, 用何種方式製作能,製作成什麼格式是最省力的, 對開發, 對資料人員的加工量是最少的, 能否支援程式執行. 資料的儲存的介質,格式決定了後面的開發方案

開發方案分析: 目標達到能說清楚這件事怎麼做就可以了. 內容格式方面可以自由擴充套件. 可以以下面的我的分析方案為參考:

可參考我之前的部落格:<<概要設計 －－需求定義及描述方式>>

圖2(需求分析格式)

二. 方案評審

這一步是必須的. 讓業務專家, 或者有經驗的人給你把下關.這樣對你的方案是一個很大的補充. 一個人的想法很難保證想的很全, 所以, 可以經過這個環節進一步充實你的方案.等這一步完成後, 你會形成專案列表. 就是針對每個開發功能, 拆解為詳細的開發步驟, 並估算出工時, 如下圖所示:

圖3(任務分析明細圖)

這樣有助於你完成更為詳細的開發計劃. 一定要把任務項列細了, 越細, 對後面的進度控制就越有幫助.

三. 專案啟動會議

正如我上上篇文章所說, 這個過程的好壞會對後面的開發任務有很大的影響.在這個過程, 重點是進行需求交底. 把前面的分析結果再加上已經評審通過的內容做成PPT, 給整個團隊成員做講解. 讓團隊中的每個成員都能知道

我們很難保證讓團隊中的每一個人都能把所有的業務都理解的很清楚, 這是很難辦到的, 但可以保證的是,當這個任務為某個人做的時候, 他會更專心的去聽這塊內容, 對於要執行者,他是最為關注的. 這樣當需求交底完成的, 可能是大部分人對需求都有所瞭解, 理解度在20%~60%左右吧, 但執行此任務的人理解度應該能達到90%左右. 不用擔心, 我們後面有辦法讓那些只理解20%的人也能掌握另外的沒掌握的內容.

當需求交底完成後, 就要開始進行方案交底了, 一般你會把之前分析的內容給大家講出來, 並給出自己的一套預設的開發方案,然後由大家來評審這個方案如何.

在這個過程,有開發, 有測試, 有需求, 有資料,都會從不同的角度去分析此問題.在討論過程中,那些本來可能還是太懂的人, 結過這麼討論,就會更明白了許多. 這樣, 其理解度會上長到50%應該是沒問題的.做為主持者, 當你發現某些人確實不在狀態時,可採用單獨提問方式來讓他加深記憶,這都是可以的.

還有不太清楚業務的, 沒關係, 下面我們就要根據前面敲定的方案來排定任務了. 因為已經經過了前面的方案討論, 所以對開發的時間應該有所把握, 這時,對於不清楚業務而無法估算出時間, 或者為了估算出正確的時間以至不會讓自己任務拖延的, 也要再熟悉一遍需求. 經過這樣, 需求基本上就都搞清楚了.那最後就要出我們的作戰圖了:

圖4(作戰圖示例)

之前也說過, 作戰圖的作用, 就是把事情盤點清楚(當然你也可以理解為"網路圖"), 讓每一個人所做的的任務都能具體到整個過程的位置, 地位, 清楚自己的任務在整個專案中處在什麼樣的關鍵位置上.

這就是作戰圖的優勢, 把團隊的目標凝聚在一起.

四. 迭代開發

如上幅圖所示, 我們有很多工點, 任務項, 我如何能讓在開發過程中, 讓我們的團隊更具有凝聚力, 更能向上呢, 答案就是自適應團隊. 那如何才能實現呢.

那就是短週期迭代. 我們可以把每一個任務做成一個小週期的迭代. 你這個迭代必須是有交付物的, 沒有交付物, 那就沒辦法驗證你的成果.

在這個過程中, 我們只需要回答兩個問題就足夠了: 1. 能不能用. 2.有什麼用. 當你進行完這個迭代後能回答這兩個問題, 那麼, 我就可以認為這個迭代完成, 可以進行一下個週期的迭代.

以前我們在排定任務的時候, 總是在想著這個任務開發完成後再交由測試去測.這樣相當於開發與測試在並行, 相互的交集就比較少. 開發只管開發的事, 完了後修改BUG就行了. 而測試呢, 只需求不停的測試版本就行了, 什麼也不用管. 這樣帶來的問題就是修改BUG不及時, 有可能會出現開發成了這個功能好久後測試才提出這個問題, 開發再去修改. BUG越往後修改效率就越差的. 所以, 應該想辦法讓任務風險前移.

當我給定一個開發任務時, 當他提交時, 應該是嚴格結過測試, 需求確認的. 測試的驗證, 保證了該功能是"能用"的問題, 而需求的評審通過意味著該功能的"有用的", 自然也就是有價值的. 有用, 但不能用, 價值無法傳遞出去; 能用(可以使用), 但沒用(此功能沒有意義), 相當於做無用功. 所以在交付時, 一定是回答了"能不能用", "有什麼用"之後的.

這樣, 在排定任務時, 就把開發, 測試, 需求無形中繫結在一起了, 自適應何愁不來.

在迭代開發中, 過程監控的方式手段很多, 比如我們常用的: 晨會, 夕會, 週會, 每日彙報. 專案可的視覺化方式也有很多, 比如常用的任務燃燒圖, BUG趨勢圖, 明細任務顯示圖等.

說到這不得不提下每日彙報的內容. 每日彙報, 就是把當前的工作內容以視覺化的方式呈現出來. 有本書叫"一頁紙專案管理", 裡面介紹的方法就很好, 我又把它本地化了下, 顯示的方式如下圖所示:

圖5(每日彙報明細)

點選檢視大圖

這種方式能讓你控制每一個小的迭代細節中, 能讓你的控制更加周密. 大家可以不防試試.

關於任務任務燃燒圖, 他是從整體專案上對你當前產品的進度做出的評價, 有利於你及時調整專案中的瓶頸問題, 如下圖所示的燃燒圖: 他的做法就是總工時, 已剩餘工時之前的關係來決定的.

圖7(進度控制超前的燃燒圖)

圖8(進度失控的專案)

結合這兩種分析方式, 就可以看出專案中存在風險的專案是什麼了.

五. 整合測試

在這個過程中, 最重要的反饋產品質量的就應該屬BUG趨勢圖了, 可以反應出當前產品的BUG曲線, 來預測產品的質量. 關於BUG管理工具方面, 現在市面上也有很多, 比較有名的像BUGFree之類的, TD也不錯的, 不要收費比較高.

六. 最後就是發版了.

自然要經過評審, 確認本次版本中依然存在的問題, 解決的問題內容.