維運工作對開發團隊的 impact
Ruddy 老師今天轉頭來問我這題。
最近 devops 好流行，我們的團隊也把開發跟維運慢慢地交給同一個 feature team 做，可是就會有個問題出現啦～Code 越寫越多，要維運的東西也越來越多，可是工程師們開發能量有限，維運的多了，開發的就少了，開發速度就慢了。
所以一天一天就會變成這樣：
然後很多人就會覺得很不舒服，因為之前一個
sprint 都可以衝那麼快，現在可能只剩下一半的速率了。為什麼會這樣呢？我覺得可能的原因是技術債、新的語言與框架的引入、系統上線後 User
與市場的反應等等。
當然，我們敏捷的人是歡迎這些改變的，但速率的降低與解線上那些有的沒有的雜事，會讓人很不好受，我說的不只是管理者（PO or
PM），工程師們自己也不好受。
所以怎麼辦呢？
或許在某個時候整個改寫、重寫是不錯的作法：像是 Dropbox 的這個故事：
可是約耳趣談軟體說千萬不要重寫啊：
其實該問的問題是，什麼時候是重寫的好時機？我跟老師討論後，或許這個時機不錯：
公司可能用原本的 MVP 跌跌撞撞的上線了，賺到了一點錢，或是拿到了投資，或許在這個時候，我們可以重寫系統，因為這時候的資源比較多、氣氛也比較好？ XDDD
說真的，我也不喜歡重寫，我也覺得應該要一直一直 refactor，調整架構，敏捷地往前走。有的時候，真的可以用 refactor 撐著，但有的時候，就是真的手上的 code 已經不足以符合新的需求，只好重寫。
所以，這時候更考驗團隊的經驗了，評估一下這個系統的 life cycle，撐得住就撐，撐不住就真的別硬撐了，趕快開始改寫，挖出一塊來，成為一個 micro service 之類的，讓系統跟團隊能承受更高的挑戰。
最後，我知道還是很多人對開發速度很糾結，我還是畫個 CLD 來分析好了：
就是個簡單的 B 迴圈，意思是，假如真的是自己的 code 自己維運，沒有別人幫忙的話，開發速率跟維運的比例最終會達到平衡，那就是你的團隊的速度。
要認清事實：之前的開發的很爽的速度，是假的。
留言
張貼留言