文章出處
文章列表
1.確定選題。
應用NABCD模型，分析你們初步選定的項目，充分說明你們選題的理由。
錄制為演說視頻，上傳到視頻網站，并把鏈接發到團隊博客上。
截止日期：2016.5.6日晚10點
閱讀教材第8章，8.1~8.3節 P157~168，了解獲取用戶需求的辦法，每個組可以選擇一二加以應用。
8.4節P168-171 查閱NABCDA模型的具體說明。
2.0---------------------------------------------------------------
2.SCRUM 流程的步驟 1
完成產品Backlog的編制，在spint計劃會議之前，確保product backlog井然有序。
閱讀教材第8章，8.5節 P171~173，幫助我們確定列表的優先級。
8.5節 P174~186，幫助我們估算工作量。
小組展示
下周二（2016.5.10）課堂上，第個組用6分鐘時間盡情展示一下小組風采與選題。
形式可以但不限于由一人主講其他成員配合，內容可以但不限于以下內容：
團隊名稱的由來、團隊口號的含義，選題的理由、預期達到的目標，產品Backlog展示。
希望各個隊伍認真策劃并加以演練，以達到較好的展示效果。
評分：
本次作業由同學們和老師共同評分，每個組對其他組的展示內容與效果進行打分。
3.0-----------------------------------------------------
SCRUM 流程的步驟2: Spring 計劃
1. 確保product backlog井然有序。（參考示例圖1）
2. Sprint周期，一個沖刺周期，長度定為兩周，本學期還有三個沖刺周期。
3. 確定Sprint目標。
3.1 產品負責人概括產品backlog,對sprint目標進行總體介紹，講清他認為最重要的故事。
3.2 團隊從最重要的故事開始逐一討論每個故事，估算時間，理清每個條目的含義，在必要的情況下拆分backlog條目。所有重要性高的backlog條目都要填寫“如何演示”。
3.3 團隊根據生產率，選擇要放入sprint中的故事。
4. 把故事進一步拆分成任務。（參考示例圖2）
5. 形成Sprint backlog。 Scrum master隆重登場，組織大家按照SCRUM流程，步步為營順利開展工作。（參考示例圖3圖4）
要求：將1，3，4，5項工作成果組織成一篇博客，發布在團隊博客上。
截止日期：2016.5.12晚10點。
4.0-----------------------------------------------
1.準備看板。
- 形式參考圖4。
2.任務認領，并把認領人標注在看板上的任務標簽上。
- 先由個人主動領任務，PM根據具體情況進行任務的平衡。
- 然后每個人都著手實現自己的任務。
3.為了團隊合作愉快進展順利，請堅持每日立會。
- 定下每日例會的時間地點。
- 例會情景請拍照留影（至少一次，發布到博客上）。
- 會上大家依次報告:我昨天做了啥，我今天要做啥，我碰到了哪些問題。
- 每日立會時更新看板。
- 每天例會后的看板拍照顯示進度。（拍照可以固定在一個位置拍，以后還可以把每天拍的圖做成動畫。參考圖5）
4.博客發布要求：
看板設計。
任務認領情況。
下每日例會的時間地點，及一張包括全部團隊成員的例會照片。
每日例會的看板進展。
每個同學記錄自己的任務實現情況，可同時發布在自己的博客上。
此次博客截止日期：2016.5.17晚7點。
5.0---------------------------------------------------
1.團隊成員完成自己認領的任務。
2.燃盡圖：理解、設計并畫出本次Sprint的燃盡圖的理想線。參考圖6.
3.每日立會更新任務板上任務完成情況、燃盡圖的實際線，分析項目進度是否在正軌。
每天的例會結束后的都為任務板拍照并發布到博客上
4.每天看到進展，待續到sprint演示。
5.博客發布要求:
完整的任務板（有燃盡圖），5.18號晚10點之前發布到博客上，5.19號的例會就用上。
然后每天例會追加的任務板更新后照片或截圖，直到本次sprint結束。
6.0-----------------------------------------------------
sprint演示
1.堅持所有的sprint都結束于演示。
- 團隊的成果得到認可，會感覺很好。
- 其他人可以了解你的團隊在做些什么，并得到重要反饋。
- 演示是一種社會活動，不同的團隊可以在這里相互交流，討論各自的工作。這很有意義。
- 做演示會迫使團隊真正完成一些工作，進行發布。如果沒有演示，我們就會總得到些99%完成的工作。有了演示以后，也許我們完成的事情會變少，但它們是真正完成的。
2. 可能會費點時間，實際沒有完成多少工作的狀況下演示就會變得令人尷尬。團隊在做演示的時候會結結巴巴，之后的掌聲也顯得勉勉強強。有人會為團隊感到有點兒難過。有人感到很不爽，寶貴時間被浪費在了一場很爛的演示上。
但它是苦口良藥，等到下一個sprint，這個團隊就會真得試著做完一些事情！
3.Sprint演示提示--檢查列表
- 我們軟件工程課的目的是理解開發過程、開展項目管理。所以第一要點是用你們的工作成果展示你們理解了一個sprint流程。
- 清晰闡述sprint目標，免得有些人對產品一無所知。
- 讓演示關注于業務層次，不要管技術細節。即注意力放在“我們做了什么”，而不是“我們怎么做的”。
- 暫不需要花里胡哨的演講，集中精力演示可以實際工作的代碼。
- 節奏要快，不要演示細碎的bug修復和微不足道的特性。
- 可能的話，讓觀眾自己試一下產品。
- 展示Sprint回顧的過程及成果。
4.Sprint演示日期：2015.5.27
下周二課堂上，第個組用6~8分鐘時間進行第一個Sprint的演示。
7.0------------------------------------------------
Sprint回顧
讓我們一次比一次做得更好。
1.回顧組織
主題：“我們怎樣才能在下個sprint中做的更好？”
時間：設定為1至2個小時。
參與者：整個團隊。
場所：能夠在不受干擾的情況下討論。
秘書：指定某人當秘書，籌備、記錄、整理。
2.回顧流程
- sprint總結：Scrum master向大家展示sprint backlog，在團隊的幫助下，對sprint做總結，包括重要事件和決策等。
- 輪流發言：每個人都有機會在不被人打斷的情況下講出自己的想法：他認為什么是好的，哪些可以做的更好，哪些需要在下個sprint中改變。
- 生產率分析：對預估算的生產率和實際的生產率進行比較，如果差異比較大的話，分析原因。
- 改進之處：快結束的時候，Scrum master對具體建議進行總結，得出下個sprint需要改進的地方。
3.回顧輔助（參考圖7）
Good：可以繼續保持的做法。
Could better：需要改變的做法。
Improvements：有關如何改進的具體想法。
4.回顧結論
即時貼上。
圓點投票來決定下一個sprint會著重進行哪些改進。
每個sprint只關注幾個改進就夠了。
5.回顧截止日期：2015.5.25晚10點
6.讀書
閱讀《構建之法》第8、9、10章，發布讀書博客。
將些次Sprint演示與總結情況發布到團隊博客上。
每個人也對此次Sprint進行總結，連同讀書筆記與提問，發布在自己的博客上。
截止日期:2016.5.27晚10點。
然后好好休息，下周開始新的Sprint周期。
參考圖7
參考圖6
參考圖4
參考圖5
參考圖1
參考圖2
參考圖3
參考圖4
文章列表
全站熱搜
留言列表
