發表文章

目前顯示的是 2月, 2017的文章

the DevOps journey (1) - 敏捷開發不相信時程預測?

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

the DevOps journey (0) - 敏捷開發真和每個開發人員有關?

圖片
#不想看廢話,直接按這裡跳到重點 這年頭大多數人已經沒有耐心,已經很難看完一整篇長篇大論,因為這樣,這幾年我們寫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。 關於開發方法的重要性 身為一個以寫程式起家的開發人員,就一個軟體開發人員的生命週期來看,我算是到了很老的時候,才願意承認軟體專案/產品的開發過程中,最重要的可能不是開發技術,而是開發方法。 技術能力的強度,是進入軟體(專案/產品)開發領域的入場券,它就是一塊敲門磚,技術能力的強度,決定了你敲門的力道。然而一但當門打開,你開始了一個專案,進入了一個團隊,參與了一個產品的研發,技術能力對成果的影響力,可能就開始慢慢式微了。請注意, 個人技術能力可能會影響開發團隊產出的

asp.net Web開發框架 (8) - 使用krajee進行非同步檔案上傳

圖片
這一篇介紹 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的開發人