軟工網絡15團隊做業7——Alpha衝刺之過後諸葛亮

1、總結的提綱內容

a. 項目管理之過後諸葛亮會議

（一）設想和目標

1. 咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

讓大學生經過記帳養成良好的消費習慣，解決了大學生不知道錢花到哪裏去，沒有好的金錢規劃等問題。在以前的團隊博客的需求分析中對典型用戶和典型場景有清晰的描述。

2. 咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)

基本完成MVP的功能。原計劃就已經肯定好目標，打算把核心功能先實現了。 有按照原計劃交付時間交付。 用戶數量原計劃是12個，alpha階段纔剛剛發佈，主要由內部開發人員在使用。

3. 和上一個階段相比，團隊軟件工程的質量提升了麼？ 在什麼地方有提升，具體提升了多少，如何衡量的？

提升了。分工協做方面有所提高。由於原來不大懂微信小程序開發具體流程，在分工方面只能分個大概，後來不斷熟悉開發具體流程，PM在分工方面進行了調整，alpha階段沒有實現後端，則把後端人員調至前端開發。整個項目開發的效率有所提高。

4. 用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

預想一致。離目標還有一段距離。由於是alpha階段，咱們尚未實現殺手功能，只完成了最核心的記帳模塊和報表模塊。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

設想太過飽滿，在實際設計過程當中，發現有些功能尚未能力實現。結合自身編程能力和需求進行功能設計。

（二）計劃

1. 是否有充足的時間來作計劃?

有，在alpha階段的前兩週都用來寫計劃。

2. 團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

你們一塊兒討論，選擇合適的計劃。

3. 你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

基本完成。

4. 有沒有發現你作了一些過後看來不必或沒多大價值的事?

有。在需求分析時，考慮以後要完成除核心功能和殺手功能外的其餘一些不是很必要的功能，好比皮膚設置等。

5. 是否每一項任務都有清楚定義和衡量的交付件?

大部分沒有，通常按照你們主觀上的認識來定義功能。開發人員根據要求完成功能模塊後，咱們組成員會進行使用，並提出建議。

6. 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

基本都能按照計劃進行。對前端語言的不熟悉，在某些功能模塊實現方面，花了比計劃還要長的時間。

7. 在計劃中有沒有留下緩衝區，緩衝區有做用麼?

有。每一個人的進度都不同，有時候一些模塊會有一些bug須要修復，花費的時間常常比計劃的要長。

8. 未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

結合開發人員的技術能力，合理安排時間。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

時間計劃表要和開發人員的技術能力和功能模塊的複雜程度相結合。咱們會明確緩衝區的長度，確保計劃能按時完成。

（三）資源

1. 咱們有足夠的資源來完成各項任務麼?

人力資源足夠，可是技術資源和時間資源還有所欠缺。由於你們都是第一次接觸微信小程序的開發，沒有系統學習小程序開發，操做起來難度仍是挺大的。時間上，你們由於各類事情會感受時間上有些不充足。

2. 各項任務所需的時間和其餘資源是如何估計的，精度如何?

把每項任務的功能實現列出來，關於支持功能實現的後端技術也列出來。根據列表的功能數和功能實現的難度（如網上是否有資源能夠參考）來估計所需資源和時間等。

3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?

咱們團隊安排了2名測試員，人力資源是夠的，在測試時間上安排有些不合理（安排的太少了），致使在alpha階段發佈程序時，程序還出現了一些bug。測試軟件/硬件資源是足夠的，可是在使用這些資源方面，咱們團隊還不能熟練操做。確實低估了不須要編程的資源（如界面排版設計），由於程序界面設計的語言你們沒有接觸過，很難經過設置一些變量值來實現你們設想的界面。

4. 你有沒有感到你作的事情可讓別人來作（更有效率）?

目前你們都沒有這種感受，由於咱們的任務是根據你們的技術能力、擅長領域來分配的。但有時也會出現分配給組員任務太重的現象，這個時候咱們會及時調整任務分配。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

在分配任務的時候，要先大概瞭解下程序的前端、後端各個模塊完成的工做量，再根據每一個人技術能力和擅長領域來分配任務，適時根據實際狀況來調整任務。

（四）變動管理

1. 每一個相關的員工都及時知道了變動的消息?

是的。咱們團隊有建一個微信羣，有關項目的任何變動消息會在上面發佈。

2. 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

你們一塊兒討論決定最核心的功能，若出現不一樣意見的話，會採用投票的方式來決定功能是屬於「推遲」仍是屬於「必須實現」。

3. 項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

有。經你們的討論，考慮到時間問題和你們技術水平，在alpha階段咱們只關注於記帳小程序的核心功能。包括記帳模塊和圖表模塊。咱們的出口條件就是：選擇日期、類別進行記帳，能夠準確記錄當天的總結餘和選定日期查看當天的明細，選擇年月查看消費類別的比例。

4. 對於可能的變動是否能制定應急計劃?

在進行這個項目時，並無制定應急計劃。但在出現咱們計劃與實際出現誤差時，咱們會及時調整計劃。

5. 員工是否可以有效地處理意料以外的工做請求？

大部分能。PM會把工做請求給相應的技術人員實現，若是技術人員沒法實現，你們能夠一塊兒想辦法完成。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

在變動管理方面，咱們團隊作的不夠，在實現程序過程當中變動的內容也是直接臨時你們通過討論決定，這樣很容易與原來的設計內容相違背。若是還能再來一次，咱們會在計劃設計方面，多考慮變動狀況的發生和相應的應急方案。

（五）設計/實現

1. 設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

在一開始的原型設計環節就進行了設計工做。由黃登峯和何雨柔同窗完成。黃登峯同窗擅長界面排版，何雨柔同窗是咱們團隊的PM，會根據咱們團隊開發的小程序核心功能是記帳
這一關鍵點出發，給出界面設計的建議。恰在合適的時間與合適的人。

2. 設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

遇到過。好比在報表功能要放在和明細帳單頁面一個頁面呢，仍是獨立出來一個頁面。PM召集你們討論，每一個成員都給出本身的見解，通過討論咱們決定把報表模塊獨立出一個頁面，這樣讓用戶在短期內使用中發現咱們程序的主要功能，這樣在排版方面也顯得更加簡潔明瞭。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？

用微信自帶的測試小工具。仍是挺有效的，能夠分析時間效能、cpu使用狀況等等。

4. 什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

記帳功能模塊。涉及到帳目類別、金額、時間的數據存儲。發佈以後有個嚴重的bug就是選擇不一樣日期進行記帳後，對應日期的明細出現了混亂，好比今天的帳目記錄到昨天去了，或者是沒有記錄進去。在測試過程當中，並無發現這個bug，是在發佈以後才發現有時候會出現這種狀況。

5. 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

每一個人針對本身負責的模塊進行代碼複審，讓相關功能模塊的開發人員進行互相代碼複審。嚴格執行了當初制定的代碼規範。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

設計過程當中要注重測試。經過測試，開發人員可以及時修改bug或者更換設計思路。

（六）測試/發佈

1. 團隊是否有一個測試計劃？爲何沒有？

有。在程序開發過程當中，測試人員針對程序開發的功能模塊制定了測試計劃。

2. 是否進行了正式的驗收測試？

是。經過微信測試工具和測試人員的使用來修復已發現的bug。

3. 團隊是否有測試工具來幫助測試？

有。微信自帶的測試工具。

4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

使用微信自帶的測試工具，經過分析測試工具的測試結果。有用。

5. 在發佈的過程當中發現了哪些意外問題？

出現了一些以前沒有發現的bug。發佈以後有個嚴重的bug就是選擇不一樣日期進行記帳後，對應日期的明細出現了混亂，好比今天的帳目記錄到昨天去了，或者是沒有記錄進去。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

要注重測試，測試人員要熟練掌握測試工具的使用，可以使項目的完成事半功倍。

（七）團隊的角色，管理，合做

1. 團隊的每一個角色是如何肯定的，是否是人盡其才？

根據每一個成員的擅長領域和技術能力決定。作到了人盡其才。

2. 團隊成員之間有互相幫助麼？

有，遇到問題你們都會一塊兒討論、一塊兒想辦法，解決問題。

3. 當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

由PM進行調解，你們一塊兒討論。

（八）總結

1.你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

達到第二個等級：可重複性。咱們團隊能過作到管理制度化，創建了基本的管理制度和規程，管理工做有章可循。初步實現標準化，開發工做比較好地按標準實施。變動依法進行，作到基線化，穩定可跟蹤，新項目的計劃和管理基於過去的實踐經驗，具備重複之前成功項目的環境和條件。

2.你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

目前處於規範階段。在alpha開發階段，一開始你們會出現一些意見不統一的狀況，須要你們不斷的磨合。如今咱們團隊可以團結協做完成項目開發，遇到不一樣意見也可以在較短期內解決。

3.你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

對微信小程序的開發流程有了更深入理解。開發人員也對一些前端語言有了進一步的熟悉。你們可以更加團結協做作事，效率也更高了。

4.你以爲目前最須要改進的一個方面是什麼?

咱們項目的殺手功能尚未實現。由於考慮到alpha階段的時間和你們的技術水平，把殺手功能放在了下一階段的開發。

5.對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

原則：咱們最優先要作的是經過儘早的、持續的交付有價值的軟件來使客戶滿意。事例：在alpha階段，咱們完成了最核心的功能，在後期開發咱們會始終圍繞用戶需求把實現其餘的功能。原則：在團隊內部，最具備效果而且富有效率的傳遞信息的方法，就是面對面的交談。事例：咱們團隊每一個禮拜都要開一次會議，若是有什麼疑問，能夠直接面對面提出。原則：每隔必定時間，團隊會在如何才能更有效地工做方面進行檢討，而後相應地對本身的行爲進行調整。事例：咱們團隊每一個禮拜都要開一次會議，探討工做進度和工做任務等，你們會提出使工做更有效的建議，如是否調整計劃，修改工做任務，調整任務分配等。

b. 全組討論的照片。

2、根據展現博客中給出的團隊成員在Alpha階段的角色和具體貢獻排序：

名字	角色	團隊貢獻排序	可驗證的貢獻	團隊我的貢獻分
邱曉嫺	前端	1	記帳模塊，修改bug	35
陳凱欣	前端	2	報表模塊，修改bug	32
何雨柔	PM	3	安排任務，每日的進度追蹤，服務器的配置	13
黃登峯	測試	4	原型設計，界面設計	11
張晨晨	後端	5	架構設計，服務器的配置	9