Agile-quick-guide
アジャイル-プライマー
アジャイルは、開発プロセスが変化するビジネスニーズに合わせられるように、1〜4週間の短い反復を使用してソフトウェアを段階的に構築するソフトウェア開発方法論です。 すべての要件とリスクを事前に予測する6〜18か月のシングルパス開発の代わりに、アジャイルは、1〜4週間の反復後に実行可能な製品が配信される頻繁なフィードバックのプロセスを採用します。
アジャイルの役割
スクラムマスター
スクラムマスターはチームリーダーであり、チームメンバーがアジャイルプラクティスに従ってコミットメントを達成できるように支援します。 スクラムマスターの責任は次のとおりです-
- すべての役割と機能間の緊密な協力を可能にするため。
- ブロックを削除します。
- チームを妨害から保護するため。
- 組織と協力して、会社の進捗とプロセスを追跡する。
- Agile Inspect＆Adaptプロセスが適切に活用されるようにするため
- 毎日のスタンドアップ、
- 計画会議、
- デモ、
- レビュー、
- 回顧会議
- チーム会議と意思決定プロセスを促進するため。
プロダクトオーナー
プロダクトオーナーは、ビジネスの観点からプロダクトを推進する人です。 責任または製品所有者は次のとおりです-
- 要件を定義し、それらの値に優先順位を付ける。
- リリース日と内容を決定します。
- 反復計画およびリリース計画会議で積極的な役割を果たす。
- チームが最も重要な要件に取り組んでいることを確認します。
- 顧客の声を表すため。
- 完了および定義済みの受け入れ基準の定義を満たすユーザーストーリーを受け入れます。
クロス機能チーム
すべてのアジャイルチームは、5〜9人のチームメンバーと6〜10年の平均経験を持つ自給自足のチームでなければなりません。 通常、アジャイルチームは3〜4人の開発者、1人のテスター、1人のテクニカルリード、1人の製品所有者、1人のスクラムマスターで構成されます。
プロダクトオーナーとスクラムマスターはチームインターフェイスの一部と見なされますが、他のメンバーはテクニカルインターフェイスの一部と見なされます。
アジャイルチームはどのように作業を計画しますか？
アジャイルチームは反復で作業し、各反復が10〜15日間のユーザーストーリーを提供します。 各ユーザーストーリーは、バックログの優先順位付けとサイズに基づいて計画されます。 チームはキャパシティ（チームがタスクに取り組むために使用できる時間）を使用して、計画する範囲を決定します。
ポイント
ポイントは、チームがコミットできる量を定義します。 ポイントは通常8時間を指します。 各ストーリーはポイントで推定されます。
容量
キャパシティは、個人がコミットできる量を定義します。 容量は時間単位で推定されます。
ユーザーストーリーとは何ですか？
ユーザーストーリーは、ユーザーが機能として必要とするものを定義する要件です。 ユーザーストーリーは2つの形式にすることができます-
- <ユーザーロール>として<機能>が必要なため、<ビジネス価値>
- <ビジネスの価値>を<ユーザーロール>として<機能性>にするには
リリース計画では、相対的なスケールをポイントとして使用して、ユーザーストーリーに大まかな見積もりが与えられます。 反復計画時に、ストーリーはタスクに分割されます。
ユーザーストーリーとタスクの関係
- ユーザーストーリーは何をすべきかについて語っています。 ユーザーが必要とするものを定義します。
- タスクは、それがどのように行われるべきかについて話します。 機能の実装方法を定義します。
- ストーリーはタスクによって実装されます。 各ストーリーはタスクのコレクションです。
- ユーザーストーリーは、現在の反復で計画されるときにタスクに分割されます。
- タスクの推定時間は、通常2〜12時間です。
- ストーリーは受け入れテストを使用して検証されます。
ストーリーが完了したら
チームは*完了*の意味を決定します。 基準は-
- すべてのタスク（開発、テスト）が完了しました。
- すべての受け入れテストが実行中であり、合格です。
- 欠陥はありません。
- 製品の所有者はこの話を受け入れました。
- エンドユーザーに配信可能。
受け入れ基準とは何ですか？
基準は、製品の所有者が受け入れられるように、機能に必要な機能、動作、およびパフォーマンスを定義します。 開発者がユーザーストーリーが完了したことを把握できるように、実行する内容を定義します。
要件はどのように定義されていますか？
要件は次のように定義されます
- ユーザーストーリー、
- 受入基準あり
- ストーリーを実装するタスク。
アジャイル-マニフェスト
2001年2月、ユタ州のスノーバードリゾートで17人のソフトウェア開発者が集まり、軽量な開発方法について議論しました。 彼らの会議の結果は、ソフトウェア開発のための以下のアジャイルマニフェストでした-
'__ 私たちは、ソフトウェアを開発し、他の人がそれを行うのを支援することにより、ソフトウェアを開発するより良い方法を発見しています。 この作業を通じて、私たちは価値になっています-
- プロセスとツールを介した個人と相互作用
- 包括的なドキュメントよりも機能するソフトウェア
- 契約交渉を介した顧客コラボレーション
- 計画の変更への対応
つまり、右側の項目には値がありますが、左側の項目にはさらに値を付けます。 '__
アジャイル宣言の12の原則
- 顧客満足度-貴重なソフトウェアを早期かつ継続的に提供することにより、顧客の要件を満たすために最優先されます。
- ようこそ変更-ソフトウェア開発中の変更は避けられません。 開発段階の終盤であっても、絶えず変化する要件を歓迎します。 アジャイルプロセスは、顧客の競争上の優位性を高めるために機能するはずです。
- 動作中のソフトウェアの配信-より短い時間スケールを考慮して、数週間から数か月に及ぶ動作中のソフトウェアを頻繁に配信します。
- コラボレーション-ビジネスの人々と開発者は、プロジェクトの全期間を通じて協力しなければなりません。
- 動機-プロジェクトは、やる気のある個人を中心に構築する必要があります。 個々のチームメンバーをサポートする環境を提供し、信頼できるようにして、彼らが仕事を成し遂げる責任を感じるようにします。
- 対面式の会話-対面式の会話は、開発チームに情報を伝える最も効率的かつ効果的な方法です。
- 動作中のソフトウェアごとに進捗状況を測定します-動作中のソフトウェアが重要であり、それが進捗状況の主要な指標である必要があります。
- 一定のペースを維持-アジャイルプロセスは持続可能な開発を目指しています。 ビジネス、開発者、およびユーザーは、プロジェクトを一定のペースで維持できる必要があります。
- 監視-敏technical性を高めるために、技術的な優秀さと優れた設計に定期的に注意を払ってください。
- シンプル-物事をシンプルに保ち、完了していない作業を測定するためにシンプルな用語を使用します。
- 自己組織化されたチーム-最適なアーキテクチャ、要件、および設計が自己組織化されたチームから生まれるため、アジャイルチームは自己組織化され、他のチームに大きく依存するべきではありません。
- 定期的に作業を確認-チームがより効果的になり、それに応じて行動を調整する方法を反映できるように、定期的に行われた作業を確認します。
アジャイル-特徴
反復的/漸進的で進化する準備ができている
アジャイル開発方法のほとんどは、問題を小さなタスクに分割します。 どの要件にも直接的な長期計画はありません。 通常、短期間の変動、たとえば1〜4週間の反復が計画されます。 計画、要件分析、設計、コーディング、単体テスト、受け入れテストなどのソフトウェア開発のすべての機能で機能する部門ごとのチームがイテレーションごとに作成されます。 反復の終了時の結果は実用的な製品であり、反復の終了時に利害関係者に示されます。
デモの後、レビューのコメントが取られ、必要に応じて作業ソフトウェアに組み込まれる予定です。
対面コミュニケーション
各アジャイルチームには、スクラム方法論の製品所有者などの顧客担当者が必要です。 この代表者は、利害関係者に代わって行動する権限があり、反復の間に開発者の質問に答えることができます。
情報ラジエーター（物理ディスプレイ）は、通例、通行人がアジャイルチームの進捗状況を確認できるオフィス内に目立つように配置されています。 この情報ラジエーターには、プロジェクトのステータスの最新の概要が表示されます。
フィードバックループ
毎日の立ち上がりは、アジャイル開発の一般的な文化です。 *デイリースクラム*とも呼ばれます。 これは、各チームメンバーが互いに行ったこと、次に行うこと、および直面している問題についてステータスを報告する短いセッションのようなものです。
アジャイル-毎日のスタンドアップ
名前が示すように、毎日の立ち上がりは、アジャイルチームのすべてのメンバー間での毎日のステータス会議です。 定期的な更新のためのフォーラムを提供するだけでなく、チームメンバーの問題に焦点を合わせて、迅速に対処できるようにします。 オフィスの場所に関係なく、アジャイルチームがどのように設立されても、毎日の立ち上げは必須の方法です。
デイリースタンドアップとは何ですか？
- 毎日のスタンドアップは、すべてのチームメンバー間の毎日のステータスミーティングであり、約15分間開催されます。
- すべてのメンバーは3つの重要な質問に答えなければなりません-
- 昨日やったことは？
- 今日は何をしますか？
- 私が直面している障害…/私は…のためにブロックされています
- 毎日のスタンドアップはステータスの更新のためであり、議論のためではありません。 ディスカッションのために、チームメンバーは別の時間に別の会議をスケジュールする必要があります。
- 参加者は通常、座る代わりに立ち、会議がすぐに終わるようにします。
スタンドアップが重要な理由
アジャイルで毎日立ち上がることの利点は次のとおりです-
- チームは毎日進捗状況を評価し、反復計画に従って成果を上げることができるかどうかを確認できます。
- 各チームメンバーは、その日のコミットメントについてすべて通知します。
- 遅延や障害についてチームに可視性を提供します。
誰がスタンドアップに参加しますか？
- スクラムマスター、製品所有者、および配信チームは、毎日スタンドアップに参加する必要があります。
- 利害関係者と顧客は会議に出席するよう奨励されており、オブザーバーとして行動できますが、スタンドアップに参加することは想定されていません。
- 各チームメンバーのクエリと直面している問題に注意することは、スクラムマスターの責任です。
地理的に分散したチーム
アジャイルチームメンバーが異なるタイムゾーンから運用している場合、スタンドアップは複数の方法で実行できます-
- 異なるタイムゾーンにあるチームのスタンドアップミーティングに参加できるメンバーを順番に選択します。
- チームごとに独立したスタンドアップを用意し、Rally、SharePoint、Wikiなどのツールでスタンドアップのステータスを更新します。
- 電話会議、ビデオ会議、インスタントメッセンジャー、その他のサードパーティの知識共有ツールなど、さまざまなコミュニケーションツールを用意してください。
アジャイル-完了の定義
ユーザーストーリー、反復、およびリリースの*完了*の定義を以下に示します。
ユーザーストーリー
ユーザーストーリーは、ユーザーの日常言語で数文で定式化される要件であり、反復の中で完了する必要があります。 ユーザーストーリーは次の場合に行われます
- すべての関連コードがチェックインされています。
- すべてのユニットテストケースに合格しました。
- すべての受け入れテストケースに合格しました。
- ヘルプテキストが書き込まれます。
- プロダクトオーナーがストーリーを受け入れました。
繰り返し
反復とは、製品のリリース内で作業し、受け入れられるユーザーストーリー/欠陥のタイムボックス化されたコレクションです。 反復は、反復計画会議で定義され、反復デモおよびレビュー会議で完了します。 反復は*スプリント*とも呼ばれます。 反復は次の場合に行われます
- 製品のバックアップが完了しました。
- パフォーマンスがテストされました。
- ユーザーストーリーは受け入れられたか、次の反復に移されました。
- 欠陥は修正されたか、次の反復に延期されました。
リリース
リリースは、テスト済みの製品/システムのバージョンの内部または外部への配信を表す主要なマイルストーンです。 リリースは次の場合に行われます
- システムはストレステストされています。
- パフォーマンスが調整されます。
- セキュリティ検証が実行されます。
- 災害復旧計画がテストされています。
アジャイル-リリース計画
リリース計画の目的は、製品に増分を提供する計画を作成することです。 2〜3か月ごとに行われます。
誰が関与していますか？
- スクラムマスター-スクラムマスターは、アジャイルデリバリーチームのファシリテーターとして機能します。
- 製品所有者-製品所有者は、製品バックログの一般的なビューを表します。
- アジャイルチーム-アジャイルデリバリーチームは、技術的な実現可能性または依存関係に関する洞察を提供します。
- 利害関係者-顧客、プログラム管理者、主題の専門家などの利害関係者は、リリース計画に関する決定が下される際にアドバイザーとして機能します。
計画の前提条件
リリース計画の前提条件は次のとおりです-
- プロダクトオーナーが管理する、ランク付けされたプロダクトバックログ。 一般に、リリースに含めることができると製品所有者が感じる5〜10個の機能が使用されます。
- 能力、既知の速度、または技術的な課題に関するチームの意見
- 高レベルのビジョン
- 市場およびビジネス目標
- 新製品のバックログアイテムが必要かどうかの確認
必要な材料
リリース計画に必要な材料のリストは次のとおりです-
- 投稿された議題、目的
- フリップチャート、ホワイトボード、マーカー
- プロジェクター、計画会議中に必要なデータ/ツールを備えたコンピューターを共有する方法
- 計画データ
計画データ
リリース計画を行うために必要なデータのリストは次のとおりです-
- 以前の反復またはリリース計画の結果
- 製品、市場状況、期限に関するさまざまな利害関係者からのフィードバック
- 以前のリリース/反復のアクションプラン
- 考慮すべき機能または欠陥
- 以前のリリース/推定からの速度。
- 組織カレンダーと個人カレンダー
- 依存関係を管理するための他のチームおよび主題の専門家からの情報
出力
リリース計画の出力は次のようにすることができます-
- リリース計画
- コミットメント
- 監視される問題、懸念、依存関係、および仮定
- 将来のリリース計画を改善するための提案
議題
リリース計画の議題はすることができます-
- 開会式-ウェルカムメッセージ、レビューの目的と議題、ツールの整理、ビジネススポンサーの紹介。
- 製品ビジョン、ロードマップ-製品の全体像を示します。
- 以前のリリースを確認-計画に影響を与える可能性のある項目に関する議論。
- リリース名/テーマ-ロードマップテーマの現在のステータスを調べ、必要に応じて必要な調整を行います。
- 速度-現在のリリースと以前のリリースの速度を表示します。
- リリーススケジュール-リリースの主要なマイルストーンとタイムボックスの決定とリリース内の反復を確認します。
- 問題と懸念-懸念や問題を確認して記録します。
- 完了の定義の確認と更新-*完了*の定義を確認し、技術、スキル、または前回のイテレーション/リリース以降のチームメンバーの変更に基づいて適切な変更を行います。
- 考慮すべきストーリーとアイテム-現在のリリースでスケジューリングするために考慮される製品バックログのユーザーストーリーと機能を提示します。
- サイジング値の決定-速度が不明な場合、リリース計画で使用されるサイジング値を計画します。
- ストーリーのサイズを粗くする-配信チームは、検討中のストーリーの適切なサイズを決定し、ストーリーが大きすぎる場合は、ストーリーを複数の反復に分割します。 製品の所有者と主題の専門家は、疑念を明確にし、受け入れ基準を詳述し、適切なストーリー分割を行います。 スクラムマスターは、コラボレーションを促進します。
- ストーリーをイテレーションにマップ-配信チームと製品所有者は、サイズと速度に基づいて、イテレーションのストーリー/欠陥を移動します。 スクラムマスターは、コラボレーションを促進します。
- 新しい懸念事項または問題-過去の経験に基づいて新しい問題を確認し、記録します。
- 依存関係と仮定-リリース計画中に計画された依存関係/仮定を確認します。
- コミット-スクラムマスターが計画を要求します。 配信チームと製品所有者は、それを最適な計画として通知し、次のレベルの計画、つまり反復計画に移行することを約束します。
- 通信および物流計画-リリースの通信および物流計画を確認/更新します。
- 駐車場-駐車場を処理すると、すべてのアイテムを解決するか、アクションアイテムとして設定する必要があります。
- アクションアイテムとアクションプランの配布-アクションアイテムを所有者に配布し、アクションプランを処理します。
- Retrospect -会議を成功させるために、参加者からのフィードバックを求めます。
- 閉じる-成功を祝います。
アジャイル-反復計画
反復計画の目的は、チームがトップランクの製品バックログ項目のセットを完了することです。 このコミットメントは、反復の長さとチームの速度に基づいてタイムボックス化されます。
誰が関与していますか？
- スクラムマスター-スクラムマスターは、アジャイルデリバリーチームのファシリテーターとして機能します。
- 製品所有者-製品所有者は、製品バックログの詳細ビューとその受け入れ基準を扱います。
- アジャイルチーム-アジャイル配信は、タスクを定義し、コミットメントを達成するために必要な労力の見積もりを設定します。
計画の前提条件
- 製品バックログのアイテムにはサイズがあり、相対的なストーリーポイントが割り当てられています。
- 製品所有者によってポートフォリオアイテムにランキングが与えられています。
- 各ポートフォリオ項目の受け入れ基準が明確に記載されています。
計画プロセス
以下は、反復計画に含まれるステップです-
- 反復に適合するストーリー数を決定します。
- これらのストーリーをタスクに分割し、各タスクを所有者に割り当てます。
- 各タスクには、時間単位の見積もりが与えられます。
- これらの見積もりは、チームメンバーが各メンバーが反復に費やすタスク時間をチェックするのに役立ちます。
- チームメンバーには、過負荷にならないように、速度や能力を考慮したタスクが割り当てられます。
速度計算
アジャイルチームは、過去の反復に基づいて速度を計算します。 Velocityは、反復でユーザーストーリーを完了するために必要なユニットの平均数です。 たとえば、チームが最後の3回の反復で各反復で12、14、10ストーリーポイントを使用した場合、チームは次の反復の速度として12を使用できます。
計画速度は、現在の反復でいくつのユーザーストーリーを完了することができるかをチームに伝えます。 チームが割り当てられたタスクをすばやく完了すると、より多くのユーザーストーリーを取り込むことができます。 それ以外の場合、ストーリーも次の反復に移動できます。
タスク容量
チームの能力は、次の3つの事実から派生しています-
- 1日の理想的な労働時間数
- 反復における利用可能な日数
- メンバーがチーム専用に利用できる時間の割合。
チームに5人のメンバーがいて、プロジェクトでフルタイム（1日8時間）働くことを約束し、反復中に誰も休暇を取らないと仮定すると、2週間の反復のタスクキャパシティは-
5×8×10 = 400時間
計画ステップ
- 製品所有者は、製品バックログの最高ランクのアイテムを説明します。
- チームは、アイテムを完了するために必要なタスクを説明します。
- チームメンバーがタスクを所有します。
- チームメンバーは、各タスクを完了する時間を見積もります。
- これらの手順は、反復のすべてのアイテムに対して繰り返されます。
- 個人がタスクで過負荷になった場合、そのタスクは他のチームメンバーに分散されます。
アジャイル-製品バックログ
製品バックログは、実行するアイテムのリストです。 アイテムは機能の説明でランク付けされます。 理想的なシナリオでは、アイテムをユーザーストーリーに分解する必要があります。
製品バックログが重要な理由
- 各機能に推定値を提供できるように準備されています。
- 製品のロードマップの計画に役立ちます。
- 製品により多くの価値を追加できるように、機能を再ランク付けするのに役立ちます。
- 最初に何を優先するかを決定するのに役立ちます。 チームはアイテムをランク付けし、価値を構築します。
製品バックログの特性
- 各製品には、大規模から大規模な一連の機能を持つことができる1つの製品バックログが必要です。
- 複数のチームが単一の製品バックログに取り組むことができます。
- 機能のランク付けは、ビジネス価値、技術的価値、リスク管理、または戦略的適合性に基づいて行われます。
- 最高ランクのアイテムは、リリース計画時に小さなストーリーに分解され、将来の反復で完了することができます。
アジャイル-便利な用語
合否基準
機能が有効で、要件を満たしていることを受け入れるために、製品所有者または顧客によって設定される条件です。
バックロググルーミング
これは、製品マネージャーまたは顧客がアジャイルチームからフィードバックを取得して製品のバックログを管理する継続的なプロセスです。 このプロセスには、ポートフォリオアイテムの優先順位付け、小さなアイテムへの分割、将来の反復のための計画、新しいストーリーの作成、受け入れ基準の更新、または受け入れ基準の詳細な作成が含まれます。
容量
チームが1回の反復で完了することができる作業量です。
特徴
リリースで開発できる、利害関係者にとって価値のある製品または機能に対して行われた改善。
繰り返し
タイムボックス内で完了でき、製品のリリース内で受け入れられるテーマベースのワークアイテム。 反復作業は、反復計画時に定義され、デモとレビュー会議で終了します。 スプリントとも呼ばれます。
インクリメント
増分とは、製品が徐々に開発されるにつれて変化する状態です。 通常、マイルストーンまたは固定反復の数で表されます。
プロダクトオーナー
製品所有者はアジャイル配信チームのメンバーであり、製品バックログでビジネス要件を収集してランク付けする責任があります。 製品所有者は、リリース/イテレーションで行われることを伝えます。 彼/彼女はコミットメントを設定し、反復中の要件の変更からチームを保護する責任があります。
製品バックログ
機能および非機能製品の要件のセット。
製品バックログアイテム
ユーザーストーリー、欠陥、アジャイルチームによって開発される機能である可能性があります。
ポイント
ユーザーストーリー、機能、またはその他のポートフォリオアイテムの相対的なサイズを設定するために使用される一般的な単位。
リリース
テスト可能な増分のソフトウェアへの配信をサポートするために作業が行われるタイムボックス。 スクラムでは、リリースは複数の反復で構成されます。
要件
所定の契約または機能を満たすソフトウェア製品の仕様。 ユーザーストーリーとポートフォリオアイテムは、要件の種類です。
ストーリーポイント
アジャイルチームがユーザーストーリーと機能の相対的なサイズを推定するために使用する単位。
スプリント
反復と同じ。
タイムボックス
成果物が開発される固定期間。 通常、タイムボックスの開始日と終了日を修正するとともに、リソースの数も修正されます。
Task
これは、反復内のユーザーストーリーの完成に貢献する作業単位です。 ユーザーストーリーは複数のタスクに分解され、各タスクをチームメンバー間で分割して、タスクの所有者としてマークできます。 チームメンバーは、各タスクの責任を負い、見積りを更新し、必要に応じて完了した作業または予定を記録できます。
ユーザーストーリー
ユーザーの特定の要件を満たすためにリストされた受け入れ基準。 通常、エンドユーザーの観点から書かれています。
速度
反復またはタイムボックスで受け入れられた作業に重み付けする尺度。 通常、反復で受け入れられるストーリーポイントの合計です。
