敏捷是一系列技術和方法的集合，可提高團隊內的決策、生產力和思考能力。
這些技術涵蓋了傳統軟體工程的各個方面，例如專案管理、軟體設計和架構以及流程最佳化。為了使它們盡可能簡單地實施，它們由經過簡化和優化的程序組成。
因為適當的心態可以顯著影響團隊應用技術的程度，所以敏捷也是一種心態。這種心態有利於團隊成員之間的資訊共享，以便可以集體做出重要的專案選擇，而不是由經理單獨充當決策者。擁抱敏捷心態需要讓整個團隊參與規劃、設計和流程最佳化。敏捷團隊的每個成員都參與技術的應用，並與整個團隊分享相同的資訊。
對於許多沒有經歷過如此成功的團隊來說，敏捷與它所承諾的有很大不同，而這種差異的很大一部分往往是團隊對每個專案的態度。大多數軟體開發企業都涉足敏捷，雖然其中許多企業都取得了成功，但一些團隊的成果並不理想。他們在專案運作方式上取得了一些進展，足以讓擁抱敏捷的努力變得值得，但他們還沒有看到敏捷所承諾的重大變化。這是心態轉變背後的主要想法：「敏捷」是指幫助團隊培養高效率的心態。
然而，「心態轉變」到底是什麼意思呢？在軟體團隊工作需要每天規劃、設計、開發和發佈軟體。 「心態」與此有何關係？事實證明，您和您的隊友處理這些問題的方式會影響您在日常工作中採用的許多程序。
這是一個例子。 每日站立是團隊成員討論目標和問題的聚會，是團隊最受歡迎的敏捷方法之一。我們讓每個人全程站立，以保持會議簡短。對於許多團隊來說，在專案中添加每日站立會議已被證明是非常成功的。
理解敏捷價值觀（敏捷宣言）
敏捷價值觀重點
• 敏捷宣言包含可打造高效團隊的共同價值觀和想法。
• 「個人和互動重於流程和工具」意味著團隊應該先專注於團隊中的人員以及他們如何溝通，其次才是他們使用的工具和實踐。
• 「工作軟體勝過全面文件」意味著交付滿足使用者需求的軟體比交付描述軟體的規格更重要。
• 工作軟體是指能為公司創造價值的軟體。
• 「客戶協作勝過合約談判」意味著對待每個人都像同一個團隊一樣。
• 許多高效的敏捷團隊將產品所有者視為專案團隊的成員來進行協作，而不是作為客戶進行談判。
• 「回應變化勝過遵循計劃」意味著認識到計劃會變得不準確，並且交付軟體比執行計劃更重要。
• 任務板是一種敏捷的規劃工具，其中使用者故事被附加到板上，並根據其在當前專案或迭代中的狀態分類為列。
12 個敏捷軟體的原則
我們的首要任務是透過儘早持續交付有價值的軟體來滿足客戶 - 客戶永遠是對的。
歡迎不斷變化的需求，即使是在開發後期。敏捷流程利用變革為客戶帶來競爭優勢。意思是：
a.當發生變化時，沒有人會陷入「麻煩」。
b.我們同舟共濟。每個人都在合作。
c.我們不會坐等改變，直到為時已晚。
d.我們不再將改變視為錯誤。
e.我們從變化中學習。這是團隊成長並更好地共同建立軟體的最有效方式。
短い期間を優先して、数週間から数か月の間、動作するソフトウェアを頻繁に配信します。アジャイル チームは、タイムボックス化された反復を使用して動作するソフトウェアを頻繁に提供することで、顧客に最大の価値を提供できるようにプロジェクトを常に調整します
開発チーム内および開発チーム内で情報を伝達する最も効率的かつ効果的な方法は、対面での会話です。チームのメンバーが対面でコミュニケーションを取らない場合、大まかな点では同意しても、最終的には異なる目標に向かって作業することになる可能性があります。包括的なドキュメントを作成すると、曖昧さが生じやすくなり、状況がさらに悪化する可能性があります。
プロジェクト全体を通じてビジネス アナリストと開発者が日常的に協力することで、効率が向上します。これは、ビジネス プロフェッショナルがチームのパフォーマンスを確認して意見を提供するためにプロジェクトの最後まで待たなければならず、プロジェクトのこの時点で修正を完了させるとはるかにコストがかかるためです。
やる気のある個人を中心にプロジェクトを構築します。彼らに必要な環境とサポートを与え、彼らが仕事をやり遂げることを信頼してください。
稼働中のソフトウェアは進捗状況の主な尺度です。チームが達成した内容を伝える最も効果的な方法であるため、プロジェクトのステータスに関する最新情報を全員に提供するには進捗レポートよりも優れています。これが、アジャイル チームが反復開発を使用する理由の 1 つです。各イテレーションの最後に動作するソフトウェアを提供し、チームが何をしたかを全員に正確に示す実際の製品デモンストレーションを行うことにより、読み違えることはほぼ不可能な方法でソフトウェアの進捗状況を全員に最新情報を提供します。
アジャイルなプロセスは持続可能な開発を促進します。スポンサー、開発者、ユーザーは、一定のペースを無期限に維持できる必要があります。
優れた技術と優れた設計に継続的に注意を払うことで、機敏性が向上します。
シンプルさ (未完了の作業量を最大化する技術) は不可欠です。アジャイル チームは、不要な機能や過度に複雑なソフトウェアの構築を避けることで、ソリューションを可能な限りシンプルに保ちます。
最高のアーキテクチャ、要件、設計は自己組織化チームから生まれます。自己組織化チームは、製品の構想からプロジェクト管理、設計と実装に至るまで、プロジェクトのあらゆる側面に対する責任を共有します。
チームは、定期的に、より効果的になる方法を振り返り、それに応じて動作を調整し、調整します。各反復後と終了時に、時間をかけて振り返り、学んだ教訓について話すことで、このプロジェクトでは、アジャイル チームは常にソフトウェアの構築を向上させています。
人気のアジャイル手法
それらの簡単な定義:
スクラム、エクストリーム プログラミング(XP)、リーン、カンバン
1.スクラムおよび自己組織化チーム
スクラムは、アジャイル プロジェクト管理における段階的な進歩、継続的な改善、協力を強調する強力なフレームワークです。スクラムは、少しずつ価値を提供することを重視し、強力なチーム ダイナミクスを育成することで、組織が製品開発の複雑さと不確実性を乗り越えるのを支援します。
2.エクストリーム プログラミング(XP)
強力なアジャイル手法であるエクストリーム プログラミングは、技術的な品質だけでなく、クライアントと開発者の緊密な協力にも重点を置いています。 XP は、ペア プログラミング、TDD、継続的インテグレーションなどの手法を使用して、急速に変化する環境でユーザーのニーズを満たす高品質のソフトウェアを作成するチームをサポートします。フィードバック、シンプルさ、コミュニケーションに重点を置いているため、要件が頻繁に変更されるプロジェクトに特に適しています。
3.リーン
アジャイルにおけるリーン手法では、効率、継続的な改善、顧客満足度を重視し、無駄をほとんど省いて最大の価値を提供します。チームは、リーンの概念と実践を導入することで、コラボレーション能力を向上させ、ニーズの変化により迅速に対応し、業務を合理化できます。この方法は、柔軟性と顧客重視の開発というアジャイルの原則とうまく機能し、現代のソフトウェア開発における強力な戦術となっています。
4.カンバン
効果的なアジャイル手法 カンバンでは、効率、視覚的な管理、継続的な開発に重点が置かれています。カンバン ボードとコンセプトの実装を通じて、チームはワークフロー管理を改善し、コラボレーションを促進し、顧客価値の提供を高めることができます。適応性があり、フローを重視しているため、優先順位や要件が定期的に変化する環境で特に効果的に機能します。
위 그림은 Scrum, XP, Lean이 모두 어떻게 Agile 가치를 핵심으로 갖고 있으며 몇 가지 가치, 아이디어, 관행을 서로 공유하는지 보여줍니다.
애자일 소프트웨어 개발 수명주기
Agile SDLC는 제품이 처음부터 끝까지 거치는 구조화된 일련의 단계입니다. 6단계로 구성됩니다.
1. 개념: 프로젝트 범위 및 우선순위 정의
2. 시작: 프로젝트 요구 사항에 따라 Agile 팀 구성
3. 반복: 고객 피드백을 고려한 코드 생성
4. 릴리스: 코드를 테스트하고 문제를 해결하세요. 이 모든 작업이 완료되면 제품의 최종 반복이 프로덕션에 출시될 수 있습니다.
5. 유지 관리: 제품의 서비스 가용성을 보장하기 위해 지속적인 기술 지원을 제공합니다
6. 단종: 제품 수명의 끝, 종종 새 제품의 시작과 동시에 발생합니다. 제품이 새로운 소프트웨어로 교체되거나 시스템 자체가 시간이 지남에 따라 더 이상 사용되지 않거나 조직과 호환되지 않는 경우 이 단계에 들어갑니다. 소프트웨어 개발 팀은 먼저 소프트웨어가 폐기된다는 사실을 사용자에게 알립니다. 교체가 있는 경우 사용자는 새 시스템으로 마이그레이션됩니다.
팀이 선택하는 프로젝트 관리 접근 방식에 따라 애자일 수명 주기가 조금씩 달라집니다. 예를 들어 스크럼 팀은 반복과 비슷한 스프린트라는 짧은 간격으로 운영됩니다. 또한 스크럼 마스터와 같이 명확하게 정의된 역할이 있습니다. 반면 칸반 팀은 필요한 역할 없이 연속적인 흐름처럼 운영됩니다. 익스트림 프로그래밍은 팀이 엔지니어링 기술의 우선순위를 정하고 더 짧은 반복으로 작업하는 또 다른 예입니다. 그러나 모든 소프트웨어 개발팀의 목표는 동일합니다. 바로 작동하는 소프트웨어를 사용자에게 적시에 제공하는 것입니다.
以上是解鎖敏捷：超越框架的詳細內容。更多資訊請關注PHP中文網其他相關文章！
