なぜリモート開発チームが必要なのか?
コスト効率、グローバル人材へのアクセス、柔軟性など、リモート開発チームを統合するメリットと戦略を探る。
SCRUMは経験的プロセス制御理論に基づくプロジェクトマネジメント手法であり、アジャイルマニフェスト(2001年)の価値観に合致する。これは制限的な作業方法論ではなく、最終的な形をストレートにイメージすることなくソフトウェアを提供できるフレームワークである。SCRUM方法論の主な利点は、要件変更のコストを最小限に抑え、すぐに使える可能性のある機能を迅速に提供することである。
実際のところ、これはプロセス全体が常に最適化され、そのニーズに適応していることを意味する。 チーム そして 製品 の全作業期間を通じて プロジェクト.管理責任 製品開発 は、プロダクトオーナー(PO)とデザインチームの間に広がっている。POは、製品開発の方向性に関する意思決定を行う責任者であり、製品の全体的な「ビジョン」を持っている。タスク管理は、カンバンボードに基づいて行われる。 スプリント SCRUMボードと呼ばれる機能)。プロセスの各参加者は、バックログにタスクを追加することができるが、優先順位を設定する責任はOPにある。プロジェクトチームは、POのアイデアを具体的なタスクに「変換」し、その実施を計画する責任を負う。
プロセスは反復(スプリント)に分けられる。約2週間続く1つのスプリントの一部として、プロジェクトチームは事前に計画された機能の一部を実装し、テストします。
スプリントは "プランニング "から始まり、事前にPOがバックログの上位にグルーミングして設定したタスクをチームで議論し、準備する。その後、これらのタスクの難易度が見積もられ、難易度に応じてポイントが与えられる。チームの構成や作業条件が比較的一定しているため、各スプリントで実施されるポイント数は再現性があり、今後の作業計画を立てることができる。計画会議の最後に、1スプリント内で完了するポイント数の合計が多いタスクが選択され、新しいスプリントが開始される。
スプリントの途中では、グルーミングが行われる。これは、OPがさらなる期待やアイデアをチームに提示するミーティングであり、プロジェクトチームはそれらを分析し、より小さなタスクに分解し、可能な提案をOPに提示する。将来のタスクを計画する際、OPはアナリスト、ユーザー、UX、グラフィックデザイナーに相談する。追加分析 (マーケット リサーチやデータサイエンス)がこの段階で必要になることが多い。いわゆるユーザーストーリーを分析・策定した後に初めて、POはそれらのストーリーをバックログとして公開する。ユーザーストーリーには、OPが与えられたタスクやタスク群に何を期待するのか、タスクが完了したかどうかを認識するためにどのような基準を用いるべきかという情報が含まれていなければならない。
スプリントの間、いわゆる「デイリースタンドアップミーティング」が毎日開催される。このミーティングで、各開発者はチームの他のメンバーに、直近の1日の作業内容を伝え、場合によっては、今後の作業を妨げる問題や障害について報告する。このように現在の状況を交換することで、さまざまなタスク間の潜在的な衝突をより早く発見することができ、開発者が問題に行き詰って作業が進まないという事態を避けることができる。デイリースタンドアップの前提は、できるだけ短く、しかし同時にその役割を果たすことである。ミーティングの常套句は、チームがそれを短く保つことを奨励する。
スプリントの間、タスクは現在のステータスに従ってSCRUMボード上で移動される。列の選択は通常、企業やチームの作業システムに対応し、バージョン管理システムやリリースの頻度に関連する。私たちの場合は以下のようになります:
スプリントの後には、レトロスペクティブが行われる。これは作業の最適化に特化した会議である。チーム全員で、直前のスプリントでうまくいったこと、改善すべきことを話し合う。また、前回のレトロスペクティブを参照し、作業を改善するためのアイデアをすべて実行できたかどうかをチェックすることも多い。レトロスペクティブで議論される問題は、開発ツール、プレッシャー、タスクの難易度、コミュニケーションの問題(開発者とチーム、POの両方)など、多岐にわたります。
SCRUMプロセスの適切な実施の責任者はSCRUMマスターである。これはしばしばチームの中で最も理解しがたい役割である。SCRUMマスターには決定権がない。意思決定はチームとPOが共同で行い、SCRUMマスターの役割はプロセスの適切な進行の障害となるものを取り除くことである。
SCRUMマスターの職務には以下のようなものがある:
あわせて読みたい: