笑談軟體工程 – 敏捷開發的逆襲,經實生產,減少不必要的浪費

本書作者Teddy在書中提到軟體開發中的浪費可以歸類成以下七種:

  1. 半成品
  2. 多餘功能
  3. 重複學習
  4. 交接
  5. 工做切換
  6. 延遲
  7. 缺陷

 

以下僅為個人讀書心得,參雜書中內容,若有版權問題懇請回復修正Orz。

半成品

記得在開發案子的過程中,總會有那麼幾次機會因為B需求比A需求來的趕而插隊先做,然後A就變成了半成品躺在那,當B需求完成實得知A工能暫時不需要完成了,久而久之,專案當中就放了幾個連我自己都不知道能不能動的東西在那邊,人懶了時間久了,也忘記它到底能不能被移除。

書中舉了一個有趣的例子:「傳統的開發方式,會用一本厚厚的『需求分析書』來寫使用者案例之類的,假設總共有100個使用者案例,若每一個開發周期(Maybe 兩週)只能完成3個使用者案例,半年過去了,總共也只完成了36個使用者案例,那剩下的64個已經放了半年了,這些使用案例難道不會因為時間的演進需求改變而不值得信賴嗎?」,也就是說,傳統的開發方式就會讓這本「需求分析書」總是處於「半成品」的狀態無法完成,在某種程度上也會是一種浪費。

多餘功能

多餘工能這個錯誤對我來說好像也曾經犯過,我總會想著要「未雨綢繆」,不過在上一次月會當中我改變了我的想法,多做一些不符合需求的事情或打算其實不一定會對專案帶來什麼好處,反而可能會造成隱藏的半成品。

在這個章節裡看的一段也讓我對軟體工程與系統分析上的謬誤有點釋懷,在學校裡系統分析課程教我們應該要在軟體開發前做一連串詳盡的分析,但在軟體開發的過程當中需求一直在變絕對是不變的真理,做太多的事前設計就變成了「食之無味,去之可惜」的東西。

那到底該怎麼辦?軟體的架構要越改越好是需要一點一點慢慢演進的,不會一次就做到最好,而是要「頻繁的與使用者做互動,得到回饋後不斷的修正演進」,並且搭配一些軟體工程實務如:自動化測試、持續整合、重構等等方式來維持軟體之品質與維護性(不然有很大的機會會把程式碼越改越爛的XD)。

重複學習

進公司工作後,前輩耳提面命的告訴我,自己試可以,但一旦發現苗頭不對之後就趕快站起來問,原因在於,我們遇到的大問題,或許前輩早已對它瞭若指掌,僅需三分鐘就能化解自己的心頭之恨…,但因為自己的堅持則會花太多時間在重新學習一件事情上。已前的我或許就很愛什麼都自己鑽研出來,後來發現,透過這樣的方式跟前輩學習,不僅我自己一樣能學會,而且還能解省軟體開發上所花費的冗於時間。

另外就可以談談Coding style 與standard 的問題,當程式碼的可讀性與一致性不好的時候,整個團隊的人則會花額外的時間去看懂自己在寫什麼(儘管你以為分工夠細不會害到別人,但實務上總是一直害到別人…),我覺得這也是另一種重複學習。

交接

我自己覺得交接這件事情跟重複學習很像,你教導另一個人學會你負責的部分也是一種額外學習,並且想想看超級比一比這種遊戲,經過兩三個人之後,最後一個人對原本功能的人之可能會與原作者大相逕庭。

所以在專案當中,不一定要只專注於自己的問題,對整個專案做全盤的了解,將會降低在交接時的成本(因為自己懂,根本不需要交接是吧)。

工作切換

工作切換這檔事,似乎早已發生在學生們的身上,我們要上課、打工、接案、運動…各種各式各樣的活動切換來切換去的,可想而知每一件事的效益會下降多少吧?若要說你還是很厲害能全面掌握,那我相信這樣的人單獨作一件事情的時候可以獲得的效益可能會在更高一點。

以公司層面來說好了,公司可能同時有兩三個案子在跑,其中有一個是維護令外的事開發,老闆可能會希望我們遊走在這些專案當中,但我們要「熱機」到可以在某一個專案跑的狀態可能都需要花一些額外的時間來熟悉一下,想像一下你可能兩個月沒打保齡球是不是需要先打個三五場熱身一下找找手感。

延遲

做什麼事情好像都在等待,等待上頭答應、等UI畫好、等夥伴有空…,等這些有的沒的,都會讓我們花費太多額外的時間,後來發現,當開發方式改變之後真的可以省下蠻多時間的,例如說:你跟你的夥伴頻繁可以近距離的溝通,這樣就不用在開會時再提出,專案既不會延宕也可以順利進行。

另一種延遲則是開發環境這種東西,我的老舊筆電其實還蠻好用的,只可惜在進公司跑專案才發現,一次完整的建置與自動產生程式碼竟然要花掉我十五分鐘,換了新電腦之後,一樣的事情我可以省掉一半超過的時間,在每一次編譯的動作都省下一分鐘來看,一天最至少可以省下一個小時在等待上,這種高效益的投資真的在好不過阿XD。

缺陷

最後講的大概是軟體的BUG吧,缺陷會引發上述六種浪費的其中五種,我們為了修復缺陷,我們必須要想辦法找出問題點在哪,這是一種「額外學習」,結果發現這個功能當初負責的人可能不是你,但你卻又臨危受命要把他修好,則又會產生「交接」,手邊的工作沒做完卻又要停下來修好這個BUG,就產生了「工做切換」,也因為這個BUG,產品沒辦法順利release ,就產生了一種「延遲」,最後這東西就變成了一種「半成品」。

好,知道BUG有多可怕了嗎XD,減少BUG數量手段有很多,最基本的可能是測試(我也好想學好想做阿),再來就是Code review,我們常常看不到自己的Code寫的好不好,但是若團隊中有人可以重複確認自己的code是否有問題,既可以維持Coding style,也可以幫忙找出邏輯上的錯誤,進而提升軟體品質減少BUG。

 

總結

自己也是軟體開發的新手,能夠變得更好的事情都好想嘗試,以前看這類型的書與文章都不會有太多的感受,直到接過專案、到公司上班後才發現,這些事情對我來說有多麼貼近…XD,書還沒有讀完,目前為止幾乎是每一章每一節都刺重我心阿…希望可以慢慢的從自己改變起,改善自己產出的軟體品質。

 

Reference

好書推薦 –笑談軟體工程 – 敏捷開發的逆襲