「SCRUM BOOT CAMP THE BOOK」から学ぶ「スクラム」について

f:id:ryoutaku_jo:20190721191623p:plain

【結論】

スクラムとは、アジャイル開発の一種で、「一度にまとめ」では無く「少しづつ」作ることで、不確実性に対処する開発手法

スクラムでは、短い期間(1週間など)で、設計〜開発〜リリースを実施して、それを繰り返す

スクラムは、経験主義を基本としており、スクラムを通して様々な事を学ぶことが出来る

【目次】

【本題】

アジャイル開発について

ソフトウェア開発で最も重要な事は、実際の利用者の生活や仕事などが便利になり、営利目的であればソフトウェアに対して価値を感じて貰うことで収益を生み出すことです。

その目的を達成し、成果を最大化する為の開発手法の一つが「アジャイル開発」と呼ばれるものです。

アジャイル開発には、以下の様な特徴があります。

・「一度にまとめ」では無く、「少しづつ」作る

・利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を修正する

・関係者は目的達成のために、互いに協力し合いながら進める

これは「事前に全てを正確に予測し、計画する事は出来ない」という根本的な考え方が背景にあります。

スクラムについて

このアジャイル開発の方法論については、いくつか存在しますが、その中でも現在主流になっているが「スクラム」と呼ばれるものです。

スクラムには、以下の特徴があります。

・現在の状況や問題点を常に明らかにする(透明性)

・定期的に進捗状況を確認し、プロダクトが正しく作れているか?仕事の進め方に問題が無いか確認する(検査)

・問題が見つかったり、より良い手法があった場合、現状の手法を変える(適応)

プロダクトバックログについて

スクラムで開発を進める上で、欠かせないものが「プロダクトバックログ」です。

プロダクトバックログとは、プロダクトへの要求を抽出し、それらに優先順位をつけて一覧化したものです。

順番は、その要求が実現された時に得られる価値・リスク・必要性などによって決定します。

開発は、プロダクトバックログの順位が高いものから進めて行きます。

また、各項目毎に作業工数の見積もりを行います。見積もりは何人日といった絶対値では無く、他の作業量との相対値で表されることが多いです。

プロダクトバックログは、一度作成が完了しても、状況に応じて、絶えず更新(要求の追加・順番の変更)を行います。

項目の書き方に決まりはありませんが、ユーザーストーリーという形式で書くことが多いです。

スクラムにおけるチーム内の役割分担

スクラムでは、関係者毎に役割が設定され、それに基づいて実施されます。

スクラムにおける役割は以下の3種類です。

【プロダクトオーナー】

プロダクトオーナーは、プロダクト開発の責任者で、プロダクトの結果責任を取る立場になります。

プロダクトバックログの並び順に対する最終決定権を持ち、他のメンバーがその決定を覆す事は出来ません。

・プロダクトのビジョンをチームに共有する

・おおよそのリリース計画を定める

・予算を管理する

・作られたプロダクトが要求に沿っているか検査する

なお、プロダクトオーナーは、開発チームの仕事の進め方などに干渉は出来ません(相談は可能)

スクラムマスター】

スクラムが上手く実践できる様に、プロダクトオーナーと開発チームの補佐をするのが、「スクラムマスター」です。

主に、以下の様なことを行います。

・わかりやすいプロダクトバックログの書き方をプロダクトオーナーや開発チームに教える

・プロダクトバックログの良い管理方法を探す

・スプリント計画ミーティングなどの進行を行う

・プロダクトオーナーと開発チームの会話を促す。生産性を高くなる様に促す。

・開発の妨げになっている事をリスト化(妨害リスト)して、優先順位をつけて、解決方法を検討する

【開発チーム】

「開発チーム」は、実際にプロダクトを制作する役割を担います。

テストチームといった様な機能毎にチームは区切らず、チーム単体でプロダクトが作れる様に、メンバーは構成されます。

コミュニケーションコストを抑える為、3〜9名で構成されます。

開発チーム内に上下関係は無く、メンバー全員の合意のもと、仕事の進め方を決めます。

スプリントについて

スクラムでは、短い期間で設計・開発・テスト・デプロイを行いますが、このプロダクトリリースに必要な作業を終えるまでの期間を「スプリント」と呼びます。

スクラムでは、この「スプリント」を何度も繰り返すことで、開発を進めて行きます。

短い期間で検証を進める為に、スプリントは最長でも「1ヶ月以内」で設定する必要があります。

また、スプリント内に予定していた開発が終えられなかったとしても、期間の延長は行いません。

【スプリント計画ミーティングの実施】

プロダクトオーナーに何を開発すべきか判断して貰います。

開発チームは、それがどのくらいの期間で開発が可能であるかを明示します。

【スプリントバックログの作成】

プロダクトバックログを具体的なタスクに分割します。日毎に進捗が確認できる様に、個々のタスクは1日以内の単位にします。

【デイリースクラムの実施】

毎日15分間、以下の内容について開発チーム内で報告を行います。

・前回のデイリースクラムからやったこと

・次回のデイリースクラムまでにやること

・困っていること

デイリースクラムは問題解決の場では無いので、問題解決に当たって議論すべきことがあれば、報告後に必要なメンバーだけが集まる会議を設定します。

【スプリントレビューの実施】

スプリントの最後に、プロダクトオーナーが現状リリース可能な機能のレビューを行います。

スプリントレビューでは、以下の事について報告・議論を行います

・(開発チーム)完了出来なかったプロダクトバックログの項目について説明

・(プロダクトオーナー)プロダクトの状況やビジネスの環境について説明

・(全体)プロダクトバックログに追加すべき項目の有無について議論

・(全体)プロジェクトを進める上で、問題となる事項について議論

・(全体)現在の進捗を踏まえたリリース日の予測

【スプリントレトロスペクティブの実施】

スプリントレトロスペクティブでは、直近スプリントの振り返りを行います。

上手くいったことや今後の改善点を整理して、より良いやり方に変え続けて行きます。

スクラムを実践する際の注意点

スクラムマスターとプロダクトオーナーは方向性が違うので兼任出来ない

スクラムでは、ゴールやミッションを強く意識しながら行動することが最重要

・プロダクトバックログ作成時、致命的な漏れを無くす為に、最初に重要な項目を洗い出す

・作業を見積もる際は、正確に見積れる作業から比較して、相対値で見積もる

・見積もりはあくまで推測なので、見積もりに時間をかけ過ぎない

・詳細に見積もるのは、直近のタスクのみ

・作業を見積もる際は、開発チーム全員で対話して、様々な観点を取り入れる

・スプリント計画ミーティングでは、確実に終わらせられる計画を作る

・作業完了の定義を明確にする

・デイリースクラムは、報告会ではなく、スプリントの目標を達成できるか検査する場だという認識で参加する

・デイリースクラムは、問題解決の場では無いので、問題解決に関する議論は別の場で行う

・スプリントの期間は予測に使うので、延長してはならない

スクラムの目的をスクラムチーム全員が理解して実践しなければならない

・プロダクトオーナーと開発チームとでは責任を持つ部分が異なるので、誤解が生じやすい

・プロダクトバックログは、ユーザーストーリーで書くことで、プロダクトオーナー・開発チーム双方が伝えやすくなる

・プロダクトバックログでは、要求を実現したい意図(誰が?何故?)を記述する必要がある

・実現したいことが曖昧だと手戻りが発生してしまうので、直近のスプリントで取り組むタスクの曖昧な部分を整理する必要がある

・目標達成が難しく、計画の修正が必要なった場合でも、プロダクトの品質は犠牲に出来ない

・調整するとすれば、「予算」「期間」「実装する機能(スコープ)」から選択するケースが大半

・実装方法を工夫する事も、スコープの調整になり得る

・特定の人がリーダーシップを発揮するのではなく、その状況で最も力を発揮する人がリーダシップを発揮するのが理想

・開発チームがどういったスキルを持っているのか明確にしておく必要がある

・但し、一人一人が得意な作業だけに自分の領域を狭めてしまうのではなく、未知の問題にも挑戦する必要がある

・実際の作業に関係ない人の意見は参考意見に過ぎない

・最初は失敗だらけでも、失敗から学んで成長して行かないといけない

スクラムは、体験して学んでいく為の仕組みである

参考情報

書籍「SCRUM BOOT CAMP THE BOOK」

《今日の学習進捗(3年以内に10000時間に向けて)》

引越し先の賃貸の契約やら何やらで、あまり勉強できず

学習開始からの期間 :226
今日までの合計時間:2164h
一日あたりの平均学習時間:9.6h
今日までに到達すべき目標時間:2064h
目標との解離:100h
「10,000時間」まで、

残り・・・「7836時間!」