敏捷中的極限編程——項目經理和 nTaskers 的實用指南

已發表: 2020-07-08

我們收到了很多關於瀑佈極限編程的請求——以及作為項目經理如何從中受益。萬一您不知道極限編程是什麼，它是一種敏捷框架形式，PM 可以在軟件開發環境中充分利用可用資源。

敏捷 SDLC 環境中的極限編程 (XP)

資料來源：Udacity.com

極限編程 (XP) 是一種敏捷軟件開發框架，專為提高軟件質量、開發團隊的工作流程和提高客戶滿意度而設計。

它是一種為您的項目設計的更順暢和高效的軟件開發生命週期 (SDLC) 的方法，它於 1996 年 3 月 6 日首次在一個項目中實施。

為什麼選擇極限編程 (XP)？

極限編程致力於在整個項目中提供迭代和循環的軟件版本；而不是在一個單一的、漫長的項目開發生命週期之後將所有東西放在一起。

這些較短的迭代周期有助於團隊成員和客戶在整個開發過程中評估和審查項目的進度。

極限編程 (XP) 是由什麼組成的？

價值

XP 包含以下 5 個值：

溝通：任何行業的軟件開發項目或項目都嚴重依賴溝通。 XP 專注於團隊和客戶之間的有效溝通。
簡單性：XP 尋找完成工作的最簡單方法。這意味著做必要的事情，從而減少浪費，只解決已知問題並保持設計簡單，以便有效地創建和維護。
反饋：反饋在項目改進中起著重要作用。 XP 鼓勵即時反饋。這有助於團隊確定改進空間並修改實踐。
尊重：團隊必須在個人和專業上相互尊重，以實現目標。
勇氣：XP 支持所有級別的勇氣。這可以包括反對什麼不起作用以及任何影響項目有效性的事情，或者接受反饋和改進方法。

實踐

XP 的核心是一組相互關聯的軟件開發實踐。雖然可以孤立地實施這些實踐，但許多團隊發現一些實踐會加強其他實踐，應該結合起來進行。這可以完全消除您在軟件開發中經常面臨的風險。

XP 最初的十二種實踐包括：

計劃遊戲
小版本
隱喻
簡單的設計
測試
重構
結對編程
集體所有製
持續集成
每週 40 小時
現場客戶，和
編碼標準。

多年來，團隊發現某些做法可以強化其他做法。為了消除風險，這些應該是統一的。以下描述包括基於各個團隊經驗的一些改進：

整個團隊：團隊應該由具有不同技能的跨職能團隊組成。通過這種方式，它們可以相互補充以實現特定的結果。

坐在一起：大多數人都同意麵對面交談是最好的交流方式。團隊應該坐在一起，沒有溝通障礙，例如隔間牆。

信息豐富的工作空間：應安排團隊以使團隊的工作對彼此以及團隊外的附屬人員透明的方式進行。

精力充沛的工作：這意味著確保一個人身心健康，可以專注於工作。這也意味著不應該有過度工作和尊重團隊來支持他們的身心健康。

另請閱讀：

如何在當今的工作環境中像專業人士一樣管理項目？

結對編程：這種做法背後的理念是兩個大腦比一個大腦好。結對編程是指通過 2 個人坐在同一台機器上進行軟件生產。通過這種方式，可以進行持續的工作審查，並且問題會得到更快的響應。這種方法已被證明可以提高質量並保持更加專注。

故事：故事定義了產品應該具有的對客戶和用戶有意義的功能。這些故事用於計劃，也可以作為進一步對話的提醒。

每週週期：每週的第一天，團隊開會反思迄今為止的進展。應該在一周內交付的故事由客戶選擇。團隊決定如何處理這些故事。這背後的目標是在本週末之前實現可運行的、可驗證的功能。固定期限允許生產可以向客戶展示以獲取反饋的功能。

季度週期：季度週期的目的是在整個項目的背景下檢查每個週週期的詳細工作。客戶在特定季度內為團隊提供整體計劃。這不僅可以讓團隊了解項目，還可以幫助客戶與其他利益相關者合作。

Slack ：這意味著在每周和每季度的周期中添加一些低優先級的任務或故事。如果團隊在更重要的任務上落後，則可以放棄這些任務。否則，這些也將完成，增加滿足估計時間表的機會。

十分鐘構建：整個系統和所有測試應在 10 分鐘內運行。如果時間超過此限制，則多次重新運行將花費更長的錯誤間隔時間。這種做法鼓勵構建過程的自動化，使其定期運行，以運行所有測試。

持續集成：這種做法鼓勵立即對現有更大代碼庫的新代碼進行測試。這有助於更快地發現和修復集成問題。這種做法需要紀律，並取決於十分鐘構建和測試優先開發的做法。

測試優先編程：而不是遵循常規方式，即，

開發代碼 -> 編寫測試 -> 運行測試

測試優先編程的實踐採取以下路徑：

編寫失敗的自動化測試 -> 運行失敗的測試 -> 開發代碼以使測試通過 -> 運行測試 -> 重複

這種做法也減少了問題識別和解決的反饋週期。這導致引入生產的錯誤數量減少。

增量設計：這種做法描繪了預先做一定量的工作以了解系統設計的廣度視角。之後，在交付特定功能時，進一步研究設計特定方面的細節。這種方法降低了更改成本，並允許您在必要時根據可用的最新信息做出設計決策。

角色

XP 包含了特定的實踐供您的團隊遵循，並且沒有為團隊成員建立特定的角色。但是，根據要求，最常見的 4 個角色是：

客戶：期望 XP 客戶積極參與該項目。客戶做出有關項目的所有業務決策，例如：

系統應該怎麼做？這是指包含的功能及其完成的功能
系統什麼時候完成？這意味著接受標準
應該花多少錢？這意味著項目的預算，以及
接下來應該做什麼？交付功能的順序。

開發人員：開發人員實現客戶確定的故事，這意味著交付具有確定功能的項目。

追踪者：追踪者是可選角色，取決於團隊是否需要。這是由一位開發人員執行的，用於跟踪相關的敏捷指標，對於進度評估和確定需要改進的關鍵領域至關重要。這對於進度跟踪和確定需要改進的關鍵領域很重要。其中一些指標可能包括工作時間、加班時間、通過和失敗的測試、速度以及速度變化的原因。

教練：這個角色很有幫助，特別是如果團隊剛剛開始。教練可以是以前使用過 XP 的外部顧問，可以幫助指導團隊進行 XP 實踐和自律。聘請教練有助於避免新團隊可能犯的潛在錯誤，從而加快項目進度。

極限編程的優勢

極限編程使軟件開發人員可以專注於編碼，而不必擔心與項目相關的非生產性活動
極限編程最重要的好處是，它允許軟件公司減少在無用活動上的金錢和時間等資源支出，而這些資源可以用於項目實現和其他頭腦風暴會議等活動。
極限編程還降低了項目失敗或編碼故障的風險，確保客戶最終得到他們想要的產品
極限編程是一種了不起的方法，它不需要代碼複雜且每個人都難以理解，並且在使用這種方法的開發人員的代碼中顯示出來，因為每當其他人接管他們的職位時，他們都可以非常理解代碼容易地
XP 的最大優點之一是一切都是透明的，並且在每個人面前，這有助於讓每個人和所有事情都負責
持續的反饋也是極限編程的一個令人難以置信的特性，它允許開發人員無所畏懼地編寫代碼，而不用擔心判斷，因為他們總是可以通過收到的反饋來修復小錯誤
定期測試軟件的所有元素，對所有代碼進行錯誤檢測，並使用客戶驗證測試確保客戶在比平時更短的時間內獲得工作原型或實際工作軟件
極限編程還可以幫助公司滿足他們的客戶並保持他們的業務更長時間
在極限編程方法論中，每個人都是平等的群體，每個人都必須像同齡人一樣分擔負擔，這意味著從需求到代碼，開發人員將並肩工作，沒有人感到不被欣賞或被遺忘

極限編程 (XP) 生命週期

XP 生命週期可以用周週期和季度週期來解釋。

首先，客戶定義故事集。團隊估計每個故事的大小，連同客戶估計的相對收益，表明用於優先考慮故事的相對價值。

如果由於涉及的技術考慮不清楚，團隊無法估計某些故事，他們可以引入 Spike。尖峰被稱為研究的短時間框架，可能在常規迭代開始之前或與正在進行的迭代一起發生。

接下來是發布計劃：發布計劃涵蓋將在特定季度或發布中交付的故事。

此時，每週週期開始。每個每週週期的開始都涉及團隊和客戶開會，以決定該週要實現的故事集。然後將這些故事分解為要在該週內完成的任務。

週末回顧團隊和客戶之間迄今為止的進展。這導致決定項目是否應該繼續或是否已經交付了足夠的價值。

極限編程實踐 (XP) 案例研究

適用於 Krizp 系統的 XP

問題

Krizp Solution 是印度一家基於 Web 的初創公司。他們的商業計劃包括為其他小公司或教育機構創建門戶網站。該公司最初是一家兼職企業，僱用已經在其他主要 IT 組織工作的人員。該計劃是只有在創業公司冒險取得成功的情況下才能繼續全職工作。他們的軟件開發流程沒有框架，因為它只是一家初創公司，項目不多，員工也很少。

該公司缺乏結構化的軟件開發方法。在紙上記下最初的要求後，客戶通過電話收到了進一步的信息和說明。通常，在開發解決方案之後的客戶審查之前，需求的主要變化不會發生。

除了錯誤修復之外，開發人員之間幾乎沒有或根本沒有溝通。他們分別在不同的功能上工作。這導致成為討論改進工作方法的障礙。

此外，這些項目沒有記錄在案。沒有項目經理來跟踪項目或確保滿足客戶提出的要求。開發人員只在要求做的事情上工作。

旅程

向 Krizp System 的團隊介紹了不同敏捷框架背後的概念。 XP 方法的使用時間跨度為一個月，並對結果進行了評估。

公司的 CEO 承擔了兩個角色：客戶代表和跟踪者。對於他的第一個角色，他優先考慮用戶故事，將它們委派給開發團隊，並定期與客戶溝通。作為跟踪者，他跟踪完成特定任務的時間。 CEO 還每週（或至少每四天一次）啟動計劃遊戲，因為項目很小，開發人員可以更快地完成一個用戶故事中的任務。然而，客戶每月只能進行兩次直接溝通，其餘時間他通過電話和電子郵件聯繫。

採用了結對編程技術，兩個開發人員一起工作。任務完成後，兩位開發人員都與 CEO 一起審查了代碼。

引入了客戶測試，團隊致力於持續的設計改進，每月大約 12-15 次。

概括

XP 方法似乎對公司的軟件開發週期產生了很好的影響。一些積極的變化包括：

更好的團隊協作、溝通和反饋
更好的任務和時間管理，以及
在沒有技術貢獻的情況下增加 CEO 參與度。

IBM 和 Sabre 航空公司的極限編程實踐

問題

為了評估瀑布與極限編程的實際應用，通過兩個案例研究進行了一項研究：一個在 IBM，另一個在 Sabre Airlines。每個案例研究都將瀑布方法與 XP 方法進行了比較。

旅程

在 IBM 的第一個案例研究中，研究人員想要研究採用 XP 方法對生產力、質量和客戶滿意度的影響。一個由 7 到 11 名成員組成的團隊對 XP 實踐的採用進行了為期一年的研究。該團隊負責為其他 IBM 團隊用來為外部客戶創建產品的工具包開發 Servlet/XML 應用程序。該案例研究分析了同一產品連續發布的兩種方法。第一個是傳統的瀑布方法，第二個是 XP。

在 Sabre Airline Solutions 的第二個案例研究中，使用了相同的方法，即通過同一產品的不同版本比較兩種方法。該團隊致力於為外部客戶開發可編寫腳本的 GUI 環境，以開發定制的最終用戶和業務應用程序。該團隊由6-10名成員組成。舊版本是在 3 年前（跨越 18 個月）使用瀑布方法完成的，而新版本是最近完成的（跨越 3.5 個月），使用 XP。

第一步是建立一個極限編程評估框架（XP-EF），它包括三個部分：XP上下文因素（XP-cf）、XP堅持度量（XP-am）和XP結果測量（XP-om）：

XP Context Factors (XP-cf) : XP-cf 用於記錄與項目相關的重要信息。這些因素包括團隊規模、項目規模、重要性和員工經驗。
XP 堅持指標 (XP-am) ：通過 XP-am，可以表達團隊使用 XP 實踐的程度。 XP-am 還幫助調查 XP 實踐中的交互和依賴關係，以及實踐可以分離或刪除的程度。
XP 結果測量 (XP-om) ：XP-cm 啟用對業務相關結果的評估，即生產力、質量等。

除了框架之外，還與團隊成員和客戶進行了訪談，以幫助了解團隊將 XP 納入客戶滿意度。

概括

在 IBM，XP 方法似乎比瀑布方法更有效率，通過以下衡量標準：

測試缺陷：對於預發布，缺陷減少了 50%，對於發布後，通過 XP 方法發布的缺陷減少了約 40%。
生產力：使用 XP 方法比瀑布方法顯著提高了員工的生產力。
客戶滿意度：客戶滿意度在 XP 中非常高，並且記錄為瀑布流的 N/A。
士氣：利益相關者的士氣在 XP 中被記錄為高，而瀑布記錄為 N/A。

在 Sabre 航空公司，也發現了類似的結果：

缺陷收集期：由於第一個版本是在 18 個月內創建的，因此基於瀑布的方法中的缺陷收集期也更長。在基於 XP 的版本中它明顯更短。
測試缺陷：對於預發布，缺陷減少了 65%，對於發布後，通過 XP 方法發布的缺陷減少了約 46%。
生產力：使用 XP 方法的員工生產力比瀑布方法高約 46%。
客戶滿意度：客戶滿意度在 XP 中非常高，並且記錄為瀑布流的 N/A。
士氣：利益相關者的士氣約為 68% XP，並記錄為瀑布的 N/A。

用例和應用

用例 1： Web 開發

問題陳述：公司網站需要重新設計。

參與者：客戶、開發人員、跟踪者

定期活動流程：
客戶告知初始要求。
開發團隊開始編程。
QA 團隊測試錯誤並通知編程團隊
客戶有更多要求
循環重複。

使用 XP：

面對面會議被稱為涉及客戶和開發人員。
客戶以故事的形式定義需求、預算和時間表。
項目經理成為跟踪者並跟踪項目進度。
開發團隊開始結對工作。代碼是同時編寫和調試的。
每週召開一次會議討論進展情況。客戶可以定義新的要求。
每季度舉行一次會議，討論故事的狀態。
舊故事完成後，形成新的故事集（下一季度的要求）

用例 2：遊戲開發

問題陳述：客戶需要從頭開始開發遊戲。

參與者：客戶、開發人員、跟踪者

定期活動流程：

客戶給出要求、時間和預算。
開發人員開始編程。
QA 團隊測試遊戲模塊。
客戶有更多的要求。
循環重複。

使用 XP ：

面對面會議被稱為涉及客戶和開發人員。
客戶以故事（遊戲模塊）的形式定義需求、預算和時間表。
項目經理成為跟踪者並跟踪遊戲開發進度。
開發團隊開始結對工作。不同模塊的代碼同時編寫和調試。
每週召開一次會議討論進展情況。客戶可以定義新的要求。
每季度舉行一次會議，討論故事的狀態。
舊故事完成後，即高優先級模塊完成後，形成一組新故事（下一季度的要求）

nTask 極限編程實踐 (XP)

nTask 是一個支持敏捷方法的極限編程框架的任務管理系統。它是專為團隊合作和項目交付而設計的在線任務管理應用程序。無論是哪個行業，nTask 都促進了 XP 方法並有助於有效的項目規劃和流程調整。

以下是 nTask 可以幫助您更好地計劃和實現項目目標的一些方法，所有這些都在 XP 框架內。

會議安排

您可以提前安排靜坐、每週會議和季度會議。可以指定會議的議程和時間安排。您可以定義會議的固定時間或向團隊發送建議的時間，以在團隊響應後最終確定。

此應用程序還允許您記下會議中討論的所有重要事項。然後可以為團隊的其他成員審查和發布會議記錄。

團隊分配

您可以通過團隊分配部分安排您的團隊和他們將承擔的角色。您可以輕鬆地為開發人員、跟踪人員和客戶定義角色。

項目創建

客戶可以創建項目並指定要求。客戶還可以定義預算和時間表。

任務創建和分配

客戶可以通過在項目中創建任務來創建故事。這些任務將包括在一個故事下要完成的活動列表。然後可以將這些故事分配給程序員。

如果一些團隊成員提前完成了故事，客戶可以為他們分配“鬆弛”任務，即剩餘時間線內優先級較低的任務。這可以節省時間以更快地完成項目。

另見：

介紹 nTask 2.0——我們最期待的更新

項目流程

項目經理或跟踪者可以幫助跟踪通過時間表模塊的項目流程。該模塊允許對項目進度進行有效監控和評估。它還有助於單獨評估不同任務的時間表以及已達到或未決的里程碑。

輕鬆協作

有時不可能舉行面對面的會議，例如當某個團隊在另一個站點工作時。在這種情況下，項目、任務和會議的自動更新可以確保及時有效的團隊協作和討論。這避免了在手動安排項目和任務跟進、溝通會議記錄或項目更新上浪費時間。

實時評論提供了一種與團隊溝通的簡便方法。無論是信息交流還是新想法，這讓團隊很容易保持一致。

相互依賴的任務被突出顯示，每個團隊成員都可以在其他團隊成員更新時立即檢查更新。這使團隊能夠及時了解不斷變化的情況並相應地計劃下一個任務。

此外，客戶可以直接與團隊協作並更新需求的任何變化。

透明度

nTask 通過其任務板提供所有項目和相應任務和子任務的透明視圖。任何創建或修改的項目都會立即傳達給團隊。無需重新檢查進度更新、會議邀請或項目報告。

更新、修改或刪除的任務為整個團隊充分了解並確切知道何時完成什麼鋪平了道路。

通過其過濾器選項，您可以選擇根據優先級或手頭的任務查看選定項目的更新。使用狀態選項，可以查看所選任務的狀態，無論它是否已開始、已完成或正在進行。

結論

這篇文章詳細介紹了作為敏捷工作者如何從 XP 中受益。此外，創建 nTask 是為了在極限編程和瀑布技術領域內執行此類要求。因此，請務必閱讀，不要忘記通過下面的評論部分分享您的想法。或者，您可以通過[email protected]給我們發送電子郵件。

另請閱讀：

2022 年 21 款最佳免費生產力應用程序
2022 年用於個人任務管理的 23 個最佳待辦事項列表應用程序
2022 年項目經理的 10 項基本項目管理技能
完成工作 (GTD) 方法和 14 個最佳 GTD 應用程序和工具
提高團隊生產力的 19 大時間跟踪軟件
2022 年最適合初創企業的 27 款任務管理軟件
2022 年 36 款最佳免費生產力應用程序
2022 年 30 款用於個人任務管理的最佳待辦事項列表應用程序
2022 年適用於敏捷團隊的 22 個最佳免費項目管理工具
管理虛擬團隊：挑戰、技巧和虛擬團隊管理工具
47 條最佳團隊合作名言，以慶祝合作和激勵