雜談出了什麼問題

常常會因為這些事情而失眠,所以乾脆來整理一下好了。

簡單的數學

排時程就是簡單的數學,完成日期與工作就是零合遊戲,一個trade off。當完成日期提前,意思就是工作(規格)要縮減。反過來增加規格,時程就會延後。這數學太簡單到怎麼可能有人看不懂。如果能在增加規格的情況下,還能如期或是提早完成,那肯定有幾種可能

  1. 時程估計有誤,沒有人不犯錯的,時程的估計也有可能會犯錯。
  2. 有潛在的問題,一定有偷工減料,或是驗收不實。
  3. 有外援,也就是除了延長時間,減少規格之外的第三種方式,加人。

效能與架構的複雜度

效能並非一日造成的,多半是很多程式碼堆疊在一起之後造成整體的效能低落。

架構的複雜度也相同,多半是一次又一次用偷懶的心態或是快速不顧品質的時程疊家之後就造成一個複雜的架構。這樣的架構多半代表未來維護的困難,以及在修改規格之後造成潛在的bug。

這兩種問題的形成都是來自相同的原因,只顧眼前,然後造成未來更多的問題。

而當每次規格"決定要"修改的時候(不管有沒有通知主程式也就是我),主程式提出反對的意見時,大部分都被忽略。也就是規格要改,可能會有一定程度的風險,不管,就是要改。

什麼叫做錯的決定

專案進行中會遇到很多二選一,大部分是

  1. 很快解決現在的問題,可是會造成未來更大的難關。
  2. 無法很快(必須花點時間)解決現在的問題,可是未來可以減少類似情況發生。

人在恐懼,怨恨,競爭,日常運作,時程的壓力,甚至是貪婪的引誘下就會做出那個錯誤的決定。

重要與緊急的迷思其實大家都聽過,只是真正發生在自己身上的時候總是不覺得自己就是那個倒楣鬼。

製程

製程(開發的規範)有一定的節奏

設計-審核-開發-測試-回報-修改-再測試

打亂或是沒有完成這個節奏就會造成有東西無法追蹤了。

規格修改的流程則是

設計-審核-開發-討論規格-討論時程-寫入規格-開發

沒有完成這個流程多半專案的時程都會失控。

要不要預留規格修改的時間

不要,但是總時程要有預備時間。

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s