發表文章

目前顯示的是有「敏捷開發」標籤的文章

導入敏捷最難的是什麼?

圖片
『導入敏捷最難的是什麼?』上課時同學這麼問。 『這問題,我可是很有經驗呢。』我心裡這麼想著,然後慢慢的回答… 導入敏捷最難的是…『組織總想在其他條件都不改變的狀況下,實現敏捷轉型。』 我常說:『人人擁抱敏捷,但真實狀況是…沒人想要改變。』 你說,不會啊,我們公司常常改變! 老闆總是朝令夕改…搞的大家無所適從。 我笑著說:『是啊,那是他改變你,不是改變他自己。況且,你不是也不喜歡別人常常改你的工作模式…對吧?』 總之組織從上到下,沒人喜歡『被改變』。 所以,導入敏捷當然可以…但,不能碰KPI、不能違反ISO、不能調整考績與獎金制度、不能改變合約簽訂方式、不能變更HR既定規則、不能調整休假與簽核流程、不能違反愚蠢的勞基法規法條、不能取消既有的公司會議(不管多麼無效)、不能改變組織結構、不能拆分部門與團隊…在所有外界環境都不改變的狀況下,要我們協助導入敏捷…幹的好。 這不是『難』,這根本是『為難』。 但我得說,這才是企業轉型的真實狀況。有興趣『談』轉型的老闆很多,有膽量豁出去的可算是鳳毛麟角,除非… 『除非什麼?』學生問。 除非…那公司差不多快掛了,死馬當活馬醫,這時候老闆可能會破釜沉舟,孤注一擲。但也往往能帶來最好的成效。 這也是大家常常看到,新創和小公司比較容易導入敏捷的關係。在大概超過百人左右的組織中,即便想要在一個小部門中導入敏捷,都很容易碰到與企業規範衝突的問題。 要知道,你可是在跟整個組織既有的習慣和文化對著幹,後台不夠硬,身段不夠軟,導入到最後,往往沒能改變組織,先陣亡的會是你自己。 『那怎麼辦?』另一位學員問。 『看起來很難,但也不是沒辦法。』我說『先準備好自己,別聽到台上講的精彩,一股熱血就勇往直前。也別亂找顧問,敏捷轉型不是小事。要幫企業實踐轉型,得長時間陪著企業一步步解決問題,身為顧問,你要非常清楚每一個工具、每一個activity想達成的目的,然後幫助企業選擇最適合的方式,量身訂做,趨吉避凶。』 好啦,先上課吧。先搞懂Scrum每一個角色和活動的意義,到時…才能真的幫上企業實現轉型。

Azure DevOps in Action - 透過 Fork 實現 InnerSource

圖片
Fork在Github中是常見的功能,使用的情境大多是我們想修改或學習他人的程式碼時。只要我們有權限,就可以Fork他人的Repos到自己的帳號底下。Fork和Clone不同,Fork可以追朔到來源的Repo,讓新建立的Repo與來源之間有所連結。 對於開源的open source專案來說,Fork是很有意義的功能,但對於企業來說也有需要嗎? 有的。 這幾年企業內部盛行InnerSource [1] 的觀念,過去企業常常把source code視為不可觸碰的機密,甚至要求source code不可離開Lab(或特定部門)。在那個年代,你可能在某大型軟體公司工作了好幾年,卻還是看不到與自己部門(所開發的產品)無關的其他系統的任何一行程式碼。 但,現在時代不同了。 近年來,開發人員(和他們的主管)明顯地發現了open source所帶來的價值。同時,對於程式碼的安全性與開發規範也日漸成熟(如今,上道的程式設計師幾乎都懂得機密資料不該寫死在程式碼中),這使得企業也開始對於程式碼的開放不再感到懼怕。因此也在對企業內部員工開放程式碼後,獲取了很多前所未有的好處。 最顯著的好處是,員工可以透過檢視同事的程式碼進而學習和成長,回顧你自己過去的學習經驗,你會發現,其實大部分的程式設計師,都是透過 看別人的程式碼 來學習的(而非單單只是看書、上課、或是自學)。一旦停止觀摩,開發人員的成長就遇到瓶頸了,也就是說,觀摩其他人寫的程式碼,可以說是最好的學習方式(沒有之一)。 如果你覺得這沒什麼,認為讓員工成長這種事情對企業也沒啥好處,那你可以再反過來想。當企業內的所有開發人員,都知道自己的程式碼有可能會被其他人檢視(review)時,對於一個稍有廉恥心的開發人員來說,這是一個很大的提醒。當企業內培養出這個文化之後,大部分有自尊心的開發人員,都會在簽入程式碼之前,再看一下有沒有不該出現的code,以及是否有因為偷懶或取巧而品質不佳的程式碼。這使得軟體開發人員無形中更加的謹慎,對程式碼的自我要求將提高,而不只是 讓程式能動就好 。久而久之一旦養成習慣,在無形之間也提升了程式碼品質。 還有另一個典型的情境,也非常有價值。 近代的軟體開發往往是基於組件或套件的重用,在企業內也是,我們常常會用到他人所撰寫的套件或工具,這可以讓開發速度和時程加快,同時也提高重用性(提高重用性就是意謂著降低成本,切記)...

軟體開發的改變、困境、與挑戰

圖片
你一定看過底下這張圖,對吧。我得先說,這可能不是一篇政治正確的文章... 但我還是歡迎大家補充自己的看法... 有次上課時,有位擔任主管的學員在課程休息時間問我:『到底DevOps能對公司帶來什麼價值?(翻成白話就是…它真的有用嗎?)』這問題看起來不難回答,我腦袋裡立刻蹦出一堆答案,但…我要如何在30秒到1分鐘的時間內,讓學員有個本質上的概念呢? 前陣子我一直在思考這個問題,剛好這時候,我在FB上看到朋友貼來的一張圖,我猜你肯定也看過。 後來這張圖還出現了好幾個版本,基本上目的都一樣,就是揶揄客戶的不講理。也的確,這世界上沒有白吃的午餐,軟體開發和商業設計很像,同時要快、要好、又要便宜,天底下哪有這種好事? 正當我也想轉貼出去的時候,突然轉念一想,難道真的沒有可能讓成品的交付 又快、又好、又便宜 ? 如果有呢? 那實現出這個成果的企業,豈不是能夠領先其他競爭者一大截? 而且,如果這件事那麼不合理,為何幾乎每一個客戶都這麼要求呢? 甚至包含我自己。 前陣子我在印製一批教材的時候,我對印刷廠的要求似乎也是這麼的『不合理』,我希望它印製成本要低、品質當然不能拙劣、關鍵在於速度,由於訓練課程即將開始,我希望三天內可以完成…,回頭一想,我自己不就是那個傳說中的奧客嗎? 結果呢? 結果印刷廠還真的完成了(使命必達!)。不是應該不存在嗎? 為何印刷廠實現了這件事呢? 我不知道他們怎麼做到的,但我回想最近這十年印製教材的經驗,我發現,比起十年前,現在確實是又快、又便宜、品質也好上了一大截。是怎麼回事? 如何讓理當『不存在』的事情發生的? 這部份就不難理解了,我想是因為『產業升級』。最近這十年客製化小量印刷的技術不斷更迭(當然也是拜IT技術所賜),許多只有一兩個員工的小印製店,靠著電腦和幾台印刷設備,就可以印製出媲美印刷大廠的成品品質,印製時間和成本還來的更低。 產業升級 ,讓過去被視為 不存在 的交集點發生了。 而DevOps根本就是軟體開發領域在最近十年中最大的『產業升級』。在DevOps中我們強調頻繁交付(速度要快)、我們強調程式碼自動測試、在CI/CD Pipeline中的系統安全弱點掃描(品質要好)、我們強調減少浪費、讓開發成本有機會可以降低(要便宜),我們不正就是在實現過去認為不可能的事情嗎? 面對全球化的競爭,許多廠商正在改變,改變的不只是觀念思維,也包含開發方法、技術...

Improvise

圖片
今天在改一個以前自己寫的系統。 愈改愈覺得,當初怎麼會這樣設計的? 很多寫法實在看不下去,只好重構一番,把過去的一些設計和架構做些調整和改善。我猜,只要你是職業(不需要是專業)的開發者,肯定也曾有過這樣的經驗。 我們常常覺得過去的東西似乎還有可以改善的空間,所以,系統就這樣在修修補補之中度日。 曾經我覺得這樣子不行,所以花了一些時間認真學習各種pattern、架構設計、框架開發...等知識技能,想說從此之後,應該能高枕無憂,在開發時做出比較能夠長治久安的設計。 結果呢? 跟你猜的一樣,並沒有。系統還是在修修補補中度日。這到底是為什麼? 幾年之後我知道,原因很簡單,因為環境在變,技術在變,需求在變,我們活在一個多變的真實世界,然而我們能控制、能掌握的變數實在太少,少到所有的預先規劃和設計最後看起來都變得可笑。 所以,敏捷(Agile)不相信計畫(Plan),甚至誇張一點說,敏捷不相信有完美的預先設計(Design)。 但注意,這不是完全不要設計,而是,不管當時看起來怎麼完美的設計,你都要有這個心理認知--『 日後它一定會變得不完美 』。不管你做了什麼樣精細的計畫(Plan)你都要知道,這計畫未來一定會走歪,只要你是活在一個充滿變數與未知的真實世界中。 你不相信? 或許你會問,那為何過去的年代,計畫似乎是有用的,甚至有人手上可以有好幾套劇本,事情的走向總是被掌握在足智多謀、細心計畫的智者手中? 那是因為過去的時代沒有現今的科技與技術,資訊的傳遞也不像現在這麼迅速,當時的世界給了人們一個假象,讓人誤以為自己可以掌握些什麼,能夠控制些什麼,能夠讓事情的走向依照計畫,或是運籌在股掌之間。 也確實,當你手上的資源越多、運算能力越強大,面對的問題越簡單、變數越少、時間越短,那預測和掌握未來的可能性不是不存在。 反之,當你手上的資源越少、變數越多、你就會發現對未來的掌握度趨近於零,事事依照計畫走的可能性根本不存在。 所以我們乾脆不要計劃了? 開發時也不用做任何架構設計? 對,也不對。 對的是這個想法,預先計畫和預先設計並不可靠,這意味著你不能完全倚賴它。 不對的是這個行為,你不能完全不做任何計劃或設計,你只是不該再像是以前那樣鉅細靡遺地去設計,並要求所有人照著劇本走,期待規劃好了就不會再改變。 會不會很矛盾? 對我來說完全不會,因為這就是人生。 ...

真正的需求訪談,是談價值、而非只談功能。

圖片
前幾天聊到價值(Value),給我點時間,讓我細說從頭。 這幾年做案子下來,發現大多數的SA/PM/PO在需求訪談時跟客戶談功能很在行,談價值卻很吃力。你可能覺得疑惑,需求訪談不就是談需求嗎? 為何會扯到價值? 回答這問題前,先幫我想想,一個軟體的需求是為了什麼? 沒錯,需求是為了實現價值,功能則是需求的具體表現。 舉例來說,一個電子商務網站可以有各式各樣的功能,但核心價值要嘛是銷售、要嘛是服務,OK,這個你一定懂。 但大多數的SA或技術人員,受過了多年的技術訓練,談功能很拿手,各種工具、圖表、道具順手捻來毫不手軟,客戶看的眼花撩亂但也很開心,因為看到這麼多功能(工項)被列出來,腦袋裡自然而然幻想著,當這些功能實現,需求『自然』就滿足了,而需求被滿足,價值『自然』就實現了。 但真的是這樣嗎? 做那麼多年的軟體之後,你肯定知道,不是的。擁有一堆功能跟這個 軟體/網站 能不能滿足客戶需求乃至於實現某種價值,根本可以是兩回事。 然而很多客戶(和廠商)死不信邪,以為價值沒實現是因為功能不夠多(天殺的!!!這是我碰過最可怕的思維...) 然後試圖用無止盡的增加功能來滿足可能根本不存在的想像出的需求,然後在心裡期望價值能發生。(天佑PM/天佑SA/天佑客戶...) 每當我們要求跟客戶談需求時,試圖把焦點拉回價值(而不是一直停留在談功能上),一開始客戶都很不習慣,因為這仿佛很抽象,廠商自己也擔心,因為哪有一個網站可以保證上線後就財源滾滾而來? 就好比你賣一個ERP軟體要保障客戶使用後利潤增加一成,這...似乎有點難? 對,但就是因為這很難,所以久而久之,我們把價值放一邊,銷售時就拼命暗示客戶你有某種需求等著被滿足,而要滿足這些需求,則要做出這些功能,只要你買了這些功能,一切就搞定了。 然後,最初期待實現的價值呢? 恩...沒實現嗎? 不要緊,下一套軟體我們再來談... ------------------ 相關課程: http://www.studyhost.tw/NewCourses/ALM 電子書: http://studyhost.blogspot.tw/2014/10/blog-post_1.html 如果需要即時取得更多相關訊息,可按 這裡 加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

MVP(最小可行性產品)的重點不是雛形、不是迭代、不是探索需求、而是實現價值!!!

圖片
最近網路上有幾篇文章, 這篇 文章中談到的MVP(最小可行性產品)那個圖,我在上課時也常用,也常被問到一樣的問題,而我的回答也總是很簡單... 在下圖中第一和第二個路線的例子裡,我們從來都不是說要做『一台汽車(太具體了)』,而是說要做一個運輸或交通工具(相對抽象),因為一開始你根本不會知道具體需求是甚麼,下圖中的『汽車』只是運輸器具的一種呈現方式,但根本不是一開始的目標... (如果你做過產品,就會知道,開始時需求根本不可能是具體的,更不用說有什麼『清楚的規格』這種事情了,再清楚的規格,其實都是你自己的想像,只要碰到市場都會幻滅) (講到這裡你應該知道我認為下圖是對是錯了,但重點在於,這些根本不是重點!!!) 這幾篇文章討論到最小可行性產品這個議題時,都少了一個我們做軟體專案時非常重要的概念,就是:『MVP的每個迭代(或交付)都必須要對用戶產生出價值(Value)』。 因此我在談MVP時的重點,從來都不是雛形(prototype)、也不是邊做邊改去符合(或探索)用戶需求,甚至不是其實我認為也很重要的快速反饋,而是『時刻產生價值』。 沒有帶來價值的產出,不管是滑板、腳踏車還是機車、汽車,對我(客戶)來說,都叫做『浪費』。 當客戶的預算有限、需求常常變、一切彷彿都捉摸不定時,你很有可能永遠都不知道客戶(或市場)到底最終要的是戰車還是超跑,但,不管你產出的是什麼,只要能在當下立即為客戶帶來『價值』,那就是好東西,否則不管你做出什麼曠世巨作或太空梭,只要沒能帶給客戶價值,我們都稱之為『浪費』。 敏捷專案管理中所追求的,是每一個迭代、每一次交付都要能為客戶帶來『價值(Value)』。這很不容易,但這才是我在乎的重點... 後記:關於價值,為何我們那麼看重? 後續我又做了一些補充,請參考 這裡 。 ------------------ 相關課程: http://www.studyhost.tw/NewCourses/ALM 電子書: http://studyhost.blogspot.tw/2014/10/blog-post_1.html 如果需要即時取得更多相關訊息,可按 這裡 加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

The DevOps Journey – Index

圖片
去年(2016)關於DevOps的討論很多,但內容大多相對抽象,對於從來沒有接觸過軟體開發生命週期管理(ALM)的技術人員來說,不是很容易掌握DevOps的精神。 不過,隨著工具的成熟以及敏捷開發概念的盛行,我們越來越能夠看到DdevOps在各行各業的具體實例與應用。同時,不管是專案或軟體產品,在各類的軟體開發的情境中,ALM/DevOps/Agile幾乎已經是近代軟體開發方式與專案管理的主流。 過去這幾年筆者有幸參與各種不同類型的開發團隊,包含軟體產品開發、也有客製化專案軟體開發,同時偶而也協助企業導入ALM/DevOps/Scrum。因此,這一系列的文章中,如果可以,我希望能夠把我們這幾年面對軟體開發方法,以及使用ALM/DevOps/Agile的一些經驗,有條理一點的整理出來,如果你有興趣,不妨嘗試慢慢的看看,如果實在已經不習慣看長篇文章,也可以挑有興趣的重點來讀。 我先定義一下我們的範圍: 採用的開發技術包含.NET傳統桌面應用程式和網站、iOS和Android開發,使用的DevOps/ALM工具主要是VSTS/TFS(版控包含Git和TFVC),從需求、設計、開發、測試、CI、CD、線上監控、客戶反饋…大致上都有涉及。 開發團隊包含設計人員(Designer)、前端開發人員、後端開發人員,當然還有PM(PO)、客戶服務(或Sales) 底下是系列文: the DevOps journey (0) - 敏捷開發真和每個開發人員有關? the DevOps journey (1) - 敏捷開發不相信時程預測? the DevOps journey (2) - 如果時程難預估,不如追求透明度… the DevOps journey (3) - 『透明度』與『自動化』… the DevOps journey (4) - 建立VSTS站台與專案(2017年Q1版) the DevOps journey (5) - 在VSTS站台與專案中添加成員 the DevOps journey (6) - 安排與設定專案的迭代 the DevOps journey (7) – 你的source code還沒上版控嗎? the DevOps journey (8) – 使用TFVC程式碼版控 the DevOps journ...

如何培養你的『溝通力』

圖片
這是一篇欠了很久的文章。不寫,是因為我覺得這主題要寫的好著實不容易,但偏偏『溝通』這件事情,是專案管理當中非常重要的一環,也是工程師想要蛻變或升級的一個必學功課。(因此這一篇讀起來要有點耐心) 在溝通這件事情上,身為開發人員或PM的你,理論上應該要非常有經驗。從專案一開始(甚至說還沒開始)『溝通』就持續在發生。在presale介紹產品時,在SA洽談規格時,在UAT面對客戶的挑剔時,在專案延遲面對客戶的責難時... 你肯定會發現,需要『溝通力』的場合真是無所不在。 既然需要溝通的場合天天發生,那表示,大部分的PM或工程師,都能夠順利的做好『溝通』這件事嗎? 完全沒有,甚至可以說,大部分的專案都是敗在溝通上面的。特別是工程背景的技術人員,在面對溝通上,總是常常犯著有形無形的錯,卻始終不自知。然而,這是個性和訓練背景的不同使然,可能真的是非戰之罪。 但只要有機會,工程師必須調整自己,才能夠往另一個層次的方向邁進。 備註:上面所說的,正好就是資深技術人員不一定能夠成為好的PM的原因,雖然我自己找的PM,都堅持必須要有技術背景,但我也非常清楚,對於有技術背景的專業人員,由於受的訓練與思考模式的不同,其實相當不容易跳過這個gap。 接著,我們就來談談溝通這件事情。 首先,你第一個你必須注意的事情是, 溝通是一件需要花時間的工作 。大多數的工程師喜歡思考、也喜歡動手、甚至喜歡談技術,但不喜歡說話,特別是不喜歡耐心的聽別人說話。 『不喜歡耐心的聽別人說話』,是溝通的第一個致命傷。(你認為自己算是很有耐心? 或覺得這應該是個容易克服的問題? 請先往下看再說...) 你必須知道一件事情(這是一個心態的調整),所謂的溝通,並非是想盡辦法(透過技術或是專業)說服對方,而是給對方一個說服自己的機會。意思是,當你想要和對方溝通,如果你的潛在目的是只想讓對方照你的意思做,那不叫溝通,基本上那就是談判(或是說服)。 溝通是,你必須抽離自己的角色和立場,從一個第三者的角度來看,你自己所在意的,和對方所在意的,兩者之間有多大的距離,為了讓雙方都滿意,該如何找出具有創造性的第三選擇,而非只執著在自己要的結果或對方想要的結果上面。(想深入了解這個概念,可以參考柯維的『第三選擇』一書) 柯維在 『 第三選擇 』 中說:「溝通中的傾聽是你讓對方充分表達並且了解...