| 項目 | 内容 |
|---|---|
| 這個作業屬于哪個課程 | 2021春季軟體工程 （羅傑 任健） |
| 這個作業的要求在哪裡 | 提問回顧與個人總結 |
| 我在這個課程的目标是 | 提高軟體開發能力，鍛煉團隊協作能力 |
| 這個作業在哪個具體方面幫助我實作目标 | 在經曆實際開發過程後，回顧學期初的問題，給出答案，并對本學期的學習過程進行反思 |
回答問題
Q1 結對開發是否真的能提高效率？
有這樣的疑問主要源于以下幾個方面：
- 4.6 兩人合作的不同階段和技巧中提到萌芽階段和磨合階段：
如果我們做的項目是真實的，有具體而多變的需求，有工期、品質和資源的沖突，團隊成員各自的水準、目标也不一緻，那麼團隊内部不可能沒有沖突。
每個人有不同的習慣、解決問題的方式，是以兩人在許多細節的問題可能有不同的意見，這種時候産生的沖突如何解決？如果都是聽從水準較高的程式員，那與該程式員一個人完成有何差別？而且這個階段耗費的時間是否都是有意義的時間？ - 結對開發需要經常交流，并且是有效的溝通，這就增大了社交的壓力，增大了沖突發生的可能性，尤其是對于不善言談的人來說。并且在 6.1 靈活開發的第三步提到
一切交流隻能通過Scrum大師來完成。這一措施較好地平衡了“交流”與“集中注意力”的沖突。
那是否說明在程式設計的時候專注于程式設計、交流的時候專注于交流才能取得更好的成果？結對開發中是否存在“交流”與“集中注意力”的沖突？ - 4.5.2 中提到
結對程式設計中，因為有随時的複審和交流，程式各方面的品質取決于一對程式員中各方面水準較高的一個。
如果說結對開發對于水準較差的人來說能提高自己的水準，那對于那個水準較高的人有什麼意義？ - 4.5.3 不間斷的複審中提到
結對程式設計加劇了壓力，長時間緊張工作，導緻工作時段降低，再加上兩人同時完成一個任務，是否耗費了更多的時間？每個人每天的高效率工作時段不超過3-4個小時。
一對程式員完成預定任務之後，就可以休息，或者開展其他較輕松的工作，而不應該死闆地按照工作日八小時的規定而繼續程式設計。
解答
在我們結對程式設計的實際過程中，我對以上幾方面相關問題有了如下的了解：
- 我們在程式設計的過程中确實遇到了一些意見不同的時候，我們選擇了一起讨論，直至一個人說服另一個人的方式，這個讨論的過程也是互相學習的過程，我們可以學習到對方一些好的程式設計習慣，也能了解到一種不同的思維方式，雖然耗費一些時間，但我并不認為這個時間是無意義的，這些收獲都是獨自程式設計無法體會到的。
- 因為我和我的隊友比較熟悉，可以直接清楚地說出自己的意見，而不用過多考慮措辭等其他方面，是以相比于程式設計，社交方面增大的壓力可以忽略不計。
- 我和隊友的程式設計水準處于持平的狀态，是以會聽取雙方的建議、從中擇優，在這個過程中，我們都能有所收獲。我認為，即使是水準高與水準低的人一起程式設計，也總會有一些收獲。
- 如在第一點所述，雖然在讨論的過程中會耗費時間，但我并不認為這個時間的花費是毫無意義的，在這個時間裡，我們收獲了自己程式設計難以得到的體會，如不同思維方式間的碰撞等。
Q2 在設計中應該關注人數更多那類人群的使用體驗還是兼顧多種人群的使用體驗？
12.3 評價标準的第5條是适應各種類型的使用者：
适應各種類型的使用者
我們的軟體要為新手和專家提供可定制化的設計。一些操作方式，如快捷操作，使用者可以自行調整。我們還應該為存在某些障礙的使用者（色弱、色盲、盲人、聽力有缺陷的使用者、操作鍵盤滑鼠不友善的使用者等）提供一定程度的便利。
如果要兼顧多種人群的使用體驗和使用感受，則需要為軟體設計更多的功能以适應不同人群的需求。但更多的功能會增大使用軟體的認知阻力，且對于多數人群，一些功能可能是不必要的，甚至有些累贅的。
在12.1.2 從使用者角度考慮問題也提到了
使用者對那些選項對話框的種種選擇會有更大的畏難情緒。
那我們在設計中應該關注人數更多那類人群的使用體驗還是兼顧多種人群的使用體驗？
這個問題在我們團隊開發的過程中已經得到了答案：
在設計的過程中，團隊經過讨論定義了典型使用者和典型場景，依據使用者需求設計各種功能。在有一個新的想法後，我們會讨論這個需求是否屬于典型使用者、典型場景的需求，在一個産品中并不需要覆寫所有人群的需求，也不需要覆寫某一人群中所有人的需求，而應着重考慮該産品典型人群的需求。若是不加選擇地增加功能，隻會使産品功能變得備援。近年來使用者對于産品的選擇也越來越傾向于簡約輕量，是以有時在設計時比做“加法”更重要的是做“減法”。
Q3 是否需要為部分操作的表示用語制定行業标準？
12.3 評價标準的第4條 一緻化和标準化中提到：
在軟體中，對同一事物和同類操作的表示用語，各處要保持一緻。例如，某詞典軟體有“幫助使用者收集生詞并且背誦生詞“的功能。這個功能要有明确一緻的稱呼，不能混雜着叫”單詞本“、”生詞本“、”Word List“、”Word Book“、”單詞檔案“……等等。
在我對各種軟體的使用體驗中，影響使用者體驗的因素不隻是某一軟體操作的表示用語，更多的是不同軟體對于同一操作的表示用語、同一功能的稱呼各不相同，帶來了一定的認知阻力，那是否需要為這些操作的表示用語制定行業标準？
我認為這是非常需要的。我們在團隊小程式的開發過程中，遇到的一個很大的問題就是使用者覺得難用，而其中有一個重要因素是操作用語是使用者不熟悉、不了解的。比如，通常情況下，我們習慣于将統計圖的資訊劃分為橫坐标、縱坐标，在表格中輸入橫縱坐标畫出圖像。但為了适應多種圖表類型，在開發過程中，我們定義了資料組的資料結構，然後在表格中提示使用者輸入橫坐标和資料組，而這顯然是不符合使用者認知的，使用者并不知道資料組具體指什麼，這就給使用者使用增加了一定難度。
從這個例子中，我體會到了統一标準的操作用語的重要性，這會大幅度減小使用者的使用阻力。除了統一的操作用語之外，統一的圖示表示、頁面布局等都會降低使用者使用一個新産品遇到的的障礙.
Q4 專人負責和團隊負責，哪個模式更有利于團隊工作？
7.2.4 各司其職，對項目共同負責中提到：
團隊的各個角色合起來，對整個項目最終的成功負責，為什麼？因為每個角色在其職責範圍内的失敗都會導緻整個項目的失敗，而且各個角色的工作都是互相滲透、互相依賴的。這種互相依賴的方式也鼓勵團隊成員在自己本職之外為其他領域做貢獻。
14.2.1 中提到：
所有人都可以參與QA的工作，但是最後要有一個角色對QA這件事負責。不但角色要獨立，而且在最後軟體釋出時，必須得到此角色的簽字保證。
每個人的工作互相滲透、互相依賴，但如果所有人都對項目最終成果負責，是否會導緻責任推脫？如果最終有一個角色對成果負責又是否會造成其他人的懈怠？
專人負責和團隊負責，哪個更有利于工作？
在經過實際的團隊協作後，我認為每個人都必須對項目負責，至少對自己完成的部分負責，最終可以根據項目不同部分的實作成果進行評估。但同時，團隊也需要一個pm的角色配置設定任務、督促成員，把控項目整體品質。我們在Alpha階段采取了pm輪值的方式，Beta階段選出了一個人做pm，我認為後一種方式使團隊效率更高、凝聚力也更強。
Q5 二維的完成任務次元、團隊貢獻次元的評價體系是否全面合理？
17.6 績效管理中提到：
為了更客觀地反映員工績效的不同因素，有些公司實施過二維的評價體系：
完成任務次元：主要由團隊成員和直接經理商量年度目标，直接經理有較大的自由度決定“超額完成/完成/未完成”的比例。
團隊貢獻次元：還是嚴格根據人員百分比，評出團隊中最好的20%、中間的70%，以及最需要改進的10%。
首先，團隊貢獻次元很難量化，根據工作量計算，還是根據工作類型計算，還是根據工作時間計算，依舊難以找到一個合理公平的方式，沒有解決根本問題。
17.6 中還提到一種情況：
一個心不在焉的程式員可以一天寫2000行代碼，然後測試人員和其他開發人員要花很多時間來修複其中的缺陷，這些同僚原本要做的任務就被耽誤了。
在這種情況下，也許這個人完成了自己的任務，也有不小的工作量，但所得到的結果卻适得其反，給其他人造成了較大的工作量，這種情況下，又該如何量化？
在團隊實際的開發過程中，我們團隊的任務得分由基本分和品質分構成，基本分根據任務難度以及需要花費時間得出，品質分由團隊成員複審給出。我認識，這樣的方式比較合理地評估了每個人的任務量，同時也解決了上面提到的需要修複缺陷的情況。但在大型項目中，對每個任務都進行難度判斷、完成時間預判以及完成品質評價，可能會導緻比較大的工作量。
新的問題
在小程式的開發過程中，由于團隊隻有五個人，在全員開發的過程中，很難再分出人做測試、pm、美工，在這種情況下，強行給一部分人安上測試、pm的角色是否反而會降低開發效率和工程品質？那是否這些角色的設定可以由每個團隊按需配置？
知識點
需求
在需求分析階段，主要應用了NABCD分析的方式。
Need部分的分析同時也是功能設計的依據，通過對使用者需求的分析，我們大緻确定了需要圖表繪制、模闆分享、分類管理等功能。Approach部分我們确定了以微信小程式的方式開發應用程式、實作産品功能 。Benefit部分我們确定了産品的優勢，構思了一些殺手級功能。Competitor部分我們與市場上類似功能的産品做了比較，進一步确定了我們開發的方向。在Delivery部分我們設想了一些推廣宣傳産品的方式。這個分析的過程，也就是我們對功能進行初步設計的過程。
設計
在設計過程中，我們定義了典型場景、典型使用者，從使用者需求出發進行設計，在設計的過程中還需要考慮實作的方式及難度，合理配置設定時間和任務。
在設計過程中，還需要進行界面原型設計，初步繪制示意圖，确定小程式的功能布局。最後，還需要後端進行資料庫設計以及前後端接口設計。在設計階段，我們都是采取一個人主要設計，其他人提出想法建議，一起讨論修改的方式，這樣大大提高了會議的效率。
實作
在實作過程中，根據提前定義好的前後端接口、功能設計等，前後端同步開始實作，遇到問題在微信群以及會議中積極商讨解決。同時在實作過程中，為了能更好地協作，一些工具鍊的使用是必要的，如gitlab、共享文檔等。
在實作過程中，團隊成員間有效的溝通是非常有必要的，所有可能有歧義的地方都需要進一步确認，在對設計作出修改時需要通知到所有人，確定每個人的接口文檔都是最新版，否則很有可能會導緻做出“無用功”。
測試
測試是非常重要的一個階段，也是保證軟體工程品質的重要手段。除了單元測試外，還需要壓力測試、場景測試等。與以往的課程有完整的輸入輸出定義進行開發不同，由于與不同使用者進行互動，需要考慮到各個方法，如使用者的錯誤輸入、不同手機的版本問題等，隻有進行了全面詳盡的測試，才能保證使用者的體驗。
釋出
在釋出過程中，需要考慮到微信小程式的稽核時間的問題。在釋出時，需要考慮多種宣傳方式，尋找目标人群，用海報的形式吸引使用者眼球。同時需要建立使用者群，積極收取使用者意見。
維護
在維護階段，需要充分聽取使用者回報，修正使用者遇到的bug。對于使用者的一些針對功能以及外觀方面的建議，需要在使用者群體中進行調查問卷，聽取更多人的意見，并在團隊内進行商讨，最終決定是否進行修改以及如何進行修改。
個人總結
個人項目
在閱讀了《建構之法》并且根據自己的了解寫了三篇部落格後，我對軟體工程有了基于理論上的初步了解。在提問的同時，也進行了相關的思考。在案例分析作業中，我通過對軟體的調研、分析、對比、評測，對開發軟體有了一定的了解和想法，并在自己開發的過程中對于使用者的實際體驗有了更多的重視。
結對程式設計
在結對程式設計的過程中，起初思維方式以及程式設計習慣的不同，我們會産生一些分歧，然後針對這些問題進行讨論。但讨論的過程其實也是一個互相學習的過程，同時在讨論中，我們對題意也有了更細緻的了解。總體來說，雖然結對程式設計相較于個人會多花費一些時間，但是在這些時間裡，我們能學習到一些新的東西，而不是一直按照自己的習慣一成不變。
團隊項目
在團隊項目中，我們完成了繪制圖表的小程式，在這個過程中，每位隊友都付出了自己的努力，克服了許多開發過程中遇到的困難。我主要負責後端代碼的開發，總體來說完善地完成了自己的任務，并且收獲了許多開發經驗。
團隊協作中有效的溝通是非常重要的，我們在一次次會議中對遇到的問題逐一讨論、解決，充分聽取每個人的意見，在經曆需求、設計、實作、測試、釋出、維護這些階段後，順利釋出了符合預期的小程式，并且每個人都有自己的收獲，我也實作了自己“提高軟體開發能力，鍛煉團隊協作能力”的課程目标。
最後，感謝各位老師、助教、隊友的辛勤付出！