- 精益軟件度量——實踐者的觀察與思考
- 張松
- 5341字
- 2019-01-01 23:46:37
3.3.1 項目定義
經過前面的業務策略階段，管理層應該做出判斷，確定這個項目在可見的一系列機會里是一個高價值的目標，并初步論證了可行性。這時候需要根據前面階段獲得的信息，識別和澄清這個項目要解決的業務問題，定義交付目標，配置所需資源，并在制定在交付過程中期望組織的提升目標。
1．問題定義
做正確的事情，第一步是要識別出正確的問題。阿爾伯特·愛因斯坦曾經說過，“如果我只有一個小時的時間去拯救世界，我會用59分鐘來定義問題，用1分鐘尋找解決方案。”清晰地定義問題是設定目標、制定計劃的前提。我們經常會低估了問題本身的定義對后續方案產生的影響，實際上，僅僅是描述的不同都會對解決方案的方向產生重大的影響。
一個項目的立項通常是為了解決一個或一組業務問題，目的可以是使產品覆蓋更大市場和更多用戶，或是滿足某類客戶新的業務需求，為現有用戶提供更多價值，也有可能是為了贏得一個重要客戶的招投標，完成一次對市場的試探，還有可能是滿足某個政府或是行業的合規要求。
Big Bank在這個項目中要解決的問題如下。
?很多個人和家庭擁有相當數量的閑置資金，正以低于通貨膨脹率的銀行利率在銀行里貶值，他們缺乏相對穩健的投資渠道獲取高于銀行定期存款利息的收益。
?很多個人和小企業主在缺乏短期資金的時候，難以通過一般正規金融機構以舍理利率獲取貸款。
?作為中介機構，Big Bank如何高效地撮舍上述兩類客戶的需求，形成交易并從中獲利？
?Big Bank如何通過這個新業務跟已有業務之間的協同作用，擴大對零售金融市場的覆蓋，形成競爭壁壘？
Big Teleco正在開發的這個產品，其所面臨的業務問題則是進一步拓展下一代無線通信市場的份額，在市場上形成技術領先的優勢，而當前這個項目則是為了滿足產品在一個新市場部署實驗局的規格要求。
如果把項目分成問題域和方案域，不少組織和個人都會不自覺地混淆問題域和方案域。一個具體現象就是，當開發團隊討論一個項目的時候，把所有的時間都用在了分析、設計和實現解決方案上，大家都在說要如何開發某個特性，很少看到有人甚至提起這個特性到底是要解決什么問題，為誰帶來什么樣的價值，問題的產生場景是怎樣的，大家對這些問題的答案經常是想當然。
這種現象其實也跟不少組織中的角色定義有關。在很多領域，分析問題的人和分析解決方案的人被分成不同的角色，比如分析員、架構師、開發人員，三個角色之間的關系明顯就是前者為后者分析問題，后者為前者提供解決/實現方案，而后者經常缺乏對問題域的全局掌握和關注，導致做方案的人不時會把時間和資源放在了無關重要、甚至是錯誤的問題之上。
2．交付目標
一般來說，我們很難通過一次交付就徹底地解決一個業務問題，一次交付的目標更可能是為了達成產品路線圖上一系列路標中的一個。這個路標可以是一個新的價值流的端到端的實現，也可以是在現有的價值流上增加不同場景，為用戶提供更加豐富的選擇。
交付目標應該有可度量的開始點和截止點，也就是有清晰的邊界。這個邊界可能會在交付過程中，根據最新的信息而調整。但在任何特定的時候，項目的所有干系人對邊界都應該有一個清楚的共識。
Big Bank這次的交付目標是在同類機構之前，以最小可行產品的策略，將這項新業務推向市場。
?通過在線方式，幫助借貸雙方方便、安全地完成投資和借貸。
Big Teleco這個項目的交付目標是某客戶在該特定市場部署實驗局所必需的2個關鍵需求。時間點對于這次交付至關重要，管理人員需要根據市場的要求來定義決策評審點，Beta測試開始時間等關鍵時間點。
3．提升目標
從來都不要指望脫離日常工作的刻意培訓能給交付能力帶來本質的提升，就好像沒有球員能夠不經歷無數場的拼殺就能成為偉大的球星，也沒有外科醫生能不經歷無數場的手術就能成就卓越的醫術一樣，只有真實項目上的挑戰才能激發人們學習和創造的潛力。一個組織要分析相關行業和競爭對手的數據，對自身交付競爭力做出評估，有策略地制定提升目標。研發競爭力的提升必須要以項目為載體，在實踐當中部署實施。
Big Bank經過分析，認為自己的開發中心在效率上、質量上都領先于同行業的軟件開發組織，但是在進入在線業務領域后，競爭格局出現了很大的變化。除了其他金融機構的競爭，各大互聯網公司也在嘗試進入金融領域，正以各種方式嘗試直接或間接地提供針對個人和企業，特別是小企業的金融服務。
這些互聯網公司對機會和市場的響應方式和速度，卻跟傳統金融機構有很大的差別，方式上經常顯得更有創意，不拘于已有金融服務的模式，反應速度上不是傳統大型機構的步調所能匹配。以往大型金融機構所擁有的網點和客戶數量優勢，是新進入者不得不面對的堅實壁壘，而這個壁壘在互聯網的規模覆蓋和社會化營銷的效率面前卻威力不再。
因此，Big Bank 的管理層決定，這次的項目應該作為一個試點，嘗試新的開發方法、流程和技術，以及用戶體驗設計和網站運營手段，把互聯網公司當做標桿，提升對市場的響應速度和產品研發的價值命中率。
Big Teleco 的產品開發團隊的劃分是基于產品架構對子系統和模塊的設定做出的，Big Teleco 越來越意識到這種模式帶來的兩個問題。
?現有的模塊團隊的劃分開始局限產品架構的設計。系統工程師做設計的時候，總是有意無意地會把現有團隊結構和能力范圍作為約束條件，影響了最適宜設計的產生。
?能力的細分越來越嚴重，具備全局能力的工程師越來越少，培養周期越來越長，并且要形成端到端的交付能力，哪怕是為了很小的一個特性，都需要引入大量的溝通和協作成本。
因此，Big Teleco在這個版本的開發中決定在一定限度內打破模塊團隊的協作模式，嘗試根據項目目標組織臨時特性團隊的工作方式。
4．資源配置
一個大型的開發組織一般都有多個產品、多個版本在同時進行當中。這就涉及到在不同發布目標之間的權衡，決定資源，特別是優質資源的分配。優秀的人員和關鍵的設施永遠都是稀缺的，如果不稀缺的話，倒是讓人有點懷疑這個組織的運營效率了。資源的投入經常是多個項目、多個產品之間博弈的結果。
鑒于這個項目的業務和開發方法對現有團隊都是屬于比較新的模式，為了能夠確保交付和學習兩方面的目標，Big Bank決定成立一個新的開發團隊，從其他團隊抽調部分精兵強將，再從外部找個經驗比較豐富的廠商舍作開發。
Big Teleco的人員管理和培養屬于功能部門的職責，項目經理需要根據當前項目所要完成的活動確定所需技能和相應人員的數量，會同各個功能部門經理、產品線總監，協商獲取相關資源。
項目管理人員需要根據項目的目的和里程碑來規劃項目，在規劃的時候需要覆蓋進度、質量、資源和風險各個方面。
5．進度目標
項目管理人員需要根據自身所采用的流程模型和團隊在整個產品開發生態系統中的位置，識別交付所需的各項活動、每項活動所需的時間，以及活動之間的依賴，并以這些數據為依據描繪項目的關鍵路徑
，從而制定進度目標。
項目的關鍵路徑信息可以幫助項目管理人員識別交付過程中的里程碑。里程碑提供了一個常規機制來跟蹤項目的進展是否跟預期相符。雖然我們強調項目當中的反饋機制應該使相關人員能夠盡可能接近實時地獲取信息，即刻采取行動，這些里程碑給團隊之外更廣泛的項目干系人一個必要的機會，一起分析最新的項目和環境信息，調整后續的時間點、投入、工作范圍和目標，或做出其他必要的決策和干預。
里程碑的定義要有明確的目標。典型里程碑的標志通常是跟某交付物的驗收結束相關，確保驗證的力度和問題的解決符合預定的階段性質量目標。
●階段性評審的結束，比如需求、設計、測試計劃等。
●某個交付物的質量保障活動的結束，比如功能測試、集成測試，用戶接收測試（UAT）。
在迭代交付模型里，典型的里程碑是發生在每個迭代結束的時候，以迭代展示（Showcase）為標志。團隊會在這個場合將交付物——經過驗證的特性，演示給項目的干系人，并獲取反饋。有的團隊也會利用這個機會（團隊外的各方干系人在場的機會），針對一些中間產物，諸如界面原型、架構設計和技術決策分析、測試用例等，收集反饋，甚至開展評審活動。
Big Bank期望在年底之前發布產品，決定采用2周一個迭代的策略，以便及時得到反饋和對計劃做出適應性的調整。Big Bank把第一次內部發布定在了第四個月，也就是元旦前的一周，然后，根據這個時間點倒推出了下列信息。
?每個迭代的期望速率（交付的點數）。
?關鍵交付物的驗證時間點。
?外部依賴的檢查點、接收和驗證計劃。
?性能和負載等非功能屬性的驗證計劃。
?用戶接收測試的時間點。
這個項目采用典型的迭代開發模型，在開始的時候計劃了一個2周的啟動階段，這個階段的交付物如下。
?需求：目標用戶模型（Persona分析）、用戶體驗路線圖、業務流程、信息架構、界面原型、用戶故事列表。
?技術：架構設計、關鍵技術決策、關鍵非功能性需求的可行性驗證。
?計劃：估算、優先級、依賴分析、風險分析。
由于這個產品對外部的依賴是幾個已經投入使用的后臺系統，所以跟那幾個后臺系統的負責團隊確認了開發協作的方式和集成測試的時間點。
Big Teleco使用的是由經典IPD（Integrated Product Development）流程衍生出來的一套結構化、端到端的產品開發流程，包含概念、計劃、開發、驗證、發布和生命周期6個階段。IPD流程覆蓋產品開發團隊（PDT）、財務、開發、支持維護、制造、采購和市場各個組織，本文只關注其中軟件開發相關的部分。
在計劃階段，軟件相關的交付物包含：系統規格和概要設計、用戶體驗設計、需求分解和分配、系統測試和驗證計劃、文檔計劃、支持和維護計劃……
6．質量目標和手段
不同類型的產品有不同的質量目標。對于一個飛行導航系統和一個blog系統來說，其質量的要求自然有所不同，因此使用的測試手段和其他質量保障活動也會有所不同，需要不同的質量保障策略。
Big Bank測試和開發人員來自一個大的資源池，基于項目的需求組成一體化團隊，也就是說各個層面的測試和驗證是在團隊內部完成的。在測試人員主導下，團隊中不同角色的代表一起制定了一個覆蓋3個層面（單元、功能、集成）的測試策略、自動化策略、用例管理策略。
在這個項目里，開發人員將負責單元測試完成，測試人員將會跟業務分析人員一起定義每個用戶估算的驗收條件，并設計功能和集成測試用例。功能和集成測試用例的自動化則根據工作量的平衡，由開發人員和測試共同完成。
Big Teleco擁有完整的質量保障體系，具體內容如下。
在產品的整個開發周期里，對各個階段、各個功能部門的交付物，包括各種分析、設計和計劃文檔，軟件代碼和測試用例都有嚴格的走查、評審機制。
測試手段覆蓋開發人員測試（單元測試和單元級別的模塊和集成測試）到測試人員測試（包括系統集成測試、Beta測試等）。
Big Teleco的測試團隊獨立于開發團隊，這種組織模式基于的觀念如下。
?測試的獨立性能夠為產品的驗證提供跟開發不同的視角和思維模式，因此更有利于發現缺陷。
?測試是一個專門的技能，在組織中應該有專門的團隊為能力的培養和提升，以及提煉和吸納業界的最佳實踐負責。
電信類產品雖然日新月異，不過相對于商用軟件和互聯網軟件，主流電信類產品開發技術在過去的十幾年間變化不大。同樣的，測試策略在同一個產品線里的各個產品和版本之間有很強的繼承性，基本是以漸進的方式演化。因此，測試經理在項目定義的階段，更關注的是參與設定產品的質量目標、制定測試和驗證計劃，參與項目計劃的制定，協調測試資源的到位。另外在電信領域，為本類型產品量身定做的自動化測試工具會大幅降低測試的用例的開發和維護成本，所以測試經理還會需要梳理測試工具開發的需求，甚至帶隊參與測試工具和模擬軟件的開發。
除了獨立的測試團隊，Big Teleco還有獨立于項目的質量保證部門，與各個功能部門緊密協作，負責質量戰略和目標的落實。質量部需要做以下工作。
?根據業務目標，協助制定質量策略。
?參與項目計劃和計劃的評審。
?分析歷史項目指標數據，協助制定當前項目的質量目標。
?負責流程的運轉和優化改進，以及相關知識和能力的傳播和提升。
7．資源的規劃
什么時候應該談投入什么樣的資源，包括人員和設備？這個時候，項目管理人員就需要用真憑實據，對照過往的歷史數據和項目相關信息，提出資源的要求。
Big Bank的項目團隊組成通常是根據項目的需要，考慮技能匹配和時間安排，從部門資源池里選擇。這次Big Bank的項目管理人員跟舍作廠商一起對初始的發布目標進行了分析和估算，經過權衡可獲得內部人員數量和采購預算，再把交付目標的要求和學習提升的期望納入考慮，得出的結論是，為了滿足要求，需要自己團隊出5個人，廠商出10個人。
Big Teleco的項目團隊具有相當的穩定性，熟悉一個產品的業務領域，甚至只是熟悉一個模塊的業務和技術，都有可能需要1～2年的時間，因此，通常是上一個版本團隊的人員釋放之后就逐步投入同一產品的下一個版本，人員的穩定性對團隊成熟度、技術積累、開發效率都要較大的影響。這個項目也是一樣，上一個版本的開發已經進入最后的系統驗證階段，人員開始逐漸投入到這個版本。
對于個人來講，項目的參與人員需要了解團隊計劃，評估個人對于交付目標的承諾，并且識別成長的機會。每個人心里都有一本賬，而這本賬的計算結果會時時刻刻地影響著個人、團隊的士氣和投入度。
Big Bank的開發人員Tom心里評估著團隊的目標和計劃是否靠譜，看看自己是應該拍拍胸脯，承諾保證完成任務，還是應該擺出一副苦樣子，表示一下對于激進目標的擔憂，另一方面又思考著這個項目對自己在技術上還有業務上的成長是否有幫助，盤算著自己在這個項目上的貢獻和成果是否成為未來升職加薪的籌碼，增加自己在工作市場上的競爭力。