00:04
1月19日木曜日時刻は、朝9時15分になりました。
昨日より暖かいですけど、まだまだ寒い日が続きますね。
みなさん、体調に気を付けてください。
おはようございます。ひめみのkeethことくわはらです。
では、本日も朝活を始めていきたいと思います。
本日はタイトルにありますけども、スクラムガイドをですね、
スクラムガイド.orgが出している公式のガイドがあるんですけど、
それをちょっと読んでいこうかなと思ってます。
このガイド自体はですね、2013年7月に書かれたものっぽいので、
ちょっと最新のスクラムのやり方とか手法とかと、
どこまでマッチするかわからないんですけど、
昔のものだといって、
じゃあ古いから読む価値がないかっていうことでもなさそうですし、
ちゃんと根本的なところは似てくるとか、
あまり変わってないと思うので、
その辺が吸収できればいいのかなと思ったりしております。
そのために読んでいこうかなと思いましたので、
早速やっていきたいと思います。
ちょっとですね、やっぱりスクラムガイド長いので、
ここから数日間にわたって続くんじゃないかなと思っているので、
気長にお付き合いいただければと思います。
じゃあ行きましょう。
スクラムガイドです。
このスクラムガイドの目的からですけども、
スクラムというのは複雑なプロダクトを開発・維持するためのフレームワークであります。
本ガイドではスクラムの定義を説明します。
定義には役割・イベント・作成物とそれらをまとめるルールというのは含まれます。
スクラムはケン・シェワバーさんとジェフ・スザーランドさんというお二人が開発したものであって、
スクラムガイドにはこの二人が執筆提供しています。
両者は特にスクラムガイドを支援しています。
スクラムの定義ですけど、スクラムは名詞ですね。
複雑で変化の激しい問題に対応するためのフレームワークであり、
習得は困難は本当に周りでスクラムマスターを取ったりとか、
実際に実施をしている方のいろんなお話を聞くと大変そうだったりつくづく思いましたね。
スクラムというのは1990年代初頭から複雑なプロダクト開発の管理に使用されてきたプロセスフレームワークであります。
プロダクトを構築するプロセスや技法ではなく、
様々なプロセスや技法を取り入れることのできるフレームワークになります。
これらのプロダクト管理や開発プラクティスの相対的な有効性を明確にして改善を可能にするのである。
スクラムフレームワークはスクラムチームとその役割、イベント、作成物、ルールで構成されています。
それぞれに目的があり、スクラムの成功や利用には欠かせません。
スクラムのルールは役割、イベント、ルール、作成物をまとめ、
それらの関係性や相互作用を統括するものであります。
スクラムのルールについては本校全体で説明するのでまあまあまあって感じです。
スクラムフレームワークを使用する戦略には様々なものがあり、
それらについては本校では触れませんとおっしゃっています。
では続いてスクラムの理論ですね。
スクラムは経験的プロセス制御の理論、いわゆる経験主義というのを基本にしています。
経験主義とは実際の経験と基地に基づく判断によって知識が獲得できるというものであります。
03:03
スクラムでは反復的かつ前進的な手法を用いて
予測可能性の最適化とリスクの管理を行います。
経験的プロセス制御の実現というのは透明性、検査、適応の三本柱に支えられていますよと。
ではそれを一個一個見ていきますが、まず透明性ですね。
経験的プロセスで重要なのは結果責任を持つ者に対して見える化されているということであります。
透明性とはこうしたことが標準化され、見ている人が共通理解を持つことになりますよと。
例としてはプロセスの用語を参加者全員で共有をしている、
作業をする人とその作成物を受け取る人が完成の定義というのを共有していると、などなどですね。
共通の認識がちゃんと取れているというところも透明性なんですね。
続いて検査です。スクラムのユーザーというのはスクラムの作成物や進捗を頻繁に検査し変化を検知します。
ただし検査を頻繁にやりすぎて作業の妨げになってはいけません。
熟練の検査人が念入りに行えば検査というのは最大の効果をもたらしますよと。
続いて適応ですね。
プロセスの不備が許容値を超え成果となるプロダクトを受け入れられないと検査人が判断した場合、
プロセスやその構成要素を調整する必要があります。
調整はできるだけ早く行い、これ以上の逸脱を防がなければいけません。
スクラムでは検査と適応を行う4つのイベントをスプリントで規定しています。
詳しくはスクラムイベントのセットで説明しますけど、大きく4つで
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブというところでした。
続いてスクラムチームのお話に移りたいと思います。
スクラムチームというのはプロダクトオーナー、開発チーム、スクラムマスターで構成されています。
スクラムチームは自己組織化されており、機能横断的であります。
自己組織化チームは作業を成し遂げるための最善の策をチーム外からの指示ではなく、自分たちで選択するようになります。
機能横断的チームはチーム以外に頼らずに作業を成し遂げる能力を持っています。
スクラムにおけるチームのモデルは柔軟性、創造性、生産性を最適化するように設計されています。
登場人物についてお話をしていく感じですね。
まず一人目はプロダクトオーナーです。
プロダクトオーナーは開発チームの作業とプロダクトオーナーの価値の最大化に責任を持ちます。
その作業は組織、スクラムチーム、個人によって大きく異なります。
プロダクトオーナーはプロダクトバックログの管理に責任を持つ一人の人間になります。
プロダクトバックログの管理には以下のようなものがあります。
1つ目はプロダクトバックログアイテムを明確に表現します。
2つ目はゴールドミッションを達成できるようにプロダクトバックログアイテムを並び替えます。
3つ目は開発チームが行う作業の価値を最適化します。
4つ目はプロダクトバックログを全員に見えるか透明か明確化し、スクラムチームが次に行う作業を示します。
5つ目は必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらうということです。
常規の作業はプロダクトオーナーが行う場合もあれば開発チームが行う場合もあります。
06:00
いずれの場合も最終的な責任はプロダクトオーナーが持ちます。
プロダクトオーナーは一人の人間であり、委員会ではありません。
委員会の要求をプロダクトバックログに反映することもあるでしょうが、
プロダクトバックログアイテムの優先順位の変更についてはプロダクトオーナーと相談しなければなりません。
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの意見を尊重しなければいけません。
プロダクトオーナーの決定はプロダクトバックログの内容や並び順という形で見える化されています。
開発チームに作業依頼できるのはプロダクトオーナーだけになります。
開発チームはプロダクトオーナー以外から作業依頼を受け付けてはいけませんということですね。
ここ結構ポイントですよね。
介入できるというか、そういうお互いのやり取りのところですね。
以上をどうやってするかなんですけど、プロダクトオーナーと開発チームのところだけなんですね。
スクラムマスターをそこに介入しちゃダメだというところが結構重要ですね。
続いて開発チームです。
開発チームは各スプリントの終わりにリリース判断可能な完成したプロダクトインクリメントを届けることのできる専門家で構成されています。
つまり一人ではないということですよね。
先ほどのプロダクトオーナーは大体一人だと思いますけど、開発チームは複数人でやるという。
名前の通りチームですからね。
開発チームというのは自分たちの作業を構成管理します。
そのことは組織からも認められています。
その創著効果によって開発チーム全体の効率と効果というのが最適化されます。
開発チームには以下のような特徴がありますよ。
こっちにもいろいろありますね。
1つ目、自己組織化されているプロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は誰もスクラムマスターでさえも教えてくれない。
2つ目、機能横断的であるインクリメントを作成するスキルをチームとして全て備えています。
3つ目、ある人にしかできない作業があったとしてもメンバーの肩書きは開発者だけであります。
このルールに例外はないというところですね。
4つ目、テスティングやビジネス分析のような領域であってもスクラムは開発チームのサブチームを認めていない。
このルールにも例外はないということですね。
5つ目、開発チームのメンバーに専門能力や専門分野があったとしても最終的な責任は開発チーム全体が持ちますというところが重要ですね。
続いて開発チームの規模についても触れられていますね。
開発チームに最適な人数というのは、小回りが利く程度に少なく、一つのスプリントで重要な作業が成し遂げられる程度に多い人数であります。
開発チームのメンバーが3人未満の場合は総合作業が少なく、生産性の向上に実はつながらないんじゃないかなというふうにおっしゃっています。
また、開発チームの規模が小さいとスケール不足が原因で、リリース判断可能なインクリメントを届けられない可能性もあります。
メンバーが9人を超えた場合は挑戦の機会が多くなってしまいます。
また、チームの規模が大きいと経験的プロセスの管理が複雑になってしまいます。
スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターをこの人数に含めません。
続いてスクラムマスターです。
スクラムマスターはスクラムの理解と成立に責任を持ちます。
09:04
そのためにスクラムマスターはスクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにします。
スクラムマスターはスクラムチームのサーバントリーダーである、役中、メンバーが成果を分けるために支援や奉仕をするリーダーのことです。
いわゆるサーバント、奴隷という意味なんですけど、言いなりになるという意味ではないです。ちゃんとサーバントリーダーというところが重要ですね。
スクラムマスターはスクラムチームとやり取りをする時に役に立つこと、立たないことをスクラムチームの外部の人たちに理解をしてもらいます。
スクラムマスターはこうしたやり取りに変化をたらすことでスクラムチームが作る価値を最大化しますよと。
スクラムマスターはプロダクトオーナーを支援するというところが次のセクションですね。
スクラムマスターは様々な形でプロダクトオーナーを支援しています。
効果的なプロダクトバックログの管理方法というのを探すとか、明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームについても理解してもらうと。
経験主義におけるプロダクトプランニングについて理解する。
価値を最大化するためにプロダクトバックログを調整する方法を知っている。
アジャイルを理解実践している。
必要に応じてスクラムイベントをファシリテイトするというところですね。
続きまして、スクラムマスターは開発チームを支援するということですね。
スクラムマスターは本当にとにかく支援支援というところですね。
ではどんな形ですかという形ですけど、もちろん様々な形があるんですが、今回5つですね。
1つ目、自己組織化機能横断的な開発チームをコーチします。
2つ目、開発チームが価値の高いプロダクトを作れるように支援します。
3つ目、開発チームの進捗を妨げるものを排除します。
4つ目、必要に応じてスクラムイベントをファシリテイトします。
5つ目、スクラムがまだ完全に適応を理解されていない組織環境で開発チームをコーチします。
ここは結構重要な、3つ目のところの開発チームの進捗を妨げるものを排除するというところですね。
ここ、いわゆるファイアウォール的な役割もスクラマスターはしてくれるはずだとか役割だと思っていて僕は。
ファイアウォールって言うとちょっと語弊あると思います。
何でもかんでも弾く意味ではないですからね。
ありますけど、妨げになるものがどんどんあるんだったらそこはスクラマスターの方が排除しに行くということですね。
プロダクトオーナーではなくてスクラマスターがここをやるっていうのが僕はポイントだと思いました。
続いて、スクラマスターは組織も支援しますよということでした。
こちらも様々な形がありますが、今回も5つですね。
1つ目は、組織へのスクラムの導入を指導、コーチします。
2つ目に、組織へのスクラムの導入方法を計画します。
3つ目に、スクラムや経験的プロダクト開発を社員や関係者に理解、実施してもらいます。
4つ目、スクラムチームの生産性を高めるような変化を促します。
5つ目、他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高めるようとします。
こういうような支援をしていきます。
とにかくスクラムマスターっていうのは、この開発現場プロジェクトにおけるどんどん支援をしていくポジションであるというところがポイントっぽいですね。
これを読む限りは。
では続いていきましょう。
スクラムイベントっていうところですね。
12:01
冒頭に出てきました。
異動の名前がありましたけど、その説明がここで入ってくるんだろうと思います。
スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化します。
すべてのイベントは時間に上限のあるタイムボックス化されたイベントになります。
スプリントを開始するとその期間は固定化され増減することはできません。
スプリント以外のイベントについては目的が達成されたときに終了することもあります。
プロセスで無駄なことをせずに必要な分だけ時間を使うためになりますよと。
スプリント以外のスクラムイベントっていうのは何かを検査適用するための公式の機械であります。
スプリントはその他のイベントの入れ物になりますよと。
これらのイベントは必要な透明性や検査が実現できるように設計されています。
これらのイベントがなければ透明性は低下し検査適用の多くの機械というのを失ってしまいますよということですね。
では一つ目スプリントから説明が入りますね。
スクラムの中心はもちろんスプリントになります。
これは完成した利用可能なリリース判断可能なプロダクトインクリメントを作るための1ヶ月以下のタイムボックスになります。
スプリントは開発作業を行ううち連続した期間になりますよと。
スプリントが終了するとまた新しいスプリントが開始されます。
スプリントはスプリントプランニング、デイリースクラム、開発作業、スプリントレビュー、スプリントレトロスペクティブで構成されます。
スプリントで以下のようなことを行いますよと。
まずスプリントゴールに悪影響を及ぼすような変更を加えない。
二つ目に品質目標を下げない。
三つ目に学習が進むにつれてスコープが明確化され、プロダクトオーナーと開発チームの交渉というのが必要になる可能性があります。
まあまあありますね。
スプリントは1ヶ月以内のプロジェクトと考えることができます。
プロジェクトと同様にスプリントは何かを成し遂げるために使うものでありますよと。
スプリントには開発者対象の定義、開発のための設計や柔軟な計画、開発作業、成果となるプロダクトが含まれますよと。
スプリントの期間というのは1ヶ月以内に制限されています。
スプリントが長すぎると開発対象の定義が変更されたり複雑になったり、リスクが増大したりする可能性がありますよと。
ゴールに対する進捗を少なくとも1ヶ月ごとに検査適用することで予測可能性が高まるのであります。
またリスクも1ヶ月分のコストに収まるようになりますよと。
リスクもその期間分に収めることができるというのは確かに良い観点だなと思いましたね。
続いてスプリントの中止ですね。
先ほどはスプリントそのものの話だったので、次はスプリントを中止する時の話が出てくるそうです。
スプリントはタイムボックスの終了前に中止できます。
スプリントを中止する権限があるのはプロダクトオーナーだけになります。
この時に関係者、開発チーム、スクラムマスターの意見を参考にすることももちろんありますよと。
スプリントゴールが古くなった場合はスプリントを中止することにもなるでしょう。
会社の方向性や市場、技術の状況が変化するとスプリントゴールは古くなってしまいます。
状況を考慮して意味がなくなったらと思えばスプリントを中止すべきですねと言っています。
ただしスプリントの期間は短いので中止したからといってさほど意味をなすことも実はないんじゃないかなという話もされていますね。
15:01
スプリントを中止した場合はプロダクトバックログの完成したアイテムをレビューします。
部分的にリリース判断可能なものがあればプロダクトオーナーが受け入れることになります。
未完成のプロダクトバックログアイテムは再見積もりをしてからプロダクトバックログに戻します。
そこにかかった作業の価値は急速に低下するため頻繁に再見積もりが必要になります。
作りかけの機能とか設計について時間が経つと状況が変わってしまうためその価値が失われてしまうことが多いです。
そうすると最初から見積もりをやり直す必要が出てきます。
リリースを中止すると結構大きな決断になります。
一方で、さっきのスプリントの説明にもありますが、リスクを最小化に抑えるというところもあったりするので
重要な決断ではあるけれど、そんなにインパクトはプロジェクト的には大きくないのかもしれないですね。
ただ、リリースが近づいてきたところ、プロジェクト全体としての着地が見えてきたところで
そのとあるスプリントが止まることになると、結構大きな問題が起きたんだなという感じがするので
最初のうちならばいいですが、後半になって発生するとなると何かやばいことがあったんだろうなという感じですね。
スプリントを中止すると新しいスプリントのスプリントプランニングがもちろん必要になりますので
そのためのリソースも消費してしまいます。
それからスプリントの中止がチームのトラウマになってしまうこともあります。
これ確かに感じるかもしれないですね。
1回スプリント中止っていうのを実施してしまったことによるトラウマじゃないですけど
次回またあるんじゃないかとか、それをやったインパクトっていうのを経験してしまうので
これはこれで怖いよねってことですね。
ただ、スプリントの中止は滅多に発生しないことが多いですよってことですね。
僕の周りでスプリント中止したって話、実は幸いか分かるんですけど聞いたことは一度もないですね。
考えたことあるみたいな話はもちろん聞いたことあるんですけど
実際に止めたっていう話は聞いたことないので
本当に滅多に起きないことなんだろうなと思いました。
では続いてスプリントプランニングの話ですね。
スプリント作業っていうのはスプリントプランニングで計画をします。
これはスクラムチームの共同作業になりますよと。
スプリントが1ヶ月の場合はスプリントプランニングのタイムボックスは最大で8時間になります。
プランニングには最大で8時間。
いわゆる日本だと1日ですね。1営業日しかかけないと言ってますね。
スプリントの期間が短ければスプリントプランニングの時間も短くすることは多いです。
スクラムマスターは参加者に目的を理解してもらうようにします。
スクラムマスターはスクラムチームにタイムボックスを守るように伝えます。
スプリントプランニングでは以下の質問に答えますよと。
スプリントの成果であるインクリメントで何を届けることができるか。
インクリメントを届けるために必要な作業はどのように成し遂げるかっていうところですね。
これはいくつかのトピックに分かれていて、トピックはでも2つですね。
トピック1つ目。スプリントで何ができるかってところですけど。
開発チームはスプリントで開発する機能を予想します。
プロダクトオーナーはスプリントで達成すべき目的と
完成後にスプリントゴールを達成するプロダクトバックログアイテムについて検討します。
スクラムチームはみんなで協力してスプリントの作業を理解します。
スプリントプランニングのインプットっていうのは
18:00
プロダクトバックログ、最新のプロダクトインクリメント、開発チームの予想キャパシティと実績になります。
プロダクトバックログから選択するアイテム数については開発チームが責任を持ちます。
スプリントで何が達成できるかを評価できるのは開発チームだけになりますよということですね。
開発チームがスプリントで届けるプロダクトバックログアイテムを予想した後に
スクラムチームでスプリントゴールを設定します。
スプリントゴールとはプロダクトバックログを実装することで実現するスプリントの目的であり
開発チームがインクリメントを開発する指針となるものになりますよということですね。
2つ目、トピック2は選択した作業をどのように成し遂げるのかというお話ですが
プロダクトバックログアイテムを選択しスプリントゴールを設定したら
開発チームはそれらの機能をスプリントで完成プロダクトインクリメントにする方法を決めますよと
採択したプロダクトバックログアイテムとそれらを届ける計画を合わせてスプリントバックログと呼んだりします。
開発チームはプロダクトバックログを動作するプロダクトインクリメントに変えるために
必要なシステムと作業の設計から着手します。
作業の規模や工数はバラバラであっても構わないが
作業の計画については開発チームがスプリントで達成できそうなものにしますよと
開発チームがスプリントの最初の数日間で行う作業については
スプリントプランニングで作業に分解します。
作業の単位は1日以下にすることが多い。
開発チームは自己組織化してスプリントバックログの作業を引き受けます。
これはスプリントプランニングだけでなく、必要であればスプリントでも行います。
プロダクトオーナーは選択したプロダクトバックログアイテムの明確化やトレードオフを支援します。
開発チームの作業が多すぎたり少なすぎたりした場合は
選択されたプロダクトバックログアイテムについては
開発チームのプロダクトオーナーで話し合います。
あるいは技術やドメインに詳しい人にアドバイスを求めることもあります。
ここで第1、3社に意見を求めることもあるということですね。
スプリントプランニングが終了するまでに
開発チームは自己組織化したチームとしてどのようにスプリントゴールを達成し
どのように期待されるインクリメントを作成するかを
プロダクトオーナーとスクラムマスターに説明できなければいけないということですね。
というところでどうしようかな。
ちょっと中途半端なんですが
ここで終了しようかなと思います。
ちょっと長いですし、また明日に繋げようかと思います。
時間も常に30分を超えてしまったので
一旦今日はここで朝方終了しようかなと思います。
スクラムのお話ですね。
読むだけだと全然知識としてインプットしか入らないので
スクラムの本当の真髄というのは実際にやってみて分かるところですね。
まさに経験学習というところを重きを置いているんですけど
このフレームワークそのものも経験学習なんだというところですね。
ただ知るだけでも全然スクラムに対する印象だったり
他のチームがやっていることについての共通言語ができるので
コミュニケーションが取れるというのもすごくいい話なんじゃないかなと思ったりしています。
ではまた次回、明日も頑張っていけたらなと思います。
それでは終了したいと思います。お疲れ様でした。
