學期初提問部落格
- 軟體工程_第一次閱讀作業
學期初問題與解答
第4章 結對程式設計
總之，如果運用得到，結對程式設計可以取得更高的投入産出比（Return of Investment）。
-
Q1
此處的投入産出比仿佛是一個缺乏定義的概念。結對程式設計的核心想法大概是一人領航一人實際操作，并通過頻繁交流迫使雙方共同努力提高自身水準，這種工作模式在參與者水準均較高且相當的情況下一定程度上自然能減少錯誤、有一定督促效果，但考慮到磨合成本，以及現實中參與者往往存在水準、技能的差異，能否真的達到比兩人高效協同工作收益更高，我持懷疑态度。
- 回答
- 本學期實際的結對程式設計中确實出現了上面提到的磨合、技能差異問題，代碼複審确實能提高代碼品質，但效率和收益并不高。總的來說，結對程式設計還是需要結對兩人均有較高且相當的水準才能效果較好。
第6章 靈活流程
教材中對靈活開發團隊成員提出了較高的要求：
1.以有進取心的人為項目核心，充分支援信任他們。
2.自助管理、自我組織、多功能型。
對于團隊成員品質的保證，我有以下兩個問題：
-
Q2
這樣的團隊成員要求不說極高，但也算很高了。那麼，為了持續保證成員品質，是否需要以某種形式進行團隊成員出入的管理？以何種标準合适呢？
-
- 團隊項目有安排換人，但我們組通過了無人轉會申請，是以并沒有人員更換。主動的人員出入對于一個團隊來說可以說是比較糾結的一件事，隊伍磨合後可能出現誰都不想換的局面。但在實際項目中，若以效率和收益為首要考慮，換人仍是很有必要的。将與團隊融入程度不高的個人替換可能确能提高整體的工作效率，但這件事需要一個高層管理人員執行，否則我想大多數隊伍内部會礙于面子、傷和氣等問題不處理這樣的問題。至于具體以何種标準，我認為是一個很難描述的問題，視情況而定。
-
Q3
靈活開發以充分信任為前提，但人和團隊往往是有惰性的。即便是每日例會平行比較工作量，如果所有人在安逸的條件下都有一定的惰性，那就失去了比較的價值。如此而來，是否應當引入外界篩選壓力進而督促團隊提高效率呢？外界壓力和信任是否存在一定沖突？
-
- 在團隊項目中我們讓每個人做超短期的每日計劃，并通過每日例會追蹤進度保證工作的持續推進。實際效果很好，有效地降低了惰性，大家都很負責地及時傳遞自己的任務。一般情況下不需要額外的外界壓力也能做好自己的本質工作，并在例會上交流問題保持一個互相信任的友好環境。
對于靈活流程，我有以下問題：
-
Q4
靈活開發以個人沖刺為工作行為單元，任務多零散。這樣的模式對于有複雜依賴關系的軟體系統，是否會導緻在工作對接上導緻效率降低呢？
- 問答
- 在團隊項目中，我體驗過前後端對接協同修改的艱辛。自然，相比于一個人把一個功能點全棧完成，進一步打散的任務會有更高的對接成本。但對于一個分工明确的隊伍，這樣做總體而言效率會更高。隻能說愈合熊掌不可兼得。若要真切地提高對接效率，隻能在需求文檔制定時盡可能細化明确需求，讓涉及的人員都有明确同一的參考标準。
第16章 IT行業的創新
兩三個專注于某一領域的匠人，用非大規模制造技術打造出來的東西還有價值麼？IT曆史告訴我們，有很多成功的産品都是從小作坊開始的。
-
Q5
曆史中的成功和當下成功的條件是很不同的。如今，軟體行業的品質要求、使用者需求都比以往多得多（使用者容忍度低），在這種情況下，小作坊形式的産物會不會更容易面臨因資源不足的問題難以達到當今環境的品質标準線，進而難以成功？
-
- 視需求而定。一個一般的軟體（指全棧開發，尚不面臨超大使用者量帶來的諸多技術問題）開發所需的技能和整個流程往往很相似。實際需要的最小團隊規模也可以壓縮的很小，個人認為對一些簡單任務，本學期團隊項目的人數到其兩倍左右的人數就足矣勝任。要保證品質，需要有專人測試，并且各角色的開發人員對自己的工作充分負責并積極改進，可以說是态度問題吧。在需求明确的情況下達到需求即可，在需求尚未充分明确時以一種盡可能好的态度去争取，面對發現的問題認真解決，把握時間節點，那做出來的項目品質就可以保證。抛開推廣相關問題，小作坊可以把産品做得小而精，我想在合适的大環境機會下也有同樣機會獲得成功。
軟體工程實踐中學到的知識點
需求分析
- 面對衆多需求，團隊需要進行充分的分析和必要的使用者調研進而确定優先級。
- 一個清楚的需求文檔對于前後端高效對接至關重要。
代碼設計
- 盡可能早的明确代碼規範并執行。
- 前端開發盡可能早的統一UI風格群組件庫，或項目開始前先實作統一的元件庫一同使用。避免後期風格不一緻造成的額外修改成本。
代碼實作
- 多問多查，參考他人的實作改進。
代碼測試
- 我在團隊項目中的開發工作是前端開發和PM。測試前端時對照需求進行完整的功能測試，不放過任何error。
- 可以的話找使用者内測，實踐經驗表明100個人一起找Bug發現問題的效率要高的多，并常常發現和基于裝置差異的問題。
代碼釋出
- 宣傳很重要。在特定開發場景下可以的話争取官方支援。團隊項目過程中我們聯系了社聯官方進行宣傳推廣後使用者量激增。
代碼維護
- 靈活開發講究快速響應使用者回報，我們在團隊項目中實踐了這一原則，使用者反響很好，不斷積極地給我提出各種回報幫助我們改善軟體。
心得總結
結對程式設計
- 個人認為結對項目體驗較差，問題過于關注算法，與其說像一個軟工題不如說是個算法題。建議以後的結對項目問題換成輕量級的全棧開發任務，兩人實作一個五髒俱全的迷你軟體（如小網站），适當延長時間，将任務重心移到軟體工程上，不要再出算法題了。當然這樣的話測試成本會高的多，還是要根據課程組實際資源考慮。
團隊項目
- 團隊項目中我的角色是前兩個階段前端開發，最後一個階段PM。
- 前端開發最大的感受是UI設計應該盡早統一風格。否則，每隻程式猿的美術風格（造詣）不同，實作出來的UI會風格差異較大。另外，不明确設計時程式猿往往傾向于找現有元件湊合着用，有的元件可修改性較差，後期若要調整工作量較大。可以的話在項目真正開始開發前先統一寫一套樣式元件共用，這樣就能較好的統一風格。
- 當PM的感受頗多。首先是面對衆多需求，要根據使用者真實需要、軟體目前階段的核心目标、團隊成員的時間進行篩選，應優先将精力投入高優先級的任務盡快提高軟體整體的使用者體驗再關注細節改進。其次是進度追蹤的方法。項目中我們讓每個人做超短期的工作計劃并在每日例會上追蹤，效果較好，每個人都基本能及時完成任務，即便某一天因種種原因沒有進度，後面也會快速補上。最後是宣傳推廣時直面核心使用者的好處。我們在beta階段釋出後拉起了社團管理人員的群，接收各種回報意見，與此同時不斷推廣我們的軟體，從這起，我們的使用者量快速增加。
- 最後，感謝我的所有團隊成員，他們都超！超！超！超！可！愛！！（芬姐兩倍的超以表真情）。我們隊伍氛圍始終很融洽，每個人都對自己的任務很負責，并互相幫助，在歡快吐槽中愉快改bug。大家都在積極學習新技能， 整個項目過程中，我們除去PM有6個開發人員，其中三個都嘗試過全棧開發，其中雨飛爸爸更是從小程式寫到後端再寫到網頁端兼代碼複審orz。尤其感謝芬姐詳細得令人窒息的需求文檔、精緻的原型設計和魔鬼Push，也感謝我沒有選課但友情全程參與開發的小夥伴lqc，還有自願聯系我們加入的宇飛提供的社聯層面的宣傳推廣幫助。
- 配圖一張：
軟體工程提問與個人總結