靈活開發其實也是企業的一種管理文化。
目前軟體行業靈活開發管理最大的問題在于太看重具體的形式，而忽略了靈活的初衷。
很多公司請幾個靈活教練建立流程，把會議室的椅子都搬走宣布從今以後大家站着開會了，使用靈活管理工具建立疊代、建需求、分任務，可是這真的就意味着靈活了嗎？
因為靈活，老闆要求這個功能明天上線，怎麼實作我不管，畢竟響應變化高于遵循計劃。
因為靈活，我們希望每天至少釋出一個版本，沒辦法，靈活要求我們快速地傳遞可工作的軟體。
因為靈活，雖然需求我們還沒想好，但是這個版本要保證本周内上線，靈活宣言說得好，要欣然面對需求變化。
因為靈活，我們項目一篇文檔也沒有，畢竟工作的軟體高于詳盡的文檔。
。。。。
我們不禁要問，這真的是靈活嗎？靈活的初衷是團隊成員能夠更加緊密地配合完成工作，靈活開發強調擁抱變化，但并不意味着可以随心所欲地變更需求。靈活開發的實質是通過疊代式增量軟體開發的方式，防止出現長期閉門造車嚴重偏離客戶需求，達到快速響應市場變化的目的。
下面我想分享下我們公司在近百人的開發團隊，同時進行十幾個項目開發的過程中，是如何使用
CORNERSTONE管理平台進行靈活項目管理的。
一、角色劃分
傑夫·薩瑟蘭将SCRUM團隊中的角色分為三種：
- 開發團隊成員，負責開展具體的開發工作；
- Scrum主管，協助開發團隊把事情做得更好；
- 産品負責人，決定應該做什麼工作，拟定待辦事項清單的内容。
我們根據我們開發中的實際情況将系統中的角色分為以下四種：
- 項目經理：相當于Scrum主管，負責協調團隊内部合作，召集站立會議，把控項目整體進度。需要明确的是，項目經理并不是一個傳統意義上的團隊上司。用更流行的話說，項目經理更像是一個仆人式上司。項目經理不應該對團隊成員大吼小叫，也不會告訴研發人員該做什麼以及如何開發一款産品，而是應該集中精力幫助研發人員清除前進道路上的障礙。
- 産品經理：相當于産品負責人，負責決定應該做什麼工作，拟定待辦事項清單的内容，确定各個事項的優先順序。事實上，和很多人了解的不同是，确定各個事項的優先級幾乎是靈活中最重要的工作。為什麼？在軟體開發領域有一條根據數十年研究工作總結出來的原則，即在任何一款軟體中，80%的價值來自20%的功能。人們總喜歡說每個需求都是重要的，但産品經理需要問一下自己，究竟哪些需求能夠給整個項目帶來最大的價值？而這些能夠帶來最大價值的需求就必須優先完成。
- 開發人員：開發人員是項目開發任務具體的實施者。他們負責完成開發任務，及時回報開發進度。
- 測試人員：測試人員是項目測試任務具體的實施者。他們負責制定測試計劃，編寫測試用例，建立以及回歸缺陷。
在
中，我們可根據項目成員的具體職能設定不同的角色和權限。
二、收集需求（使用者故事）
在項目開始前，産品經理應該基于使用者或市場的需求，來編寫使用者故事，即
中的需求。一個好的需求（使用者故事）一般應該滿足INVEST标準：
（一） 獨立性（Independent）——盡可能地使一個需求獨立于其他的需求。需求之間的依賴使得制訂計劃、确定優先級和工作量評估都變得很困難，通常我們可以通過組合需求和分解需求來減少依賴性。
（二）可協商性（Negotiable）——需求的内容要是可以協商的，需求不是合同。
（三）有價值（Valuable）——每個需求必須對客戶具有價值。
（四）可評估（Estimable）——開發團隊需要衡量需求，以便确定優先級和工作量，并便于安排工作計劃。
（五）規模小（Small）——一個好的需求要盡量維持小規模，至少要確定在一個疊代周期中能夠完成。需求越大，在安排計劃、工作量評估等方面的風險就會越大。
（六）可測試（Testable）——一個需求要可以測試，以便确定它是可以完成的。如果一個需求不能夠測試，那麼你就無法知道它什麼時候可以完成。
基于以上原則，CORNERSTONE支援在建立需求時，關聯其他需求（這樣我們便可以做到組合需求來控制單個需求的粒度！），關聯測試用例（确認需求是可以被測試的！），關聯疊代（確定需求可以在一個疊代中完成！），設定優先級以及開始截止時間。
三、沖刺規劃會議（Sprint Planning Meeting）
在每個疊代開發正式開始前，我們都會舉行一次規劃會議，由産品負責人講解需求，由所有團隊成員一起負責将需求拆解細化成具體的開發任務。開發任務的顆粒度最好足夠細，以確定一名開發人員在一個疊代周期内可以開發完成。
一次沖刺規劃會議中的産物一般為：
（一）具體配置設定到每個開發人員的任務清單；
（二）會議紀要，
提供了WIKI功能，可以在系統中儲存每次會議的會議紀要；
四、每日站會
在疊代開始後，我們團隊一般每天上午固定15分鐘左右進行内部溝通。我們一般會打開
任務的看闆視圖：
每個團隊成員隻需要用三到五句話說明以下三個問題：
- 我昨天做了什麼來完成我的任務；
- 我今天打算做什麼來完成我的任務；
- 有沒有什麼可能的阻礙因素會導緻我不能按時完成任務。
一般來說，項目負責人需要聚焦于幫助團隊成員解決阻礙因素，以幫助所有任務按時完成。
五、随時關注團隊進度
在疊代的開發過程中，項目經理需要随時關注項目的開發進度。我們的項目經理一般通過
提供的項目儀表闆來檢視項目的整體完成情況；通過燃盡圖了解任務的完成情況；通過缺陷分布、缺陷累計來了解疊代完成的品質。
系統自帶的甘特圖能随時檢視疊代的具體程序以及每個項目成員的任務分工情況，做到配置設定合理。
除了以上統計外，還有一個“報表”功能屬于管理者專用，報表功能包含疊代燃盡圖、代碼送出統計、狀态分布統計、每日新增曲線，每日完成曲線、累計數量曲線以及成員工時清單等統計資訊。
六、評估總結
在每一次疊代束之前，我們的研發團隊成員還要聚在一起開個評估會，向産品負責人示範在這個階段之内取得的成果，接受評估意見。研發團隊成員會評估一下清單上的工作任務已經完成了多少，自己是在這個階段的沖刺中認領了太多任務以至于沒有做完，還是工作任務認領得太少了。
同樣提供了彙總視圖，用以在這類會議上展示說明。
最後總結一下，靈活其實是一種管理方式，靈活不會告訴我們具體每個項目應該怎麼做，傑夫·薩瑟蘭有句話說得好，不要猜測，要規劃、執行、檢查、行動。我認為這句話道出了靈活的本質。