close
首先來個有點長的前言
我覺得開發自己的專案比工作的專案有意思多了
一般工作的專案會有許多問題:
.通常不太合理的時程壓力
.不適任的隊長或隊友
.通常不太合理的時程壓力
.不適任的隊長或隊友
開發自己想做的專案則自由多了
主要問題是:
.沒有錢
.通常是自己全包
主要問題是:
.沒有錢
.通常是自己全包
沒有錢就少了一種動力,工作的專案雖然無趣,甚至常常很坑,但正常是會有錢拿的。
我目前為止自己個人開發的系統就兩個
第一個後來無限期停工
當初目的主要是想實現自己的物件導向設計觀念
我當初想要的的確實現出來了
但是系統本身並不是為了能夠滿足使用上需求
使得開發的動機不足,最後就停工
我目前為止自己個人開發的系統就兩個
第一個後來無限期停工
當初目的主要是想實現自己的物件導向設計觀念
我當初想要的的確實現出來了
但是系統本身並不是為了能夠滿足使用上需求
使得開發的動機不足,最後就停工
第二個還在進行中
我開發的是自己想用的系統,也就是我本篇想描述的故事
我開發的是自己想用的系統,也就是我本篇想描述的故事
我以前因為工作使用過一個公司員工寫的工具程式,某些方面上很不錯,但設計上有些問題
1.輸入很不方便
2.彈性不足
1.輸入很不方便
2.彈性不足
所以我想自己也來寫寫看,一開始有幾個問題:
1.輸入介面打算用web,技術上有些難度,很難先想好要怎麼實作
2.我打算使用跟別人的程式不同的技術來實現,這也帶來些未知數
3.需求只是個方向,並不明確,就算先寫好規格,很可能也會大幅度變動
4.按照過去經驗,開發只憑著個人興趣為動力,如果開發時間太久才能有能用的系統,很可能中途就沒動力停工
1.輸入介面打算用web,技術上有些難度,很難先想好要怎麼實作
2.我打算使用跟別人的程式不同的技術來實現,這也帶來些未知數
3.需求只是個方向,並不明確,就算先寫好規格,很可能也會大幅度變動
4.按照過去經驗,開發只憑著個人興趣為動力,如果開發時間太久才能有能用的系統,很可能中途就沒動力停工
最後我選擇採取類似敏捷式的作法,每次就以一個需求為目標來達成
達成過程中會想到其他需求,就先列入待辦事項
達成後再從待辦事項中找出下一個目標
如果發現目標卡在別的需求未完成,才先更換目標
達成過程中會想到其他需求,就先列入待辦事項
達成後再從待辦事項中找出下一個目標
如果發現目標卡在別的需求未完成,才先更換目標
這做法的問題在於時程很難控制
過程中我一直重構與抽出共用
如果我不這樣做,之後會是很大的技術災難
過程中我一直重構與抽出共用
如果我不這樣做,之後會是很大的技術災難
開發出來的程式是可以使用與滿足我的部分需求
並沒有開發出來不是自己要的東西的問題(只是能滿足的需求還不值得花費的時間)
但如果實際工作採取這種做法,那就糟糕了
一般工作的專案很講究時程的,控制不住時程是很難被接受的
並沒有開發出來不是自己要的東西的問題(只是能滿足的需求還不值得花費的時間)
但如果實際工作採取這種做法,那就糟糕了
一般工作的專案很講究時程的,控制不住時程是很難被接受的
一般開發還有另一種做法,就是先規劃與設計,然後再開發
如果能夠先規劃與設計好的話
因為最後會做的事情已經大部分都在計畫之中,所以時程就能與預估相差不大
很多公司都採取此做法
我不用的原因是我清楚知道自己無法先規劃好
而實務上,規劃的人也常常沒辦法規劃好,但情況就是得規劃與設計
最後...隨便找個軟體設計師應該都能告訴你結果可以有多慘
如果能夠先規劃與設計好的話
因為最後會做的事情已經大部分都在計畫之中,所以時程就能與預估相差不大
很多公司都採取此做法
我不用的原因是我清楚知道自己無法先規劃好
而實務上,規劃的人也常常沒辦法規劃好,但情況就是得規劃與設計
最後...隨便找個軟體設計師應該都能告訴你結果可以有多慘
全站熱搜
留言列表