[閱讀]我的閱讀做業week7

 

People-oriented in Agile

 

• People-oriented in Agile
  • One Leader
  • Prepare
  • Good ideas from users
  • People-oriented
  • Performance
  • No silver bullet , But people management
  • Summary

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

下面就以這一點爲核心談談個人一些想法吧。

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

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

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

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