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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

實現敏捷開發的條件

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

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

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

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

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

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

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

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

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

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

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

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

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

作者簡介


Advertisement

更多 iThome相關內容