ウォーターフォールでしか開発実績がない企業へのスクラム導入実績あり！スクラムは現状把握をするためのフレームワークです
マンハッタンコードでエンジニアをしてるJ.J. ( @MHTcode_JJ )です。
弊社マンハッタンコードではアジャイル（スクラム）開発を開発手法の基準としています。タイトルにある通りウォーターフォールしか開発実績のない企業へのスクラム導入も開発支援の範囲とし、サービス展開しています。
そんな中で、既にアジャイル（スクラム）開発をしている企業様への開発支援も行っているのですが「スクラム」という言葉だけが先走ってしまっている感覚がありました。
ということで、今回は「スクラム」について理解していることや解釈していることを記事にしてみました。スクラムについて簡単に解説をしていきますので、もし間違っていることがあれば知識をアップデートしていくので教えてもらえると嬉しいです😀
スクラムについて詳しく知りたい方がいれば公式のスクラムガイドを読んでみてください。
登場人物
プロダクトオーナーとデベロッパーは対等な関係であり、スクラムマスターはその双方の支援を行います。デベロッパーとスクラムマスターを合わせてデベロッパーチームと呼びます。
スプリント
期間は１週間から１ヶ月など様々で、作り立てのチームの場合は１週間から開始することが多いです。何度もスプリントを回しており成熟したチームであれば１ヶ月を１スプリントとすることもあるそうです。マンハッタンコードは２週間を基準にすることが多いです。
リファイメント
このスプリントで開発するバックログのインプットを行う
優先順位はプロダクトオーナーが決める
プランニング
プロダクトオーナーが優先順位付けしたバックログに対して2週間でどこまで生産できるのかをデベロッパーチームが計画を立てる
GOサインはプロダクトオーナーが出すため計画を立てたらスクラムマスターまたはデベロッパーチームからプロダクトオーナーに報告を行う
デイリースクラム
今日やったこと・明日やること・問題課題の共有をデベロッパーチームとスクラムマスターで行う
スプリントレビュー
作ったもののデモンストレーションをデベロッパーチームからプロダクトオーナーに行う
レトロスペクティブ
デベロッパーチームとスクラムマスターでそのスプリントの振り返りを行う
各セレモニーには使っていい基準時間があります。2週間スプリントであれば、プランニングは最大4時間・デイリースクラムは15分・スプリントレビューは最大1.5時間などです。
セレモニーの関係性
スクラムあるある
スクラムにおいてレトロスペクティブを行わないチームもありますが、レトロスペクティブもスクラムにおいては必須であり、重要なイベントです。
また、そのスプリントの対象となっているバックログの内容変更はしないことが原則です。まれにプロダクトオーナーからデザインをこう変えたい・仕様をこう変えたいというオーダーが入ることもありますが、プランニングに差異が生じるため基本的には変更不可とします。どうしてもやりたい場合は新たにバックログを生成し、次のスプリントなどでそのバックログを取り扱いプランニング→開発といった形式で進めます。
まとめ
だいぶ大枠にしか触れていませんが「スクラム」について理解していることや解釈していることを書いてみました。各セレモニーの目的、完了の定義、受け入れ条件（アクセプタンスクライテリア）、看板ボードの作り方といったHow toなど、スクラムにおいて重要なポイントはまだありますので追って書いていきます。
また、弊社ではスクラムの導入において、企業様のデベロッパーのみでなく、プロダクトオーナーサポートも行ってます。ゴールとしては、プロダクトオーナーがバックログを自ら生成しプロダクトの責任を取れるよう行動できるようになること。デベロッパーにおいては、スクラムマスター不在でも自立したチームを作ることです。もし、アジャイル（スクラム）開発を検討したい企業様がいらっしゃいましたらお気軽にご相談いただければと思います😀✨
宣伝
お仕事のご相談・ご依頼
マンハッタンコードは、スマートフォンアプリの開発に特化しております。エンジニアリングから、デザイン、プロジェクト推進などアプリ開発を総合的に請け負うことが可能です。
弊社のホームページからお問い合わせください。
お問い合わせの際には「noteの記事を読みました！」と一言入れていただけると嬉しいです！
この記事が気に入ったらサポートをしてみませんか？