傳統的軟體開發
摘錄至 Scrum Primer
http://www.scrumalliance.org/resources/339
傳統的軟體開發
不管是大型或小型的公司, 所使用的傳統建構軟體方式, 是眾所皆知的"瀑布式"開發方法, 也就是循序式的生命週期開發方式. 它雖然有很多變形存在(像是V-Model), 但是一般來說, 開始是詳細的規劃階段, 在這裡會把最終產品的內容詳細研究和設計, 並且將所有的細節都紀錄在文件中. 在執行任務時所需的設計都已經被確定, 所有的工作已利用甘特圖或是微軟Project等整理的井然有序. 團隊藉由加總每個人對於每個步驟的評估, 來得到整體開發所需要的時間. 一但利害關係人徹底檢視並且許可後, 團隊便開始工作. 團隊成員完成他所專門的部份, 然後再交個下一個人, 就像是生產線的形式來進行. 一但工作被完成, 它將交付給測試部門(有時候叫作品質保證部門), 讓產品在交給客戶前進行完整的測試. 在整個過程中, 所有計畫都被嚴格控制, 以避免有任有偏差, 讓產品是真的照當初所設計在生產.
這個方法有優點也有缺點. 它的最大好處是它相當有邏輯性 - 在建構之前先想清楚, 把它都紀錄下來, 照計劃行事, 確保每件事情都盡可能的有條理的. 不過它有一個很大的缺點: 人們會參與其中.
例如, 這個方法要求, 在開發週期的一開始, 就要把所有的想法都提出來, 這樣才能把它們都放進計畫中. 但是我們都知道, 好的想法在整個過程中都可能會出現 - 可能在最開始, 中間, 或有時候是再產品上市前一天. 若是一個流程不允許這樣的改變, 它將會抑制創新的產生. 在"瀑布式"開發流程中, 若是在開發後期才出現一個好的點子, 這並不是一件好事情, 而是一個凶兆.
"瀑布式"開發方法也強調把所有東西記錄下來, 當作是溝通重要資訊的最主要方法. 如果我能夠記越多我所想到的東西在紙上, 這將會很可靠地把它們傳遞給專案中其他成員, 這是非常合理的假設. 此外, 如果它記在紙上, 它將會是明確的証明, 告訴大家我已經完成我的工作了. 但是事實上, 在大多數情況下, 沒有人會讀這50頁左右的需求文件. 即使當他們有看這份文件, 誤解的情況可能更嚴重. 一份被記錄的文件只是我的想法的一部份, 當你閱讀這份資料, 你會產生出另外一種抽象概念出來, 可能和我這次真正的想法相差甚遠. 所以嚴重的誤解發生也就不足為奇了.
當人們參與其中時, 還會有一種狀況發生: 當你第一次實際使用產品, 在實際操作時所得到的滿足的感覺. 你會立即想到20種方法來讓產品可以做的更好. 不幸地, 這些非常有價值的想法通常會在產品開發末期產生, 這時候要改變會是非常困難並且有破壞性. 換句話說, 要做正確的事代價是非常昂貴的, 至少在當你在使用傳統的開發方法時是這樣的.
人們是無法預知未來的. 例如, 比賽結果通常是無法預期的. 不可預測的技術問題出現時, 會強迫你改變方向. 更近一來說, 人們不擅長對於不確定的事情, 做出長遠的計畫. 如果要你今天猜猜, 你未來八個月每週會怎樣工作, 你一定覺得這是一件空想的事情. 這也就是為什麼許多精心製作的甘特圖會失敗的原因.
此外, 循序式的生命週期開發方式會使得團隊成員, 在交接工作時產生敵對的關係. "他要求我建構一些不在規格上面的東西", "她總是改變心意", "我無法對一些我不能控制的東西負任何責任". 這些都會讓我們對於循序時開發有另一種思考 - 它非常沒有樂趣. 瀑布式模型是產品開發人員痛苦的根源, 它讓產品無法顯現出開發人員的創造力, 技能和他們的熱情. 開發人員並不是機器人, 這個流程把人們當作機器人看待, 這正是造成人們不快樂的原因.
一個僵化, 拒絕改變的流程, 只能做出二流的產品. 顧客可能會得到一開始他們所要求的(可能至少有一兩個需求被漏掉), 但是當他們看到產品後, 客戶會想這真的是他們所要的嗎? 在一開始收集所有的需求, 然後就把它們固定不變, 產品只能被宣告和當初想的一樣好; 而不是讓人們從經驗和探索中, 去讓產品更加完美.
許多循序式生命週期開發方式的實踐者, 一再遭遇到這些問題. 但是, 它看起來是這麼的有邏輯, 因此當遇到問題時的第一個反應是: "如果我們能把它運用的更好, 它就會是可行的" - 如果我們能規劃的更好, 紀錄的更詳盡, 不要改變得這麼多, 每件事情將會進行的很順利. 不幸地, 許多團隊只得到相反的結果: 他們越努力這樣嘗試, 情況反而越糟. 這還包括許多管理團隊投入他們的名聲和資源, 去改變這個和現實狀況不同的瀑布式開發模型, 這似乎是一開始就犯了很明顯的錯誤. Scrum完全不是這樣的作法的.....
留言列表
