People-oriented in Agile

面向人的敏捷開發，恩，這就是我今天想要表達的主題。之所以想表達這個主題，主要還是因為我在項目中的職能：項目經理——在管理一個團隊與溝通的過程中，關于這一點觸動最深。

下面就以這一點為核心談談我的一些想法吧。

One Leader

The Cathedral and the Bazaar： “given enough eyeballs, all bugs are shallow”

這句話是The Cathedral and the Bazaar的主旨，按我理解來說它的意思是：只要搏人眼球，瑕疵無所遁形。

在大教堂的模型中，是由一個完整的開發團隊來開發一個項目。而在集市的模式中，一個完整的項目是借助于互聯網的東風由網上的各位愛好者貢獻而產出的。粗略來看，集市模式看起來更好，因為它能減少大量的個人開發時間。瑕疵之所以無所遁形，是因為群眾的眼睛是雪亮。同時，開源的代碼讓不同的思想在同一個項目中產生了碰撞，可能會產生非常奇妙的靈感。

但是我個人是談不上贊同或不贊同哪種模式的。大教堂模型更像是當前主流公司所采用的模式，有一個完整的開發團隊來開發某個軟件或模塊。在看過另外一篇文章Lost in CatB后，我覺得一味爭論開源化還是商業化的問題本身是沒有任何意義的，一味地肯定或否定某種模式只是片面之說，一種模式的存在即是其合理的表征。我更加贊同的一種觀點是：不管是開源還是商業化，都必須要有一個人對整個項目負責。不是兩個人，不是三個人，而是一個人。

這一點上讓我感受頗深是因為另外一支隊伍。這支隊伍是我們團隊初期預想的最有競爭力的一支隊伍——最根本的原因是他們隊伍里我欣賞的人很多。這就意味著團隊里的每個人都有著獨當一面的能力，獨自解決問題的思路與別樹一幟的想法。

但是他們的開發過程中出了一些毛病，我也能明顯感受到：

• 名義上的項目經理參與不到真正的項目開發中來
• 實際上的項目經理沒有完全發揮項目經理的職能，沒有一個整體的規劃和組織

我了解他們組的同學，也知道他們的設計師和文檔撰寫人員的厲害。他們的文檔有些時候我真的是自愧弗如，而他們的設計師本身也是工程經驗非常豐富，也非常有責任感。

但是，他們組缺少一個靈魂核心：項目經理。一個項目缺少好的項目經理等于缺少潤滑劑。如果沒有對一個項目負責的項目經理，項目雖然可能在磕磕絆絆中會前進一些，但是發展到后期就會彰顯出它的不協調。

設計上的事情可能框架的設計師可以全權負責。但是要把這些理想的圖紙付諸實踐，到每一個人身上的時候，就需要項目經理來安排進度。

Prepare

Do less, start earlier。 
Once we have the design, we can plan the construction。

看到這句話，突然感慨萬千。聯想到了我們項目初期時我做出的選擇，現在看來那時的拼命確實是有必要的。

當時還是團隊項目的第一周，本來是需要在第一周只需要項目經理做NABC需求分析的。但是深諳設計的重要性的我沒有滿足于現狀。從第一周開始我就和設計師商量框架、實現方案、設計思路以及可行性。并且在第一周就已經制定出了可行的，學習成本較低，并且可以讓大部分人都參與進來的技術方案。

不止這些，我還和UI設計師鹵蛋一起商量網頁原型設計，尋找好用的設計工具。其他人也沒閑著：主程序員在尋找各個實驗的標準原始數據錄入表，而兩外兩位開發人員則在尋找標準的預習報告模版以減輕后面的工作量。

雖然第一周的工作在后來被驗證依舊是沒做到非常細致與縝密，但是第一周我們的規格說明書的雛形初成有著重大的意義。它不僅是團隊風貌的展示，更是后面我們前端后端對接順利的保障。界面原型設計是前端與后端工程師無形的接口，它在項目開始前就已經得到多次修繕，這使得前端和后端第一次對接非常成功。

Start earlier，上帝不會虧待任何一個早準備的孩子。

Good ideas from users

The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

提到這一點我就不得不提到敏捷開發。敏捷開發中的迭代周期短，是因為在短周期的迭代后可以獲得最新的用戶反饋并及時更新需求以獲得更好的軟件滿意度和質量，這也是敏捷開發的特點之一：Responding to change over following a plan。

因此，我們團隊設計了一些激勵措施例如發紅包等來激勵用戶向我們反饋他們最真實的需求。并且由于我們產品本身定位方向切實戳中了學生通點，有很多熱心的學弟學妹會主動在群里反饋一些可行的建議，這樣動態調整需求，讓我本身對第二輪迭代要做的功能進行了大幅度的修改，更加符合用戶的需求。最好的建議往往來自想使用的人。

People-oriented

Agile methods are people-oriented rather than process-oriented. 
Furthermore his studies of software projects have led him to conclude the people are the most important factor in software development.

敏捷開發是面向人而不是面向過程的，是要以人為本的。這一點上我的感觸最深。我在團隊項目中充分地感受到了我自己身為項目經理的膠水作用。我就像個跟屁蟲，每天都跟在每一位我還不放心的開發人員后面一直追問他的進度，發展情況，是否遇到了解決不了的困難，是否希望可以調換任務，是哪里出現了問題等。即使有每日scrum meeting，我也會每日如此追蹤，一直到督促他們完成當天的任務或者跟他們一起解決當天的任務為止。

而每個人在項目中發揮的作用都非常重要。

人和程序不一樣，程序接收固定的輸入，執行固定的步驟，給出可行范圍內的解。但是人，只要是愿意參與溝通的，他們身上都會有無限可能。

Performance

但是典型的軟件項目往往是沒有規律及可預測環境的。項目成功的唯一正確度量就是：最終的結果通過整個生命周期里的實施達到了預期目標嗎？ 很難知道什么關鍵活動導致了項目成功和失敗，很少有人能夠通過舊有或現有的項目獲得答案。幾乎不可能判定哪些決策導致了成功或失敗。

在這一點上我感觸比較深的是，在團隊最后績效分配上我做出的選擇。我最終還是沒有選擇嚴格按照當初定好的團隊貢獻分配策略來嚴格給分。一方面確實有很多地方是我的失誤:

•   時間估計錯誤
•   任務量估計不足
•   中間形式規定含糊

這些都是我的失誤，而且因為這些失誤導致我和隊員都付出了巨大的時間，卻收獲較小，有很多是可以使用非常簡單的技巧就可以完成的，最終卻繞了遠路。我沒法因為我安排任務不合理而使得任務最后完成效果較差而把他們的真正貢獻打折。另一方面就是隊員本身能力的確有限，雖然我已經設身處地地在分配任務時按照不同能力分配門檻不同的任務，但是也有很多時候效果依然不盡人如意。

No silver bullet , But people management

我認同在軟件的開發中沒有任何一項技術可使軟件工程的生產力在十年內提高十倍的說法，但是我認為在軟件開發的過程中，為了提高生產力，更需要的可能不是從軟件開發的方法下手，而是要從團隊的人力管理上下手。好的項目經理應當懂得如何為合適的人分配合適的任務。不論是瀑布模型，敏捷開發模型，模型本身都不應該是一個軟件開發的關注重點——人才是軟件開發的關注重點，模型只是建議，可人才是決定性因素。

一個團隊是否能協調有力地前進，不在于他們采用了哪種模型，使用了什么工具，懂得了什么不一樣的方法，而在于團隊內的好程序員和他們的項目經理。

Summary

自我當項目經理以來，初期時每日兢兢業業，生怕哪天自己沒有安排好后兩天的進度計劃而使整個項目被迫停止下來。雖然途中也遭遇了許多挫折，遇到了很多的意外情況，比如有時因為中間形式不規范（數據處理部分）而導致對接困難，大部分時候我遇到這種情況都得把雙方的代碼閱讀一遍，然后修改代碼格式才能對上。心里的疲憊與苦澀，導致有一天上午我真的有感受到身體負擔過大而心絞痛。

每天都有人勸我早些休息，不要那么拼命，但是為了團隊能協調前進，有些時候我不得不費非常大的力氣去做一些很瑣碎的事，很麻煩的事，很吃力不討好的事。

但是這些都是值得的吧，至少在我看來，這些獨有的經驗與心路歷程，都將是我一生的財富。