2019-09-09
前兩年就開始做乙個專案體量分級，這個基礎的概念，不說清楚，總感覺不好。現在筆記總結的差不多了，整理發布部落格吧。這裡只談交付產品為軟體，或者軟硬體一體的專案型別。對於當下的軟硬體一體的專案，大多重點在軟體上，在演算法上，結合在一起，可能雖然名義上軟體不單獨售賣，也不收費，但是，可以說，軟體仍是其核心所在。我們軟硬體開發者，經常會對乙個專案的大小進行評價，但是，缺乏乙個統一的標準。甲說的乙個大專案，在乙看來只是中型專案，那麼，交談起來，可能就有偏差了。
我結合自己的專案經驗，製作了乙個分級**。我為什麼要提出這個**？很簡單，減少溝通的障礙。**不準確也沒有關係，我們都不準確，但是，我們是在談論同乙個東西。隨著討論多了，不斷修改，總能達成一致。不準確是可以慢慢修正的。溝通上不準確，可是有大問題的。這裡只針對新立項的專案為討論物件，對於那種已經有1.0版本，但是需求有變，想要2.0版本的專案，並不是我們的討論物件。因為，對於已經作過的專案，需求分析、**架構、技術難點、文件等工作，大部分都是作過的。順便討論一下文件、流程等。**a、b、c，分別對應大中小，每個級別 三個檔次：如a1，a2、a3。不用分的過細。
class
sub class
human month
worker num limit
description
a（大型）
a1196 ~ 256
500w，大概率一年以上，2年內。 18 ~ 24
a2108 ~ 196
400w 12 ~ 18
a372 ~ 108
300w 10 ~ 15
b（中型）
b148 ~ 72
200w，7 ~12 個月。
b224 ~ 48
120w 5 ~ 9月
b312 ~ 24
70w 3 ~ 6月
c（小型）
c18 ~12
50w
c24~8
30wc3
1~420w
更高階的s、ss級別專案，如**、京東、支付寶，天知道到底投入了多少人月、多少資金。因為很少人遇到，樣本也很少，暫時不討論了。
對於專案級別的衡量因素，分為兩個方面：持續時長（人月），涉及到的人數。 有些專案比較 任務拆分 比較 分散，環節過，且難以不同環節的技術差異度偏高，但是，需要的人月卻不多。涉及到的人多了，就表明協作上的複雜度高。就意味著環節a的人難以理解環節c、d的人負責的內容，在做系統設計上，就有更大的概率出現疏漏、偏差。故參與的人數上限 非常重要。另外一方面，總「人月」較高，並不代表工程大，可能只是做的慢。或許其他團隊去做，一半的人月都是 可能的。所以，「人月」是乙個波動範圍的較大因素，我們想要這個因素穩定，經理需要穩定的人月規劃，老總更需要，那麼，我們就需要讓團隊穩定。負責人應該竭力組建穩定而強大的團隊。
一、小型專案
一家小公司內，三五個人，花費三五個月能完成的專案，只能算小型專案。更小的，就是個人發起的，三五個朋友一起做的，甚至可能在業餘時間做。這樣小的專案，絕大多數只會產生一兩個程式。即使寫需求規格說明書、系統設計、概要設計、詳細設計等文件，都可能沒有中型專案乙個文件內容多。三五個人，大家都是熟人，啥都敢說，都敢責問，要的就是迅速迭代，盲目要求文件反而是累贅。
因為開發者太少，甚至連敏捷、xp等流程都走不起來，大家早晚開一次會，同步一下進度就行了。小型專案，最多派乙個人來做測試。因為可能專案不重要，測的不仔細也行。出bug了再改。或者個人專案，自己兼職ui、測試、運維。怎麼說呢，這些工作本來就是程式設計師該幹的，只是當下分工更細緻了。
專案越小，死掉的概率越大。個人專案，大概率會死掉。這便是不需要文件的乙個次要原因--沒用。但是，總會有成功的。成功後再改版，卻發現很多東西都忘了，這就糟糕了。所以，開發中間產生的各種文件、設計稿、筆記等，都盡量儲存下來。c級別不需要 嚴格遵守統一過程、或者文件需求，只需要注重 需求、概要等文件保持更新即可。大概率業務很簡單，連用例圖、流程圖、活**都不需要。稍微寫一下文件，也是為了幫助梳理業務，幫助思考。
二、中型專案
我們分析的重點，也是中型專案。不像三十年前，那時候編譯理論才剛剛完善、oop出現不久，aop僅僅是學術問題，也沒有網際網路，也不知道持續迭代、持續交付。年紀小的朋友可能不知道九十年出c++編譯器要賣三千美刀，linux還是個玩具，gnu還沒有核心。可想而知彼時的工具鏈與生態環境。2023年出現的」軟體工程「術語，彼時只有20年歷史，乙個學科在20年與50年之間會發生什麼呢？所以，軟工教材上的東西，看起來與多數人多數專案的情形並不一致。這十餘年，也是scrum、xp等方**發展流行的階段。但，沒有人能說，自己的做法是標準的，是最高效率的。各種變體、各種修改，被團隊採用。我們可以觀察到，採用這些方**的專案，多是市場變化較快的，to c端的網際網路專案。to b端專案，即使專案偏小，也會採用傳統的rational unified process (rup)，或者準確來說，是aup。簡單總結：既要快，也要穩定，需要文件。可能b3專案只注意概要設計，不注意詳細設計。而b1專案，會細緻到每乙份文件。
要明白，文件是用來幹什麼的？1，規範化的文件減少了交流障礙；2、為了防止撕逼。參與者多了，隊員之間可能都不是那麼熟悉，遇到**或者設計上的問題，腦子就會盤算，是不是自己的問題，咱也不敢說，咱也不敢問。這是人之常情。這也是為什麼團隊要經過磨合才能有效工作。也是團隊為什麼要保持穩定的原因。軟體工程實踐告訴我們，溝通成本隨著人數增長超線性增長。而標準文件化，能幫助我們在口頭溝通與文件溝通之間達到最佳效率。大白話就是：以最省錢的方式把活兒幹好幹完。
總的來說，b 級別，必需要保證 需求、概要、詳細 等文件，有餘力者，保證 各種uml繪圖、測試用例文件。至於各種文件相關的問題，我會在接下來的總結blog中分析。
對於軟體開發者，我們做的大概率是b級別專案，畢竟，中小公司多是社會的常態，普通技術水平也是社會常態。帕累託法則應該還是有效的。對於軟體開發者而言，要爭取多寫文件，即使領導說沒時間。這樣，既能防止了撕逼，保護自己，也能實打實的加快進度。
對於專案技術負責人、產品經理，其職責就是就好需求分析、概要設計；對於技術負責人、小組長，其職責就是做好詳細設計。不能把自己應該做好的事情丟給下層的人。佔了title，就因該幹好分內之事。而現狀就是，不少技術管理崗的人，把職責下放。出了設計上的問題呢，就大家一起扛，實在不利於專案。
三、大型專案
我還沒有見過仍採用傳統統一過程的專案。我曾參與三個大型專案。畢業時的網際網路公司主業務專案，註冊使用者剛突破千萬。但是是網際網路專案，持續運營了多年，對於這種持續迭代型的專案，我也不確定對其分類是否合理。第二份工作的遊戲本來是b1級專案，硬生生的被老闆變成了a級專案。14年的末，開始做的虛擬試衣專案，算作a1級專案。所以，我主要的分析經驗，**於此專案。
a級別，必需保證統一過程中所有文件。中大型專案，大概率會有後續版本更新，而且，由於專案持續時間很久，團隊人員變更會更為頻繁。我不希望每個新來的人，都來問我。我希望，文件就能教會他80%的專案知識。
雖然人數多，但是，專案常駐 人員可能較少。可能對於一些人，只需要投入幾個月的時間。例如a1最多32人，可能持續開發者只有20人。由於專案很大，每個人的個人技能有限，難免產生盲人摸象的現象。所以，我們以前的實踐裡，會就大專案裡涉及到的各種技術做分享會，爭取讓所有人，對於整個產品都有直觀的認識。可以不了解原理，但是，一定要了解目標。
我們都知道，隨著專案的持續運營，新的需求會持續的加入進來，特別是一些早期並沒有被考慮的需求，若不更改架構設計，將導致採取一些特殊設計的方案來解決。隨著」特例「的增加，系統將變得難以維護。直到有一天，有人受不了了，要重構。如果在專案開發周期內就出現了重構，大家就要注意了，就是負責做設計的人，沒有幹好分內工作。
對於中型專案，人月評估大概是準確的。而對於大型專案，人月預估會變得不準確起來，因為專案複雜度的增長不是線性的。沒有找好專業的負責人，就貿然評估並開幹，時間加倍也很常見。
comments
對軟體專案中產生的需求進行分級管理
客戶的需求是否應該得到滿足？軟體工程是否目的就是滿足客戶的需求？這個問題看來是無法加以回答的，因為，它沒有提供兩個基本的解釋，其一 客戶 的需求即算從客戶的利益立場出發，是不是合理的？其次，客戶的需求有多大程度上是必要的？還是只是一種個人的喜好？如果說對於商業客戶來說，在專案開始前，還存在著做與不做...
理論 長尾理論代表的專案過程
理論介紹 長尾 英語 the long tail 或譯長尾效應，最初由 連線 的總編輯克里斯 安德森 chris anderson 於2004年發表於自家的雜誌中 1 用來描述諸如亞馬遜公司 netflix和real.com rhapsody之類的 的 商業和經濟模式。是指那些原來不受到重視的銷量小...
目標 我的軟體工程實踐專案
1 這次的軟體工程實踐專案是要我們開發移動應用的軟體，而我本人對於android較感興趣，所以對到最後能學習到的能力的預期當然是 有能力獨自開發能穩定執行功能簡單的應用，比如教務處查成績軟體等 懂得如何團隊協作，想要開發功能穩定，強大的軟體，單幹肯定不行，所以要積累團隊協作的經驗 2 而對課程的期望...