,

Mockup的重要性 - 艾菲肯專案管理小學堂

不一致的溝通 需求確認的流程,資訊是不對稱的,開發團隊會以技術面以及以往的專案經驗去思考需求;客戶會從生活經驗中去思考需求,可能看了某新聞報導人工智慧用在商業決策上,大型購物平台提供了完整的金流與物流服務累積了一些對資訊技術的認知,綜合自身的商業策略、願景、業務、產品、市場去思考需求。 客戶可能在技術可行性上的認知不足,導致想法天馬行空,開發團隊也可能不了解顧客群的特性與產品的核心價值,設計了複雜而不實用的產品,產品負責人與雙方的溝通可能有誤差,導致需求認知不一致。 基於mockup去規劃與設計功能需求 也因此我傾向於先透過第一手的溝通內容,先萃取初期的需求,透過user…

驗收準則 article reviews about how to write a acceptance criteria - 艾菲肯專案管理小學堂

本週閱讀了以下三篇關於驗收準則的文章: ACCEPTANCE CRITERIA:https://www.leadingagile.com/2014/09/acceptance-criteria/ What Characteristics Make Good Agile Acceptance Criteria?:http://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ …

需求與使用者故事 – 艾菲肯專案管理小學堂

如何把系統需求變成明確、可實作的規格是我們首先要處理問題,規格實例化( specification  by example )和驗收測試導向開發( acceptance-test-driven development) 是兩種常見的方法,有興趣的朋友可以參考Gojko…

專案中的隱形殺手:技術債( Technical Debt ) - 艾菲肯專案管理小學堂

技術債( Technical Debt ) 技術債( Technical Debt ) 是指我們常常為了某種目的而抄捷徑,或者替軟體帶來災難性的種種壞東西: 不良設計:曾經合理但如今卻不再是如此的設計。 …