敏捷，其實很簡單
DevOpsDays 2021的會場，有個活動叫專家面對面好像(具體叫啥我忘了)，主要是讓與會者能夠和現場講師有更多互動。當天分享結束後，主辦單位請我去那坐一下(我當然也從善如流的照做了)，正當我回答完幾位學員的問題，準備離開的時候，有一位年紀比我稍長的先生坐了下來，有條不紊的介紹完自己的團隊與專案後，開口問了幾個問題。
其中，有一個很關鍵，大概是這樣的內容：『如果團隊手上非常多插單的情況，導致每個迭代都無法正常進行，這樣適合 run scrum嗎?』根據多年的經驗，這個問題肯定只是表象，背後一定有著其他沒說出來的狀況。
我想了想，反問他：『你們的迭代設定多長?』
『一周或兩周，每個團隊有點不同』他回答。
我疑惑的問：『所以用戶的需求等不及一周的時間? 非得立刻插單不可?』『因為都是一些非常嚴重bug，不立刻處理不行』他說
『那你們真正該面對的不是插單的問題，而是整個專案已經快失控了，這樣等於每天都在救火啊?』我看著他。
他有點不好意思的說：『的確是這樣的。』
『那我的建議會是…』我認真的回答他道：『你們應該停止任何新功能的開發，先把所有的bugs解決，然後找出系統架構上或開發上的核心問題，到底~是什麼原因導致系統bugs層出不窮? 先著手解決它，別讓團隊陷在持續救火的處境裡…』
如果團隊每天都必須救火，那不管你 run 什麼方法都是對專案沒有幫助的，敏捷或scrum的導入不會立刻改變團隊的體質，如果大家的習慣不改變，團隊面對的困境還是會持續僵在那裏。
『但是，如果不開發新功能，這樣專案就不會有進度了啊?』他似乎有些擔憂這個。
如果你不停止開發新功能，去面對團隊本該處理的核心問題，這樣你看到新功能的進度，也只是個假象，終有一天，層出不窮的bugs會在專案的後期吃掉你所有的進展，最終，你會無法交出任何一個功能給客戶。
『恩，我知道』他面有難色地回答。說完謝謝之後，就皺著眉頭離開了。
我知道他心裡的考量和難處。
回到根本，敏捷其實很簡單–就是務實的面對問題，努力交付出用戶真正可以用的軟體。但，在這世上，總是有很多事情，特別是技術面以外的事情，並非那麼的務實。有時候我們的思慮，可能還包含了人情、績效、政治…等等各種其他方面的考量。這時候，問題就被我們搞複雜了。
就如同我在DevOpsDays中說的，敏捷一直都很簡單，但讓一切複雜的，是人。如果我們把專案的成果建築在不穩固的基礎上，不管你的專案看似多麼地 on schedule， 一夕之間都有可能歸回無有。
相關課程：
敏捷開發專案管理與Azure DevOps實戰
https://www.studyhost.tw/NewCourses/ALM
留言