亂亂寫 Blog

這是 Bentham 的文章

不知道日後還會不會留著就索性先轉貼在自已的 blog 上嚕！

裡面有很多觀念是很不錯的，大家可以自已去思考怎麼去面對自已待的團隊 和 自已做事的方式

只要把想法轉化成行動，再由行動轉成習慣。

最後自然而然地就會是團隊的文化

不需要為了 CMMI 而 CMMI ，即使是 CMMI 也可以很 Agile

 

------------------------------------------------------------

背景介紹
Sara Ford 從學校畢業以後就馬上加入Microsoft，在Visual Studio團隊工作了六年，目前在CodePlex團隊擔任Program Manager(程式經理)的工作，她在這篇部落格文章裡描述了怎麼從每三年一個循環到三個星期一個循環的適應過程，對想開始從傳統瀑布(Waterfall)開發模式轉到敏捷(Agile)開發的團隊而言，這份經驗很值得大家借鏡，我想當個中間人引導大家來讀這篇文章。
三加一個教訓
Sara用時光如果可以倒流的方式來點出三個Agile的重點
1.Design and plan for the very next step, instead of designing and planning for the very next feature.
我想把它譯成：＂要就馬上做，不要想著下次再改＂
有很多時候花很長時間想設計，寫了長達６０頁的規格書，結果到後來寫出來的程式不見得跟規格書一樣，倒不如不想太多以後，只想接下來三個星期可以完成的工作，專心的把事情做好，這樣就比較不會落入＂等太久＂或＂想太多＂的麻煩，每次專案都是到後來才趕工累得要死，而且很多時候都是程式開始寫的時候問題才會出來。

2.Break down work into smallest possible sets. Adding work is fun and rewarding; removing works is panful and risky
不以善小而不為；把小磚塊建好了才有辦法蓋高樓。
把工作細分，不要覺得事情小就不以為然，這是Agile的重點之一，Sara本來覺得只把三個星期完成的事情送出去外面給使用者會被嘲笑，殊不知把一項完成的工作堆出去，要比三項半成品推出bug一堆好得多，所以Agile是著重在可以合理掌控的工作量。
3.Design and plan 80% of the way as the very next step. Use feedback to solve the remaining 20% in the very next step after that.
每次解決80%的問題，剩下20%接著解決，所以不想完美主義，事情才可以一步步完成。
很多問題是沒辦法一次解決的，在解題的過程中你會得到一些重要的資訊，接著要解決就比較容易，有些問題甚至會自行消失，變成不是問題。

4. Forget everything you’ve been told about what makes a Program Manager successful at Microsoft. Thinking about this will only drive you insane and make you completely miserable on a real agile team.
第四點是她在Microsoft的心得，原本在大案子裡做的經驗要全部忘掉，這樣才能完全融入Agile的開發環境中。

隱藏的資訊
我覺得Sara的成功經驗有幾個重點，大家不注意可能看不見：
1.專案特性
由於CodePlex是一個推動OpenSource的網站，所以五星期一次的更新週期沒有問題，如果像一般軟體需要測試安裝或切光碟的話就不太容易。
2.老闆支持
Sara的老闆 Jim Newkirk 出過一本 Test-Driven Development in Microsoft.NET 的書，所以老闆本身是相信Agile的。Sara剛到組裡的時候問＂密碼最長幾個字元？＂結果每個人都告訴她＂去看測試程式是怎麼寫的就知道了！＂實際的建置取代了文件，這是Agile的重點。
3.Developer主導的Agile
Sara說，有人問她是怎麼說服這個團隊用Agile的？她回答是＂剛好相反，是她被說服的，本來這個小組的Developer就是Agile了＂，讓寫程式的人主導要怎麼做，讓可以直接影響軟體品質的人主動要求，這樣做出來的東西要不好也難。
4.你願意放棄你所熟知的方式嗎？
我想這是執行Agile的最大阻礙，管理程式設計師的專案經理一但失去所謂的＂控制＂，要讓大家去＂亂搞＂，那就沒有章法了。Sara用了很多心思去放棄原先的思維方式，最後發現Agile的開發方式對這個團隊而言是比較合理的。
 

後記
各位可以注意一下５星期為一周期的規劃圖，兩週寫程式，一週穩固，再來讓測試小組接手做一週的完整測試，然後第五週放上機房。
另外他們的辦公室配置也值得一提，所有的人全部在開放空間裡(來上班的時間就工作，工作完早點回家，不要在公司做家裡的事，在家裡想公司的事，Very Agile!)，寫程式的人兩個人一組坐在Y型的桌子(Pair programming)，測試小組在左方一排，Developer可以直接跟Tester討論測試結果，PM去面壁別吵到大家(No Manager is Good Management)。　:)
白板上用來控制專案進度的貼紙，很有效，誰什麼時候做什麼事情一清二楚！
在Microsoft總部這裡Agile己經引發一股熱潮，有越來越多的成功案例，不過都是局限在小一點的專案，目前聽說最大的團隊是Office裡的OneNote，而且不只Microsoft，NASA也有成功案例，以台灣大多數是小規模軟體公司來看，這確實是值得注意的發展趨勢。