如何用一篇文章了解清楚acp敏捷項目管理?
我們使用各種各樣的敏捷軟件來編寫特性,循環和跟蹤任務,談論敏捷,但是我們真的在正確的軌道上嗎?
很明顯,敏捷是絕對以結果為導向的,去文檔化、去流程化,高效的溝通協作,是極其有意義的。
為了記錄,敏捷經理需要維護一個更詳細的需求池;去流程化,口頭交流成為常態,團隊耦合度更高。
首先,讓我們讓我們先看一看
敏捷性的一些概念
產品Backlog:
積壓是需求池。待辦事項列表。
積壓工作說明了什么:
1.有待發展的任務。
2.任務優先級。
敏捷需要維護一個詳細的需求列表。這個列表通常要求scrum持有者(通常是產品經理)對所有要開發的東西有深刻的理解,并且能夠將它們分解成更詳細的任務。
故事board:
在開發領域,故事版本是任務流的可視化窗口,一般有"待開發","正在開發中,"待測","待返工"和"待發布"。所有的任務都由任務操作者轉移到下一步,這樣任何人都可以看到任務的完成情況。
▲在開發中,故事板展示了所有需求的工作流程。
燒毀圖表:
在短跑中,人/小時是一個相對固定的值。在這個時間框架內,充分安排開發任務,每天定好時間,畫出時間燃盡圖。項目成員通過燃盡圖了解時間進度。如果項目的燒完時間與預計時間重合,則估算需求時間并合理安排;如果沒有,需要在接下來的沖刺中進行調整。
這些概念定義了敏捷各方面的工作,這些流程和節點是敏捷開發的基礎和保障。
第二,離開敏捷工具
我們是如何敏感的?
一個誤區:當我們使用敏捷管理工具時,我們是敏捷的。
隨著敏捷在業界的不斷融合,各種工具產品層出不窮。國外的吉拉、redmine、Axosoft,國內的leangoo、禪宗都有自研工具,比如百度的icafe,阿里的aone,騰訊的tapd。
(▲來源:"開發商")
我們在敏捷管理工具上構建迭代,構建需求,研發,測試,等等。,然后在收到需求流轉的郵件后開始工作...任務在測試和研發之間流動,bug被提交給研發,研發解決bug...我們聲明我們是敏捷的!
我們習慣了敏捷軟件的便捷,習慣了通過拉組來解決一切,但是我們已經失去了敏捷的初衷,scrum的初衷。
▲吉拉的名字來自哥斯拉。
假設我們沒有。;沒有任何項目協作軟件,如何實施敏捷?
設置一個環境,現在沒有協作工具。是的,但是大家都坐在一起。有人站起來說,既然如此,我們就讓我們變得敏捷!
▲敏捷工具消失了。
敏捷路徑中必須有項目負責人來制定計劃,把握項目的方向。這個下午王,我很驚訝地看到你的骨頭,所以你應該承擔這個責任。
還有一個關鍵人物SM。SM的全稱是scrummaster,中文是scrummaster。一般來說,SM需要一個對技術開發和當前項目有清晰認識的技術經理。
雖然缺少網上工具,但至少要準備一些簡單的材料:一卷雙面白紙或者一疊便利貼;一支筆,一面平墻或者一塊黑板。
如果還有電腦可用,excel或者word,甚至寫字板都可以。如果沒有電腦,那將是一張白紙。總之,你得找個地方寫下你的積壓。
需求池示例(任務名稱、平臺、詳細描述、優先級根據P0-PX逐漸降低)
確定沖刺周期的自然日。我們可以用月/旬/周的概念作為一個周期,我們選擇一周(五個工作日)作為沖刺周期。
根據優先級,從需求池中拉出你認為應該添加到你可憐的第一個sprint中的需求。唐不要太貪心。你可能認為大約一周。;的發展就夠了。拉SM,單獨開個小會。
▲當然,我不我不希望你們兩個站在一起。你們兩個要開會。
你們一起看需求,SM根據經驗先分解需求。比如一個需求在開發層面需要分解成ABC三個部分,這三個部分形成三個開發任務。
分解之后,你得到一個更詳細的待開發列表。
在正式開始沖刺之前,產品、研發和銷售。ampd和測試需要一起召開scrum會議,討論這個sprint的功能點。
會上討論了什么:
1.需求討論或技術討論;
2.成員估計需求所需的開發時間;
3.需求是否與人的時間匹配,需求是否排入沖刺;;
4.交流感情。
▲每個任務的預計時間最終由scrummaster判斷。
scrum會議后你的工作:
1.組織這個sprint中的需求列表;
2.安排每個需求的預期開發時間;
3.在故事頁上寫一個小紙條;
4.在故事頁上貼一張小紙條;
5.制作一個燃盡圖。
注釋的改進版本,說明開發人員、任務描述、預計時間和每日耗盡時間。
故事版的布局如下:
一個標準的故事版本:開始時,所有的小筆記都在"待開發"專欄。
那個就是它。可以開始沖刺了。
以為這就完了?天真。
接下來,你一定要來參加每天舉行的項目短會。為了縮短會議時間,我們通常站著開,所以也叫"常務會議及會議。早上上班后或者晚上下班前,我們花十到十五分鐘完成。
▲每日常務會
展輝都誰將出席:
1.你(項目持有人)
3.其他scrum成員
車站將做什么:
1.昨天大家都做了什么,遇到了什么問題,如何解決或尋求解決方案;
2.昨天的完成情況。;的任務,還剩下多少時間,是否需要修正時間(增加或減少時間),將完成的任務轉移到下一個環節(從一項中撕下紙條,粘貼到下一項中);
▲任務進行中的小紙條示例。
3.功能測試后是否有返工;
4.交流感情。
你會后的工作:
畫一張燒壞圖
▲沖刺的任務時間隨著沖刺的進度逐漸減少。
一次又一次,在完成一次沖刺后,你召開了第二次scrum會議。這個時候題目在:的敏捷培訓。讓s與你分享:首先,什么是敏捷?他從哪里來的?他從哪里來的?
敏捷源于精益,精益源于豐田。豐田當年為什么要搞精益?因為一個字窮。被稱為“精益之父”的大野泰一是東方著名的斗士。
Scrum的三大支柱:透明、檢查和調整;
敏捷的優勢包括:1。縮短上市時間;2.提高質量;3.提高效率;4.提高員工參與度;
敏捷的概念:1。管理層必須在敏捷相關的事務上投入時間;2、只能討論如何實施敏捷,不能討論為什么要搞敏捷;
3、零缺陷思維:第一時間把事情做好;
Scrums3355理論(這個你要懂,不然會被鄙視);
三個角色:
ampgt;po對需求產品經理負責。
ampgt;smscrummaster框架
排除障礙,確保流程,仆人管理,服務意識
ampgt;開發團隊
三個工件:
ampgt;產品積壓
(需求池)列表、訂單、列表
ampgt;〉sprintbacklog(下一代列表)
ampgt;倦怠圖表每天完成任務的剩余工作時間
五次會議:
ampgt;〉沖刺計劃會議(下一代計劃會議)2-4小時
ampgt;每天站立15分鐘。
ampgt;2-4小時沖刺產品需求梳理會議
ampgt;←沖刺評審會議1-2小時
ampgt;←沖刺回顧1小時
五種價值觀
ampgt;開放性和開放性。gt;集中和。gt;勇氣與勇氣。gt;尊重ampgt;承諾
掌握了這些概念,你基本上對敏捷有了一個大致的認知。另外,教練需要掌握哪些技能?因為敏捷偏向于開發團隊的培訓,所以敏捷需要涉足Rampampd工作,涉獵產品線的工藝順序,必須有項目經驗。其他是熟悉理論,培養人才的必備技能。