就這樣，c專案組糊里糊塗的開始了敏捷之旅。在第乙個迭代完成後：
2023年2月21日-3月4日，專案組成員每天站在白板前進行每日站立會議。如果發現了需要討論的話題，就在會後進行討論。
2023年3月4日，專案組進行了第一次回顧會議。沒有評審會議了，因為專案組僅完成了預估工作的不到一半，僅提供了乙個demo。
團隊在白板前進行第一次迭代回顧，會議總耗時乙個小時。會議結果如下：
1. 做得好的
a) 成功完成demo，所有bug都修復了。
b) 每日站立會議對團隊有很大幫助，可以清楚知道團隊其他成員在做什麼。團隊協作比以前更好了。
c) 感謝美國團隊的及時響應。
d) 感謝團隊成員的認真負責，開發和qa聯手解決了瀏覽器相容問題，開發把silverlight的單元測試整合到每日構建中。
2. 需要改進的
a) ui是個瓶頸，開發流程不順暢，有時會等待。
b) 沒有完成工作計畫。
c) 會議太多，時間太長。
3. 改進計畫
暫略。糾結的目標
第一次迭代是相當糾結的乙個迭代。完成既定的任務，遵照scrum的流程和建立自組織團隊，這三個目標交織在一起。在其中還混雜著，證明敏捷優於以前模式的壓力，這部分壓力承載了證明自己的期許，公司管理層的期待和團隊參與者們的期望。
殘酷的現實
從很多方面來看，第一次迭代都不能算成成功。團隊承諾的過多，甚至算不上團隊承諾，而且不能順利完成。工作流程中暴露出很多問題，瓶頸變得顯而易見。
從樂觀的角度看，也有些進步。團隊在持續解決工作中出現的問題，合作與溝通也在進步中。
怎麼辦？
很多團隊都是在第
一、二次迭代中不能頂住壓力，最後只好回歸以前的工作方式。
1. 意識灌輸
在暴露出的各種問題面前，團隊顯得無助，懷疑論正在成長。作為敏捷推動者，要知道「壞訊息就是好訊息」，不停詢問團隊「這樣的問題在以前的模式中能夠發現和解決嗎？」讓這些問題暴露出來，這本身就是敏捷實施的成果。
2. 頂住壓力
不管怎樣，專案交付的壓力持續存在，而管理層因實施敏捷對團隊的關注，導致壓力持續增大。作為敏捷推動者，在這時候要頂住壓力。乙個好辦法是告訴團隊，管理層對團隊當前的工作進度並不滿意，讓我們一起來想想辦法解決這個問題。
3. 培養信心
作為敏捷推動者，不要過於強調我有好辦法，要注意發掘團隊的閃光點。這是培養自組織團隊最有效的一種辦法，認可和表揚團隊的閃光點，培養團隊自主改進的信心。
C專案敏捷實施 第一次計畫會議
本系列將記錄專案中引入敏捷的過程和相關的一些思考，歡迎進行交流。2011年2月16日前，與專案經理和開發組長進行過兩次前期交流。2011年2月16日，公司領導確認對專案進行過程改進，確定由我協助專案進行改進。2011年2月17日，與中國團隊的專案經理進行面談，確定引入迭代開發模式。2011年2月18...
第一次專案
部落格班級 作業要求 homework 11169 作業目標 作業源 學號 211806422 記錄完成 1.行數 132行 記錄過程 關於git的一些流程步驟著實讓我非常頭疼，也諮詢了很多寫完的同學，包括室友，都比較困難的去完成這些東西。包括下面這個git clone 等等 在 的書寫方面，運用了...
拳皇遊戲第一次迭代
拳皇小組成員展示 2017301750064 楊小康 組長 2017301040171 周炎 組員 2017301390035 桂義 組員 2017301040172 邵鵬飛 組員 2016301550188 沈真元 組員 2017301200260 杜樹俊 組員 團隊成員的分工 第一次迭代所完成的...