の基本的な手順はAgile software development
何ですか?
また、アジャイル手法を使用して新しいプロジェクトを開始するにはどうすればよいでしょうか?
10 に答える
OP、「アジャイル ソフトウェア開発」の段階的なガイドは文書化されておらず、マニフェストに沿った手順はすべてアジャイルとみなされます。
しかし、始めるには、学習の「手持ち」/「本による」段階が必要であることも理解しています. そのため、現在の開発プロセスを確認することをお勧めします。多くの時間を浪費している「無駄な」活動を見つけ出し、その活動に費やされた時間を相殺/最小化するアジャイルな実践を取り入れてください。たとえば、ビルドの問題に日常的に取り組んでいる場合は、最初に継続的インテグレーション サーバーをセットアップし、厳格なチェックインの事前スクリーニングをセットアップします。誰もが迷いや疎外感を感じるようにすべてを変えるのではなく、
- 一度に1つの練習を拾う
- それに約2〜3週間投資してください..慣れてください
- チームの全員が役に立ったと感じているかどうかを確認してください。もしそうなら、それに固執し、それをあなたの新しいプロセスの一部にしてください。それ以外の場合は、破棄して見つけ、別の代替手段に置き換えます。
チーム全体がアジャイルに慣れていない場合は、お勧めします (強度の順に)
- アジャイル開発者の実践 (Andy Hunt、Venkat S.、薄い本、初心者向けの高い価値対ページ比率)
- アジャイル原則の実践とパターン (Robert & Micah Martin)
- TDD (beck, astels, et.all)、リファクタリング (Fowler, Joshua K.) など、莫大な成果が期待できる特定のプラクティスについて、毎週「Getting Better」セッションを実施します。
- XP Embrace Change - Beck、Poppendieck の Lean Books、Agile S/w Development - Alistair Cockburn、Peopleware - DeMarco、Lister などの哲学書を探しましょう。
ここにリストされている本を参照することをお勧めします
アジャイルの原則を紹介する「Autumn of Agile 」というスクリーンキャスト シリーズがあります。まだエピソード数は多くありませんが、エピソード計画は次のようになります。
- アジャイルの価値と実践の概要
- オブジェクト指向の基本的な設計原則
- 実際の設計パターン
- 単体テストの基礎
- モック オブジェクト
- TDD
- プロジェクトファイル/フォルダー構成
- ソース管理の基本
- 継続的インテグレーション / ビルドの自動化
- アジャイル プロジェクト計画の原則
- ドメイン駆動設計のコア概念の概要
Henrik Kniberg が、すばやく簡単に読める短い PDFをまとめました。あなたはそれを読むことから始めることができます。あなたの質問に対する答えと、それ以上のものを得ることができます。
Gregory S. Smith による記事「Creating an Agile Environment」( http://www.methodsandtools.com/archive/archive.php?id=70 ) とビデオ「Transition To Agile Methodology In The Enterprise」( http ://www.renewtek.com/index.php?page=agile-methodology-in-the-enterprise )
アジャイル ソフトウェア開発アプローチを採用する最善の方法は、現在の状況によって大きく異なります。なぜアジャイルを採用したいのですか? あなたにとって最も重要なメリットは何ですか? 解決しなければならない最大の問題は何ですか? 破壊的な一括導入を行うためのリソースはありますか? それとも、時間のかかる、潜在的により痛みを伴う漸進的な導入から始めることを好みますか?
「アジャイル導入パターン」という本を強くお勧めします。どの導入アプローチが自分に適しているかを考えるのに役立ちます。また、アジャイル開発に詳しい人、つまりチームを観察し、パターンとアンチパターンを見て、それらに対処する方法についての経験を提供できる人から直接 (オンサイトで) 助けを得ることも良い考えです。
最初の 1 つとして私が常に採用したいと考えているプラクティスの 1 つは、反復回顧展です。これらは、アジャイル アプローチの適応サイクルに不可欠です。
robert marin による "Agile Software Development, Principles, Patterns, and Practices" をご覧ください。Java と ac# のバージョンがあります。http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445
この本に対するIljaの2番目の推奨事項:http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521
この本の中で最も価値のあるものは、特定のビジネス価値(品質、市場投入までの時間など)を達成するために最初に採用するプラクティスの説明だと思います。
本のレビュー:http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521 サンプルチャプター:http ://www.informit.com/store/product.aspx?isbn = 0321514521 #info8
最後に、groups.yahoo.comのアジャイルメーリングリストに参加してください。ScrumDevelopmentまたはAgileProjectManagementのいずれかがニーズに適しています。
機敏であるかどうかにかかわらず、多かれ少なかれ機敏です。
すでに行っていることからさらにアジャイルになるには、
- さらに視覚化する (画面上のメトリック、ビジュアル ボードなど)
- より多くのフィードバックを取得し、フィードバック ループを短縮します (CI、コード メトリクス、バグ メトリクスなど)。
- 同時進行中の作業 (WIP) の量を減らします。つまり、個人レベルとチーム レベルの両方でマルチタスクを減らします。
何か新しいことに挑戦できるなら、かんばんをお勧めします。これは最も規範的ではなく、最も柔軟なアジャイル ツールであり、ワークフローを視覚化することから始めて、WIP を制限するだけです。
最良の方法は、技術的に経験豊富なアジャイル コーチを雇うことです。採用したいアジャイル手法 (スクラム、XP、クリスタル、かんばんなど) を以前に実行したことがある人を、チームで作業してもらいます。彼らはあなたの労働環境を確認する必要があります - そして、できれば助けになる環境で働きます. 彼らの参考文献をチェックして、彼らが実際にそれを実際に使用していることを確認してください。たくさんのワナビーと偽物。
チームに経験豊富な誰かがいると、すべての違いが生まれます。本を読んだだけで身につけるのは至難の業です。文化を変えようとしているのに、チェックリストやアルゴリズムを使ってそれを行うことはできません。それは社会的な複雑さです。あなたは複雑なシステムで緊急の行動を奨励しようとしています.
アジャイル コーチを雇うことができない場合は、チーム内、またはあなたの部署や会社で経験のある他の人を見つけて、彼らをチームに招待してください。あなたの状況を彼らに見せて、彼らの意見を聞いてください。
チームが異なれば、必要なアドバイスも異なります。それは、チーム メンバー、使用するテクノロジーの種類、業務の種類など、さまざまな要因によって異なります。
何よりも、地元のアジリストと連絡を取り、顔を合わせて学びます。
私は多くのアジャイル本を読みましたが、その中で本当にお勧めできる本は、James Shore 著の「The Art of Agile Development」です。