分類彙整: 軟體開發

突破團隊效能的瓶頸

大家的討論圍繞在團隊如何提供學習成長的機會;假如團隊成員每一個人都能在各方面領域有夠水準的表現,那麼團隊必然會有高效能的產出。不過同人在過去的軟體專案開發經驗中體驗到,讓成員學習成長是一條艱辛且漫長的路,領導者必須有耐心提供更多的時間和空間來促進成員的學習成長,否則很容易適得其反。這讓同人想到從另一種觀點去思考跨領域團隊的問題,我認為也許不是期待成員具備跨領域的技能,而是運用限制理論的觀點來突破團隊效能的瓶頸。 閱讀全文

分類: 利害關係人, 問題解決, 學習, 專案團隊, 思考, 溝通, 生活感觸, 開發流程 | 發佈留言

訊息拆解組合的宣告式語意

一般而言,程式碼的立即運算是比較符合人們想法直覺的演算法,也就是依據上一個運算的結果來決定後續的演算邏輯。但對較複雜的程式邏輯而言,立即運算常會形成多重運算路徑的歧路而使程式的開發與維護變得更繁複,面對這種狀況也許我們需要採用另一種典範來簡化設計;也就是延後運算的處理,等到需要得到答案時才一次求解計算出結果,省卻許多繁複的條件判斷或迴圈的控制。在這裡同人想發表一系列文章分享四種不同主題延遲運算,它們都是以 C++ 語言實作的延遲運算,包括訊息拆解與組合、拆解命令列、資料表的查詢、以及搜尋 Xml 找到符合的資料。

首先,這一篇文章我們先來談談延遲運算在訊息拆解與組合的應用。 閱讀全文

分類: 分析設計建模, 學習, 寫作, 生活感觸, 編程技巧, 職場, 設計原則, 軟體開發 | 2 則留言

為什麼敏捷沒有效?

敏捷為什麼會沒有效?同人以為不是因為敏捷不適用,沒有依據現實環境來調適敏捷方法及實務、或是沒有讓成員熟練調適過的流程,都會導致敏捷的失誤。然而再大的失誤都比不上忽略外部觀點的優越感、過度樂觀、和認為一切都在掌控中的心態作祟。敏捷不需要依賴技術、效率與控制,而是重視關係的相互信賴、整體協調與參與促成良性互動,因為後者會讓人回到外部觀點的具體和客觀,它們比前者更能發揮較大的力量。 閱讀全文

分類: 利害關係人, 品質文化, 問題解決, 學習, 寫作, 專案團隊, 思考, 溝通, 生活感觸, 組織, 職場, 開發流程, 閱讀 | 發佈留言

開發者的集體智慧

上禮拜參加了Agile 臭皮匠聚會,會中討論到 Planning Poker 的相關議題,讓我想到之前在閱讀《再想一下:好決策的關鍵思考術》看到「數大即不同」的觀念,覺得很有趣。後來同人在 Scrum Community in Taiwan 看到有關管理層遇上敏捷的討論,我看到一句話讓我想到《領導的技術》這本書談到領導力量與組織關係的觀點。這兩個事件讓我意識到有趣的關連,想到可以寫這篇文章來分享我看開發者集體智慧的觀點。 閱讀全文

分類: 利害關係人, 問題解決, 專案團隊, 專案規劃, 思考, 溝通, 生活感觸, 組織, 職場, 開發流程, 閱讀, 領導 | 發佈留言

軟體開發團隊的心理型賦權

賦權是賦予團隊力量的一股能量流動,但這股能量為何會停滯而不再流動,以致於團隊因官僚特性顯得僵化,使創意枯竭與乾涸而喪失解決問題的洞見?同人觀察這正是團隊之間喪失信賴,不能信任彼此的合作關係,而只相信英雄主義。 閱讀全文

分類: 利害關係人, 品質文化, 問題解決, 學習, 專案團隊, 思考, 溝通, 生活感觸, 組織, 職場, 衝突, 閱讀, 領導 | 發佈留言

領域物件的概念性表層設計

領域物件代表領域概念的真實資料,但對於詮釋資料的抽象概念卻會受到時空環境的影響而變化。當領域物件不能面對現實而調整,那麼系統的設計將變得愈來愈繁複,但改變領域物件需要變動資料庫又往往是工程浩大要承擔巨大的風險,到底有沒有兩全其美的辦法呢?在此同人分享領域物件的概念性表層設計,它提供開發者自行定義領域物件概念性表層界面,並透過動態代理,以領域物件的資料自動產生領域物界概念性表層的實作。 閱讀全文

分類: 分析設計建模, 問題解決, 編程技巧, 職場, 設計原則 | 發佈留言

讀取 Trello 任務看板的資訊

最近同人發現原來可以匯出 Trello 看板的任務與階段資料的 Trello Dump 已經不能用了,同人只好動手以 jQuery 寫程式用來讀取 Trello 任務看板資訊。程式完成後想到可以分享這支程式,除了為自己留下記錄外,也供有需要的人當做參考。 閱讀全文

分類: 利害關係人, 品質文化, 問題解決, 專案團隊, 專案監控, 溝通, 編程技巧, 職場, 開發流程, 領導 | 5 則留言

開發團隊工作文化的調適

同人認為開發團隊工作文化的調適最關鍵的地方,是要讓每個角色為解決問題而行動,而不是因為命令或規範而不明究理在做事,因為這樣很容易因為官僚而成災。因此,不要因為覺得浪費時間或為了避免衝突而不溝通,往後團隊將會因為沒有解決問題而付出更大的代價,更嚴重的是成員受到文化的感染,將會變得缺乏承諾、規避責任、甚至最後導致忽視成果,團隊不再擁有專業的雅典娜,而阿波羅的計劃也永遠趕不上變化呀。 閱讀全文

分類: 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 神話, 組織, 職場, 衝突, 開發流程, 閱讀, 領導 | 2 則留言

看不到人,就沒有人的問題?

很多人都知道軟體專案最難解決的是人的問題,但對超理智型管理者來說,人的問題不算什麼。實際上,超理智者經常視人而不見,因此根本不認為他們需要解決人的問題。就像某位長官一心想改變架構,卻拒絕承認架構變動會造成風險升高的衝擊,明顯的駝鳥心態;以為把頭埋在沙堆裡,看不到人,就沒有人的問題。 閱讀全文

分類: 分析設計建模, 利害關係人, 品質文化, 問題解決, 專案團隊, 專案管理, 思考, 溝通, 生活感觸, 管理, 組織, 職場, 衝突, 領導 | 發佈留言

軟體的團隊合作不只是分工

軟體專案的管理者應該注意,造就行為模式的結構一旦產生,人人都做自己以為正確的事,實際上卻造成完全相反的結果。這時候要領導專案團隊的正確方向,需要系統化思考,才能認清結構,以打破錯誤的行為模式。分工的迷思會讓管理者建樹不見林而沒有把穩方向。 閱讀全文

分類: 品質文化, 問題解決, 專案團隊, 生活感觸, 系統思考, 職場, 開發流程, 領導 | 發佈留言