第19章 より効果的なアジャイル:プロセス改善
「fix systems, not indivisuals」(個人ではなく仕組みを修正する)
好きな考え方
それな!!!
「間違いを許す」ことは「間違いを無視する」という意味ではない
いい言葉だ。。相手を責めないように気を遣った結果、間違いを見て見ぬふりにしちゃうこと、多いから気をつけよう
自分に対してもいえそう。自分がした間違いを許すのと、無視するのでは全然話が違う
的を射ているなぁ、、
ソフトウェアの生産性を絶対的な尺度で計測することはほとんど不可能だが、
このあたり、EBMが進んできて、結構変わってきている印象がある。もちろん絶対的な尺度とまでは言い切れないと思うけど
軸だし、既存の絶対値をつかっているのもよさそう
最初の5回のスプリントでは平均ストーリーポイントが50で、次の5回のスプリントでは平均ストーリーポイントが55であるとすれば、チームの生産性が向上していることがわかる。
ベロシティがあがったから生産性向上しました!は言いたくないなあ...10倍くらいになっていたら別だけど
もちろん、生産性の計測については「計測によって何を質問しどこを調べたら良いかは明らかになるが、必ずしも答えが分かるわけではない」という姿勢でいるのが良いだろう
それそれ。ベロシティを信用しすぎない、使いすぎない方が良いようにおもう。
インプットに対してアウトプット量が生産性だとしたら、バックログアイテムのバイト数 対 コード行数が正確なのでは?バックログアイテムの合意時間 対 コード行数
このときのコード行数は一定の基準を満たす
問題のあるチームメンバーを多数決で締め出そうとする場面を何度か目撃したことがある
無闇に人数を追加しても生産性は上がらない話は聞くけれども、ここの追い出す話はポジティブに語られているんだろうか。
私たちが見てきた組織の問題は次のようなものである。
森さんがみたら「うーん。。。」って言いそうな問題ばかりだw
ここにある問題はアジャイルやスクラムをする前の問題…ってことですか?
WIP制限かけるの、初期のチームだと多用している。(最初は制限1でやってみている)
プロフェッショナルデベロップメント
知識やスキルを高めるための教育的なアクティビティのみでなく、マネージメント、チームワーク、プロフェッショナリズム、コミュニケーションスキルの向上といったことも含まれます。
ストーリーポイントの割り当ては、一度決まった後は変更しないが、レトロスペクティブミーティングでレビューできる
地味にやったことなかった。今度テーマに出してみよう
どの場合も、個人の生産性を計測する有効な手段は存在しない
個人の生産性を継続できないという話は、認知心理学の話とも繋がってくる気がするなあ。
レトロスペクティブ
1. 準備をする
いつも冗談からミーティングを始めることで、間違いを許すことと心理的安全性の雰囲気を作っている
ここ気になる。冗談から入ってそんな雰囲気になるかなぁ。。。
これはmiholovesqをみていると、できるんだなーっておもってしまう。自分にはできないが。
計測ごっこに注意
ウッ、、認知バイアス、、、
検査
■チームのスクラムの実践を調べて、計測のベースラインが形成されるほどの一貫性があるかどうかを確認する。
これはありそう
ちゃんと計測したことなかった。。。
確認の仕方がよくわからない、、
■スプリントレビュー、スプリントレトロスペクティブ、スプリントプランニングでチームのパフォーマンスを確認する。チームはそうした機会を利用して検査と適応を行っているだろうか。
レトロスペクティブとプランニングでは、検査と適応がなされ、都度改善は進んでいる印象はある。スプリントレビューは、意見は出るものの、POが意見をあまり取り入れずに、役員の人の意向を探りながらPBLを手入れしているのが気がかり。
行っているとは思うが、程度は怪しいなーってなる。検査が不適切かもしれないとかは毎回思うなー。
行ってるとは思っているが、それが適切かはわからない
■リーダーとしてチームの改善をどれくらい支援しているだろうか。特に、短期的なデリバリーニーズと長期的な改善目標のバランスをどれくらいうまく取っているだろうか。
リーダーとしてなのかはわからないが、品質面のプロセス改善は大分支援できている気はする。短期的なデリバリーニーズはあまり考えられていないので、バランスが取れているのかは自信がない。
自分は長期的に偏っているというのは自覚があるけど、短期的利益を求めている人はプロダクトマネジメント力が足りないだけだなーって思ってる。
バランスは考えたことがなかった、というか、二兎を追っていた気がする。スクラムマスターとしての支援はかなりできていたと思っている
■ワークフローをマッピングし、遅延がないか調べる。不必要な遅れによってデリバリープロセスにどれだけのムダが生じているか評価する
今のチームでできていないのでやってみよう
不必要かどうかを定型的にみたことないかもな。VSMが安定するとこういうことやりやすそう。
遅れは同期開発の時はなかったかなぁ、非同期だとまだ母数が少ない、、
適応
■ストーリーポイントを使ってプロセスの変更の効果を計測する。
計測はしている。ベロシティはあまり向上していないが、バグの数は着実に減りつつある。
そもそも計測してないのでやってみたいと思ったが月面着陸は今開発をしていないので、enPiTでやろうか一瞬頭をよぎったけど計測ごっこになっちゃう可能性が高そうなので、うーん、、
計測可能なアウトカムを初期から構築できるかがどうかが、プロジェクトの成功にかかっている気がする
■関連するスクラムイベントで検査と適応を一貫して使用するようにチームに働きかける。
なんとなくSMの仕事っぽい気がして遠慮してしまっている。。
「SMに質問なんですけど、〜〜は〜〜になっていると思うんですけど、〜〜になっているほうが進めやすいと思いました。どうですか?」みたいにロールに質問するとやりやすいですね
SMの仕事として行えているかなーと思っている
■レトロスペクティブが重要であることと、レトロスペクティブの結果に基づいてチームが次のスプリントで直ちに変更を行うように支援することをチームに積極的に伝える。
これもなんとなくSMの仕事と思いつつ、こちらは積極的に伝えられている。
SMの仕事として行えているかなーと思っている
支援するっていうところまでふくめて自分はやるように気をつけているなー
■カンバンを使ってチームの作業を可視化し、遅れているものを探す。
遅れているかどうかの軸では可視化できていないが、DONEになるまでの時間が長いものを可視化するようにはしている。
遅れているかどうかの判断がまだつかないなぁと、それがストーリーポイントとかによる計測…?