發表文章

目前顯示的是 9月, 2020的文章

導入敏捷最難的是什麼?

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

什麼是Azure Cosmos DB?

圖片
Cosmos DB是微軟的高可用性、低延遲資料庫。近代的電商網站或微服務應用程式,都強調所謂的高可用性(就是網站或服務很難死掉)與快速回應,一旦系統上線,大概都不太容許服務的中止或延遲。 要實現這個能力,我們在Web或AP層可以做HA(high availability)架構,一般透過負載平衡(Load Balance)搭配Auto Scale的方式來實現。從Azure的Web App到常見的Container解決方案(像是K8S, AKS)的使用,背後很多的考量都是為了實現這樣的高可用性需求,讓流量增加的時候動態的在Web或AP層自動延展(動態增加伺服器): 但你慢慢會發現,當Web/AP伺服器可以近乎無限的延展之後,瓶頸接著發生在DB身上,因為傳統的關聯式資料庫,要實現像是Web Server或AP Server這樣快速延展分流成本相對而言非常高。且在資料的抄寫和回應的速度上要能夠有所保障,其架構都不若Web/AP Server的Scale那麼單純。 過去,用戶端的數量大多可以預測,但現在人手一台平板手機加NB,網際網路上的服務所面對的用戶端數量較之以往不可同日而語,如果要支撐一個全球服務的網站,傳統DB的Cluster架構常常力有未逮。 舉例來說,我們知道在資料處理上,有個CQRS架構(讀者可以上網搜尋相關資訊,例如 https://docs.microsoft.com/zh-tw/azure/architecture/patterns/cqrs ),其基本的概念是,真實世界中,資料查詢(讀取)與寫入的比例其實並非對等的。例如,台灣前陣子的口罩銷售地圖這類的應用,很明顯查詢的需求遠高於更新(寫入),大部分的全球化應用都有類似的情境。而傳統的資料庫程式設計,卻往往將讀取和寫入設計成同樣的工作通道(例如同樣的db access connection)。 倘若我們可以將資料的讀取,分散在全球不同的資料中心,讓讀取的節點可以分散,而工作比例較低的寫入動作,僅在其中一兩個節點進行,再將寫入的資料自動抄寫到不同的讀取節點,將有助於提升應用程式的查詢效能,這對於很多全球化或分散式的應用來說,是一個相對理想的架構。 這時候,NO SQL(Not Only SQL )類型的資料庫,就開始被許多大型網站考慮了,而Cosmos DB就是一個可以滿足這樣需求的資料庫。