如何用一篇文章了解清楚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工作，涉獵產品線的工藝順序，必須有項目經驗。其他是熟悉理論，培養人才的必備技能。