開放空間會議雜記 II : 在敏捷開發中, 架構設計和工程實務要要怎麼玩 @ David Ko的學習之旅

只隔了 5 天, 我在台北又利用開放空間會議的方式, 進行了一次討論. 有趣的是, 不同主題和不同的參與者, 發生了一些我意想不到的狀況, 趁著記憶猶新, 趕快把它給記錄下來.

這次討論的題目是: "在敏捷開發中, 架構設計和工程實務要要怎麼玩”. 也就是說, 我們這次把注意力集中在軟體開發的實作方面. 像是 TDD 要如何進行, CI 有什麼工具可以使用, 或者是 story 要如何拆解, 架構設計要如何演進. 因此, 是很道道地地工程師會有興趣的主題.

觀察到的事情

1. 在提討論問題 (topic) 時, 雖然有不少人提, 但是開始討論後, 卻只有少數題目受到青睞. 導致剩下不少題目, 並且每組討論人數變多. 有可能是大家看到更好的題目, 所以放棄自己想要討論的題目. 也有可能是大家怕自己的題目沒人來, 所以就直接往人多的地方走. 原因是什麼, 我不知道. 但是覺得還蠻有趣的

2. 要準備一些食物. 基本上專心討論是很花時間的, 中途需要補充零食, 才會有體力進行下去.

3. 有些題目, 如果自己沒有基本常識, 進去討論時容易覺得有聽沒有懂. 不過, 這時候可能就要用力問, 至少可以得到一些線索, 讓之後回去, 可以知道要從哪邊開始.

4. 如果參與的人越多元, 聽到的經驗會越不同, 但是沒有一招能夠治百病, 你需要因時因地制宜. 不過, 即使沒有一招能夠打片天下無敵手, 但是在些不同做法中, 你還是可以得到一些解決問題的靈感.

5. 雖然可以得到不少經驗分享, 但是如果參與討論的人都是不太懂的人, 這樣得到的分享, 可能需要再次確認. XDD

6. 這次討論的重點在 engineering practice, 但是最後都集中在人的思維, 以及組織結構僵化的場景. 流程可以學習, TDD 可以被教會, 但是人心是很難轉換的. 畢竟, 江山易改, 本性難移.

要學會 Scrum 或是 TDD, 不一定很難學會, 外頭有很多很棒的老師, 並且也有很多精彩的書籍可以參考. 但是人或是組織的問題, 是需要我們自己去面對的.

教練或是名作者大多是獨立顧問, 不見得有經歷我們所遭遇的痛苦. 即使有, 也可能只是旁觀者的角色. 看別人做容易, 但是自己下海後就完全是兩件事. 有時候還可能只是念過書, 並沒有實際落實的經驗.

我們都知道, 導入新作法, 其實就是在做變革管理. 強迫通常沒有好結果, 需要透過一些 soft skill, 像是引導或是教練輔導等等來進行. 因此, Agile meetup 曾經辦過一次討論會 (當敏捷遇上引導：在領導團隊變革遭遇什麼困難), 收集了大家導入時遇到的一些問題, 希望可以從中規劃出些課程或是活動, 來幫助我們去減輕那些問題. 請大家耐心等待吧 XDD