[Agile/scrum] 擁抱改變

真害羞,動不動就擁抱。

但是在做軟體的時候,很難不改變的。先來說說傳統瀑布式開發的做法。

 Waterfall


在傳統的瀑布式開發法,一個專案會被切成需求分析、設計、開發、測試,有時候 前面還會加個cooking,後面測試又還有phase 1、phase 2等等,假設一開始,kickoff的時候,專案被估計是一年,可是最後總是會、常常會發現專案delay了,為什麼?大家指來指去,都怪他他他,所以delay了。

面對delay這件事,PMP會教:"抓buffer",於是一個stage就抓一個buffer,怎麼抓?怎麼決定buffer要抓多久?

                       "猜"

多感傷阿,一群受了這麼多教育的人,面對問題還是在猜。


Root cause


抓Buffer是一個消極的解法,真的的解法是找出問題,去解決、或至少面對真正的root cause。而真正的root cause是:需求改變了。

承認吧!在開發時程中,需求總是會改變,不知道為什麼,反正他就是會變,假如有公司有軟體專案開始到結案,需求都沒有改,那這間公司已經倒了。


Deal with it !!!


面對需求的改變,通常有兩種做法:


1. 用合約、spec來不讓改變發生

需求改變的時候,會發生三種現象:
  • 業務端會去跟客戶吵,"大家把合約攤開來看阿"
  • QA/RD/designer/architecturer也會去吵,"大家把spec拿出來看阿"
  • PM會被狗幹
整個團隊陷入一種不和諧的狀態,與客戶的關係也不會太好,在這樣的情況下,基本上,所有人都是抗拒的、不愉快的,要在這樣的情況下做出好的軟體無異是緣木求魚。

於 是,有人會說,一開始就要想得好一點、想得透徹一點,一切都想好,把所有變數都考慮進去,就妥當了。但這不是火鳳燎原,這種八奇是不存在的,就算有,他也 在google、facebook等等大公司上班了,不會龜在你的公司。相信我,假如在軟體專案裡面有人說,所有的事情我之前都想到了, 我都準備好了,那只是聽起來很安心,跟這樣的團隊成員合作,你104可以先開了。


2. 直球對決

既然會下雨,那你就帶雨傘阿。既然會改變,那就跟著改阿。於是,團隊的能力必須要提升到另外一個境界,程式必須要寫得很有彈性,當改變發生時,帶來的痛苦不 會太大。這很難嗎?其實也還好,真的把物件導向、design pattern學好、用好,就會比較不那麼痛苦了。其他人也是,要做出這些心態的改變,讓團隊是和諧的、快樂的。把專案交給一個有團隊的感覺的團隊,會比較容易成功的。




More on the Changes...


PM要注意,就算你的團隊是願意也可以接受改變、擁抱改變的,但每一次的改變,仍然要是讓專案更好的,而不是頤指氣使,也不是當兵時候的"左去右回、死老百姓阿?"維持團隊的士氣,在改變發生時是很重要的,這,老實說,真的是PM的責任。



 Conclusion


說了這麼多,改變既然一定會發生,就接受他吧;就跟之前寫的一樣,既然都會下雨了,你就帶個雨傘,享受一下浪漫的雨天吧。

留言