Azure DevOpsを使ったアジャイルの実践：Daily Scrum編（管理者/スクラムマスター向けおすすめの構成と確認ポイント）
Azure DevOpsアドベントカレンダー11日目です！
最近は開発者向けの内容が続いていたので、今日はおたよりでもリクエストがあった管理者/スクラムマスター向けの安全にスプリントを進むためのおすすめのAzure Boardsのスプリントタスクボードの構成のレシピと確認ポイントを紹介します。
スプリント期間を安全に進んでいくためには、毎日のDaily Scrumでの検査や計画の調整が非常に重要になってきます。
Daily Scrumってそもそも何を確認すればいいんだっけ？というそもそもの話から、
確認したいものを確認するための定量的なメトリクスやその確認ポイントを紹介していきたいと思います(/・ω・)/
スクラム開発やアジャイルをやっていなかったとしても、プロジェクト管理における日々の進捗管理のひとつのアイデアとして参考になればと思います。
その他のAgile/ScurmのプラクティスをAzure DevOpsでやってみよう！系の記事はこちらに。
Daiy Scrumはなんのために？
本家のScrum Guide 2020でのDaily Scrumの定義は以下の通りです。
デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対す
る進捗を検査し、必要に応じてスプリントバックログを適応させることである。（中略）
開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの 1 ⽇の作業
の実⾏可能な計画を作成する限り、必要な構造とやり⽅を選択できる。これは集中を⽣み出し、
⾃⼰管理を促進する。
デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進
する。その結果、他の会議を不要にする。
すなわち、このイベントで達成すべきことは以下になります
- 計画に対する進み具合をチェックする
- 今日やることを決める
- block（障害物）の有無を確認する
- blockがあれば、解決するために何をするか決める
おすすめのAzure Boards スプリントタスクボード構成のレシピ
Azure DevOpsでのタスク管理はBoards>Sprints>Taskboardでやっていきます。
Daily Scrum（以降デイリー）での検査を効率的に行えるようにするために、タスクボードを以下のように構成すると検査をしやすくなります。
「今日やること」が一発でわかるように
Azure Boardsのタスクボードのデフォのレーンの構成はToDo,InProgress,Doneです。
この設定だとデイリーでToDoのどれが今日までにやるやつだっけ？となって検査しにくいので、「Today」のレーンをタスクボードに追加して一発で今日やることがわかるようにします。
このイベントでは今日やることを決める必要があるので、これで今日やるべきことが確認しやすくなるし、大量のToDoから「今日やること」にフォーカスしやすくなります。
タスクボードの右上、Column Settingsを選択して
Add Columnを選択
Column NameをToday、TaskをTo Doにして（これが新しく追加された列のステータスを表す。Todayはまだ着手状態じゃないのでTo Doにする）、新しくできたTodayのCloumnをToDoの次にdrag&drop（この並びがタスクボードのレーンの並び）。
設定が完了したらSaveを押下。
Todayのレーンが追加されました。
地味だけどこの設定をいれることで今日やることにフォーカスしやすくなるのと、日中のタスクの進み具合が確認しやすくなります（In ProgressにいるタスクとTodayのレーンにいるタスクが終わりそうならOK、進み具合がいまいちだったらテコ入れ）。
bockの有無をわかりやすく
デイリーでは障害物の有無を確認する必要があります。なので障害物がある（うまくいってない）タスクは一発でわかるようにしたい。
Taskのwork itemでは障害物の有無はデフォルトでblockというboolのフィールドがあります。なにか上手くいっていないタスクはこれをYesにする感じですね。
というわけで、このBlock==Yesだったらそのタスクに色がつくようにしたいと思います。
タスクボード右上、歯車マークのConfigure Teams Settingsを押下
Styles>Add Styling ruleを押下
Rule Nameでスタイルルールの名前を設定、Colorでタスクボード上での色、ルールは
- Work Item Type == Task
- Blocked == Yes
で設定。設定が完了したらSaveで保存。
とってもわかりやすくなりました。
いつやるのか(Target Date)を見えるようにする
タスクボード上にタスクがいっぱいあるとどれがいつまでにやればいいのかがぱっとわかったほうが「今の進み方で大丈夫そう？」が検査しやすくなるので、タスクのカードにTarget Date（いつやるのか）が出てくるようにすると進み具合の検査と再計画の調整がしやすくなります。
特に、1週間のスプリントならまだしも2週間以上のスパンになるとタスクボード上で管理すべきタスクが増えてとてもじゃないけど「いつやる予定か」がパッとわからないと追跡がとても大変になってしまうので設定をおすすめします。
ちなみに、デフォだとタスクのwork itemには「いつやるか」を示すTarget Dateのフィールドが出てこないので、Organization Settingsから変更する必要があります。
そしてAzure DevOpsユーザーの方にはおなじみかもしれませんが、デフォルトで用意されているAzure DevOpsのProjectのProcess Template(Basic, Agile, Scrum, CMMI)をそのまま使うとwork itemのカスタマイズはできないので、最初からプロジェクトを作るときにはデフォルトのProcess Templateを継承してオリジナルのテンプレートを作成して使うことを強くおすすめします。
この辺のオリジナルテンプレの作り方やwork itemのカスタマイズの仕方は前に書いたこちらの記事を確認してください。
今回はタスクボードにTarget Dateのフィールドが出てくるようにしたいので、Organization Settings>Process>使用中のProcess Templateを選択して
Work Item Type > Taskを選択
New fieldを選択して
Use an existing fieldでTarget Dateを選択して、Add fieldボタンを押下
追加されました。これでタスクのwork itemでTarget Dateが使えるようになります。
ではタスクボードに戻り、
タスクボード右上、歯車マークのConfigure Teams Settingsを押下して
Fields>Taskで、Additional fieldsのセクションで+Add fieldを押下してTarget Dateを選択して追加してください。設定が完了したらSaveを押下。
Target Dateがパッと見えるとすっきりしますね。
遅延の有無をわかりやすく
管理上よく聞くご要望が「遅れているものをパッと識別したい」。そんなときはblockがあるタスクの色を変えたときと同じ方法を使って、遅れているタスクに色をつけます。
今度のスタイルルールはこんな感じで。
- Work Item Type == Task
- Target Date < Today（Target Dateが今日の前）
なんだか危ない感が出ますね。
おまけ：使わないフィールドを非表示にする
「デイリーの確認をしやすくするため」という主旨からは外れますが、もうひとつデフォの設定から個人的にどうしても変えたいもの。
それはPBIにAssigned To（やる人）が出てこないようにする
PBIは「チームの持ち物であって誰か個人が責任を持つものではない」ので、Assigned Toが表示されるとなんとなく違和感あるのと開発者にPBIは誰かがやるとかいう誤解を与えたくないのと、どうせ使わないので非表示にしてます。PBIだけでなく、BugやArchitecture SpikeなどPBIと同じ階層にいるwork itemも同様です。
Target Dateをタスクで見えるようにしたときと同じ設定箇所で、今度はFields>Product Backlog Itemにいって、Show Assigned Toのチェックを外します。
大分見やすくなりました＾＾
確認すべきポイント
追跡/検査がしやすいタスクボードができたので、続いてはデイリーでの確認ポイントのご紹介です。
このままのペースで予定通り終わるんだっけ？
スプリントプランニングで、今回のスプリントで実行する予定のタスクの切り出しと実行計画（このタスクはこれぐらい時間がかかるのでこれをいつまでにやって）を立てます。
デイリーではプランニングの時に立てた計画のまま進んだとして、スプリントゴールが達成できるかどうかを確認します。
炎上したりスプリント最終日の直前にPOに「なんの成果もあげられませんでした！」って土下座しないといけないような事態をさけるためには、計画や戦略は立てたら立てっぱなしにしないで頻繁に妥当性を評価して、状況に応じて調整することがほんとにほんとに大事です。
今の計画で大丈夫なんだっけ？このまま進んでちゃんと予定通りに終わる？をかなり頻繁に確認して、必要であればテコ入れをしていくことで炎上を回避して安全に進むことができます。
これをトラックするために、Burndownというメトリクスがあります。
Azure Boardsのタスクボードでは、選択したスプリントの残り作業の傾向を表示してくれます。
以下のような点をチェックするのに有用です。
- スプリントに割り当てられたすべての作業を完了する目処は立っているか？
- このスプリントにスコープクリープ（割り込み作業は発生していないか？
仕様としては、「そのスプリントのタスクボードに存在しているすべてのタスクのRemaining Workの合計」が、現時点からスプリントの最終日に向かってどのように増減していくかをシミュレートしてくれます。
見方はこんな感じです。
緑の線のチームに残された時間は、Capcityで設定した1日に働ける時間をスプリントの残日数で掛けた値が出てきます。
たとえばこのチームだと、全員一日に働ける時間は8時間×チームの人数は5人×スプリントの日数（２週間スプリントとして、営業日でカウントすると10日）なので、バーンダウンの一番左のスプリントの一日目では400hの時間が残されていることになります。
そして、このチームに残された時間はスプリントが進むごとに減っていきます。
※ちなみに、デフォルトだと「どこをBurndownの開始とするか」の設定は画像のように「スプリントの最初の日を表示しない」となっています。スプリントの最初の日はプランニングで大半の時間を使ってしまうから実際残作業を片すことができる時間そんなにないよね、という意図なのかわかりませんが、「スプリントの最初の日を計測の起点とするか/しないか」はチームによって設定を合わせてください。
（ちなみに私はプランニングの時間もすべてタスクに切り出して残時間を入れて計測するので、この設定は✔にしてます）
グレーの理想線のように、最初から最後の日に向かってだんだん青の残作業合計が減っていって、最終日にはゼロになるのが理想的な進み方ですね。
この青の残時間は、タスクのRemainingを変えると即時で反映されます。なのでリアルタイムで進み具合を検査することができますね。
この緑のチームに残された時間と残作業をウォッチしていけば、チームに残された時間で残りの作業が終わりそうかをトラックしていくことができます。
上の画像のBurndownから分析すると、こんな感じかな？
- 残された時間に比べて残作業が大分小さいので、そもそもの計画段階で作業内容を過大評価してたかもしれない
- 12/6-9の間で残時間が増えているので新しいタスクが増えたか、既存のタスクの残時間の見積もりが変わったか、予定していた作業が計画通りに進んでいない可能性がある
- 12/9-10の間での減り具合がそれ以前の減り具合と比較して芳しくない。思ったより難しくて進まなかったとか、レビュー待ちからなかなか進まないとか、なにかblockがある？
- 12/10時点ではチームの残された時間を残時間が大きく超えてはいないので、この段階で間に合わない（工数オーバー）という判断にはならないけれど、12/11にこの増えた分も含めて予定通り終わるのかが若干リスク。このままだと12/12とか結構いっぱいいっぱいになりそう
Deep Dive: Burndownの見方（危険な兆候）
「こういう形は上手くいってる」「こういう形のときは気をつけろ」！というサンプルが以下のサイトで紹介されています（チャートは手描きなのと全部英語ですが）。
Azure DevOpsのこのドキュメントでも関連記事として紹介されていますね
若干極端な例もありますが、Burndownがこの形になってたら上手くいってないぞ！というアンチパターンをいくつかピックアップして紹介します。興味がある方は参照元のUnderstanding the Scrum Burndown Chartをご覧ください。
1.もう終わらない
チームはスプリント全体で遅れています。最後の方で残作業を表す線はゼロになる見込みはなく、これはPOやステークホルダーに「すみません、完了できませんでした」ってごめんなさいしないといけないやつです（なぜこうなる前に言わなかった案件）。
これはもはや日々のチェックポイントであるデイリーが機能してない可能性があります。レトロスペクティブでちゃんとデイリーがやれてたかふりかえることをおすすめします。
2.早く終わらせたけど後半なにもしてない
これは一見早く終わっていい感じじゃない？かもしれませんが、右の方よく見てください。後半なにもやってません。
これは開始2日目ぐらいのデイリーで「思ったよりも早くおわりそう」というのは予測できると思うので、そのタイミングで後半の過ごし方の計画の調整をした方がよかったかもしれません。
また、「思ったより早く終わる」というのはチームが実際完成させる能力と見積もった作業量や複雑さに差がある/複雑さや作業量を計画時点で過大評価していた/バッファを詰みすぎていた可能性があり、妥当性のある計画を立てていなかったことになるので、見積もりと計画を修正していく必要があります。
終わればなんでもいいわけではないので日々のデイリーで「計画と比べて実際の進捗が妥当か」を検査するようにしましょう。
3.取り組む作業の複雑さの過大評価
これも上の「後半なにもしてない」パターンと似ていて、なにもしていないわけではないけれど残された時間に比べて残作業が大分少ないです。これだとチームは毎日半分ぐらいの時間は何もしてなかったことになります。サイトの英語の表現そのままだと「休もうぜ！(Let's Have a Rest)」って皮肉られてます。
4.空まで続いていく割り込みタスク
これは若干極端すぎる例ですが、これはもうスプリント序盤にして残された時間を超えて残作業時間が増えているので工数オーバーになってます。
これはもう手遅れですが、予定外の残時間の上昇は非常に目を配るべきポイントです。デイリーでこの兆候が見られたら、割り込みタスクの有無や計画した作業内容が実際やったらとても複雑だった、という可能性を疑って、テコ入れをすることをおすすめします。
5.適切にスタートラインを切れていない
チームがスプリントを正しく開始していません。
きちんと開始できていれば、開始初日にチームに残された時間と同じぐらいのタスクの作業時間がプロットされるはずです。
さらに、プランニングの開始が単に遅れただけでなく（単に遅れただけなら序盤のどこかのポイントで残作業時間はMaxになってるはず）、中盤にかけてゆるやかに上昇してるので「計画しながらタスクを進めていた」ということになります。計画がないと進捗のトラックなんぞできないので、プランニングの開始が遅れたならなにをおいてもプランニングを終わらせて残りの作業と時間を適切に識別する必要があります。
また、そもそもプランニングが遅れたり既定のTimeBoxよりもめちゃめちゃ時間が掛かるということはそれ以前の作業の詳細化：リファインメント（要件整理や仕様決め、ハイレベルアーキや実装手段の詳細化）がまっとうにできていない可能性が非常に高いです。
今日のcapacity分ちゃんと働けてる？
たとえば、チームのCpacityがこんな感じだった場合、チームが1日に働く時間は40hとなります（おやすみの日は考慮してください）。
例えばデイリーで、
Today+In Progressの合計時間がチームの1日のCapcity（40h）よりもだいぶ少ない場合、「えっ、今日これだけしか仕事しないの？」ってなって1日の過ごし方としてはまっとうでない感じになります。
この状態が続くと、Burndownのアンチパターンの2,3に陥る可能性があります。
2,3みたいに終わるならまだいい方でですが、To Doのレーンの時間（154）がチームに残された時間を上回る場合、後でめちゃくちゃ残業しないといけないことになるor終わらないことになるので、明らかに今日の過ごし方としては適切でない感じになります。
なので、以下を確認するとよいかと思います。
- ちゃんと今日働く分は働いてるか（チームの1日のCpacityと大きな差がないか）
- 残り作業（To Do）の残時間合計値でちゃんと終わりそうなのか（ToDoの残時間数合計÷チームの1日のcapacityで得られる数字が残日数より大いと残された時間で終わらない）
誰かにタスクが集中していないか
タスクボードでwork detailsを✔すると、
こんな感じでチーム/各メンバーに残された時間と今回のスプリントで実施する作業の残時間の合計が確認できます。
たとえばチーム全体でみたらこんな感じでなんだか余裕がある感じに見えても、
一人がこんな感じだったらこの人に作業が集中していて、この人はこのままだと残業しないといけなくなってしまうのでタスクを誰かに巻き取ってもらうなどのテコ入れが必要です。
その他気をつけること（カルチャーとか習慣的なところで）
-
タスクボードを常に最新化する習慣づけ
これはなかなか最初のうちは難しかったり忙しくなってくると余裕がなくなってくるんですが、タスクボードが現状と合っていないと正確にトラックできなくなってリスクの検知もできなくなるので、とても強い意志を持って習慣化することが大切です。
イテレーション開発やスクラム開発では1-数週間のスパンで生きていくので、1日リスクが検知できなかったりリスクに対する手を打たなかったりするとだいぶ危険になります（終盤になって終わらくなくなって残業増えるとか、最悪の場合「なんの成果も得られませんでした！」になることも）。 -
WIP（Work In Progress）の数は最小限に
これは複数平行すると管理がしにくいとか追跡がしにくいというのもありますが、一番最悪な複数平行してやった結果全部中途半端で品質が低い/終われなかったというオチを避けるためです。開発者が同時に抱える作業量が増えると、ひとつの作業の完了までのCycle Timeは長くなります。完了が遅れることによって十分にフィードバックを取り入れる暇がなくて結果的に品質が下がる、最悪の場合完了できないという恐れがあります。
参考：https://lucidspark.com/blog/limiting-WIP-for-agile-development
-
ひとつのタスクの粒度を大きくしすぎない（8時間とか）
毎日トラックしていくので、8とか16とかタスクの粒度が大きいと正確にトラッキングできなくなってしまいます。Mac2-3時間を目安に。 -
PBIと成果物は常にリンクする
テストケースやブランチ、プルリクエストなど。何か問題があったときや最後に成果をまとめるときにクエリで引けるようになるので、とても楽になります。追跡性を担保する者は救われる。
ご安全に！
スプリントを成功させるためには日々の検査、適応がとても大切です。
今日も一日ご安全に！(｀･ω･´)ゞ
References
Discussion