cappyzawa
cappyzawa
Jun 22 · 7 min read

2019/06/17–19で開催されたCSM研修に行ってきた

Certified ScrumMaster® 2019/6/17–19 — training

試験も通り晴れてCSM(Certified Scrum Master)になった

参加したきっかけ

約1年間名ばかりのScrumマスターをやってきて、なんかScrumって遅いなーと思っていた。基本に立ち返るとScrumはアジャイルな状態になるためのフレームワークであるためこれはおそらく自分/自分のチームのScrumが間違っているに違いないと思い研修に参加した

話すこと

Scrumとは?と言う話より、俺たちのScrumのここが間違っていたということに焦点をあてる。その説明をする上でちょっとScrum知識にも触れていこうと思う。

🙅 コンポーネントまたはプロセスによるPBIの分割

PBIはProduct Backlog Itemの略。

よくこんなPBIが積まれていないだろうか?

  • foo サービスの設計をする
  • foo サービスの実装をする
  • foo サービスのテストする
  • foo サービスの…

これはあまり良いとは言えないPBIだ。PBIはINVESTを守る必要があり上記はそれを満たしていない. (それに利用者ベースになってもいない) INVESTについての詳しい説明は下記に任せる。

ユーザーストーリーの”INVEST”とどう付き合うか | GuildWorks Blog

1つのPBIはそれだけで出荷可能になる状態を目指すべきだ。この状態になることで1Sprintごとにフィードバックを受けられる状態を作ることが可能になる。今回あげたよくない例は1Sprintごとにウォーターフォールを進めている典型である。

まずはこの状態を作るところから初めると良さそうだなと思う。

🙆 機能ごとに1つのPBIを作るようにする

またScrumの1Sprintの推奨期間は1week-2week(最長30days)であるが、どのくらいの時間があれば小さい出荷可能な(最低限動く)ものを作れそうかということをベースに期間を決めるのが良さそうだと思う。もちろん要求を細かく分割することは忘れないでほしい。(上の悪い例であげられたものを全部やるには30daysは必要だ!とか言う基準ではないという意味)

🙅 PBIからSBIを決めるのがPO

SBIはSprint Backlog Itemの略で、POはProduct Ownerの略。

Sprint PlanningにてPOが開発チームに向けてここまでお願いします。といって、開発チームができそうかできないか判断するというフローを取っているチームは結構多いんじゃないだろうか。

🙆 PBIからSBIを決めるのは開発チームの役割であり、それに対してPOと合意する。

開発メンバーは自立している。(インクリメントを作っていくという責任を忘れずに)

また、POは開発チームの限られた時間/作業でよりいいものを届けていくためにPBIの優先度判断に全力をそそぐべきだ。

🙅 動くもののないスプリントレビュー

ちょっとPBIの分割ともかぶる。

今回は調査・検証をしました!みたいなレビューがよくありそうだが、こういうのはよくない。(フィードバックをもらえる情報が0であるため)

🙆 難しいことではあるが、極わずかでも価値を出しながら調査や検証をすることを目指す

ソフトウェアに置ける一番の依存は学習/知識であるためこのようなことが発生しやすいのだと思う。

チームに学習をするための時間は必要か?

上記を実践する場合、いつ学習のためのまとまった時間をとるんだと言う話になる。

自分の意見になってしまうが、これは必要かつ必須で開発チームはそれを確保するための努力をする必要があるし、その時間がとれていないのならば1Sprintで作業する量を減らすべきであるとも思う。

1つ講師のMJで面白い話があって、寿司屋において一番危険なのは切れ味の悪い研がれていない包丁であり、そういうことがないようにきちんと勤務時間内に包丁を研いでいる、ということを大将に聞いたらしい。

ではソフトウェアにおいて一番危険なのは何かと言う話になり、スキルの研がれていない開発者だということになったw

開発チームのスキル不足で利用者が本当に欲しい価値を提供できないというのは避けるだと思うから、しっかり研ぎ続けた方がいいと思う。

🙅 経験に基づかない決定

🙆 Scrumは経験主義

もちろん最初は直感による決定を行う他ないのだが、その後は経験に基づいて何かを決定していく必要がある。

PBIの見積もりも経験によって決めていく必要があるし、作るものでさえも経験によって決めていくべきだ。

Sprint Review時にフィードバックを得られる環境を作れていない場合は、Reviewによって得られる経験は0であるため次のアクション決定を行うべきではない。(現実問題決めるしかないから、問題に気づきにくい)

利用者に価値を届ける以上、何を届けたら利用者として一番価値が高かったのかと言うことを経験していける環境をつくることに尽力する。

最終的に優先度の判断はPOが行うことではあるんだが、やることに対しての意味がない/あるの議論をしている暇があるのなら、小さなPBIをつくってフィードバックをもらうことに努めるべき。

もちろん仮説は大事なので、仮説なしでとりあえずやれ!と言っているわけではない。

やる意味がない・あるがわかっているなら要求は不確実でないわけだから、無理にScrumをやっていく必要がない

🙅 ベロシティを上げていく

リファインメントでポイントを見積もって、そのポイントの高低で自分たちのスクラムがうまくいっているかいないか判断しているところは多いと思うが、実はベロシティはスクラムの一部には含まれていない。

じゃあなんでリファインメントで見積もるのかというと、チームの認識のずれを発見するためである。

Scrumにおいて大事なことはベロシティ(できあがったものの量)というよりはフィードバックへの適応である。

ベロシティがいくら高くてもフィードバック基づいた改善ができないものの価値は低くなる。

それよりかはチームとしてフィードバックをもらい適用する時間を確保することに努めるべき。

ちなみにベロシティは定量的に何かを測定できていそうにみえるが、あのポイント自体正確な見積もりを支援するものではないため幻想であることを理解したほうがよい。

まとめ

自分/チームが間違っていたという内容に焦点をあてて紹介した。

Scrumでかちっと決められているものはわずか(?)であり、それ以外は自分たちのチームに合わせてカスタマイズしても良い。(チームで話あって決める)

なので基本的には正解はなく、自分たちが価値をすばやく価値を届けるために必要だと思ったことは実践して良い。つまり遅いなと感じるのは何かしらチーム独自のルールに間違いがある or 誤ったScrumプロセスを踏んでいるだと言うことだ。

自分たちのルールを決める上で忘れてはいけないのはScrumはアジャイルな状態を目指すためのフレームワークでしかないということだ。Scrumを続けているとおそらくScrumをやることが目的になってしまってアジャイルな状態になるという大きな目的を忘れてしまいがちになると思う。 何か議論になったときは、最終的にそれはアジャイルな状態に近づくのか?ということを軸にして決定するのがいいんじゃないかと思う。

それとScrumとして目指す姿は自立した/クロスファンクショナルなチーム(開発チーム)であるため、POやScrumマスターはどんどん権限を移譲していくことを目指す。

参考資料

cappyzawa

Written by

#golang #concourse #vim

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade