程序員眼中的敏捷

　　我在上周參加了敏捷之旅(北京站)的活動。以前參加過各種大大小小的培訓，企業內訓，關于敏捷的一些認證。但是參加類似這種非盈利性的交流會還是第一次。以下對本次活動進行回顧：

　　第一部分：流水賬

　　先說一下此行的收獲。

　　1、第二次與段念見面，第一次見他大約是兩年前，那是他還在谷歌中國，負責測試團隊，當時記得當時他給我們講的是“敏捷測試——簡單而可行”。

　　這次見面是段老師以豆瓣高級工程總監的身份來跟大家分享豆瓣的敏捷的實踐。我一直很欣賞段老師，這次他帶來的“生長出來的敏捷”，果然沒有令我失望。

　　2、在會場積極提問提，得到了一本“風騷”的不行的書。。。

　　3、早上免費的麥叔叔套餐、中午吉野家套餐。。。

　　4、下午見到了@喬梁 ，我的敏捷生涯，跟此人有不解的淵源，他翻譯的《持續交付》，我讀了不知道多少遍，他的那個持續交付的網站，也一直伴隨著我成長。

　　5、在 Open Space 環節與段老師一起完成了show time 環節，雖然我在做這個環節有點不自信，但是我還是大膽的去嘗試了。

　　6、最最激動人心的是最后的抽獎環節。工作5年左右，每次年會都是僅僅被“陽光普照”，這次，我終于登上了領獎臺。。。200元現金“大獎”(由于我是現場報名的，報名費150)……這使我不僅在精神上盈利了，物質上也有盈利……

　　第二部分：關于Open Space分享主題的思考和總結

　　流水賬記錄完畢，下面進入正題：

　　@Shining 在會議結束時，跟我講，要我把open space環節整理一下，現在開始做作業。

　　話題#1：“程序員眼中的敏捷是什么樣子的”?

　　在做這個話題的時候，段念提出了兩個問題

　　你希望在敏捷中得到什么?

　　你希望敏捷的環境是什么樣的?

　　由于參加討論的人員組成并不是單一的開發人員，還有敏捷教練、產品經理，所以討論出的結果比較有意思，簡單的來說：

　　開發人員更關心，自身能不能在敏捷開發中更開心，學到更多的知識等個人問題

　　而敏捷教練、產品經理，更關心的是，團隊問題

　　這令我產生了一個想法，在溫飽問題沒解決的情況下，很難讓大家到一種小康水平，敏捷團隊建設，應該以人為本，最大限度的滿足團隊個體需求，才是王道。

　　由于大家的想法不統一，我們把討論的話題做了進一步的引申，就有了下面的來自于豆瓣的一種文化“吐糟”。

　　話題#2：“吐糟大會”

　　在大會上，我們分別對三種角色進行“吐糟”：

　　做產品的

　　做開發的

　　敏捷教練

　　在吐糟大會上，大家相互吐糟，有的人進行自我吐糟。會議中，大家并沒有因為自己的問題被指出而感到尷尬，而是思考。其實在一天的敏捷之旅中，大家多多少少的體會到了一些敏捷的思想。大家有勇氣面對自己的錯誤，大家愿意把問題透明化，大家愿意改進，我看到了敏捷的種子，已經埋入到了大家的心里。當然吐糟的目的并不是僅僅過過嘴癮，就像喬梁會上說的一句話“Scrum并不能解決問題，它僅僅能發現問題”，但是由于時間限制，我們并沒來得及能把大家的“吐糟”解決。其實會議到此結束已經小有效果了，因為團隊中的不同角色相互溝通了，我一直相信，一個真正的敏捷團隊是有能力“自調整”的，我說的“自調整”指的是團隊一起發現了一些問題，這些問題，會在沒有做要求或者找到具體對策的情況下，在不知不覺的情況下不復存在。當然，這些是需要長時間的磨合才能辦到的。在團隊沒有到達那種理想情況下，我還是建議能做出一些相應的對策。比如，如果吐糟大會還有時間，我建議大家能做一份“工作協議”，讓不同的角色各抒己見，相互監督，自我約束。

　　那么，工作協議是什么呢?我這里來拋個磚，下面就是我所帶的一個團隊的一份協議(工作協議隨時間推移應該是會有調整的)。

　　最后總結一下，敏捷很簡單，因為它僅僅是 “溝通，簡單，反饋，勇氣，尊重”的體現，同時敏捷也很不簡單，因為她要求大家做到“溝通，簡單，反饋，勇氣，尊重”。

　　敏捷，我們在路上。

原文轉自：http://www.anti-gravitydesign.com