敏捷開發是一種提倡擁抱變化, 控制風險的一種方法論。本文將講述在實施敏捷團隊時的一些Good Practice。
識別團隊中的Bad Smell
文檔
“hey, 幫我寫個文檔被, 以后我好回顧, 以后來人就按照這個文檔操作, 省的你一遍一遍說”.
碰到這種情況一定說, NO. 當面溝通最有效, 我已經交給你了, 再來新人, 你教. 如果認為有必要寫文檔, 誰提倡誰寫.
這種方式, 除了拒絕文檔這種低效率的溝通方式, 還要拒絕團隊為”只提意見，不主動實踐”的人提供土壤。
我們拒絕文檔，提倡高效溝通。試想一下，剛進項目的時候，客戶的人做我旁邊，找我問技術問題竟然發郵件。
站會
"xxx沒來, 等等他吧, 我希望聽聽他的工作. "
依然say no. 我們不能為了站會而站會. 站會不等人, 準備或者提前開始, 團隊快速catch up, 然后迅速開始一天的工作.
不用擔心有人缺席站會會有影響, 如果有人非常需要跟缺席人的溝通, 自己會去找他, 反之依然.
溝通
“hey, 我發現一個小bug, 能不能現在修一下, 很簡單, 估計也就10分鐘”.
拒絕. 請JIRA建卡, 或者story上添comments , 簡單描述bug, Owner在需要時自己去take卡
此時要培養的習慣
- 優先級的概念
- 再小的任務也有effort, 當前工作被打斷, 再拾回也是effort
- 任務的簡單與否, 會耗費多長時間, 一般由熟悉本任務的Dev決定, 其他人替Dev做預估都是非常不專業的表現. 一定要培養溝通習慣, 專業的事情, 找專業的人溝通，由專業的人評估。
讓每個環節更有效率
站會
go through 每天大家做的事情.
站會時只講三件事兒, 時間控制在5分鐘內（10個人）
- 我昨天做了什么
- 我今天要做什么
- 碰見什么問題,需要誰或者什么幫助.
站會主持者需要及時識別站會中的bad smell
- 站會時進行細節討論
- 講述story中, 不需要每個人都知道的細節
- 把站會當開會, 當中宣布一些顯而易見事情. 這種事情郵件就可以做到, 不需要大家每個人, 把聆聽宣講當做優先級最高的事情.
提高站會效率的手段
- 準備一個token, 只有拿token的人才能說話
- 站會時計時5分鐘, 然后告訴大家我們需要5分鐘內結束站會. 會后記錄使用時間, 在團隊養成習慣后可以不用追蹤時間
- 展會前將站會內容按照
Yestoday, Todo, Question分類, 寫在卡片上, 站會時按照卡片上的講 - 及時打斷不必要的討論
- 及時打斷問對方要承諾式的對話. (例如, xxx你今天能不能完成 xxx? 然后也渴望的眼神看著對方)
Continuous Integration / Continuous Deliver
CI/CD沒有你想象那么難, CI/CD會帶來持續的效率增長. 越早引入成本越低，反之成本越高。無論多困難困難，都建議排在最高優先級。
CI最小集合
- build script ( maven, gradle, rake, gulp.js …)
- git repository
- Jenkins Job
CI能保證的內容
- project 能夠在一個干凈的機器上build, 避免本地依賴
- 每個人都可以使用build script構建相同的開發環境(mvn idea:idea / gradle idea)
- 構建結果能夠發布, 客戶可以時刻拿到QA過的更新
CI標準集
- run check style
- run unit test
- build package
- run functional test
Continue deliver標準集合
- 將構建結果自動化發布
- 自動化更新到終端(eclipse plugin開發，自動更新到update site)
結對編程
有些客戶對結對編程并不理解，雖然不進行100%的full time結對，有些場景結對編程會帶來很好的效果。堅持下來后，這種結對方式也贏得了客戶的認可。
需要結對編程的信號
- 傳遞知識, 包括帶新人
- story涉及兩個人做的內容, 可以double check
- 需要幫助的時候
不適合做結對的情況
- spike
- 需求不清晰的Story
如何結對
- 先就story溝通思路
- 一個人寫測試, 一個人寫實現
Code Review
每天必不可少的環節，并且需要堅持每天進行。
目的
- catch up 今天的工作,
- 分享代碼技巧
- check代碼, 保持良好的代碼風格
步驟
- 先講做了什么, 如果條件允許, 先做showcase
- 按照解決思路講解代碼
- 重構(當天發現的問題, 當天重構), 站會時需要有人專門記錄refactor建議
關注點
- 別人在做什么, 如果以后碰到相關問題, 知道要怎么做, 或者找誰問.
- 了解別人解決問題的思路
- 關注代碼的bad smell
Retrospective meeting
一個安全的環境, 大家討論團隊中遇見的問題.可以采用如下方式:
- Well/Less Well/Question or Suggestion
- Star Fish (Start/Stop/More/Less/Keep)
個人推薦采用Star Fish, 每個象限都是action, 會讓回顧會議更容易產生action, 效率更高。
