00:05
はい、1月20日金曜日ですね。遅刻は昨日を回りました。 昨日の夜ですね、ついに僕の
Twitterブルーのアイコンをつくようになりました。 なんとかお金を払ったバッジがついたなぁって感じです。
おはようございます、いめめめのkeethことくわはらです。 では本日も朝活を始めていきたいとおもいます。
昨日に引き続き、今日もタイトルにありますスクラムカイトっていう記事ですね。 記事というかPDFか。
をずーっと読んでいこうと思います。 昨日読み終わったら気づいたんですけど、このスクラムカイトってやつは
2015年のバージョン1のもので、最新版2020年版が出ています。 そっちを読んでもよかったんですけど、昨日に続いて
いきなり内容変わってもあれなんで、今日はそのまま、ちょっと古いですけど、ものを読んでいこうかなと思います。 新しい本も比較して読んでもいいと思いますし、
どういう差分があったのかっていうのを追ってもいいですけど、まぁ一旦今日は 昨日についたままのスクラムガイドを読んでいこうかなと思っています。
昨日はですね、目次的にどこまで読んだっけ? スクラムイベントの途中で何か止まったような気がしてますね。
スプリントプランニングまでは確か読んだ気がしてて、 そのスプリントプランニングのトピック1、2を読んで、スプリントゴールから今日は確か読んでいくような気が
しますね。 スプリントゴールからですね今日は。
スプリントゴールっていうのはスプリントの目標セットであり、 プロダクトバックログの実装によって実現するものになります。
これは開発チームがインクリメントを構築する理由を知る指針となります。 スプリントゴールはスプリントプランニングでもちろん作成をします。
スプリントゴールを設定することで開発チームがスプリント終了までに実装する機能を柔軟に できますよ。
選択したプロダクトバックログアイテムっていうのは一貫性のある機能として届けられます。 それがスプリントゴールになることもありますし、
スプリントゴールがあれば開発チームは一致団結して作業ができますよ。 開発チームが計画するときにはスプリントゴールっていうのは念頭に置いています。
スプリントゴールを達成するためにそれらの機能や技術を実装します。 開発チームの予想よりも難しいと判明した場合は、
プロダクトオーナーと交渉してスプリントバックログのスコープを調整しますというところです。
続いてデイリースクラムの話ですね。 デイリースクラムとは開発チームが活動の速度を合わせ次の24時間の計画を作る15分間のタイムボックスのイベントになります。
いわゆる朝会的なやつですね。 前回のデイリースクラムから行った作業の検査と、次回のデイリースクラムまでに行う作業の予想を行いますよと。
デイリースクラムは毎日同じ場所同じ時間で開催をします。 これは複雑にならないようにするためになっています。
デイリースクラムでは開発チームのメンバーが以下のことを説明します。 主に3つですね。
1つ目は開発チームがスプリントゴールを達成するために私が昨日やったことは何かというところを共有します。
03:06
2つ目は開発チームがスプリントゴールを達成するために私が今日やることは何かというのを確認します。
3つ目に私や開発チームがスプリントゴールを達成するときの障害物何かありますかというのをそれを目撃しましたがというのを共有します。
この3つを15分間でババッと共有して1日を走るということですね。 開発チームはデイリースクラムを使ってそのスプリントゴールとスプリントバックログの作業の進捗を検査します。
デイリースクラムは開発チームがスプリントゴールを達成する可能性を最適化します。 開発チームというのは自己組織がチームとしてスプリントゴールを達成し
スプリント終了までに 期待されるインクリメントを作成できるかを毎日把握しなければいけません。
開発チームは開発チームまたは一部のチームメンバーというのはそのデイリースクラム終了直後に集まり
スプリントの残作業について詳細な議論適応を再計画を行うこともあります。 まあそれはそうだよね。
もうちょっと詰めたいところとか個別の相談したいことがあるようなあれば全然それはしてください。
スクラムマスターは開発チームにデイリースクラムを開催してもらうようにします。
ただしデイリースクラムを開催する責任は開発チームにあると。 あくまでスクラムマスターというのはそのデイリースクラムを15分間のタイムボックスで終わらせるように開発チームに伝える
というところですね。まあタイムキーピング的な観点なんですね。スクラムマスターというのはファシリティションすると思ってました。
スクラムマスターはそのデイリースクラムには開発チームのメンバーしか参加できないというルールを研修しますと。
これ大事ですね。そのデイリースクラムの中に例えばビジネスサイドの人とかがガッとちょっと相談したいことがあるからそのあそこに入らせてくれというふうな話をされてもそれは困るし計画がいきなりバンと崩れたりするのでそういう外部要因を弾くのがスクラムマスターの仕事だというふうに昨日読んだ内容にはありますので。
もし1週間のスプリントのバックログのアイテムがあるんですけどそのアイテムを交換しなければいけないとか新しく追加しなければいけないみたいな大きなイベントがあったらそれはスクラムマスターとかプロダクトオーナーの方で話を一旦受けてその後意思決定をしていくということになると思いますので開発チームに少なくともそれを直接話すということはしないんじゃないかなと思いますねスクラム的にはですけど。
内容によっては本当に今すぐバッとやらなきゃいけないこともあるかもしれないですけど基本的なスクラムのやり方としてはいきなりそういうところをデイリースクラムでボーンと持ってくるようなことはしないようにスクラムマスターがまずファイアウォールをするという感じですね。
続いてデイリースクラムというのはコミュニケーションを改善しその他のミーティングを取り除き開発の障害物を特定排除し迅速の意思決定を強調助長して開発チームのプロジェクト知識のレベルを向上させるものであります。これは検査と適応の重要なイベントでありますよというふうに言ってますね。
スクラムというのは基本的に学習しながら物事を進めていくというフレームワークなのでこれは本当にその通りだなと思いました。
続いてスプリントレビューです。スプリントレビューとはスプリントの終わりにインクリメントの検査と必要であればプロダクトバックログの適応を行うものになります。
06:07
スプリントレビューではスクラムチームと関係者がスプリントの成果をレビューします。スプリントの成果とプロダクトバックログの変更を参考にして価値を最適化するために次に何ができるかというのを参加者全員で話し合います。
これはステータスミーティングではなく非公式なミーティングになります。インクリメントを提示することでフィードバックやさらなる協力を引き出すことを目的とします。
スプリントは1ヶ月の場合はスプリントレビューのタイムボックスは4時間になります。まあ1ヶ月のスパンであればそれはそうだよね。
でも4時間で終わるものなんですかね。1ヶ月分。スプリントの期間が短ければスプリントレビューの時間も短くすることが多いと。
スクラムマスターは参加者に目的を理解してもらうようにします。スクラムマスターはスクラムチームにタイムボックスを守るようにももちろん伝えます。
スプリントレビューには以下の要素が含まれます。参加者、スクラムチームと重要な関係者ですね。
っていうのがプロダクトオーナーが招待してそのスプリントレビューに参加すると。
プロダクトオーナーはプロダクトバックログアイテムの完成したものと完成していないものについて説明をしますと。
開発チームはスプリントでうまくいったこと、直面した問題点、それをどのように解決したかというのを議論します。
開発チームは完成したものをデモしてインクリメントに対する質問に答えますよということです。
ついでにプロダクトオーナーは現在のプロダクトバックログを審議します。必要であれば現在の進捗から完了日を予測しますと。
ついでにグループ全体で次に何をやるかっていうのを議論して、次のスプリントプランニングに価値のあるインプットを提供できるようにします。
プロダクトの市場や今後の利用状況についてレビューした場合は、次に行う最も価値の高いことが変更されることもありますよねということでした。
最後、プロダクトの次のリリースに対するスケジュール、予算、性能、市場というのもレビューしますというのがスプリントレビューでした。
スプリントレビューの成果は次のスプリントで使用するプロダクトバックログアイテムが含まれた改定版のプロダクトバックログになります。
新たな機械に見合うようにプロダクトバックログを全体的に調整することもありますということですね。
これいいですね。ちゃんとスプリント単位でレビューして、その時に全体的に調整し直すということは全然あり得ると。
本当にいわゆる振り返りじゃなくて向き直りに近いところをやるということですね。
結構スプリントレビューって単純に成果物をステークホルダーとかも集めてみんなでやいのやいの言ったりどうだこうだって言って、
次のスプリントのチケット管理どうするかとか何をやるか逆にこれはちょっと後回しにしようかみたいな話だけかと思ったんですけど、
そういう大きい視点のものもやろうと思ったら全然やるんですね。
続きましてスプリントレトロスペクティブです。
ちょっとカタカナが多くて長いんですけども。
スプリントレトロスペクティブっていうものはスクラムチームの検査と次のスプリントの改善計画を作成する機械になります。
スプリントレトロスペクティブっていうのはスプリントレビューが終わって次のスプリントプランニングが始まる前に行いますと。
09:02
なるほど、その間に挟むんですね。
スプリントが1ヶ月の場合はスプリントレトロスペクティブのタイムボックスは3時間が基本ですと。
スプリントの期間が短ければもちろんレトロスペクティブの時間を短くすることが多いよって言ってます。
同じ時間でやってもいいけどってことですけど、長くやっても仕方ないってことですね。
スクラムマスターはこのイベントが確実に開催されるようにします。
確実にっていうことはこれ絶対要るんですね。
参加者の目的を理解してもらうようにしますと。
スクラムマスターはスクラムチームにタイムボックスを守るようにもちろん伝えます。
やっぱり時間が本当に大事ってことですね。
スクラムマスターはスクラムプロセスを説明するためにチームメンバーとしてイベントにも参加しますと。
自身も参加するんですね。
スプリントレトロスペクティブには以下の目的があります。
人、関係、プロセス、ツールの観点から今回のスプリントっていうのを検査すると。
うまくいった項目と今後の改善が必要な項目を特定整理する。
これなんかGEPTに近い感じがありますね。
続いてスクラムチームの作業の改善実施計画っていうのを作成すると。
そうは書いてないから別に登場人物の誰かがやるとは書いてなくて少なくともスクラムチームでってことですね。
でもことは必要があったら必要な人がやるってことですね。
スクラムマスターは次のスプリントが効果的で楽しいものになるように
開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらいますと。
スクラムチームは完成の定義を適切に調整してプロダクトの品質を向上させる方法を計画しますと。
単純にやることをやるべきことを淡々とやるように問題を排除してかつ効率的に進む何かっていうのを議論するっていうだけではなくて
効果的でかつ楽しいものになるようにっていうところですね。
これはちょっと面白いですね。
こういう開発とかお仕事系のフレームワークに楽しいっていうワードを入れて
かつそれをそうなるように進めるっていうのをちゃんと明記してあってなかなか面白いですね。
根性論とか精神論の話かもしれないですけど結構重要ですよね。
結局人は感情で動くものなのでここをちゃんと明記してあるっていうのは僕はとても興味深いしいいなと思いました。
単なる感想ですね。戻ります。
スプリントレトロスペクティブが終わるまでにスクラムチームっていうのは
次のスプリントで実施する改善策を特定しなければいけません。
これらの改善策の実施っていうのは開発チーム自体の検査の適用になります。
改善はいつでも実施可能なんですけどスプリントレトロスペクティブっていうのは
検査と適用のための公式な機械になります。
こっちは公式なんですね。スプリントレビューは非公式なんですね。
だからこっちの方はむしろ確実にやらなきゃいけない。
やるとしたらスプリントレビューの後にやるものですと。
もしスプリントレビューやらないことはないと思いますけどもしやるとしたら
やらないとしたらここで一緒にやっちゃうのかな。もしかしたらですけどね。
はい、というのがちょっと思いました。
次にスクラムの作成物です。
スクラムの作成物っていうのは作業や価値を表したものであって
透明性や検査適用の機械を提供するものになります。
なのでスクラムで定義された作成物は全員が共通理解を得るために必要な
12:01
情報の透明性ということを最大化するように設計されていると。
はい、情報の透明性がまずは大目的なんですね。
作成物がまだいくつか分も出てくるんですけど
一つ目の作成物としてはプロダクトバックログです。
プロダクトバックログっていうのはプロダクトに必要なものが
すべて並べられた一覧であり
プロダクトに対する変更要求の唯一の情報源である
プロダクトオーナーはプロダクトバックログの内容、可用性、並び順に責任を持つと。
いわゆる要件定義で出てきた要件みたいなもんですかね。
プロダクトバックログは決して完成しません。
開発の初期段階には最初から明確でよく理解できた要求が実は並べられています。
プロダクトバックログはプロダクトや使用環境に合わせて進化するものですと。
プロダクトバックログは動的であり適切で競争力のある有用なプロダクトに
必要なものを求めて絶えず変化をしていきます。
ここが完成しないと言っていることの本質ですね。
プロダクトが存在する限りプロダクトバックログは不滅ですと。
これちょっとかっこいい。
プロダクトバックログっていうのは今後のリリースで実装するプロダクトの
フィーチャーだったり機能、要求、要望、修正というのをすべて一覧にしている。
ほんと全部ここに集約されてるんですね。
とにかくやることっていうのは。
プロダクトバックログアイテムには詳細、並び順、見積もりの属性を付与されています。
プロダクトが使用されて価値が増加し市場からフィードバックを得られると
プロダクトバックログというのは巨大で包括的な一覧になります。
市場の変更はもうちょっと終わりません。
プロダクトバックログは生きた作成物になります。
ビジネス要求、市場の状態、技術の変化というものが
プロダクトバックログの変化につながりますよということですね。
あくまでビジネスとか市場というところが目的ですからね。
あと技術の変化もちゃんと含まれているというのはいい話かもしれない。
複数のスクラムチームが同じプロダクトの作業をすることがよくあります。
ラージスケールオブスクラムでしたっけ?
名前を聞いたことがあってスクラムアットスケールみたいなものもあったりするそうですね。
そうした場合はプロダクトの作業というのは一つのプロダクトバックログに記述します。
あ、そうなんですね。これでもう一つに集約するんだ。
またアイテムをグループにまとめる属性をプロダクトバックログにも追加します。
プロダクトバックログアイテムに詳細・見積もり・並び順を追加することを
プロダクトバックログのリファインメントと呼びます。
リファインメントって見積もりとか並び順、詳細というのを追加することなんですね。
これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスになります。
プロダクトバックログのリファインメントによってアイテムのレビューと改訂が行われます。
いわゆる優先順位付けみたいなところですかね。と思っていただけばいいのかもしれない。
いつどのようにリファインメントをするかはスクラムチームが決定します。
リファインメントは開発チームの作業の10%以下にすることが多い。
これは時間的なことですね。
ただしプロダクトバックログアイテムというのはプロダクトオーナーの判断によっていつでも更新はできる。
逆に開発チームはラクマで相談をするけど、
15:00
プロダクトバックログの変更権限は基本的にはプロダクトオーナーのみだというところのルールは徹底する。
並び順が上のアイテムほど明確で詳細であれば見積もりも正確になる。
並び順が下のアイテムほど不正確でまだ詳細ではない。
今後のスプリントで開発チームが従事するプロダクトバックログアイテムは
スプリントのタイムボックスで完成できるようにうまく細分化する必要がある。
開発チームが一つのスプリントで完成できそうなプロダクトバックログアイテムは
スプリントプランニングで選択できる準備完了、いわゆるレディの状態になったとみなせる。
プロダクトバックログアイテムは上記のリファインメントによって透明性を獲得することが多い。
開発チームは見積もりに対して責任を持ちます。
プロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともありますが
最終的な見積もりは実際に作業をする人が行います。
続いてゴールへの進捗を監視しましょうというところですね。
プロダクトバックログだけでかなりいろんな観点があるんですね。
いずれかの時点で開発ゴールに対する残作業を合計すると
プロダクトオーナーは少なくともスプリントレビューにおいてこの残作業の合計を追跡すると
そのリファインメントしたりとか見直しをするというところです。
見直しをしてその残作業を合計するというところですけど
これをどこでやるかというのは最低でも1回はスプリントレビューの場でやるんですね。
レトロスペクティブのところでやるわけじゃないんですね。
全体見直しをするという可能性もあるけどやるとしたらスプリントレビューでやるんですね。
なんかでもこれ変わってるんじゃないかな。
最新のスクラムガイドのドキュメントでどう定義されているかわからないですけど
なんとなくスプリントレビューでやるものだとは思わなかったですね。
まあいいやちょっと続けますね。
プロダクトオーナーは前回のスプリントレビューの時の残作業の合計と比較して
希望する時間までにゴールに到達できるかどうかというのを評価します。
この情報は関係者全員に明らかにされると。
合計したり見直しをしたり評価をするというところを
開発チームと一緒にやった方が早い気もしなくはないなというか
いわゆるモブプロに近い感じがあるなと思いましたが
全員を呼んでしまうと開発者の時間をコース奪ってしまうのでそういうことはしないんでしょうね。
進捗の見通しを立てるためにいわゆるバーンダウンチャートといって
バーンアップチャートみたいなさまざまなプラクティスが使用されます。
これらは有用であるけど経験主義の重要性を置き換えるものではない。
複雑な環境下では何が起きるかわからない。
すでに起きたものだけがこれから先の意思決定に使用できるということですね。
事実ベースでやりましょうということでした。
続いてスプリントバックログですね今度は。
さっきのはプロダクトバックログですけど今度はスプリントバックログです。
スプリントバックログっていうのはスプリントで選択したプロダクトバックログアイテムと
それらのアイテムをプロダクトインクリメントにして届けて
スプリントゴールを達成するための計画を合わせたものになります。
スプリントバックログは開発チームが作成するインクリメントに含まれる機能と
その機能を完成インクリメントにして届けるために必要な作業の予想であります。
18:01
スプリントバックログによって開発チームがスプリントゴールを達成するのに必要な作業が
すべて見える化されているいわゆるチケットですね。
今週スプリントでやるチケットのことだと思いますね。
スプリントバックログは十分に明細詳細であり今後も変更される可能性のある計画であります。
それはデイリースクラムで理解できる程度のものになります。
最初のパッと集まった15分間でパッと理解できるぐらいにはしっかり詳細になっているということですね。
開発チームはスプリントでスプリントバックログをもちろん修正します。
スプリントバックログはスプリントで送発されます。
こうした送発が発生するのは開発チームが計画を実行する中で
スプリントゴールの達成に必要な作業を学習するからになります。
だからチームというところが重要になってくるわけですね。
新しい作業が必要になれば開発チームがスプリントバックログに作業を追加します。
作業が完了すれば残作業の見積もりを更新します。
計画の要素が不要になればもちろん削除をします。
スプリントでスプリントバックログを変更できるのは開発チームだけである。
逆にプロダクトバックログはプロダクトオーナーしか変更権利はないけど
スプリントバックログを変更できるのは開発チームだけなんですね。
スプリントバックログには開発チームがスプリントで行う作業がリアルタイムに反映される。
スプリントバックログというのは開発チームのものになります。
スプリントは実際に開発フェーズというか実行の機会になってくるので
そこのオーナーシップを取るのはあくまで開発チームですよということが重要ということですね。
OKです。わかりました。
続いてスプリントの進捗を監視するというところですね。
スプリントのいずれかの時点でスプリントバックログの残作業を合計します。
開発チームは少なくともデイリースクラムにおいてこの残作業の合計を追跡して
スプリントゴールド達成に見通しを立てる。
開発チームはスプリントで残作業を追跡して自分たちの進捗を管理する。
ここはしっくりきますね。
デイリースクラムで残作業の数字を見直しをしていくということですね。
ラストインクリメントですね。
インクリメントとはこれまでのインクリメントの価値と
今回のスプリントで完成したプロダクトバックログアイテムを合わせたものになります。
スプリントの終わりには新しいインクリメントが完成していなければいけない。
つまりインクリメントが動作する状態であり
スクラムチームの完成の定義に合っていることを意味します。
プロダクトオーナーがリリースを決定するしないに関わらず
インクリメントは常に動作する状態にしておかなければならないというところですね。
では作成物の透明性ですね。
スクラムは透明性に依存しています。
作成物の状態を把握することで
価値の最適化だったりリスクの制御に関する決定を行います。
透明性が確保されている限り
こうした決定には信頼できる根拠が存在します。
作成物が不完全に透明化されていれば
こうした決定には不備があり
価値は低減しリスクが高まる可能性があります。
もともと不透明であればリスクしかないなという感じですけどね。
スクラムマスターはプロダクトオーナー、開発チームその他の関係者と一緒になって
作成物が完全に透明化されているかというのを理解します。
不完全な透明性に対処するにはいくつかのプラクティスが存在します。
スクラムマスターはその中から最適なプラクティスの選択して
21:02
プラクティスオーダーですね、これは。
多分5時かな。
選択してもらえるように支援します。
スクラムマスターは作成物の検査、パターンの察知、
言説の計帳、期待値と実際値の違いというのを把握することで
不完全な透明性を検知できると。
逆に言うと開発チームがこの辺をしっかり言語化できるように
このタスクの進捗だったりとかを
しっかりと嘘偽りなく表明するというのも重要だなと思いましたね。
スクラムマスターの仕事というのはスクラムチームや組織と一緒になって
作成物の透明性を向上させることになります。
この仕事には学習、説得、変化を伴うことが多い。
透明性は一覧にしてならず、透明性とは長い道のりなのであると。
最後、完成、断の定義です。
プロダクトバックログアイテムやインクリメントの完成を決めるときには
全員がその完成の意味を理解しておかなければいけません。
スクラムチームによってその意味は大きく異なりますが、
作業の完了についてメンバーが共通の理解を持ち、
透明性を確保しなければいけない。
これはスクラムチームの完成の定義と呼ばれ、
プロダクトインクリメントの作業が完了したかどうかの評価に使われます。
この定義は開発チームがスプリントプランニングで
プロダクトバックログアイテムをいくつ選択するかの指針にもなります。
各スプリントの目的はそのときの完成の定義にあったリリース判断可能な
機能のインクリメントを届けることになります。
開発チームはスプリントごとにプロダクトインクリメントを届けます。
インクリメントは実際に利用可能なものであり、
プロダクトオーナーがすぐにリリースすることもできます。
インクリメントの完成の定義に関して、
開発組織の慣例だったり標準、ガイドラインが存在する場合は、
スクラムチームは大抵でもそれを守らなければいけません。
インクリメントの完成の定義が開発組織に存在しない場合は、
スクラムチームの開発チームはプロダクトに適した完成を
定義し直さなければいけませんよということです。
複数のスクラムチームがシステムやプロダクトのリリース作業をする場合は、
全てのスクラムチームの開発チームが
共通の完成の定義を使用しなければいけない。
インクリメントはそれまでのインクリメントに追加されたものであり、
全てが正常に動くように十分テストされたものになります。
スクラムチームが成熟していくと、
完成の定義にさらに厳しい品質条件を追加することもあります。
プロダクトやシステムは完成の定義を備えるべきです。
それがあらゆる作業の完了基準となります。
最後に、スクラムは無料であり、本ガイドで提供されているものであります。
スクラムの役割、作成物、イベント、ルールというのは普遍です。
スクラムの一部だけを導入することはもちろん可能ですけど、
それはスクラムとはもちろん言えません。
全てをまとめたものがスクラムであり、
その他の技法、方法、論プラクティスのコンテナとして機能しますということでした。
あとは一応写事でいろんなことがばーっと書かれています。
一応人々のところがあります。
スクラムに貢献してくれた非常に多くの人たちの中でも、
最初の10年間に貢献してくれた人の名前を挙げたい。
まず、ジェフ・サザーランドと一緒に働いてくれたジェフ・マッケナ。
それから、ケン・スウェバーさんと一緒に働いてくれたマイク・スミスとクリス・マーティン。
翌年からはその他にも多くの人たちが貢献してくれた。
彼らの助けがなければ、スクラムは今日のように専念されていなかっただろうというところでございます。
24:04
あとは一応歴史がガーッと書かれているので、興味のある人は見てみてください。
一応このスクラムガイドの翻訳に関しては、
核さんというか、核正成さんが担当したと。
翻訳・レビューに森武さんと村橋健一さん、核谷慎太郎さん、あとは栗明読み方、ひろと…わからないという方に
とりあえず栗明さんにレビューいただいたということでした。
他にもいろんな方にもレビューいただいてますよというので、写事で締められています。
このガイドにも2011年から2013年にかけてのスクラムガイドの変更点というのがあります。
過去のものからどんな変更があったかというところですね。
いくつかありますけども、6個ありますがここはちょっと冗長になるので読むのを控えたいと思います。
じゃあ改めてこれで今日の朝活は終了したいと思います。
スクラムガイドでした。あくまでガイドなのでどうやってやっていくかとか、
実際の現場ではどういうことが起きるかという、この通りになかなかうまくいかないことなんてたくさんあると思いますけども、
それもすべて含めて経験学習としてスクラムチームの情勢だったり進化になっていくんだろうなと思いますので、
参考にしていただけば幸いですし、まずスクラムがわからなくなったりとか導入してみたくなったときは
このガイドにのっとってやっていくのがいいんじゃないかなと思いますので、ご参考に読んでいただければなと思います。
じゃあ今日の朝活はこれで以上です。
明日からまた次回、また技術的な記事に戻ろうかなと思います。
技術じゃない記事がポンポンと続いたので、テクノロジー的な記事を読んでいきたいかなと思っておりますので、
またご興味あれば参加いただければと思います。
プテラノドさん、今日はご参加いただきありがとうございました。
今日も一日頑張っていきましょう。金曜日ですね。
終了します。お疲れ様です。
