敏捷開發的Scrum晨會實踐
阿新 • • 發佈:2018-12-24
hursing所在的公司推行敏捷開發有兩年多了,其中最讓人直接感受到的就是scrum晨會。從生搬硬套到過程創新,令大家由抵觸變成積極響應,這個過程真的很花費心思。
11年12月,hursing開始在自己的團隊推行晨會。當時團隊是剛成立的,很小,包括hursing自己在內的2個老人+2個新人,基本上hursing得指導所有的事情。事實上,團隊小到不開晨會hursing也知道他們在做什麼,所以晨會的內容更多是反饋他們遇到的還未解決的問題以及提出對編碼過程的改善意見,然後hursing做一些指導和糾正。這個階段,整個團隊是在確定自己的風格和目標,探索一個合適的行為準則。
在此過程中,發現一個有用的技巧:團隊的人應該坐成一堆,而不是一排。即工位安排坐成背靠背 (或者沒有障礙的面對面),而不要一字排開地坐。這樣每個人坐著說話就行,整個團隊的人都能聽見。有了這個便利性,平常大家也更樂於溝通,甚至可以就在座位上開晨會,足夠放鬆。有事的話大吼一聲就行,完全不用郵件或即時通訊工具。需要當面溝通的話,雙腳一瞪,凳子就滑到那邊去了,立刻可以交談。如此一來平常的事務大家都知道,晨會上自然也能更簡短地敘述。
不過,座位的事情hursing沒法自己決定,不久就在10年1月聽組織安排,大家坐散了。然後團隊再加了新人,變成6個。於是大夥得找會議室來開晨會。因為平常的溝通不便,大家在晨會的發言變多了,此時限制大家發言的內容有了必要。當時對scrum也沒那麼多的認識,基本上是說“昨天做了什麼,今天要做什麼,目前有什麼問題”。這是老三點,有點“俗”,但是也不會錯,只是不是很適合實際的工作節奏。
以上算是對scrum最初的探索。
12年中,調崗換組,直到10月開始再次對一個團隊擁有一些掌控權。這個團隊很複雜,非常有挑戰性。團隊共11人,分別來自4個不同業務的組織(分由4個leader打績效,不包括hursing),而且負責同時開發兩個專案。hursing被指定為團隊的介面人,一開始還真覺得頭疼,因為團隊連個晨會都沒有,4個組織的人是跟各自的leader一起開晨會的。通過積極的反饋與溝通,最終是本團隊的人一起開晨會、但由於人員組織的複雜性,開始的時候晨會的形式也很特別:
- 每週只是一三五開。因為彼此的工作相關性不是很大,而且晨會有比較多的時間是hursing在宣講專案事宜
- 不用把技術點說得很細。因為其它組織的人可能聽不懂,這是浪費時間。只要提出了問題,由各個組織內部解決就行了,有執行困難的話才由hursing出面直接找leader幫忙。
- 今明兩天要做的事情在晨會說完後要寫在白板上,下次再擦掉寫新的。這裡沒有用傳統做法,即紙貼ToDo、Doing、Done,因為那樣不環保,且字小,不直觀,都是給自己看的,別人看不清;讓別人也能看清,那就有種無形的監督作用。團隊的負責人可以知道整體的狀況並隨時跟蹤進度,並且下次晨會的時候,各人可以回顧一下執行得怎麼樣。
- 每個組織出人,介紹自己該組織負責的模組的主流程,並且對跟別的模組有互動的部分著重描述。
- 跨組織安排工作。主要是幫忙解bug,不承擔開發任務,這樣可以互相熟悉業務。
- 推動跨組織的程式碼review
- 建立愛分享知識的氛圍,鼓勵寫技術文章
- 前兩天做了什麼,所屬的任務完成了百分之多少(標在白板上)
- 做的工作有哪些會影響別人或需要別人配合,提出來協商
- 對於正在解決的棘手問題,大家有什麼建議
- 晨會主持人很少做改進工作,誰做得不合理也沒人提點
- 各人的發言沒有預先經過組織,隨想隨講,思路混亂,停頓較長
- 過長的討論沒人打斷,每人平均發言1.5分鐘,有時候整個晨會接近半個小時
- leader當成聽報告會,樂於聽到很詳細的技術處理過程,有些點還會追著細問
- 大家聽不懂以後,經常開小差,看著別的地方也有,私下討論的也有
- 人多了,圍成的圈很大,有些人說話聲音小,部分人聽不見(建議每人都走出來背靠白板面對所有人來講,leader站在最遠的地方)