icech：在博客園看到這篇文章，寫的非常棒！貼在西部E網中，但是不知道該屬于那一欄目，就先放這里吧！
雖然我步入軟件開發行業才半年有余，但是卻有幸參與了一個開發團隊有80多人的大型項目的開發。作為一個初出茅廬者，本該抱著學習的心態，學習項目成功的經驗，可是我卻在挫敗的痛苦不斷地總結，不斷的幻想。通過這半年多的開發體驗，我得出了一個結論：項目中的人的因素是最重要，而作為項目管理者，能夠打造一個讓程序員覺得爽的開發流程，能夠在實際開發當中給予開發人員以具有指導性的建議，才是成功的。
我所期待的開發團隊是這樣的：
1.作為系統分析人員（System Analyst），除了要從商業邏輯上把握，還要能夠從技術上做整體把握。 他們需要對整個系統做詳盡的分析與設計，要考慮模塊之間的關系，也考慮如何構造對象，說到底，就是得有大局觀。把握需求的分析人員，應該參與到實際開發中來，寫UT Case就是他們的任務，這樣他們就沒有辦法逃脫寫Code了，就可以真正讓自己跟開發人員打成一片，而且也能夠把握好需求。除此以外，SA還要負責對技術的整體把握，他需要在不同的實現方式上做出抉擇，而不是放任自流。
2.作為高級開發人員（Advance Programmer），除了要熟悉某個模塊的商業邏輯，還要為Programmer繼續完備UT Case，因為SA所寫的UT Case可能更多是覆蓋Business Logic，而AP而要從系統實現角度上去完善這些Case。同時，他們需要對整個模塊進行設計，關注與其他模塊的接口，同時重要的商業邏輯由他們來做Coding和Test，并且給予Programmer以足夠的支持。
3.作為開發人員（Programmer），除了要嚴格按照業務邏輯的要求去做好Coding之外，還要能夠懂得做好代碼的優化，善于總結良好的Develop Style，并且及時與其他開發人員Share。
我所期待的開發過程是這樣的：
SA做好整體設計，針對業務邏輯寫好UT Case —> AP 繼續完善 UT Case，并實現核心業務邏輯 —> Programmer 根據所有的UT Case進行開發
這樣的流程最大的好處就是目標明確，分工明晰，避免了有人只說話不做事。至少Programmer知道自己要做的就是讓這些UT Case都通過，SA通過寫UT Case去保證業務邏輯的完備性。
聰明的你們或許會發現怎么沒有提到文檔呢？呵呵，在我看來，這些完善的UT Case就是文檔，而且開發團隊需要的是一份能夠充分闡述業務邏輯的文檔，在我們的項目中就是LPS(Logical Processing Specification)。我想只需要這個就足夠了。可惜的是，我們在開發過程中還要寫AMDS(Application Module Design Specification) 和 APCS(Application Program Class Specification)。多么紛繁復雜啊，然后這些文檔和代碼之間的一致性如何保證呢？
我多想奮臂疾呼：給我們一個覺得爽的開發流程！
[前言]：今天是7月30日，離開公司也正好一個星期。而今天也是我呆在深圳的最后一天，再過不到24小時就要踏上北上的征途了。離職之后，在深圳的窩里呆了幾天，對于軟件開發，尤其是項目的管理，有了一些新的想法，遂延續前篇[1]，將項目中的不足之處記于此，以作日后警醒之用。
1、需求不明確；項目進行到現在，也有一年有余了，而進行需求分析和概要設計的時間也有近一年了。雖然我們有很多的文檔，文檔也是洋洋灑灑數千字，上萬字，然而我們對于用戶需求把握的程度還是很糟糕的。最明顯的一點，由于我們所要做的系統第四版了，在此之前的第三版是十年前開發的。那么我們是對原有的系統進行升級呢？還是重新設計一個系統呢？我們的SA一開始都號稱著要做一個全新的系統，然后都去跟客戶做interview，去收集需求，可惜的是能力有限，時間又急迫，使得需求分析的結果還不足以指導進行概要設計。結果在開始做概要設計的時候，業務邏輯不清楚也沒有采取進一步的措施。也不知道是誰提出了由舊系統的源代碼去提煉業務邏輯，接下來公司就組織了很多SA，乃至AP去讀源代碼，然后根據這些源代碼去寫概要設計文檔。說實在的，我覺得很不可思議，大家也許會說，讀舊系統的代碼沒有問題啊。沒錯，以舊系統的代碼作為參考是沒有問題，可是如果是將舊系統的源代碼直接轉換成概要設計文檔，我們前期做的業務需求分析不就一點用處都沒有了嗎？況且這樣做，是不是也正好違背了做一個全新系統的想法呢？在我看來，根據源代碼去提煉需求，并且做概要設計，無異于盲人摸象。缺少了整體考慮的需求分析，恐怕就是頭痛醫頭，腳痛醫腳，而人還是照樣over了；
2、缺少一個完善的training和學習的體系；我覺得這是一個很糟糕的問題。雖然大家會覺得一個小型公司要建立一個完善的training體系幾乎是不可思議的，可是我想說，我們必須需要這樣的一個體系，即使這個體系僅僅是針對現有的項目的。因為會隨著項目的進行，有人會離開，也有新人會進來，如果沒有一個完善的體系的話，人員流動對于項目的影響將是非常的大。而且在促進大家去學習的過程也可以提高大家的學習能力，也能夠篩選出人才來；
3、缺少激勵機制；在項目當中，公司會有很多的懲罰措施，譬如會有一個所謂的紅黑榜，然后只有人受罰，卻沒有人得到獎勵。我曾多次表示反對這樣的方式，因為我覺得人性總是本善的，應該通過激勵的方式去促動大家努力工作。因此，我會想，如果有一個Expert排行榜，會不會更好呢？上榜人員是通過全體程序員投票選舉出來的，公司將會對他們給予獎勵。給予Expert稱號的最大好處就是樹立了在開發過程中的權威與榜樣。如果有問題，可以找相應的expert解決，正所謂，聞道有先后，術業有專攻，他們既然是專家，就會對在解決相應問題的效率上和結果上都會有過人之處；同時也可以激勵其他員工向他們學習，起到了模范作用；
4、SA與代碼脫離，與技術脫離；這是我最百思不得其解的問題。SA是什么的縮寫呢？是System Analyist。那什么是系統？我沒有辦法給出準確的定義，但是我想一個系統必須是為實現某個既定任務而存在的，業務需求就是“任務”，確實是最重要的。那么，如何“實現”是不是也很重要呢？沒有了可行的實現手段，所有的“美麗任務”都變成了Mission Impossible了。我覺得兩者都是具有相同的分量的，SA要關注需求，更要關注實現。然而我們的SA更多時候是充當著行業專家的角色，可是他們并不是行業專家。結果這個角色耗費著項目的大部分資源，卻鮮有貢獻。既做不了設計，又做不了coding，到了我將要離開的時候，他們充其量只是一個工頭了，問程序員，“什么時候能夠做完啊？”，“我只要結果”。這多么的可笑啊！SA是可以不直接參加做coding ，但是他們不能夠對技術幾乎一無所知，否則，他們如何做分析呢？System的組成不僅僅是業務邏輯，而且業務需求最后也轉化為一行行的代碼，一個個能夠運行的模塊啊。為什么就只有SA給大家培訓業務邏輯，卻沒有人為SA培訓技術呢？可笑！
5、缺乏誠信，缺乏敢于承擔責任的勇氣；在項目當中，從程序員到SA，都有一部分人員缺乏誠信。尤其是SA。我曾經聽到三位subteam的老大關于保證業務邏輯的對話：
A問B：“你怎么保證業務邏輯都已經OK了呢？”
B馬上說：“review代碼咯。”回答得一點遲疑都沒有。
C聽了，接著說：“你真的一個一個class去看，一行行代碼去看？”B也表示了懷疑：“你知道一個模塊里面有多少的class，多少的代碼嗎？你怎么可能看得完呢？”
A顯出一副無可奈何的神情點了點頭：“沒有辦法啊，為了保證邏輯只好這么辦啦。”
哇，我聽了都快吐出來了。先不說保證業務邏輯根本就不是通過review代碼可以實現的，光說A的誠信就TMD的有問題。他作為SA，首先不可能有那么多的時間將我們所有的代碼進行review，而且，我也能保證他從來都沒有看過，因為他根本就沒有辦法對我們系統的整個架構說出個所以然來。還記得《程序員修煉之道》上的第一條：Take responsibility。與之相應的那一節的前面還有這樣的一句名言：
The greatest of all weaknesses is the fear of appearing weak.
作為程序員，作為SA，乃至每一個做IT的人，都應該懂得承擔責任，為自己的每一行代碼，每一句話。我想這是做程序員的最基本要求吧。
[后記]：今天是8月1日，隨筆終于都寫完了。一部分是30日寫的，而大部分則是在北上的大巴上寫的。離開了，放棄了，然后徘徊了，痛心了，最后驚醒了。到了一個新的地方，期待著新的開始。寫得不當之處，還請各位多多批評。
|
