Latest

Day24 來點圖表!學習 PMP 中有提到的各種圖表(上)

Day24 來點圖表!學習 PMP 中有提到的各種圖表(上)

今天和明天來列點快速看看 PMP 中有提到的圖表,注意我這裡是說「有提到」,而不是「來自」,這些圖表並不是由 PMP/PMBOK 所原創,PMP/PMBOK 只是將其收錄進去服務於它的某些章節內容。 為什麼會有這兩篇文章的誕生,原因可以回到我在 Day02 的文章內容,當時提到「PMP 大部分都是情境題」,而今天和明天則是為了這個「大部分之外」所誕生的😅,也就是大家最討厭的情境與記憶應用類的題型,我在撰寫全真題時曾遇過幾次類似題型: 題目是:(描述某個情境),請問此時可以使用哪一種圖表? * (A) 圖表 A * (B) 圖表 B * (C) 圖表 C * (D) 圖表 D 這種題目需要先辨識題目前段的情境,答案卻又是記憶類型的把四種圖表都列上,既要理解情境又要知道答案選項的圖表是何時使用,是比較棘手的題型。 而在目前台灣的 PMP/PMBOK 書籍講義(ex:
SimonAllen
Day23 再一次我會怎麼建議:敏捷、迭代與增量

Day23 再一次我會怎麼建議:敏捷、迭代與增量

今天來看常被搞混的敏捷、迭代與增量。 迭代式開發 重複進行多次迭代:每次迭代都進行需求分析、設計、實施和測試,逐步改進產品。 交付 不一定每次都交付完整可用的產品,但會有一個可評估的版本或功能原型。重點在逐步完善和改進產品,每次迭代後不一定能交付可用的產品,但每次都會更接近可用。 例子 以腳踏車的組裝,初始階段交付的是輪子,隨著進展,逐步交付加裝車架、鏈條、齒輪、坐墊等版本,最終到所有零件裝到一起,最終才形成一個可用的完整腳踏車。 增量式開發 交付 分階段交付。每次交付一部分完整可用的產品,逐步增加功能和改進。重點在每次增量交付的部分都是完整且可用的功能。 例子 以交通工具的升級為例,初始交付的是腳踏車,之後逐步增量交付變成電動腳踏車、125cc機車、最終交付一台哈雷機車。每個階段交付的產品都是可以獨立使用的。 敏捷開發 * 結合迭代和增量:每次迭代都交付可用的產品增量,並基於回饋進行持續改進 * 靈活和適應性強:強調快速響應變化,允許在開發過程中靈活調整需求和計劃。 * 持續回饋和改進:每次迭代結束後進行反思和改進,通過持續的客戶回饋來調
SimonAllen
Day22 敏捷專案管理:回顧會議

Day22 敏捷專案管理:回顧會議

今天來看 Retro Meeting,是敏捷專案管理中非常重要的一部分。Retro 通常在每個 Sprint 結束後舉行,目的是讓團隊反思 Sprint 的工作過程,發現並討論問題,從而持續改進團隊的工作效率和品質。 回顧會議的目的 反思和學習 團隊成員一起回顧過去的衝刺,反思什麼做得好、什麼地方需要改進,並學習如何在未來的衝刺中避免相同的問題。 以我們工程師來說,可以有很多內容可以提出,包含但不限於: 1. 對隕石與需求變動的改善方式 2. 整體流程上的問題 3. Legacy Code 程式碼與架構的資訊同步 其中我覺得3是最重要的部分,雖然工程師討厭(但又尊敬) Legacy Code,但是屠龍者終成惡龍,我們現在寫的 code 只要未來稍有個一個人員流動斷層或各種原因出現,馬上變成未來後人的 Legacy Code ,每次有後人進來踩前人的雷,就可以在 Retro 中回報並分享,另外也要記錄起來,這樣未來 Sprint 處理類似需求其他人才可以降低踩到雷的衝擊並降低消化
SimonAllen
Day21 敏捷專案管理:衝刺審查

Day21 敏捷專案管理:衝刺審查

今天來看敏捷專案管理中很重要(但混合式專案管理常被忽略或變種)的衝刺審查(Sprint Review)。 衝刺審查通常在每個 Sprint 結束時舉辦。主要目的是讓開發團隊展示這個Sprint 完成的工作成果,並收集來自 PO 和其他利害關係人的回饋,確保產品方向與需求一致。 衝刺審查的主要活動 展示進度或成果 開發團隊會展示在衝刺期間完成的產品增量,讓大家得知這個 Sprint 的產出。 獲得回饋 利害關係人和產品負責人會對展示的成果提供回饋,這些回饋可以讓 PO 決定是否需要調整產品待辦清單(Product Backlog),優先考慮未來衝刺中需要完成的工作項目。 評估進度與後續 團隊可以回顧專案的進展,評估是否達到了衝刺目標,好讓團隊和 PO 共同討論接下來的步驟以及是否需要對專案計劃做出調整。 衝刺審查目的 公開透明 通過展示和回饋,團隊成員和利害關係人可以了解產品的開發進度,避免資訊不對稱。 快速反應 根據回饋和專案進度,團隊可以及時對開發方向計劃進行調整,確保產出符合客戶或市場商業需求。 結語 以上是理論層面的介紹,實際操作中,
SimonAllen
Day20 敏捷專案管理:產品待辦清單與衝刺清單

Day20 敏捷專案管理:產品待辦清單與衝刺清單

今天來看看敏捷專案管理中的產品待辦清單(Product Backlog)和衝刺清單(Sprint Backlog)差異: 產品待辦清單 Product Backlog 產品待辦清單是一個有(優先)序的需求列表,包含產品需要實現的新功能、修正的錯誤、技術問題和其他待改善的工作項目。 在敏捷專案中,這個清單由產品負責人 PO 管理,隨著新需求的出現或現有商業需求的優先級變化,產品待辦清單會不斷新增或調整內容。 相對於衝刺清單,產品待辦清單會是高層次的描述,不一定有具體細節,可能僅是一個功能的描述而已。 簡單來說可以理解成是「之後可以排進 Sprint 的任務或為了較大商業目的的待辦目標」。 時間週期 沒有具體時間周期,涵蓋了產品開發的整個範圍,包括未來的 Sprint 衝刺,內容可以不斷增加、調整或移除,因為其代表著產品的商業需求。 目的 整個產品功能的藍圖,它是確保研發團隊能滿足需求的計畫工具,也可以隨時可以根據新的需求、回饋或市場變化調整。 負責人 由 PO 產品負責人負責維護和管理,他們決定哪些項目進入清單以及這些項目的優先序。 如果是「
SimonAllen
Day19 敏捷專案管理:三大核心角色

Day19 敏捷專案管理:三大核心角色

Agile 敏捷專案管理在近年來越來越受到重視,特別是在軟體開發領域。它的靈活性和迭代式的開發方式,使得團隊能夠更快速地適應變化與交付。在現行 PMBOK7 中更是加入了不少敏捷的內容,所以今天就讓我們來看看「理論上」敏捷專案的三個核心角色:產品負責人 Product Owner、敏捷教練 Scrum Master,以及開發團隊Development Team 差異。 產品負責人 Product Owner 首先來看看產品負責人,PO 產品負責人主要任務是確保開發團隊所做的一切工作都符合商業目標和客戶需求,其負責定義產品待辦清單(Product Backlog),這個清單包含了所有需要開發的功能、修正的錯誤以及其他技術需求。 也就是說,PO 會決定產品的功能優先級,但是,PO 不能決定 Sprint 中進行任務的優先級排列,聽起來很撓口對不對,每個 Sprint 決定進行的任務清單稱為衝刺待辦清單,這是由開發團隊決定的,關於這點在明天文章會有更多解釋。 還有一點很有趣,PO 的工作不僅僅是列出需求清單,他們還需要持續與利害關係人(如客戶、
SimonAllen
Day18 專案與時程:時程變短或需求增加怎麼辦?

Day18 專案與時程:時程變短或需求增加怎麼辦?

在 PMP/PMBOK 中,當專案面臨變動,需求被迫增加(已通過變更控制委員會)但 Deadline 無法改變甚至提早的情況下,有多種方式可以應對這些變化。通常應對方式是集中在時間管理、範疇管理和資源管理上,例如「快速跟進」和「縮程(趕工)法」,今天就來介紹有哪些策略可行: 快速跟進 Fast Tracking 快速跟進是指將相對於「當前」的任務項,把一些專案「後續」的任務工作也拉至現在執行,也就是把後面的工作盡可能往前,提早開始做,讓一些可以平行進行的工作同時執行,而不是傳統先後順序執行。這樣可以縮短專案的總時間。 有經驗的 PM ,即使沒有學過 PMP/PMBOK ,在遇到任務中時程變故或需求變動,會熟練的協調專案團隊成員,把後期任務協調往前先執行,這個專案管理的行為在 PMP/PMBOK 就是被定義成 Fast Tracking。 風險 快速跟進可能會增加風險,
SimonAllen