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