SCRUMにおけるプロジェクト管理

マテウシュ・レスニアク

SCRUMは経験的プロセス制御理論に基づくプロジェクトマネジメント手法であり、アジャイルマニフェスト（2001年）の価値観に合致する。これは制限的な作業方法論ではなく、最終的な形をストレートにイメージすることなくソフトウェアを提供できるフレームワークである。SCRUM方法論の主な利点は、要件変更のコストを最小限に抑え、すぐに使える可能性のある機能を迅速に提供することである。

どのように機能するのか？

実際のところ、これはプロセス全体が常に最適化され、そのニーズに適応していることを意味する。チームそして製品の全作業期間を通じてプロジェクト.管理責任製品開発は、プロダクトオーナー（PO）とデザインチームの間に広がっている。POは、製品開発の方向性に関する意思決定を行う責任者であり、製品の全体的な「ビジョン」を持っている。タスク管理は、カンバンボードに基づいて行われる。スプリント SCRUMボードと呼ばれる機能)。プロセスの各参加者は、バックログにタスクを追加することができるが、優先順位を設定する責任はOPにある。プロジェクトチームは、POのアイデアを具体的なタスクに「変換」し、その実施を計画する責任を負う。

サイクルの経過

プロセスは反復（スプリント）に分けられる。約2週間続く1つのスプリントの一部として、プロジェクトチームは事前に計画された機能の一部を実装し、テストします。

スプリントは "プランニング "から始まり、事前にPOがバックログの上位にグルーミングして設定したタスクをチームで議論し、準備する。その後、これらのタスクの難易度が見積もられ、難易度に応じてポイントが与えられる。チームの構成や作業条件が比較的一定しているため、各スプリントで実施されるポイント数は再現性があり、今後の作業計画を立てることができる。計画会議の最後に、1スプリント内で完了するポイント数の合計が多いタスクが選択され、新しいスプリントが開始される。

スクラム・ソフトウェア管理

スプリントの途中では、グルーミングが行われる。これは、OPがさらなる期待やアイデアをチームに提示するミーティングであり、プロジェクトチームはそれらを分析し、より小さなタスクに分解し、可能な提案をOPに提示する。将来のタスクを計画する際、OPはアナリスト、ユーザー、UX、グラフィックデザイナーに相談する。追加分析 (マーケットリサーチやデータサイエンス）がこの段階で必要になることが多い。いわゆるユーザーストーリーを分析・策定した後に初めて、POはそれらのストーリーをバックログとして公開する。ユーザーストーリーには、OPが与えられたタスクやタスク群に何を期待するのか、タスクが完了したかどうかを認識するためにどのような基準を用いるべきかという情報が含まれていなければならない。

スプリントの間、いわゆる「デイリースタンドアップミーティング」が毎日開催される。このミーティングで、各開発者はチームの他のメンバーに、直近の1日の作業内容を伝え、場合によっては、今後の作業を妨げる問題や障害について報告する。このように現在の状況を交換することで、さまざまなタスク間の潜在的な衝突をより早く発見することができ、開発者が問題に行き詰って作業が進まないという事態を避けることができる。デイリースタンドアップの前提は、できるだけ短く、しかし同時にその役割を果たすことである。ミーティングの常套句は、チームがそれを短く保つことを奨励する。

During the sprint, tasks are moved on the SCRUM board according to their current status. The choice of columns usually corresponds to the work system of the companies or the team and is associated with the version-control system and the frequency of releases. For us it is as follows:

To do - 完了待ちのタスク
進行中 - 現在進行中のタスク
コード review - 他の開発者によるチェックを待つタスク。
準備 - タスクが開発者によってチェックされ、承認される。
ステージング - ステージングインスタンスに配置され、POの承認を待つタスク
受理 - POが受理したタスク
完了 - 本番インスタンスに配置された準備完了のタスク

スプリントの後には、レトロスペクティブが行われる。これは作業の最適化に特化した会議である。チーム全員で、直前のスプリントでうまくいったこと、改善すべきことを話し合う。また、前回のレトロスペクティブを参照し、作業を改善するためのアイデアをすべて実行できたかどうかをチェックすることも多い。レトロスペクティブで議論される問題は、開発ツール、プレッシャー、タスクの難易度、コミュニケーションの問題（開発者とチーム、POの両方）など、多岐にわたります。

ソフトウェア開発プロジェクトにおけるスクラム

SCRUMマスターの責任

SCRUMプロセスの適切な実施の責任者はSCRUMマスターである。これはしばしばチームの中で最も理解しがたい役割である。SCRUMマスターには決定権がない。意思決定はチームとPOが共同で行い、SCRUMマスターの役割はプロセスの適切な進行の障害となるものを取り除くことである。

SCRUMマスターの職務には以下のようなものがある：

プランニング、グルーミング、デイリースタンドアップミーティング、レトロスペクティブを含むSCRUMミーティングの実施
SCRUMボード上のタスクがチームによって定期的に手入れされ、POによって優先順位が付けられるようにする。
チームとPOをつなぐ役割を果たす。そのため、プログラマーの言葉をビジネスの言葉に翻訳したり、逆にビジネスの言葉をプログラマーの言葉に翻訳したりするのが難しい役割を担っているのがSCRUMマスターであることが多い。これは、私たちの会社では、SCRUMマスターが開発者、つまり技術者であるという事実によるものである。SCRUMマスターの仕事の一般的な枠組みではその必要はない。
ミーティングでは、チームのトピック外れを阻止し、アジェンダを守る。
チーム内の雰囲気に気を配る - 主にミーティングで。
対立が生じた場合の解決

あわせて読みたい：