Alpha 事後諸葛亮（團隊）

标簽（空格分隔）： 軟工實踐

作業的傳送門

設想和目标

1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

acm隊員個人訓練中的所有需求以及簡化管理層人員的管理，定義的很清楚,對典型用于和場景有清晰的描述。

2.我們達到目标了麼?

除了 個人能力分布分析 部分的個人能力圖做不了外,其他部分基本上都按時完成了,甚至提前完成,并且分析的時候發現做了部分Beta版本的内容，因為我們的開發時間其實是比較長的,從組隊确立開始後,立刻就進行了相關學習,10月中旬就開始投入開發。

3.使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼?

有固定的使用者群體,過了暑假集中集訓的高峰期，使用的不多,和預期差不多。

3.有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?

如果是按最初的思維導圖,功能太多,做不完，發現隻能挑最核心與可行性高的做，原因有很多,比如:隊伍人員的時間有很大的不均衡性,前期能參與開發的人員隻有一半;前端人員隻有一個;最了解項目的人沒有時間管理項目,交接問題導緻項目停滞了一段時間等。

做到現在，發現需求方面有一些變化,比如沒有考慮到資料量相關方面的缺少，導緻個人能力圖做不了,而靠着資料為基礎的組隊方面的功能也相應的就停滞。

是以我們的aphla的需求分析還算是相對合理的,組隊方面沒有考慮在内，但是也分析了一些自己列了一些不是很需要的需求在内。

如果從來一遍，需求方面需要更加慎重的考慮。

計劃

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

有

2.團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？

隊内讨論解決，如果還有的話,保留意見,組長擔責任。

3.你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

按照aphla版本,最主要的功能都已經實作,沒有做完的有兩個原因:

1.沒有資料支援 2.隊内讨論後發現該需求實際上是僞需求

4.是否每一項任務都有清楚定義和衡量的傳遞件?

布置任務有詳細的任務步驟,并且做了傳遞的規範說明

5.是否項目的整個過程都按照計劃進行，項目出了什麼意外？

沒有完全按照計劃進行,組長在aphla進行到一半的時候交接了統籌的任務;背景的任務結束的過早;

6.在計劃中有沒有留下緩沖區，緩沖區有作用麼?

背景任務是領取制的,完成一個任務後,可以自由選擇其中一個未完成的任務,是以時間上相對比較自由。不過根據個人時間安排,有要求每個人相應的任務量。

7.将來的計劃會做什麼修改？

由于Beta版本時間比較長,是以會從思維導圖中選擇可做的需求加入其中。

資源

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

沒有足夠的資源完成思維導圖中的内容,但是完成目前的預期還是足夠的

3.各項任務所需的時間和其他資源是如何估計的?

由組内有項目經驗的人來評估時間和任務難度決定.

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

測試任務已經算在任務當中了,接口的任務中直接包含了測試文檔的編寫。

文案所需的時間低估了，花了很多時間。

美工設計?前端人員直接上。

變更管理

3.每個相關的員工都及時知道了變更的消息?

知道，小團隊内消息傳遞比較及時

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

不了解這個

4.員工是否能夠有效地處理意料之外的工作請求？

有問題找PM

設計/實作

1.設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？

接口由背景人員一同編寫，寫到一個階段後,前端人員再開始根據原型設計來完成

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

可以的話找PM，不可以的話就自己想辦法解決。

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

沒有單元測試,接口的編寫都是要求先編寫流程圖的,測試接口我們團隊有用專門的測試工具Insomnia，并且編寫相應的測試文檔,測試文檔很有用,背景和前端人員基本上不需要直接互動,看測試文檔就知道作用了，流程圖的話是給編寫的人員理清思路的。

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

複審基本上是PM肉眼觀察,因為有測試文檔等經過測試可以用了,出錯率比較低。

測試/釋出

1.團隊是否有一個測試計劃？為什麼沒有？

編寫接口的人員直接進行相關測試與測試文檔的編寫。

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

沒有,直接釋出出來看使用效果

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

有,前面提到過,Insomnia。

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

實際使用一下看響應時間是不是在能接受的範圍内。測試工具蠻有用的,如發現某些網頁的爬取特别耗時,這個時候就選擇緩存一下。

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

本地測試是沒有問題的,但是放到伺服器上就會出現了BUG,原因是:本地的資料庫貌似可以不區分表名的大小寫,但是伺服器上是嚴格區分大小寫的。

團隊的角色，管理，合作

1.團隊的每個角色是如何确定的，是不是人盡其才？

有相關經驗的直接進行相關角色操作。

沒有經驗的再一起學習。

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

大部分都是新手上路，互相幫助是很常見的事情。

我感謝 橘子 對我的幫助， 因為 給我Insomnia的安裝包與Insomnia的基本使用。

我感謝 海林 對我的幫助， 因為 剛剛上手背景任務時候幫助解答我許多的問題。

總結:

1.你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?

第二個檔次。可重複級

1.對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

• 1.我們最優先要做的是通過盡早的、持續的傳遞有價值的軟體來使客戶滿意
• 2.即使到了開發的後期，也歡迎改變需求，靈活過程利用變化來為客戶創造競争優勢。

讨論圖檔

注:一個外出比賽,一個回家,一個拍照

附

學習進度條

第N周	新增代碼 (行)	累計代碼(行)	本周學習耗時(小時)	累計學習耗時(小時)	重要成長
1000		40		acm訓練、vs的使用,項目建立、性能分析等
1	800	1800	30	70	acm訓練,php基礎知識學習
2	600	2400	10	80	acm訓練，wampserver的安裝配置、php基礎知識學習
3	400	2800	8	88	CI架構學習
4	300	3100	12	100	CI架構學習、acm學習
5		3700	14	114
6	150	3850		118	背景開發
7		4000		122
	200	4200		129
9