敏捷宣言 敏捷原則
「敏捷宣言」是乙個籠統的術語，描述和管理用於處理it團隊和專案的幾種輕量級且更全面的敏捷方法。 scrum，看板，精益開發，crystal和極限程式設計（xp）是最受歡迎的輕量級敏捷方法。
雖然「小型scrum」適用於「敏捷宣言」，但以下所述的六個附加值應補充和增強小型團隊的敏捷性。
與專案經理保持狹窄的溝通至關重要，但是更廣泛的溝通可以帶來更多價值。 廣泛的溝通包括團隊的所有利益相關者，包括產品所有者，scrummaster和所有團隊成員。 通過在每個團隊之間或團隊與客戶之間的溝通中運用最佳原則來實現卓越非常重要。 因此，鼓勵團隊成員花些時間在會議之前做準備，以最好地適應變化並確保取得成果。 定期快速，有效地使用團隊的首選溝通渠道會營造出溫馨的環境。
在軟體專案中，單個團隊成員負責提供單個功能的責任被視為標準做法。 但是，小型團隊的成員應該在專案生命週期中有更廣泛的參與，因此他們需要共同承擔交付工作專案的責任。 在這種方法中，團隊合作起著重要的作用，團隊成員作為乙個整體一起工作，以確保從下至上的專案成功。
這可以通過以下技術來實現：支援遠端團隊成員，公平的工作量，結對程式設計，**審查和重影。 遠端團隊成員為實現共同目標而努力，但地理位置並不相同； 公平的工作量是為了確保團隊的工作量公平分配； 結對程式設計專注於實時編寫和審閱源**； **審閱，也稱為對等審閱，專注於在實現後或中斷實現後檢視和讀取源**； 遮擋是在職學習，通常用於內部培訓。
快速發展和高質量交付是每位客戶參與的期望。 儘管開發的速度很重要，但是高質量的交付對專案的持續成功有更大的影響。 通過使用質量保證技術，工具，指導和培訓，在質量開發和測試上投入時間可以幫助團隊不斷取得卓越成就。
固定專案責任通常是團隊成員通常扮演的乙個角色，而整個團隊所掌握的技能足以使他們能夠自給自足，這是敏捷的一種標準做法，但是小規模團隊的真正價值來自於成員其他角色（在合理範圍內）。 例如，工程師可以成為前端開發人員，後端開發人員，質量工程師或使用者介面（ui）設計人員。
這種方法背後的想法是確保小型團隊盡可能自給自足。 為了使小型團隊承擔多項職責，工作量必須合理並且專案流程必須簡化。 這可以通過不斷檢查和改善工作條件並簡化流程以幫助團隊專注於交付來實現。 應該提供教練指導，以幫助團隊成員提高技能。
在企業參與過程中，嚴格遵循特定業務請求的請求驅動型思維很重要，但是創新是客戶最重視的。 在這種參與中，客戶是唯一的利益相關者，他們的觀點和聲音緊隨其後。 進行創新至關重要，這是使團隊和客戶在專案定義的需求之外進行思考的關鍵，因此他們可以設想具有最具創意和最佳架構，需求和設計的最終解決方案。
成功的客戶參與對於專案非常重要，但這不足以建立並維持與客戶的牢固而成功的關係。 對於小型團隊，從客戶的業務成功角度進行業務參與很重要。 業務的增長或建立是客戶對軟體解決方案的最高優先； 因此，這應該是團隊的頭等大事。
本文的版本最初發布在medium上，並經許可重新發布。
翻譯自:敏捷宣言 敏捷原則
敏捷宣言和敏捷原則
一 敏捷宣言的四個核心 1 個體和互動 勝過 流程與工具 2 可執行的軟體 勝過 詳盡的文件 3 客戶合作 勝過 合同談判 4 響應變化 勝過 遵循計畫 二 敏捷的十二原則 1 我們的最高目標是，通過盡早和持續地交付有價值的軟體來滿足客戶。2 歡迎對需求提出變更 即使是在專案開發後期。要善於利用需求...
敏捷宣言和敏捷原則
最近在看 軟體專案管理與敏捷方法 這本書，作者將pmbok中各個過程中可以用敏捷方式進行的作了乙個說明，也給出了一些如何在使用傳統開發方法的團隊中如何推廣敏捷開發原則的方法，但總體而言收穫不大。另外我看的這一版是根據pmbok第三版編寫的，而我學習和考試pmp時用的是第四版，看書的過程比較痛苦。但看...
敏捷宣言和原則
我們正在通過親身實踐和幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，我們認為 1 個體和互動 勝過 過程和工具。2 可以工作的軟體 勝過 面面俱到的文件。3 客戶合作 勝過 合同談判。4 響應變化 勝過 遵循計畫。雖然右項具有價值，但我們認為左項更具有價值。1 我們最優先做到的是通過盡早的努力...