PMI-ACP練習題知識積累-打印版

敏捷鐵三角的參數：價值，質量，約束。傳統的鐵三角包括的參數是範圍，進度和成本

 

敏捷計劃的三個主要層級爲：發佈計劃，迭代計劃，每日計劃

 

敏捷開發模型的特徵包括 開發由多個迭代組成。

 

敏捷擁抱不肯定性，而瀑布式開發試圖消除不肯定性並管理它。

 

探測是用一個快速試驗來解決問題，而不是永無休止地討論。這是使用此方法的一個理想場景。

 

scrum 的三大支柱：可視性、檢驗和適應性。

 

敏捷的方法是在複雜決策的環境下用的最好

 

迭代 h 也被稱爲增強迭代，沒有新的功能被開發，而是已有功能要測試。

 

—共有  12 條 xp 實踐，若是團隊不能應用全部  12 條，建議運用前  6 條。

 

技術債務一般發生在團隊推遲了最終必需要作出的決定或行動時。

 

受權團隊負責管理迭代（衝刺）未完項，而產品負責人負責管理產品未完項。

 

信息發射源的對立面是信息冷凍機。信息冷凍機是一種圖表或組件，你必須開發或探索才能理解裏邊的內容。它意味着不透明。

 

產品未完項的屬性應該是 deep,表明詳略適宜的（detailed appropriately）、可估計的 （estimated）、涌現式的（emergent）、排好優先級的    (prioritized)。

 

「完成」的定義是整個團隊肯定的。

 

一個功能點從開始到完成所花費的時間被稱爲循環時間

 

產品負責人是敏捷項目中的重要角色。

產品負責人這個名詞專屬於scrum,但他至關於別的方法論中客戶的角色。因爲產品負責人的參與度很高，不少會議都會邀請他參加， 因此這個問題有點難度。迭代回顧會議是核心團隊的會議，他們在會上會查看在前一次迭代已經完成的工做並討論下一次迭代怎樣作好，團隊查看本身的工做時，產品負責人在這個會 上發揮的做用不會很大。

 

客戶和產品負責人負責編寫用戶故事。產品負責人角色存在於scrum中，其餘架構中都是以客戶角色出現的。

 

根據亞倫•桑德斯所說，敏捷失敗（失敗模式）的前 12 條是：

       1.承諾沒有自動產生組織變化或得到支持。

       2.文化不支持變化。

       3.文化沒有反思，或者執行反思不足。

       4.在項目收尾過程當中丟失標準和質量。

       5.計劃中缺少協做。

       6.缺少或者過多產品負責人。

       7.項目領導力不足，或者 scrum 主管不信任團隊並不容許團隊自主管理和自我約束。

       8.沒有現場的敏捷支持者或者教練。

       9.缺少一支完善，高績效的團隊。

       10.不維持嚴格的測試標準的狀況下，技術債務會增長。

       11.文化維持傳統的績效評估，即推崇我的時丟失團隊方面。

       12.由於變化難以進行，因此傳統或「舊式」的經營方式出現。

 

漏網缺陷是一個軟件缺陷，沒有被開發或測試團隊發現，可是後來被終端用戶發現

 

計劃撲克應該在開發用戶故事以後和建立故事點以前使用。由於計劃撲克就是採用用戶故事來建立故事點的。

 

計劃撲克是基於寬帶德爾菲估算技能、也是以共識爲基礎的工做量估算技能。有時候也稱爲 scrum 撲克，每每在故事點和開發用戶故事中用來估算相對工做量。

在計劃撲克會議中，每一位估算師各派有一副相同的價值範圍寬廣的計劃撲克卡片。

斐波那契數列經常使用來衡量計劃撲克的價值（即 0,1,2,3,5,8，等）；

另外一種常見數列是（問號，0,1/2,1,2,3,5,8,13,20,40，和 100）。

計劃撲克會議按以下運行：

       1）一名調停人，主持會議，不參與估算。

       2）產品負責人/管理人員對用戶故事做概述，並回答開發者提出的澄清問題，每每產品負責人不參與投票。

       3）每一位估算師抽取一張卡片來估算工做量。

       4）每人抽取一張卡片後，同時將他們的卡片翻轉，

       5）持高和低估算的估算師各有一個機會做立場辯護。

       6）達成共識前，不斷重複以上流程。持有用戶故事的開發者每每擁有較高可信度。

 

      

團隊正在開會討論估算。每次估算都將範圍繪製到圖上進行討論。團隊用的是哪種方法？使用了寬帶德爾菲。在這個技術中，範圍被標記在一個圖表上並用於討論。

 

在其餘條件都相同的狀況下，親和估計估算方法速度最快。

      

親和估算是預測工做量的一個方法，一般在故事點，開發用戶故事中，而尤爲在大型產品待辦事項中做用巨大。雖然還有其餘估算方法，可是基本的親和估算模式涉及從小到大範圍裏測量用戶故事。這個範圍能夠是斐波那契數列或者 t-shirt 尺碼，經常貼在大型會議室牆上。而後參與者在估算時可將他們的用戶故事貼到這面牆上。這種估算常在無聲中進行，且直到評估用戶故事，常伴有若干迭代。

      

估算開發一個用戶故事的相對工做量時，分配給每個用戶故事的時間一般稱爲時間箱，那麼每每每個用戶故事的時間箱值是2-3分鐘

進行計劃撲克時，每個用戶故事應分配2-3分鐘。每每設定的時間值是 2 到 3 分鐘來討論用戶故事。

故事點表示開發一個用戶故事的相對工做量。每個故事點表示一個固定的開發工做量值。當估算敏捷團隊時，必須考慮複雜度，工做量，風險和依存關係。

故事點是開發工做的固定單元，用在相對測量用戶故事中，以達到估算參與開發的工做量的目的。故事點並不以時間爲基礎，而以意義爲基礎。

 

用戶故事或者特性首先在發佈計劃期間被分配到迭代中。若是用戶故事是特性，那麼在迭代計劃期間會被分解成若干任務，這樣任務可再分配給特定的開發者。爲便於管理計劃和監控，估算任務持續時長的一條經驗是每一項任務的應大約佔開發時長的四小時到兩天。

 

若是一個團隊快速估算用戶故事工做量並用 xs、s、m、l 或 xl 標註，有可能使用了 下列哪一個方法？近似估計

 

敏捷開發中的主題是指一組有關的用戶故事。

 

開發一個用戶故事的理想持續時長是2-5天

 

史詩故事是一個大型故事，可能橫跨幾個迭代週期。它也被稱爲一種能力

 

速度是指對每一迭代團隊完成的用戶故事點或故事數量的衡量。一個敏捷團隊可根據稍前的速度記錄來估算下一個迭代可完成的用戶故事點數量。

 

週期（完成一個用戶故事的時間）應該隨着迭代期的推動一直縮短直到其達到最佳水 平。週期是一個用戶故事中從規格說明到可運做軟件整個過程所需的時間量。

 

正常狀況下，開發速度隨着項目的進展而提升，然而會受到不少因素的影響。

 

除了使用故事點來估算用戶故事的相對尺碼外，敏捷團隊還可以使用理想時間。理想時間表明時間量，即不受會議，我的生活，非工做日或其餘拖延，障礙和分心的干擾的狀況下，相對於待辦事項中其餘用戶故事，單獨我的創建，測試和發佈用戶故事所花的時間。

一個用戶故事爲0，說明開發團隊只須要很小的努力

能夠經過解聚把大的用戶故事分解爲小的更易於處理的故事。Disaggregation解聚 將史詩故事或大型故事分解成小型用戶故事,解聚相似與傳統項目的分解。

 

用戶故事要點（Ron Jeffries，3C）：

       簡述：用卡片（Card）來簡要描述故事。

       細節：與Product Owner（或客戶）交談（Conversation）來明確細節。

       確認：驗收評審，確認（Confirmation）被正確完成。

 

敏捷主題是一系列故事、迭代或版本。例如，一個迭代主題多是報告，所以大部 分或所有的用戶故事均可能和生成報告相關。

      

時間盒是管理某個時間被限定的項目的一種方法。只有在規定時間內經過驗收的功 能包含在時間盒內。

時間盒法約束了團隊，儘管不是以一種特別消極的方式。它只是規定時間上不能靈活變化，可是範圍能夠變化。這種狀況下迭代和版本在進度上都不會靈活。

 

發佈計劃有助於客戶和敏捷團隊決定每個項目時間範圍或者階段內應該開發的內容和一個產品理想上準備發佈的時間。

在發佈計劃會議，敏捷項目管理者和開發團隊相信討論產品前景。這確保適當要求，驗收標準，優先排序創建。

 

力場分析是尋找推進和阻礙變化的因素並給因素分配編號以瞭解兩邊力量的總和。

 

德爾菲法是一種結構化的方法，嚴格按照流程執行。參與的專家採用匿名方式發表意見，相互之間不得討論，不能發生橫向聯繫，只能與調查人員進行溝通。經過多輪次調查 專家對問卷所提問題的見解，通過反覆徵詢、概括、修改，最後彙總成專家基本一致的見解。

 

寬帶德爾菲方法是德爾菲方法的進一步發展，採用收斂原則來斷定專家們的意見是否已經趨於一致。這個收斂原則——帶寬——是專家們基於估計對象的特徵和集體經驗討論達成的共 識，並在估計過程當中用這個收斂原則來判斷專家的意見是否已經趨於一致

 

線框圖是一種無須實際功能或代碼就能演示界面的快速方法，也是向用戶展現他們 可以理解的概念的快速 方法。

 

影響項目的5 個核心風險區包括：

       生產率變化（計劃和實際操做之間的差距）；

       範圍漸變（初始協議之外的大量附加的需求）；

       規格故障（干係人對需求的共識的缺失）；

       內部日程的缺陷（對任務工期的錯誤評估）；

       人才流失（人力資源的流失）。

 

由於每一項迭代一般產生的工做產品是完美整合的，迭代每每持續 2-4周，期間不斷地進行驗證和確認以確保產品的質量。驗證是爲了確保產品的執行符合客戶的描述需求（例如用戶需求指出的），確認是爲了證實產品的執行符合預期（即符合客戶需求）。有時候一個產品多是依照規範完美整合，即它可經過驗證，可是它並不符合客戶的目標，即它不能經過確認。

 

爲產品負責人所擁有的產品路線圖，是產品需求的高層次概述，經常使用做特性優先處理，特性歸類和粗略時間框架肯定的工具，有利於促進組織特徵。

建立產品路線圖需遵循 4 個步驟：

       1）確認需求（這些會成爲產品待辦事項的一部分），

       2）將需求分類或分定主題，

       3）評估相對工做量（例如，計劃撲克或者親和估算）和優先化（價值），

       4）評估粗略時間框架（評估高速和衝刺持續時間，以及粗略發佈時間）。

 

信息發射源的定義是對項目有關的數據的可視化展現。

項目的燃盡圖是一個經常使用的來展現迭代進度的信息發射源。

它記錄兩項序列：剩餘的實際工做和剩餘的理想/預估的工做。

豎軸是工做單元（常是故事點或時間），橫軸是迭代持續時長（常是日期數字）。

理想/預估的工做序列是條向下傾斜的直線，由需完成工做價值（例如 20 故事點）的豎軸出發，延長至橫軸上迭代的最後一天（即 0 故事點）。

實際工做序列每日更新，取決於敏捷團隊的生產率和任務的複雜性。實際工做序列經常是易變的，並不是直線，它隨着項目團隊干涉開發流程而消長（每每是非線性的，反映開發的起伏）。

 

最小可售功能（mmf）是一個最小和可市場化的軟件特徵或者產品特佂。「最小」的意思是簡單和小，而且不復雜。「可市場化的」的意思是擁有部分價值，不管是產生收益或者節約成本，均可進行市場化或者銷售。

 

敏捷統一流程(aup)是統一流程或稱 up（up 自己是更詳盡的迭代和增量軟件開發的框架）的簡化版。aup 爲敏捷框架簡化 up。aup 項目包含 4 個階段：

       1）創始

       2）細化

       3）創建

       4）轉變。

在每個短迭代結束時，團隊交付一個工做產品。

 

驗收測試驅動開發（atdd）與測試驅動開發（tdd）相似，在於它一樣須要編程人員在產品代碼前編寫出測試。驗收測試驅動開發的測試旨在驗證預期軟件中的特性/行爲。

驗收測試驅動開發的迭代迭代的 4 個步驟可簡記爲 4 個 ds：

       1）discuss 討論：敏捷團隊和客戶或者商業干係人詳細討論用戶故事，包含用戶故事應有和不該有的預期行爲。

       2）distill 提取：開發團隊研習討論中的條目並提取成可驗證和確認這些行爲的測試。提取流程中，整個團隊應充分認識「完成」對用戶故事的意義，這正是驗收標準所在。

       3）develop 開發：提取後，團隊開發測試代碼和產品代碼以產生產品特性。

       4）demo 示範：產品特性開發後，團隊向客戶或商業干係人展現以得到反饋。

 

一個健全的站立會議的重點特徵包括：

       同輩壓力——由於團隊靠你們，因此同輩的指望可帶動進步；

       密切的配合——團隊應當理解對專一的必要性並獨立工做；

       細在專一——團隊應當理解每日站立會議中簡潔的必要性，由此團隊纔有效益；

       每日承諾——團隊應當理解對每人每日承諾的價值所在，並兌現這些承諾；

       辨別障礙——團隊應當集體意識到每一個人的困難，由此團隊可集體嘗試解決。

 

一個複雜的適應型系統（或稱爲 cas），是指由互動，適應型主體或成分組成的系統。這一名詞是用於在敏捷中提醒敏捷專業人員，一個產品的開發在以前能影響將來行爲的互動，事件和決策中是適應型的。混序這個詞有時候用來描述 cas。資料中顯示混序項目的三個重點特徵是：

       結盟和合做

       浮現和自我管理

       學習和適應

 

在敏捷設計流程中，原型有助於客戶瞭解當前設計狀態。3 種常見的原型是 html，書面（即概述）和線框。

線框是用戶界面的概述，確認它的內容，設計和設計功能，常是黑白色，剔除細節性的圖片和圖像。線框可在紙上，白板或者軟件上創做。

 

在早期的需求收集中，一個重要干係人一再提出現行需求討論話題以外的需求。團隊怎樣處理：團隊應該把干係人的關注點增長到停車場圖中。這是停車場圖的根本目的。它用來抓住可能重要的但應該之後再關注的偏離主題的信息。

 

敏捷開發的基石是「增量交付」。增量交付是指爲及時反饋和接納，頻繁向客戶交付連續改善的工做產品。爲演示和反饋，每每在每個衝刺或迭代的末期交付產品。這項反饋技能，可以使客戶評價產品並提出新的需求。在敏捷流程中，接受變更/更新/改善的需求，以確保客戶獲得有價值和質量的產品。一個衝刺或迭代每每持續 2-4 周，最後，漸進地交付一個新的並改善的產品。

 

精益基於  7 條原則，即消除浪費、強化學習、儘量晚決策、儘量快交付、受權 團隊、構建完整性和全盤檢視。

 

價值流程圖是敏捷採用的精益生產分析技能。一張價值流程圖可能用於分析信息或者材料的流動，從它們的源地到重點，以此來識別浪費區域。識別出的區域成爲流程可完善的地方。浪費的形式很是多，可用 widetom 來記憶。

       w---waiting 等待

       i---inventory 庫存

       d---defects 缺陷

       e---extra processing 額外流程

       t---transportation 運輸

       o---over-production 過分生產

       m---motion 動態。

一張價值流程圖一般由團隊協做繪製或記錄，這樣團隊可一塊兒定義和查看整個流程，指出流程內的浪費區域。增長價值的流程（部分或者特性的流程）一般稱爲「價值增長」，而不增長價值的流程（等待部分的到達）一般稱爲「非價值增長」。大致上講，項目均但願最大程度上減小非增長價值時間（即浪費區域）。

 

在價值流程圖中，能辨別出過程當中存在的浪費是很重要的。widetom 能夠用於記錄不一樣種類的浪費。請問，m 在 widetom 中表明什麼？M表明移動。解釋以下：

價值流程圖是一項協做性地流程分析技能，一支功能多樣的團隊繪製一個流程來識別浪費發生的地方而且確承認完善的地方。它是流程分析技能的一個例子。和價值流程圖相似，流程圖也用於繪製一個流程來識別瓶頸（即流程會減緩和產生庫存的地方）。"

 

價值流程圖是敏捷採用的精益生產分析技能，用於對造成客戶產品或服務的原料和信息（即價值）的流動進行分析。執行價值流程圖大體包括 5 個步驟：

       1）確認產品，客戶和範圍（即流程的始末）。

       2）地圖做爲團隊或者我的現時價值流，確認流程步驟，延時和信息需求。估算流程步驟的持續時長和前置期持續時長（lead time durations）。前置期是指在發生前一項流程或者事件需等待的時長。

       3）分析價值流程圖來確認浪費存在的地方（好比前置期）和流程可完善的地方（流程時間一般認爲是價值增長時間，可是應儘可能減小整個流程的時間，由此來縮短向客戶交付價值流的時間）。

       4）經過分析，總結出一份展現價值流應努力達到的前景或者目標的將來價值流程圖。

       5）經過流程完善活動（即完善）或者其餘方法來達到目標的一些工做。

 

你做爲一名新的團隊成員剛剛開始在一個敏捷項目中工做，牆上有張圖顯示了積壓的、 開始的、設計了的、編碼的和完成的工做項。這是什麼圖？

這是累積流量圖的經典例子。它代表了在系統中進行的、還沒開始的和已經完成的 工做。看板面板也符合問題描述，可是他不在4個選項中。

 

敏捷團隊必須時常處理產品待辦事項裏的產品特性優先級問題。從發佈計劃到迭代計劃，敏捷團隊必須優先處理產品的用戶故事/特性來確保高質量和高價值的特性優先得以開發，以此幫助帶來樂觀和較早的投資收益。

敏捷團隊每每在相對價值和風險方面優先處理需求或用戶故事/特性；價值由客戶決定（即客戶-價值優先級）。

兩個處理產品優先級的經常使用方法是：moscow 和 kano。

moscow 方法將產品特性分爲「必需含有」，「應該含有」，「能夠含有」和「會含有」四類。

而 kano 方法將特性分爲「必須含有（開端）」，「不知足因素」，「知足因素」和「愉悅因素」。

       「必需含有」是指必需含有的特性。

       「不知足因素」是指反過來影響感知價值而應該移除的特性。

       「知足因素」是指此類因素越多客戶越滿意，可以正相關地增長感知價值的特性，但並非必需的。

       「愉悅因素」是指能指數型地增長感知價值來知足客戶的特性。

依據風險來優先處理特性，可運用風險-價值指標。

風險-價值指標含4個象限，橫軸表示價值，豎軸表示風險。用戶故事被分配到其中一個分類/象限：低價值，低風險；低價值，高風險；高價值，低風險；高價值，高風險。成本-價值指標一樣可用這種方式造成。

敏捷中全部的優先化都是「相對的」，也就是說一個用戶故事只是相對優先於其餘用戶故事，而非在固定規模上獲得優先處理。"

 

縮寫 smart（specific 詳細的，measurable 可測量的，achievable 可完成的，relevant相關的和 timeboxed 時間定量）有助於敏捷工做者記憶一項明確任務的特徵。

       s-specific 任務是指明顯有助於用戶故事開發的任務，應該是清晰明確的。

       m-measurable 任務是指團隊和客戶可以驗證的任務。

       achievable 任務是指開發者可切合實際地執行和理解的任務。

       r-relevant 任務是指明確地爲用戶故事增長價值的任務。

       t-timeboxed 任務是指可以對開發所需的工做量和時間進行估算的任務。

 

滾動計劃（或計劃前滾動 rolling look ahead planning）包括部分波動性和階段性的計劃，尤爲是在大型複雜的項目中做用明顯。只有將來幾個迭代會做細節計劃，而時間較遙遠的迭代則只做高層次計劃。逐步完善則假定細節和需求會逐步獲得改良，而且會適時融入到計劃流程中。

 

在滾動的前進計劃中，一次計劃多少個迭代？  接下來的幾回迭代

在使用負責項目的滾動波或滾動預測將來計劃時，敏捷團隊計劃在下幾個迭代中的工做。一個滾動波或滾動預測將來計劃聚焦於計劃準備完成的工做，並不是超出這個門檻的工做，由於將來太遙遠。

 

閃電戰計劃包含故事的依存關係和涉及使用卡片來計劃項目，其中時效性、任務和故事的依存關係被肯定和考慮。

 

吉姆•海史密斯敏捷項目管理模型包括如下 5 個階段：構想，推測，探索，適應和結束階段。

 

海史密斯敏捷企業架構的 4 個層次包括：

       投資管理分層

       項目管理分層

       迭代管理分層

       技術實踐分層。

 

水晶是軟件開發靈活輕便方法的方法家族。方法家族是區分紅員的顏色代碼，例如透明，黃色，紅色。顏色的選擇取決於成果水平的要求。在光譜一端是徹底透明的。不考慮顏色，水晶架構是迭代的而且有三個基本過程：

       章程

       交付迭代

       項目總結。

水晶綱領包括：

       建設團隊，

       作探索性的 360，

       爲團隊定義實踐標準/微調方法論，

       創建初始項目計劃。

在交付週期中，水晶團隊開發，集成。像其餘敏捷架構，水晶包括協定事件，像站立會議和反思提升工做室。在包裝中團隊總結項目，進行完成儀式。

      

時間，預算和成本估算是敏捷中重要的知識和技能板塊。根據海史密斯的觀點，因爲其接受變更的範圍，敏捷方法的本質意味着它爲固定的預算和進度提供良好的支持，但變更的範圍使總成本的估算更艱難。

整體來講，預算和調度的約束是已知的，可是這發生在項目初始階段開始須要定義一組商定的基礎產品功效前；固定的範圍下降了敏捷團隊提供提升的價值的創新確實。

對於熟悉固訂價格合同的公司來講，合同簽定前裏面的需求已經是商定好的，而採起敏捷會是一個折磨人的冒險。

相反，其餘的合同類型會推薦給敏捷工做，包括：初始階段的通常服務協議和爲迭代或用戶故事分開設置的固訂價合同；工料合同；不超過固定費用合同；最後，獎勵性合同（例如，固訂價加激勵；成本加酬金及獎勵合同）。

 

一項敏捷項目中，典型的信息發射器包括：項目燃盡圖，任務板，燃起圖、缺陷圖表。

 

風險燃盡圖是用於跟蹤項目伴隨時間風險的風險管理技能。經過風險燃盡圖，干係人可迅速查看隨着時間項目風險管理的績效（好比提升，下降以及對應的量值）。嚴重度（影響和收益的產品）是沿着豎軸繪製，而橫軸是時間。影響力的量值每每是 0-5，按風險升序排列。

收益率/可能性的量值每每是 0-5，按收益率升序排列。

例如，一項風險的最高風險度是 25（5*5=25），最低風險度是 0。

敏捷團隊和客戶/產品負責人識別到風險同時分配嚴重度值到風險登記冊，並跟蹤這些值。理想狀況下，風險嚴重度會隨着時間下降。

 

 

由於風險調整未完項是按照風險而不是按照價值進行排序，因此會和產品未完項有不 同的順序。風險調整未完項取決於風險估算的方法，才能決定是定性仍是定量。

經過在風險調整未完項中對故事排序

 

適應風險的待辦事項是指按風險整理的產品待辦事項。風險可被估算爲嚴重性/結果和可能性。用戶故事也可放置在風險-價值矩陣中，得以在待辦事項中優先處理。

 

風險-價值矩陣是有 4 個象限的圖表：

       沿着橫軸是升序價值。

       沿着豎軸是升序風險。

       高價值和高風險用戶故事位於右上角。

       高價值和低風險用戶故事位於右下方。

       高價值和低風險用戶故事位於右下方。

       低價值和低風險用戶故事位於左下方。

一般團隊會優先處理高價值，低風險用戶故事，接着是高價值，高風險的，而後是低價值，低風險的，最後是低價值，高風險的。

 

高敏捷情商的意思是自我意識，控制本身的情緒並能注意到其餘團隊成員的情緒。高敏捷情商使團隊成員之間有效協做。

 

舒適而溫馨的環境是在設計團隊氛圍時重點考慮的方面，它能夠促進有效溝通，提高創造力和激勵團隊成員。構建良好的敏捷團隊氛圍的指導包括：

       團隊成員的協做；

       減小非必要的干擾/分心；

       爲信息發射源提供專用白板和牆面空間；

       爲每日站立會議和其餘會議提供空間；

       結對工做站；

       其餘人性的措施如植物和溫馨的傢俱。

      

創建一支高績效的團隊對於任何項目的成功相當重要。一支高績效的團隊表現爲：

       受權正確的成員

       創建信任

       以可持續的步調工做

       保持穩定的速度/生產率開發

       有固定時間回顧和反思工做

       有團隊領導負責移除任何障礙並提供指導和教練

       自主管理和自我約束

       協做的

       可運用如下幾種管理技能創建或促進高績效的團隊氛圍：

       移除任何下降團隊績效的障礙

       對團隊績效持高指望

       教練和指導團隊達到自身的最佳績效。 

      

 

彼特是利用滲透溝通的原則來了解保爾的困境的。滲透溝通包括抓取視覺暗示，好比肢體語言。

一支高績效敏捷團隊是滲透溝通和麪談式互動的理想組合。

 

對於分佈式團隊，在沒有組合的狀況下，一些經驗能夠提供有效溝通的最佳形式：

       團隊內部網站

       虛擬團隊空間

       電郵視頻會議

       地理分離，特別是世界範圍的，團隊要考慮語言，文化，時區不一樣。

      

積極傾聽包括聽、理解、保持和積極響應，但不包括記錄。

 

不只在敏捷中，富有動力的團隊對其餘任何項目都相當重要。富有動力的團隊運做更流暢，生產效率高，表現超越指望值。

可提升團隊動力的簡單步驟包括：

       1）共度黃金時間，團隊成員可在我的層面上了解他人以此營造社區氛圍，

       2）提供反饋，指導和訓練，讚賞和感謝團隊成員的出色工做，同時爲技能和能力提高提供指導和訓練，

       3）受權，受權團隊成員做關鍵決策，在此期間，創建信任並顯示領導對團隊能力的信任

 

敏捷中，有效的「知識分享」是成功的關鍵因素，它須要全部團隊成員和干係人對關鍵信息的近乎實時的交流。爲了促進知識分享，敏捷在流程中運用標準實踐，例如使用全面專家/多功能團隊，

       自主管理和自我約束團隊，

       協做，

       每日站立會議，

       迭代/衝刺計劃，

       發佈計劃，

       結對編程和結對輪換

       項目回顧/反思

       現場客戶支持。

固然敏捷的第六項原則是「開發團隊內部和之間最有效和最有力的傳達信息的方式是面對面對話。」從這層意思上說，敏捷傾向於和鼓勵全部干係人和團隊成員的協做，由於溝通的最好方式是面對面對話，而且反過來，促進知識分享。

      

基本上成千的決策都是在項目的過程當中決定的，其中的許多決策是爲了應對團隊無可避免面臨的問題的。所以適當地熟悉問題解決的策略，工具和技能對敏捷團隊來講是相當重要的。部分常見的問題解決技能包括：

       大聲提問；

       再次討論問題；

       5why；

       沉沒成本謬誤；

       故意持不一樣意見的人；

       保持善良，回放；

       提問探究性問題；

       反映式/主動式聆聽。

 

敏捷中一個常見的誤解是敏捷團隊並不須要一個領導者。事實上，全部的敏捷團隊都須要領導者，可是領導團隊的方式從根本上是不一樣於典型傳統的項目管理人員/項目領導者的。一些學者從理論上闡釋了這種誤解是基於敏捷團隊指望的「自主管理」品質。雖然「自主管理」的敏捷團隊受權擁有產品的全部權並承擔責任，同時可自行決策，儘管如此它仍須要一個領導者，來幫助提供指導，提供諮詢，訓練，解決問題和進行決策。

敏捷領導者所需的重要方面包括：

       受權團隊成員決定敏捷實踐和方法的標準；

       容許團隊進行自主管理和自我約束；

       受權團隊成員和客戶合做決策；

       激勵團隊創造力和探索新思想和技術才能；

       成爲提倡者，向團隊成員闡釋產品前景，以此激勵完成總體目標；

       移除並解決團隊工做中可能遇到的障礙和問題；

       向可能不熟悉敏捷的干係人溝通和宣傳敏捷項目管理的價值和原則；

       確保包括商業管理人員和開發者在內的全部干係人有效協做；

       最後，可以依據工做環境改變領導風格，以此確保有力支持敏捷價值和原則。

      

《美國項目管理協會道德與職業行爲規範》中提到，項目管理人員的義務包括：

       熟知並遵循各項政策，規章，條例和法律，規範本身職業性和志願性的工做；

       向有關人員反映不道德和違法的行爲，同時視狀況須要，上報有關人員的失職行爲；

       確保對失職行爲和違法活動的任何訴訟獲得落實，申訴必須以事實爲依據；

       毫不參與或者幫助他人蔘與違法活動。

 

《美國項目管理協會敏捷社區實踐社區章程》提出的社區價值包括：

前景 僕人式領導力 信任 協做 誠實 好學 勇氣 開放 適應力 領導變革 透明化