趁休假把系列文嗑完。今天要轉貼是和昨天同樣在「敏捷聖徒」系列的這篇：
「我們不交付大便」– 談開發步調與質疑成長 - Kuma

這篇文章先從一位估算很準朋友的故事開始說起，並帶到了估算的要點：持續而穩定的步調

各位有聽過 PDCA Cycle 嗎？這是指我們要完成一件事的四個流程：

  • Plan：計劃
  • Do：做
  • Check：檢查
  • Act：行動（指改善行動）

說穿了，敏捷開發從頭到尾其實是一個快速而持續的 PDCA 的過程。我們把一個很大的長期產品切割成一塊一塊的小部分，每個小部分做完的時候都回頭去看產品新的樣貌，並且決定下一個小部分要做什麼，什麼東西要加進來、什麼東西要丟掉，什麼事是我們這次沒做好，下次可以改善的。

而這組 PDCA 的過程，背後重視的是開發者的軟實力，例如說溝通能力，或是紀律：

Kent Beck 曾經說：「我不是一個很優秀的開發者，而我是一個還不錯的開發者，但有非常好的紀律。」

這些敏捷開發的框架，例如含 Scrum、看板、Extreme Programming 等等，他們強調的都是個人的紀律、團隊成員間的紀律、團隊對外的紀律，都沒有在強調硬實力。

你從來不會在任何一個敏捷開發的書或文章裡面看到資料結構、演算法、計算機系統，或網路底層原理。 為什麼？因為要完成你的工作，你本來就需要這些東西。就算別人不講，你不會的話本來就做不到。

敏捷開發想要做的事情其實是：在你開發時，把其它一些能夠阻礙你的外部因素全部排除掉，讓你能夠專心的發揮你原本就擁有的硬實力，進而助你取得持續而穩定的步調。

每當你違反開發人員的軟體紀律的時候，你交付出來的東西都是大便。

那如果我們沒有持續而穩定的步調，或是沒有把這些紀律落實呢？那麼我們也許就會把軟體弄得硬硬的(?)：

敏捷開發、軟體重構、單元測試、整合測試等，這些方法都不會幫助你提升硬實力，你寫程式的速度也不會變快，但是這些事情如果做得好，你的軟體每次的改動範圍都會跟你的需求的大小成正比。

什麼意思？你有沒有遇過一個情況：當客戶請你改一點點小東西，但是你實際上程式內部的改動卻會很大？ 如果有，這很有可能代表你前面的這些軟體紀律的事情沒有做的很好，你才會因為一個改動需求而不得不修改很大的範圍。

身為軟體工程師，當我們想要對 Stakeholder 提出一個反駁叫做「這個改動很大，我們很難做」的時候，我們其實應該要檢討自己，是否我已經把軟體給做硬了。

這篇文章後半段還延伸了 DoD（Definition of Done, 完成的定義）和團隊應該先穩定再擴大的議題

但對我這個初階菜鳥而言，上面引用的這些因為軟實力（沒有紀律、不寫測試）而影響生產力、甚至降低程式碼品質的部份更有感觸，也開始反思我是不是常常把軟體弄得緊繃僵硬。所以決定把這篇抽出來做為今天的轉貼，分享給大家。

那麼，今天的轉貼就到這邊，明天見～