1. 程式人生 > >讀構建之法 第五章:團隊和流程

讀構建之法 第五章:團隊和流程

min 這樣的 程序員 希望 成員 eat 貢獻 核心 不能

團隊有一致的集體目標,團隊要一起完成這目標。一個團隊的成員不一定要同時工作,例如接力賽跑。

團隊成員有各自的分工,互相依賴合作,共同完成任務。

軟件團隊有各種形式,適用於不同的人員和需求。基於直覺形成的團隊模式未必是最合適的。軟件團隊的模式,最初是混沌的一窩蜂形式:一群人開始寫代碼,希望能寫出好軟件。隨著團隊的成熟和環境的變化。

團隊模式會演變成下面幾種模式之一。

1.主治醫師模式:有首席程序員,他/她負責處理主要模塊的設計和編碼,其他成員從各種角度支持他/她的工作(後備程序員、系統管理員、工具開發、編程語言專家、業務專家)。

2.明星模式:讓團隊的利益達到最大化

3.社區模式:每個人參與自己感興趣的項目,貢獻力量,

4.業余劇團模式:這樣的團隊在每一個項目中,不同的人會挑選不同的角色。但都聽從一個指揮的指導和安排。

5.秘密團隊: 團隊內部有極大的自由,沒有外界的幹擾,不用每周給別人介紹項目進展,聽領導的最新指示,團隊成員有極大的投入。

6.特工團隊:軟件行業的一些團隊由一些有特殊技能的專業人士組成,負責解決一些棘手而有緊迫性的問題。

7.交響樂團模式:家夥多,門類齊全。 各司其職,各自有專門場地,做項目期間沒有聊天、走動等現象,同時看指揮的,重在執行。

8.爵士樂模式:和上面的“交響樂團模式”在很多方面都對立,但不能簡單地說孰優孰劣。

9.功能團隊模式:具備不同能力的同事們平等協作,共同完成一個功能。

10.官僚模式:脫胎於大機構的組織架構,幾個人報告給一個小頭目,幾個小頭目報告給中頭目,依次而上。跨組織的合作變得比較困難,因為各自頭頂上都有不同的老板。

瀑布模型:這個模型描述了單向的、不可逆的生產過程。

軟件團隊進入了一個不斷演進的evolution循環中:[開發→發布→聽取反饋→根據反饋做改進]

這個軟件什麽時候才最後完成呢?

1.時間到了。

2.錢花光了。

3.用戶滿意了。

我們能否讓用戶更早地給產品團隊反饋?

MVP方法:Minimal Viable Product,最小可行產品,又稱為Minimal Feature Set,最小功能集。

具體的做法是:把產品最核心的功能用最小的成本實現出來(或者描繪出來),然後快速征求用戶意見。

我覺得團隊模式需要成員之間相互協作,成員間不一定要同時工作,但是是互相依賴著完成的,共同完成任務。我們做項目給用戶使用,當用戶看到第一個版本的時候,他們就對這個產品很不滿意,完全沒有任何購買或使用的意願。在這種情況下,整個團隊為第一版所做的各種投入都浪費了,是因為產品團隊得到用戶的反饋太晚了。所以我們就要用到MVP方法,用最小的成本實現最核心的功能,是我們所追求和向往的。

讀構建之法 第五章:團隊和流程