敏捷的體質

在前文《主動積極的擁抱變化》一文中提到，軟體的改版週期愈來愈短，已經是大勢所趨了。

在過去，一個軟體的版本變化不會太快，相對而言是穩定的，但是，現在我們所接觸、開發的軟體，其新版本的釋出卻是愈來愈頻繁。即使是 Apple 的手持裝置作業系統 iOS，都持續以飛快的速度在改版著。更別提，進到 Web 2.0 時代的網站服務，或者是更迭迅速的行動應用程式了。

「改變」就是現在軟體的重要特質，許多開發者內心還是持續抗拒著改變，但事實上，改變是不可避免，甚至是不可或缺的。

舉例來說，你們的開發團隊釋出了一個App，收到了一些使用者的回饋意見，分析之後，覺得使用者說得有道理，而且影響還不少，你們會排到很久以後，才將這個回饋意見納入到你們的軟體裡，還是盡早安排呢？

如果你們觀察到市場的立即性變化，像是競爭對手推出了新功能，為了反應或是正面迎戰，有必要在自己的軟體也做一些加強或是變更，你會等到許久之後，還是盡快推出調整後的版本呢？

如果你想隨時隨著市場的變化、隨著你所收集來的使用者回饋，來調整你的服務或是產品，「持續的改變」顯然就是兵家常事了。

用敏捷開發來因應持續改變

當然，許多程式設計者打從心底厭惡規格的改變，在這前文中已經分析過了。但是，軟體規格的改變還是可以分為兩種，一種是沒有思考周詳，不是想的不夠完備之後才來修改，就是三心二意、今天要東、明天要西、後天又改回東來。而另一種則是為了持續調整，將方向更準確調整成更導向市場或是使用者的需求。

前者的改變是一個議題，需要制定規格的人檢討並留意。但後者所造成的改變，就如同我所說的，是「不可避免」、甚至是「不可或缺」的。所以，在前文中才會提醒，不要對所有的「改變」都抱持著負面的態度，「改變」也可能是更正面的想要做出更符合需求、更有競爭力產品的動力。

就如同這幾年以來，大家都很熱衷於討論、實踐所謂的「敏捷開發（Agile Development）」，這也是為什麼對於某些類型的應用開發，敏捷開發方法愈來愈受到歡迎，它的原因不是只是因為流行而已。

為什麼我們需要敏捷？敏捷就是希望可以快速移動，快速的調整方向。

為什麼敏捷的方法都會提倡「先射擊再瞄準」？有一個原因是希望更快的先透過軟體的釋出，收集到更多來自市場或是使用者的回饋，然後再接著調整，然後再立即發行。

每一次的調整，都讓軟體更接近目標，而快速的調整、小型的調整，可以降低每次收到回饋及做出反應的時間。

所以說，敏捷開發方法就是建立在軟體持續不斷改變的基礎上，而其中的許多方法和技巧，都是基於這個假設而來的。我也見過很愛談論敏捷方法卻痛恨軟體改變的人，然而，這似乎是相當矛盾的兩種情緒。

所以我在前文中才會鼓助要「主動積極的擁抱變化」，因為變化勢不可免，與其消極反抗、對立，不如積極的擁抱變化，將開發人員的心態、開發團隊的文化都調整成為主動迎接變化，同時，在開發方法還有開發技巧上，也都是以變化為前提。一個團隊若是從心態、文化面，到方法、流程、技術面，都調整成因應變化的，那麼，我覺得可以稱之為具備了「敏捷的體質」。

在心態上，需要開發團隊的成員都意識到，軟體即時隨著市場目標而持續動態改變，是有效獲得競爭力的方式之一。所以，「改變」就是開發的主軸之一。

當每個成員都能意識到這點，不再對必要的改變抱持著負面的想法或是抗拒，而是樂於接受改變，因為他們知道唯有透過持續不斷改變，才能夠讓軟體更貼近市場、也更貼近使用者。

「先射擊再瞄準」，雖然通常不會在第一次射擊就擊中目標，但是因為觀察到了彈著點，所以就可以估計下一發子彈的瞄準應該要修正多少偏差，才能擊中目標。

有時候，目標甚至是會變動的！也只有透過不斷觀察前一次的彈著點，接著做出調整、重新射擊，才能提高命中目標的準確度。

當每個成員都能具備這樣的心態時，團隊就容易建立起接受改變、能適應改變、甚至是善於利用改變的文化。

實現敏捷開發的條件

心理素質和文化的建立的是敏捷體質的基礎，在這個基礎上，可以進一步再發展開發方法、流程，以及技巧。

以設計技巧來說，如果你留意，就知道大家常提到、常運用到的「設計模式」，就是一套以「改變」為中心的想法。

我們甚至可以說，絕大多數的設計模式，都是為了因應改變而問世的。因為，會發生改變，所以，我們需要更容易擴充、更有彈性，以及更容易調整的設計方法。

設計模式的存在，不單只是為了要重複使用程式碼，更重要的是它要讓你的程式碼具備「敏捷」的特質。

舉例來說，如果你的程式碼從頭到尾目標都很明確，需求也都不會改變，你在你的程式碼裡使用 Factory 之類的設計模式，來允許客戶端程式碼獨立於某些「具體實作」的存在，同時允許你更換某些「具體實作」的方式，卻又不需要變更客戶端程式碼，有什麼太多的意義呢？尤其許多設計模式都會引入額外的間接層次，有時候使得程式碼看起來不那麼直接。如果需求十分確定，那為何要付出讓程式碼多出間接層次的代價呢？

在 Factory 的這個例子裡，為什麼希望客戶端程式碼和「具體實作」沒有相依性呢？

這當然是因為具體實作可能會變動，所以希望客戶端程式碼在具體實作變動時，不會因為存在相依性而受到影響。這麼一來，就可以隨著各種可能的情況，例如需求、可實作的時間容忍度、等等，來決定實作的細節。但無論如何，客戶端程式碼只要完成了，就不會再受到具體實作變化的影響。

如果你的實作很確定，永遠都不會再改變，那麼你是否需要使用 Factory 這個設計模式呢？

所以說，像設計模式這樣的設計方法，也都是為了因應「改變」，甚至是「持續不斷的改變」而存在的。

它讓設計者有機會持續隨著變化的發生，逐步演化自己的程式碼，而在每次演化的過程中，都不會付出太多的成本。

開發團隊想要建立敏捷的體質，除了成員要有能力運用能因應改變的設計方法，設計能因應改變的架構之外，在開發方法及流程也必須能夠對應。

在現在，很多人都會談敏捷的流程或方法，這就是一種好事。但是不要忘了，「敏捷」概念下的背後種種，都是環繞在「改變」這件事情上。

所以，技術面是一回事、流程方法面是一回事，都是必須以成員的心理層面及團隊文化層面去支持的。而不是只顧技術面、方法面，卻忽略了心理面、文化面，這樣往往不會收到更好的成效。在建立開發團隊的「敏捷體質」時，千萬不要忘了要同時從心理、文化層面著手。