.NET Walker

這一篇，我們來討論敏捷開發中怎麼看待時程預估，以及迭代開發的重要性… 到底專案時程能不能預測? 這是一個常常困擾初踏入敏捷開發領域的新手的問題。 你一定聽到過有人說(甚至，其實 上一篇 推薦的Martin Fowler的文章中也提到過)，敏捷開發不太相信可以進行準確的時程預測，我特別用『預測』這個字，而非預估。中文很有意思，這兩個字很接近，但有那麼一點點的不同。 前面 提到過，既然真實世界裡面的 需求根本不可能固定 ，開發人員的素質(每個人每天的產出)也不太可能統一，那我們幾乎已經宣告無法掌握軟體開發專案中，最重要的兩個變因，那這樣怎麼可能精準的預測出開發時程呢? Martin Fowler在早期的文章中，幾乎是直接告訴你，預測是不可能的。 但這件事情非常弔詭，大概所有開發人員都明白，在需求不確定的狀況下，要精準的預測專案時程、計算出人天數，是幾近不可能的事情。但 好笑 有趣的地方就在於，幾乎所有的軟體專案的業務或PM，都會要求你在專案起始前，在一切模糊的前提下，估出人天數以便於 報價 。 壓在合約裡面的驗收日期和報價耶!? 難到不需要更詳細的資訊以便於精細計算嗎? 這是繼 上一篇 提到的軟體開發迷思之後，另一個超級經典、行之有年、卻嚴重違反常識/常理的軟體開發迷思。同樣的問題又來了，難道從來沒有人覺得哪裡怪怪的嗎? 我相信有，但你會碰到各種壓力，告訴你整個業界都是這樣幹的，你區區一個程式設計師想改變這個慣例? 不可能。 因此，開發人員只能習慣性的在時程預估裡面保留一些buffer，業務/PM報價時再加一些Buffer，然後客戶的採購砍一些作為折扣，done，成交。後面就看彼此的運氣了… 不能預估，怎麼辦? 這篇文章一開始的 那張圖 很貼切，它描繪出了理想狀況與真實世界之間的差異， 上一篇 說過，兩個軟體專案的需求不可能完全一樣，因為 完全一樣 你就根本不需要新的專案，買個套裝軟體或直接copy一份即可。因此，我們知道每一個軟體專案都是新的開始，既然是新的開始， 沒做過的事情要預估時間，這本來就是一種賭博 。 這也是軟體開發和工程專案差異很大的地方，傳統的工程專案施工較容易預估人天，因為施工方法固定，需求固定，常常只是在可以控制變因的狀況下，重新做一次而已，但軟體開發不是，每一個專案都是一場新的冒險。 我常開玩笑的跟業務說，你真要我這樣報

#不想看廢話，直接按這裡跳到重點 這年頭大多數人已經沒有耐心，已經很難看完一整篇長篇大論，因為這樣，這幾年我們寫blog的時候，幾乎都零零碎碎，這使得許多學員面對知識的掌握，也變得片片斷斷。 如果可以，我希望能夠把我們這幾年面對軟體開發方法，以及ALM/DevOps的一些經驗，有條理一點的整理出來，如果你有興趣，不妨嘗試慢慢的看看，如果實在已經不習慣看長篇文章，也可以挑有興趣的重點來讀。 開始一段新的旅程 這一系列的標題中有個字眼『journey』，第一次看到這個字…是在一場研討會，我忘了是TechEd還是Build，印象中研討會的主題是Metro Style App(現在應該不多人還記得這個名字了吧?)，主講人用journey這個字眼來描述學習一種技術的過程，我覺得真TxD的太貼切了… 不知道你有沒有發現，最近五年，軟體開發的潮流根本就是一場journey，而且非常像是我最愛的影集Star Trek Voyager中的旅程。你該怎麼形容這段旅程呢? 圖乎其來? 充滿意外? 不僅如此，大夥摸著石頭過河…似乎根本沒人能告訴你往哪個方向才是對的，你也不知道怎麼走才會到終點…這差不多就是這部影集當中的旅程。 若用來描述最近五年軟體開發技術的發展，根本是整個貼切到不行，而且從Web、前端、行動裝置、開發方法、框架…幾乎都逃不過這場journey魔咒，所有的技術都是 在途(on the road) ，一點都沒有發展成熟的跡象… 當然，如果旅程總是只為了看到終點倒也世俗了些，旅程的過程中還是有很多意外的小驚喜，以及足以令人回味的點滴，不管是你早已遺忘的Metro Style Application，或是充斥各種消耗型框架的所謂前端開發技術，又或者是我們要討論的這個主題 – ALM/DevOps。 關於開發方法的重要性 身為一個以寫程式起家的開發人員，就一個軟體開發人員的生命週期來看，我算是到了很老的時候，才願意承認軟體專案/產品的開發過程中，最重要的可能不是開發技術，而是開發方法。 技術能力的強度，是進入軟體(專案/產品)開發領域的入場券，它就是一塊敲門磚，技術能力的強度，決定了你敲門的力道。然而一但當門打開，你開始了一個專案，進入了一個團隊，參與了一個產品的研發，技術能力對成果的影響力，可能就開始慢慢式微了。請注意， 個人技術能力可能會影響開發團隊產出的

這一篇介紹 Bootstrap File Input 這個套件，之所以會被歸類到asp.net Web開發框架系列，是因為整個套件和我們採用asp.net走SPA架構(不管是用WebForms或WebAPI)都非常的速配。 檔案上傳範例 首先我們有一個範例位於 Github ，如果你想要測試，下載這個範例後，基本上已經擁有所有你需要的檔案。請使用Visual Studio運行index.html這個檔案(對，沒錯，是pure html5)，執行起來的畫面像是底下這樣: 這個套件精彩的地方是上傳預覽畫面，你會看到上圖中，它除了支援中文、多檔上傳、非同步上傳，還支援圖片預覽、Mp3檔案甚至可以撥放，會不會太誇張了點? 是的，人家就是支援…更不用說UI的部分很有誠意的原生支援正體中文(包含zh-TW的多國語言js)這也是我們使用此套件的原因之一。 如何使用 整個套件的使用可以完全採用AJAX方式(當然也支援傳統的submit/postback)，搭配我們的SPA架構非常之合拍，也因此，你在運行該範例的時候，會發現只需要執行index.html即可(當然伺服器端接收檔案的部分還是需要Server Code，這我們後面介紹ReceieveFile.aspx的時候再說明)。 如果你看index.html，會發現程式碼如下: 我們先看55行的部分，這是定義一個Input標記，其中的multiple意味著支援多檔上傳，data-show-preview="true"則是支援顯示預覽視窗。當然這些設定都可以在後面透過js來更動。 而66行javaScript所呼叫到32行的setupFileUploadBox()，就是進行相關的設定，其中language: 'zh-TW' 指定了多語UI採用中文(請留意這也是我們在19行引用了locales/zh-TW.js的原因)，而後面幾個參數應該不需要太多解釋，showUpload是顯示上傳按鈕，uploadAsync說明了採用非同步上傳，maxFileCount指定了檔案上傳上限。 比較重要的是uploadUrl，這個參數指定了非同步檔案上傳的接收位置，由於這個範例採用WebForms，因此我們指定ReceieveFile.aspx，這部分我們待會後面介紹。(我覺得熟悉WebAPI的開發人