スクラムアジャイル開発に関する簡単な説明: 4 つの入力/出力、3 つの主要オブジェクト、3 つの会議

この記事では、スクラム アジャイル開発プロセスを体系的に分析します。この記事がアジャイル開発に対する理解を深め、製品開発をより効率的に行う一助となれば幸いです。

[[211673]]

Scrum アジャイル開発は、アジャイル開発フレームワークです。これは、視覚的、統合可能、かつ操作可能な増分的かつ反復的な開発プロセスです。従来のウォーターフォール開発モデルとは異なり、複雑なシステムのローカル モジュールに対して短く高速なバージョン反復を行うことで、予想される市場需要の検証に迅速に対応することを優先します。

図からわかるように、主なプロセスは次のとおりです。

この製品は、ユーザーのニーズを分析し、商業的価値順にニーズを推定し、計画されている製品機能のリストを出力します。

企画会議での議論を経て、企画パネルに沿って機能リストを整理し、製品バージョンの反復タスクを出力します。

開発反復サイクルに入り、タスクパネルに従って増分反復開発を実行し、成果物の反復バージョンを出力します。

レビューと承認フェーズに入り、リリースパネルに従って問題の原因をまとめ、反復サイクルレポートデータを出力します。

上記のプロセスから、入力/出力が 4 つ、主要なオブジェクトが 3 つ、会議が 3 つあることがわかります。これらの内容を一つずつ見ていきましょう。

4つの入力/出力

1. ユーザーニーズ、分析と変換、製品バックログ

PMはこの部分の内容を担当し、主な作業内容は以下のとおりです。

ユーザー調査と需要分析を実施して、製品の反復機能を決定し、製品のバックログを発行します。

製品のリリース日とコンテンツを決定し、反復計画の目標を設定します。

RIO（ビジネス価値/労力）に基づいて優先順位を付け、必要なリスクを考慮します。

スプリント計画を策定し、実際の状況に基づいて機能と優先順位を調整します。

2. 製品バックログ、スプリント計画会議、スプリントバックログ

この部分の内容は主に開発マネージャーの担当となり、主な業務内容は以下のとおりです。

製品の BACKLOG を、このスプリントで改良できる Sprint BACKLOG に分割します。

スプリント バックログの開発タスクは時間単位で見積もられ、1 ～ 16 時間の作業が定量化されることが予想されます。

開発の優先順位に応じてスプリント バックログを管理し、いつでもスプリント バックログのステータスを更新します。

各チームメンバーはタスクを選択し、スプリント BACKLOG を個別に変更できます。

3. スプリントバックログ、反復開発サイクル、成果物の反復バージョン

この部分は開発チームが主体となって推進しており、主な作業内容は以下のとおりです。

スプリントバックログに従って開発作業を開始し、作業タスクボードを更新します。

毎日の会議に参加し、各チームの全体的な開発進捗と問題点を明らかにします。

全体的な開発の進行が、事前に設定されたスプリント バーンダウン チャートから大幅に逸脱しないことを確認します。

高度な自己組織化管理、機能横断的なチームコミュニケーションの維持により、スプリント目標の達成を確実にします。

4. リリース版の承認、レビュー会議、定期的なデータレポート

このパートは主にスプリントチームメンバーが参加し、主な作業内容は以下のとおりです。

製品開発チームは、スプリントで完成した機能とアーキテクチャを運用デモンストレーションを通じて実証します。

PM は、製品 BACKLOG に従って開発によって配信された反復バージョンを受け入れ、製品の反復バージョンをリリースします。

スプリントの問題に関するフィードバックを収集し、根本原因を見つけ、解決策を話し合い、スプリント プロセスを改善します。

3つの重要な項目 1. 製品バックログ

製品所有者によって維持および管理される、並べ替えられ、見積もられ、段階的に進む要件のリスト。 PRD ドキュメント内の機能モジュール レコード リストまたは製品要件プールのレコード リストを参照できます。一般的に、BACKLOG エントリの内容は、機能モジュールに対応するユーザー ストーリー フローに従って表現されます。各スプリントの終了時、または一時的な要件が変更された場合は、優先順位を更新する必要があります。

図に示すように:

2.スプリントバックログ

開発マネージャーによって維持および管理されるスプリント タスク リストは、製品のバックログに基づいて調整され、開発プロセス中に利用可能な製品機能タスクに分割されます。各タスクは時間単位で見積もられます。チームメンバーは自分でタスクを管理でき、毎日のタスクの進捗状況は対応するタスクパネルに更新されます。

図に示すように:

3. バーンダウンチャート

バーンダウン チャートは、スプリント サイクル内の作業時間/作業負荷を示す 2 次元チャートです。これは主に、スプリントの期限前に残りの開発作業負荷の全体的な状況をチームメンバーに理解させるために使用されます。実際のバーンダウンチャートと理想的なバーンダウンチャートを比較することで、開発のリズムを素早く調整し、スプリントバージョンの配信のリスクを軽減できます。

図に示すように:

3回の会議 1. スプリント計画会議（目標の明確化とタスクの絞り込み）

スプリント計画会議では、スプリントの目標とスプリント BACKLOG を明確にする必要があります。議論する際には、チームの受け入れ度合い、開発スピード、技術レベル、ビジネス条件などを考慮し、スプリントの納期、増分反復開発タスク、製品バージョンの反復内容などを事前に決定する必要があります。

2. スプリントデイリーミーティング（場所固定、時間固定、全員参加、短時間ミーティング、効率的）

毎日のスクラム ミーティングは、場所と時間が固定され、チーム メンバー全員が参加するチーム コミュニケーションの一形態です。会議は約15分間続きます。スピーチは、昨日の進捗、今日のスケジュール、そして遭遇した困難という 3 つの側面に焦点を当てています。タスクボード上の作業内容をすぐに確認できます。遭遇した困難は会議後に個別に議論され、解決されます。各会議では、スプリント サイクル (2 ～ 4 週間) 内の開発の進捗状況に関するフィードバックが提供され、このサイクル中にタスク ボードが頻繁に更新されます。

タスクパネルは、「タスクの状態/作業の進捗」を2次元で表示する作業パネルです。付箋の色はチームメンバーを表し、付箋の内容はチームメンバーが担当する開発タスクを表します。タスクのステータスは通常、ToDo、実行中、テスト済み、レビュー済み、完了の 5 つの状態に分けられます。タスク パネルのステータスをいつでも更新できるように、四角い領域に色付きの付箋が貼られ、チーム メンバー全員がいつでもどこでもスプリント サイクル内の全体的な開発の進捗状況を把握できるようになります。

図に示すように:

3.スプリントレビューミーティング

スプリントレビュー会議は、主に 2 つの部分で構成されます。1 つはスプリントの配信バージョンと計画バージョンを承認すること、もう 1 つはその後のスプリントの開発と構築をまとめ、改善することです。

アジャイル開発に関する私の見解

私の意見では、チームコラボレーション手法としてのアジャイル開発には、効率性と明確さという 2 つの特に明らかな特徴があります。アジャイル開発のコンセプトでスプリント作業を開始するチームは、間違いなくプラスの開発 BUFF ボーナスを得ることになります。私たちが取り組む必要があるのは、アジャイル開発プロセスを導入し、ボーナスのメリットを最大化する方法なのです。アジャイル開発では、全員が明確な目標、完璧な技術的能力、強力な実行力を備えているため、エリート チームのメリットが最大化されることに同意します。これは最も理想的な動作モデルです。しかし、現実の非理想的な作業モデルでは、次の側面からこのチーム追加の効果を強化することができます。

製品 BACKLOG のソースは可能な限り正確である必要があり、できれば明確なデータ分析結果を裏付けとして提供する必要があります。スプリント BACKALOG のタスクは、その後のスプリントの反復中にチームの作業目標が明確かつ具体的であることを保証するために、可能な限り詳細に記述する必要があります。誰も自分の仕事量が KPI ではなく無駄な仕事になってしまうことを望んでいないので、それはチームの士気にとって大きな打撃となります。このような状況が依然として発生する場合、スプリント リーダーは積極的に全員の感情をそらし、できるだけ早く次のより適切なスプリント サイクルに入るように全員を説得する必要があります。

機能チーム間の正確で対称的な情報伝達を確保するには、チーム メンバー間で前向きなコミュニケーションの雰囲気を作り出す必要があります。アジャイル開発では、開発プロセス中の柔軟性を確保するために、効率性を重視してメンバーのワークフローにあまり多くの制約を課さないことがよくあります。要件は反復プロセス中にいつでも変更される可能性があります。開発タスク リストはチーム メンバーが独立して選択でき、タスク パネルはメンバーが独立して更新できます。コミュニケーションを重視した仕事モードです。

中国における中国の特色ある社会主義の建設に関しては、非理想的な作業モデルの下では、チームメンバーが受動的に仕事の割り当てを選択する傾向が強い。開発マネージャーは、チームメンバーの能力次元に基づいて作業タスクリストを合理的に整理し、チームメンバーが能力を制御できなくなることによる進捗の遅れ、作業効率の低下、仕事への過度の感情など、チームビルディングに役立たない状況を回避するように努める必要があります。

チームメンバーの構成構造は、スプリントサイクル中は可能な限り変更しないようにする必要があります。特に、中核となるリーダーメンバーは変更しないでください。スプリント サイクル中は、チーム全体の開発の焦点を非常に集中させる必要があります。この時点でチームのリーダーメンバーが交代すると、コミュニケーションコストの損失が確実に発生し、全体的な反復効率に影響を及ぼします。

スプリント開発プロセスでは、会議の頻度と期間を適切に管理する必要があります。私はこれまで数多くの仕事の会議に参加してきましたが、一部の会議の RIO は比例しておらず、時間がかかり、仕事の計画にプラスの成果が生まれないと個人的に感じています。多くの人が不満を言い、会議に出席したがらないのは、多くの場合これが理由です。担当者は毎回会議をリードし、会議関連のデータレポートの入出力をきちんと行い、結果を段階的に提示し、チームに積極的かつ前向きな会議フィードバックを与えるのがベストです。