再一次，我就不會走向這樣的結局

物品總有保存期限，時間到了就無法再使用，時間有限且一去不回的情況下，我們必須做出當下所能做出的決定。

我們在同個時間只能使用一條牙膏跟一隻牙刷，所以當下能得到的物品理論上是沒有辦法一直增加的。

在前幾篇文章中談到當同類型物件變多之後該怎麼進行分類和管理。

當物件還是過多時，就是回到需求面來看，學會選擇才能從源頭就減少物品，該評估自己擁有的物件到底是好或不好並練習選擇開源的套件。

如果想等到事情全部做完才叫成功，那大概永遠不會成功，我們總是會需要在還沒準備好的時候就做出當下最好的決定。

時間限制

在軟體開發領域，有些事情就是注定要花那麼久的時間。

一名女性可以九個月懷胎生下一個小孩，但一次找到九個女性，她們也無法在一個月內生出一個小孩
人月神話

人生有限，決定是不是要跟另外一半結婚生小孩就需要在有限的時間內思考，需要在某個時間點之前就做決定。

時間限制是軟體開發中最常見的限制

• 專案交付日期: 老闆說我就要
• 市場競爭: 30 年後才完成的無名小站，還有人要使用嗎
• 法定期限: 2020 全台最大線上遊戲盤中零股上線啦
• 市場機會: 疫情當下就是需要的口罩地圖
• 突發事件: 個資外洩中，帳戶資料堪憂
• 資金限制: 半年內需要達到損益兩平不然就要回家吃自己
• 年度目標: 每年打考績的遊戲又要開始啦
• 行業趨勢: 預計 2018 完成 7nm 量產

不管是什麼樣的原因，開發者必須在預定的時間內完成項目，就像是生活中擔心可能會因為年紀到了生不出小孩，也可能是擔心當你 40 歲的時候小孩還在念幼稚園，會出現照顧上的無力。

漸漸的開發方式就演變成常見的隕石式開發或是敏(加)捷(班)式開發。

隕石式開發 (Meteor Development)

隕石式開發是一種大家常見的軟體開發方法，原則上是強調老闆的重要性。

這種方法的名稱暗示了像隕石一樣快速撞擊目標，然後再迅速調整方向。

隕石式開發的特點：客戶或老闆在開發過程中提出新的需求或更改需求

開發的過程中我們仍舊會需要大量的測試，不過能做的就是盡可能利用現有的函式庫、框架來減少開發時間，行有餘力的話就導入自動化的測試來減少人為的疏忽和節省後期修復問題的時間。

敏捷式開發 (Agile Development)

如 Scrum 或 Kanban 大多強調持續交付和迭代開發，並在開發的過程中調整和優化，過程中需要有效的時間管理、不斷的定期檢討優化開發流程，透過短週期的改進來減少浪費，並透過定期的里程碑的制定來確保專案按時完成。

總之，軟體開發中的限制和期限是常態，但可以通過有效的計劃、管理和技術選擇來克服，通過調整任務優先順序、自動化測試等等方式，團隊可以練習在有限的時間和資源內提高生產力並交付高品質的軟體。