敏捷思維和方法管理專案-案例1
為什麼選擇敏捷方法?
背景和痛點:
- 我司每月進行中的專案數量超過100個,專案數量龐大。
- 每月中旬需要規劃下個月的專案。
- 每月上旬需分析上個月的專案實際情況,包括進度達成率、質量和成本預實比等方面的分析。
- 專案資訊主要透過Excel管理,難以追蹤變更,資料統計過程繁瑣。- 專案範圍擴大情況頻繁發生。
- 每月需提交專案狀況報告,整理報告內容的工作量較大,不僅消耗大量工時,還容易出現錯誤。
解決方案:
我們計劃開發一個專案管理系統,將專案資訊錄入該系統,實現專案管理系統化,各類報表自動化生成。
關於體制:
由於這是公司內部專案,無法組建專門的團隊進行設計和開發。
計劃利用專案間歇期的成員進行兼職開發,也就是說沒有專案預算的開發人員可以隨時加入專案管理系統的開發團隊。
關於期限:
儘管該系統沒有客戶方要求的確切截止日期,我們希望儘早開發出一個初始版本,在使用中逐步完善功能,這正是採用敏捷的MVP(最小可行產品)理念的體現。
關於需求要件:
我們對系統的基本需求有一個大致的想法,希望實現專案管理各方面的自動化,以減少人工干預。
我們的目標包括將來實現自動生成專案報告,並自動傳送給相關干係人。然而,很多細節尚未精細化考慮,因此我們希望以“滾雪球”的方式逐步發展我們的管理系統。
值得注意的是,兼職人員能在專案中停留的時間並不確定。如果有盈利專案,我們的人力資源可能會立即被抽調走。
我們召開了一次1小時的會議,明確了成員角色,並決定採用敏捷思維開展該專案。
需要注意的是,我們使用的是敏捷思維,而不是嚴格遵循敏捷方法。因此,我們將依據敏捷思維,結合組織能力、成員能力以及專案特點,靈活管理專案。
■定義角色
- 專案發起人:部門負責人
-產品負責人(PO,Product Owner):PMO成員
- 敏捷教練(Scrum Master,SM):部門負責人兼任
- 開發團隊(Development Team):1名全職SE+4名SE+1名兼職架構師
- 使用者:部門負責人、各團隊責任人、專案經理(PM)、PMO成員
■定義產品方向
1.我作為專案發起人,與PO分享我的產品構想、痛點以及希望實現的願景。
2.PO基於願景召集使用者(部門負責人、各團隊責任人、PM、PMO成員),收集了很多零散的需求。
這些需求中,絕大多數是寶貴的,但也有一些不切實際的需求,不需要透過系統實現。
■制定Product Backlog
1.PO將收集的需求整理分類,形成使用者故事(User Story),包括史詩級(Epic)和普通使用者故事(User Story),並將這些使用者故事放入產品待辦事項列表(Product Backlog)中。
2.PO召集專案發起人和使用者,講解產品待辦事項中的使用者故事。
目的有兩個:1)統一各方認知;
2)驗證專案管理系統的可行性。如果使用者認為與Excel沒有太大區別,可能會在這一階段終止專案。
■制定Sprint長度
Scrum Master與PO討論定義Sprint的目標和長度。需要注意的是,敏捷思維強調儘早讓團隊成員參與,以增強團隊的認同感。
儘管此階段存在一些不完全符合敏捷原則的做法,但由於團隊成員尚未從專案中釋放出來,我們暫時不召集開發者。
最終,我們將每個Sprint的長度定義為兩週,每兩週釋出一次版本。每次釋出後,專案發起人和使用者一起嘗試使用並提出意見和建議。
■架構師出場
非功能性需求梳理兼職架構師作為開發團隊的第一位正式成員入場。PO向架構師介紹系統的背景,並與架構師一起收集整理使用者量、資料量等資訊。
架構師開始系統設計,由於系統相對簡單,並且已有現成的基礎架構可供使用,因此我們給架構師1周的時間進行初步工作,定義為Sprint0。
在這1周內,架構師的任務包括:
1. 技術選型:Spring Boot + Vue + PostgreSQL
2. 搭建框架
3. 制定編碼規範
4. 配置持續整合/持續交付(CI/CD)
■制定Sprint的Product Backlog
PO根據釋出方針(產品路線圖),將使用者故事新增到Sprint1的產品待辦事項列表(Product Backlog)中。
說明:
1.Backlog是需求列表,充當需求容器,內含多個item,這些item可以是史詩(Epic)或使用者故事(User Story)。
2.任何需求和想法都可以作為使用者故事,這意味著使用者故事可以是未確定的,不必經過評審和討論確認。
然而,產品待辦事項中的使用者故事是經過團隊評審並確認的需求,這些需求可以在後續迭代中進行開發。
■開發成員入場
PO向開發成員講述產品願景、整體規劃、產品待辦事項中的使用者故事,以及Sprint1裡的使用者故事。
同時開始聽取成員的建議和意見,此階段可以修改產品待辦事項中的使用者故事。
-----------------------未完待續-------------------------
【補充資訊】
Scrum Master在敏捷專案中的具體職責包括:
促進團隊工作:
幫助團隊理解和遵循Scrum框架,確保團隊成員之間的溝通順暢,協助解決衝突和障礙。
確保敏捷實踐的實施:
確保團隊按照Scrum的原則和實踐工作,包括規劃會議、日常站會、評審會議和回顧會議。
協助產品負責人:
支援產品負責人進行產品待辦事項的管理,幫助澄清需求,確保待辦事項的優先順序明確。
清除障礙:
主動識別和解決團隊在工作中遇到的障礙,確保團隊能夠順利推進工作。
促進自組織:
鼓勵團隊自我管理和自我組織,提高團隊的自主性和責任感。
培訓和指導:
為團隊成員提供敏捷和Scrum方面的培訓和指導,提高團隊的敏捷能力。
與利益相關者溝通:
充當團隊與外部利益相關者之間的橋樑,確保資訊的透明和共享。
推動持續改進:
透過回顧和反饋機制,持續改進團隊的工作流程和效率。
度量團隊表現:
幫助團隊使用指標和資料來評估工作效果,推動資料驅動的決策。
倡導敏捷文化:
在整個組織內傳播敏捷思維和文化,促進敏捷實踐的廣泛應用。
Scrum Master的角色不僅限於管理,更重要的是引導和支援團隊以更高效的方式工作。
敏捷思維-專案實踐
相關文章
- 華為敏捷專案管理實踐分享敏捷專案管理
- 什麼是產品思維和專案思維? - Shreyas
- 系統思維實踐入門
- Choerodon豬齒魚團隊敏捷專案管理實踐應用敏捷專案管理
- 敏捷開發思維和免費敏捷管理工具敏捷
- 敏捷專案管理?敏捷專案管理
- 中興通訊測試專案實踐:敏捷測試特性文件的交付過程實踐探討敏捷測試
- mobx專案實踐
- Greenplum 學習實踐-總體思維導圖
- vue實踐06-專案實踐Vue
- JavaWeb尚矽谷書城專案思維導圖JavaWeb
- SAP freelancer接SAP專案應有底線思維
- 專案管理工具+專案思維管理我的日常工作專案管理
- 敏捷是扼殺產品思維的兇手?敏捷
- 敏捷專案管理到底怎麼實施?敏捷專案管理
- 微服務專案實踐之中建專案微服務
- maven 專案轉化成 gradle 專案實踐MavenGradle
- 專案去O實踐
- 專案經理值得一試的思維方式:專案成功方程式
- 大專案為服務架構設計思維架構
- 如何運用專案管理思維制定工作計劃?專案管理
- 值得關注的七大專案管理思維專案管理
- 慢和不變也是敏捷:貝索斯的思維敏捷
- 傳統專案管理VS敏捷專案管理專案管理敏捷
- 結構化思維助力Prompt創作:專業化技術講解和實踐案例
- vue專案實踐思考003Vue
- React專案實踐系列二React
- React專案實踐系列一React
- go專案dockerfile最佳實踐GoDocker
- 實踐JavaWeb課程專案JavaWeb
- 專案管理系列---腦圖(思維導圖)工具深度分析專案管理
- Scrum敏捷開發方法實踐Scrum敏捷
- 建立和維護大型Vue.js專案的10個最佳實踐Vue.js
- 思維題專項訓練
- 敏捷專家認為敏捷框架SAFe實際最不敏捷敏捷框架
- Choerodon豬齒魚敏捷管理實踐(三):敏捷會議敏捷
- 羅輯思維首席架構師:Go微服務改造實踐架構Go微服務
- 敏捷專案管理,POLYV來支招敏捷專案管理