天天看點

Scrum 項目 7.0 Sprint回顧

7.0------------------------------------------------

Sprint回顧

讓我們一次比一次做得更好。

1.回顧組織

  主題:“我們怎樣才能在下個sprint中做的更好?”

  時間:1個小時

  參與者:整個團隊

  場所:課室

  秘書:李康梅

2.回顧流程

(1)sprint總結:Scrum master向大家展示sprint backlog,在團隊的幫助下,對sprint做總結,

包括重要事件和決策等。

     在完成今次的任務的過程中,我們團隊經常聚在一起讨論,我們主要實作的功能是界面、圖檔按鈕、普通按鈕,

雖然實作的功能不多,但是我們每個成員都有參與到,大家都很積極,雖然我們的進度有點慢,但是我們并沒有放

棄,而是努力地把進度趕上去。      

(2)輪流發言:每個人都有機會在不被人打斷的情況下講出自己的想法:他認為什麼是好的,哪些可以做的更好,

哪些需要在下個sprint中改變。        

      Good:

      103李康梅:用圖檔按鈕來代替按鈕會比較美觀,可以繼續保持 

      109張鑫相:每個人都發表自己的意見,認真對待,積極解決問題

      112馮婉瑩:團隊可以繼續保持經常聚在一起讨論

      149麥錦俊:有主菜單可以随意切換

      Could better:

      103李康梅:化妝師和化妝品界面裡的圖檔間距太小,不太美觀

      109張鑫相:為一個問題不斷糾結,導緻進度停滞不前

      112馮婉瑩:修改和完善資料、訂單界面

      149麥錦俊:輸入中文字型會出現警告

      Improvements:

      103李康梅:改變圖檔之間的間距

      109張鑫相:遇到問題多尋找解決的途徑

      112馮婉瑩:去掉一些花俏的東西,添加實用的功能

      149麥錦俊:把中文字型存入字元串檔案中

(3)生産率分析:對預估算的生産率和實際的生産率進行比較,如果差異比較大的話,分析原因。

  在完成今次的任務的過程中,本來大家都以為今次的任務會比較簡單,結果卻花費了很多時間都沒有完成

sprint1的全部任務,進度也比我們估計的要慢很多,原因是我們對Android的知識還是不太熟悉,很多組

件的功能都不會用,而且我們總是為一個問題不斷糾結,導緻進度停滞不前。

(4)改進之處:快結束的時候,Scrum master對具體建議進行總結,得出下個sprint需要改進的地方。

   經過小組成員的讨論,我們打算在下個sprint中修改和完善資料界面和訂單界面,我們也會合理安排時間,

不再浪費太多的時間在同一個問題上。

3.回顧輔助(參考圖7)

  Good:可以繼續保持的做法。

  Could better:需要改變的做法。

  Improvements:有關如何改進的具體想法。

4.回顧結論

  即時貼上。

  圓點投票來決定下一個sprint會着重進行哪些改進。

  每個sprint隻關注幾個改進就夠了。

5.回顧截止日期:2015.5.25晚10點

6.讀書

  閱讀《建構之法》第8、9、10章,釋出讀書部落格。

第八章:需求分析

(1)軟體團隊如何才能準确而全面地找到軟體需求呢,主要有四個步驟:

        1)擷取和引導需求   2)分析和定義需求

        3)驗證需求            4)在軟體産品的生命周期中管理需求

(2)擷取使用者需求有幾種常用的使用者調研方法:

        1)焦點小組   2)深入面談  3)卡片分類  4)使用者調查問卷

        5)使用者日志研究  6)人類學調查  7)眼動跟蹤研究  8)快速原型調研  9)A/B測試

(3)競争性需求分析架構:NABCD模型,其中的N為需求,A為做法,B為好處,

        C為競争,D為推廣。

第九章:項目經理

   軟體團隊裡除了能寫代碼、測試代碼和畫圖做設計的成員,還有一類角色,不做上面這些

事情但也很重要,我們叫他們項目經理--PM。

   PM做開發和測試之外的所有事情,PM要在整個項目的生命周期管理風險。

   要想成為一個合格的PM,需要具備以下的能力:

    1)觀察、了解和快速學習能力   2)分析管理能力

    3)一定的專業能量                  4)自省的能力

第十章:典型使用者和場景

    規格說明書簡稱Spec,分為以下兩種:

    1)軟體功能說明書        2)軟體技術說明書 

     如何才能把使用者的需求變成團隊成員可以直接操作的開發工作,然後源源不斷地實作這些

需求?功能驅動的設計(FDD)是針對這個問題的衆多方法論之一。FDD由以下幾個步驟構成:

    1)構造總體模型   2)構造功能清單  3)制定開發計劃

    4)功能設計階段   5)實作具體功能

團隊成員的讀書筆記和sprint1的總結:

109張鑫相:http://www.cnblogs.com/xyz--123/p/5533889.html

112馮婉瑩:http://www.cnblogs.com/xiaoyy/p/5528874.html

149麥錦俊:http://www.cnblogs.com/maijinjun/p/5534203.html

小組成員的個人貢獻分:(小組團隊總分為80分) 

 103李康梅:22分

 109張鑫相:21分 

 112馮婉瑩:19分 

 149麥錦俊:18分