第18章 より効果的なアジャイル:計測
ストーリーポイント を 一度 割り当て たら、 チーム が 実際 の パフォーマンス に 基づい て ストーリー ポイント の 割り当て を 変更 する こと は ない。 最初 に ストーリー ポイント として 5 を 割り当て た ストーリー が、 完成 する 頃 には 8 の よう な 気 が し た として も、 ストーリー ポイント は 5 の まま で ある。 これ、僕、勘違いしてた。ストーリーポイントはリファインメントでガンガン更新してた。。。だって、アジャイル未経験のメンバでチームが初めて組閣されて、スプリント1の際にストーリーポイント1の基準が定まったことががなかったので。。。2,3スプリントは基準が揃うまで、様子見ながらすすめましょうって思っていた。。。
リファインメントで更新するのは問題ないのでは?と思った。おそらく、スプリントバックログに載って着手を開始した後、思ったよりも作業が大変だった、という時に5→8に更新、というのはだめなんだろうな、と理解していた
なるほど、スプリント期間中に変えるのはNGですよ、ということか。
ふりかえりでポイントのずれを議論するために付箋に追加で増えたポイント数を書いていたことある
これは僕もあります!!
なぜ途中で変更しないのか、ということが書かれてないけど、どういう意図があるのかな。
ベロシティからあるエピックの完了(リリース時期)を割り出したいという理由から、スプリントレビュー後にストーリーポイントを実感値に変えるというスクラムチームを先週ぐらいに観た。
ベロシティはスプリントごとに変動するため、通常は意味を持たない。大きな意味を持つのは平均ベロシティの推移傾向の方である。 データを計測しているっぽさある。この平均の推移傾向は、移動平均だろうな。
すべてのチームがストーリーポイントを使用しているからといって、各チームのベロシティを比較することに意味があるとは限らない。
よくわからないのだけど、大規模スクラムとかだと、複数チーム間のポイントの単位を揃えたりとかしないのかな?
手戻り率(R%) は、 手 戻り に 投入 する 作業 と 新しい 開発 に 投入 する 作業 の 割合 を 表す。 第 11 章 で 説明 し た よう に、 手 戻り は ソフトウェア プロジェクト の 効率 の 悪 さや 無駄 を 表す 有益 な 指標 で ある。 手 戻り 率 が 高い 場合 は、 次 の よう な 問題 を 示唆 し て いる 可能性 が ある。 この記述をみて、手戻り率(おそらくは最初は回数)を、POの練度チェックに活用してみようと思いました。
コンテキストを補足すると、ベンダーとして開発チームとスクラムマスターでお客さん先にお仕事に行くんですが、POの練度があまり高くなくて、、、(お客さんも立場上、それを認めるのを嫌がって)という状態になっていて、リファインメントに開発チームの3割位の工数が溶けているにも関わらず、スプリント期間中にPOがさらに上司の差し戻しが入って受け入れ条件が緩かったので更新します、的な発言を繰り返す案件がありまして、云々。そこに対して手戻り率を適用することで、打開策が立てられるのでは、という着想をえたという次第です
本にも書いてあるが手戻りの定義はなかなか難しい。。
「ユーザに使ってみたら、もっとこうした方がいい、となって作り直しした」のと、「ユーザが使ってみたら、この機能はいらない、となった」場合それぞれについて、手戻りとして扱う方が良いのか否か、という話を前にチームでしたことがある。
確かに。でもチームで手戻りの定義を整合できれば(議論するだけでもいいかも)、かなり意識できると思うので、それだけでも手戻り抑制効果がありそう!!
あ、でも手戻りは事象であって、内容次第ではすべてが悪いこと、ということでもないのかな??このあたりを整合しないままに手戻り率の抑制、を目的にすると、踊らされて、良い開発をするという本質を失う懸念があるのか。。(と書いている間に、上にも類似の主張を書いてくれていた!!)
そうなんです!!
手戻りの話は正直よくわからんなってなっている。手戻りと定義したいモチベーションがいまいちわからないというのが大きいのかもしれない。
単に 手 戻り 作業 には ストーリー ポイント を 割り当て ない という ポリシー を 設定 する 方法 も ある。 手 戻り 率 は 計算 でき なく なる が、 チーム が 手 戻り 作業 に かなり の 時間 を 費やし て いる と し たら、 ベロシティ が 低下 する はず だ。
そうなんですが、実際には手戻りはプラスαの作業として完了させることを期待され、プランニングで宣言したバックログは残業してでも完了させることを期待される。。。なので、ベロシティは低下しない(という現場しか見たことないです。。)※異論を認める!!というか、異論だけを聞きたい!!
スコープを柔軟にして、タイムとコストを固定化させるのがアジャイルだと聞いているので、ちょっと驚きですね。全部固定でやるなら、超高速ウォーターフォールの働きたい放題プランをやっているっていうだけでは。。。
アジャイル開発はプログラマーの復権であり、システム開発組織の幸福の実現なので、ちょっとやばい気がしました。。。
ツールが集めたデータの仕様は慎重に
本の感想ではないですが、最近、GitHubのPRのコメント数とか、ブランチのマージ数を計測するサービスがあるらしく、会社で導入しようと検討しているのですが、何の理由で導入しようとしているか気になる。(開発組織へアセスメントをしたいという雰囲気がある)
↑うちでもなんか似たような話がw
昔、BitbucketのPRが作られてから閉じられるまでの期間とその見積もりのポイント数をプロットしたことある。
https://scrapbox.io/files/61c9afd8f4249c001d61ff35.png
SlackのDMとチャネルでの発言比率をみているマネジメントはいました(DMが8~9割だから、もっと開かれたPJにしようぜ、って言っていたマネジメントがチャネルで発言したことはみたことないです。。。)
検査
■計測に対するチームの姿勢を確認する。作業の品質を最終的に向上させるような変更を行うにあたって、計測が自分たちの支援になることをチームは理解しているだろうか。
うーん、あんまりできていないかな。。ある意味間違ってはいないんだけど、計測することは間違った価値を大切にしがちで危険、という印象が根強くて、あまり計測に対して前向きではない印象。自分も今ひとつ効果的な計測がぴんときてなくて、とりあえず取れるものは全てログに残して、なんか考えたくなった時にちらちら見返しながらいい指標ないかな、って考える程度。
■チームのストーリーの大きさとイテレーションの長さを確認する。ストーリーとイテレーションのサイズは、生産性をより正確に計測できるほど小さいだろうか。
スプリント期間に応じてプランニングに使うタスクの粒度を変えるようになったなー。
だいたい一週間を目安に、どれだけできそうかという感覚で計画していることが多い。
上に同じ。仕事が大きすぎて計測できない、ということはない。
■品質にどのような計測(1つ以上)を活用しているだろうか。それらの計測は現在用いている数量ベースの計測とうまくバランスが取れているだろうか。つまり、ビジネスにとって重要なすべてのものがそれらの計測に盛り込まれているだろうか。
EBMのA2I(Ability 2 Innovation)とT2M(Time 2 Market)について計測していることが多くて、大体ガイドにある例と似たようなものを計測していることが多い。システム運用しているともっと具体的な指標になると思うけど、受託開発コンテキストだとここに収まりがち。
SonarQubeで取れる基本項目と、結合テストのテスト密度くらいかな。ビジネスにとって重要なすべてのものがそれらの計測に盛り込まれているかというとそれはNoだと思う。
見積の変数例
ストーリーポイント
初めて触るコードかどうか
初めて触るライブラリ、フレームワーク、ツールかどうか
変更予想プロダクトコード行数
変更予想単体テストケース数
結合テストのテストケース数見積に使った変数例
その機能を参照している機能数
その機能が持つデータを更新する機能数 * 2
とりあえずカバレッジを取ってるくらい。
■組織が使用しているデータのうち、ツールによって収集されたデータを確認する。そのデータはあなたが考えているとおりのものだろうか。
CV(Current Value)に関してはそこそこ取れていて、そこは大体思った通りになっている。UV(Unrealized Value)は恣意的すぎてあんまり使えていない。
組織全体でツールでデータを取っている形跡はない。
まったくやってない…
適応
■チームの作業を支援することが計測の目的であることをチームに伝える。
伝えます!
新しいメンバーが入るたびにやらないとなってなっている。(今いるメンバーは普通だけどっていう)
次は真面目にやってみようと思う(今は?
■チームがストーリーポイントとベロシティをまだ使用していない場合は、それらを使い始めるように働きかける。
これは一応トラッキングして使っている。保守問い合わせに結構大きく左右されるので、保守問い合わせの数も記録して、二つを組み合わせながら将来の見積もりをしている。
スクラムがマッチする場面ではそうするようにしているつもり。
■チームが手戻り率(R%)といった品質ベースの計測をまだ使用していない場合は、それらを使い始めるように働きかける。
以前使い始めて頓挫した。理由は、上にも少し書いた通り効果的な手戻りが定義が難しいと判断したため
手戻りという概念があまり共感できないのでそもそも使っていない。
■ツールによって集められた無効なデータやチーム間の無効な比較など、意味のない計測や誤解を招くような計測の使用をやめる。
自分のチームではやっていないが、会社で怪しい影を見ることがまれによくある。
生産性を図りたいといっている人たちには、売上と収益率を見るでいいじゃないですかっていっている。
■必要であれば、さまざまなチームのベロシティを比較することの危険性について組織を教育する。
ベロシティの比較はさすがにしていないかなあ。あんまり関係ないかもしれないけど、利益率とかで比較するとかはやっていて、業界全体が下降気味の領域の人たちは苦しんでいる印象。