第9章 より効果的なアジャイル : プロジェクト
全般的にわかりみが深い内容だ。。。
ステークホルダーに新しい要求をデリバリーするまで9か月待ってくれと頼むのはたいてい無茶な話である。3週間ならほぼ待ってもらえるだろう。つまり、スクラムチームはスプリントの途中で新しい要求が追加される心配をせずに作業に取り組むことができる。
これ全くもってその通り。で、それを実現できるプロダクトマネジメント力とチームビルディング力が問われるんだよな。チームがある程度ビルドされていないと、どのくらいの実力があるのかわからなくて手段を選択できない。プロダクトマネジメントがある程度できないと、少ないコストで最大の価値を産んだり、バックログを疎結合に保つようなビジネスをつくれない。
https://scrapbox.io/files/622f324cbf265e001db2db95.png
これいい図だな。途中までは資産なのに途中から債務になるんだよなー。
https://scrapbox.io/files/622f32da4b04e90023d90abe.png
バーティカルスライスの図、初期に見たときはすごく合点がいったんだけど、人に説明すると、「作られる機能は最初から決まっている」という誤解を招きやすくて意外と説明が難しいことがわかった
スプリントの長さをたまに変えてみるってアイデアはこの本以外で言及されているのをあまり見たことがなくて、新鮮な気持ちだった。
現在、アジャイルに関して書かれているものの多くは、持続可能なペースを「残業や休日出勤がまったくない」ものとして解釈している。筆者が思うに、このような解釈は短絡的で、個人の働き方の違いを無視している。
短絡的な解釈をしていたのでどきっとした。。
一気にがーっと働いて疲れてきたらがーっと休むのも充分持続可能なペースだよな。。
技術的負債を測る指標で循環的複雑度を使っているが、他の有効な指標があるのか知りたい。(経験ベースで)自分の所だと、テストカバレッジとかCBOとか、教科書的な指標を幾つか使ったけど、あまり役に立たず頓挫した。
SonarQube
https://docs.sonarqube.org/latest/images/successfulproject.png
推奨リーダーシップアクション
検査
■組織が過去に行ったプロジェクトの成果を確認する。組織の経験はプロジェクトの規模が小さいほうが成功しやすいという一般的なパターンと一致しているだろうか。
一定はそうな気がする。少なくとも大きいのは失敗傾向なんじゃないかな。小さすぎるのも失敗するというか、期待マネジメントがうまくできていないことがあって失敗することがあるみたい。
これはその通り。経験が浅いメンバーが集まった小規模なプロジェクトでスクラムをやったら大成功を収めて、その後全社の大人数な規模に展開しようとしたら失敗した痛い想い出が。。
メンバーが少ない方が良い。ステークホルダーも多すぎても混乱になりがちなので、減らせると良い気がする。
シーケンシャル開発でやってますが、規模は小さいほうが成功しやすい印象です。(先日やってたのも結局着手してから1年以上かかった…後半で問題が発覚しリリースずらすことになったので成功ではないかなぁと。)
■プロジェクトポートフォリオを確認する。大きなプロジェクトの中に複数の小さなプロジェクトに分割できるものはあるだろうか。
あるし、よくそうしている気はする。けど、予算の取り方としてそうであるべきかは微妙かもしれない。プロジェクトを小さくしてプロジェクトごとに予算承認を通さなければいけないとかになると、むしろやりにくそうなので、ある程度まとめた予算プールにしつつ、プロジェクトを小さく選択していくのがよさそう。
↑めちゃくちゃわかる
ある。実際に小さくすることも多い。大体のプロジェクトは小さいプロジェクトにできるイメージはある。
分割して、優先度の高いものから始めると結果的に後の方のはやらなくなることが多い。
■チームのリズムを確認する。チームのスプリントの長さは3週間以内に収まっているだろうか。
どんなに長くてもそうかなー。そういえば、川口さんも3週間っていってたな。
収まっている。2週間より長いスプリントやったことない
1週間が好み。他のチームと連携するとき、だいたい2、3週間なので合わせられる。
■チームがバーティカルスライスでデリバリーしているかどうかを調べる。
だいたいそうなっているかなぁ。
開発の仕方はバーティカルスライスでUAT環境にもそのように撒いているだが、最終的に本番環境にリリースする時は、まとめて持っていく事が多い
できている気がする。
元の構造の問題もあり、できていない。リプレイスの中でバーティカルスライスにできるように検討してますが大変そう…(現行が巨大なアプリ+テストなし)
■チームがベロシティベースのプランニングを使用しているかどうかを調べる。
だいたいそうなっているかなぁ。ディスカバリーなモードのときはどうするかなぁっていうのがなやみ。アジャイルっていうかデザイン思考とかリンスタまわりだけど。
使っている。
ベロシティは最初の方は測ることがある。スプリントが進んでいくと、一週間のスプリントに収まりそうか、という考えに変わっていく。
■技術的負債についてチームにヒアリングする。どれだけの技術的負債を抱えていて、その返済を許可されているかどうかをチームはどのように認識しているだろうか。
チームには許可されているのに、やろうとしない時もあってなんだか大変だなーってなっている。機能を作っても売れるわけじゃないのになーっていう。
返済を許可されている/許可されていないという区別があまりないかもしれない。指標ベースで技術的負債が溜まっていると判断される時は勝手にやっている。あと、技術的負債という言葉だと、個々人で認識が違い過ぎて会話があまり噛み合わないので、指標ベースで会話している(テスト密度が高いとか、循環的複雑度が高いとか)
技術的負債の返済は許可されてますが、そこを意識している人は少数。現状のコードがよくない、わかりにくいという意識は持っていそうだが、納期等で改善されずにすすんでいるケースが多いように思う。
適応
■スプリントゴールを設定するときにチームにそのベロシティを考慮させる。
口酸っぱくしていっているかなー。バックログリファインメントのときにも言っている気がする。
基本的には言っている。ただ、たまにチームがチャレンジをしたい時とかはあって(レトロスペクティブで出たアイデアを使ったら一気に効率的になるんじゃないか、という時とか、コンフォートゾーンに入っている感じが強い時とか)、そういう時は無視したりしている(ただ、大体うまくいかないので、ベロシティを意識してやるの大事だよね、とはなっている)
■バーティカルスライスでのデリバリーが可能になるような計画を立てる。この計画には、開発チームの設計能力と、バックログリファインメントに対するプロダクトオーナーのアプローチが含まれる。
それ。で、テストなりインフラなり監視なりが整っていると、ほんとうにすごく簡単にできるんですよね。。。ので、爆速でシステムを常にリリースし続けられるような開発環境を整えるって大事なんだなーって思う。最近はDeveloper Productivityっていわれるのかもしれない?
リファインメントが全然うまくできないというのはたまにある。POとかドメイン知識持ったメンバーはほんとに大事だよなーと感じる。
■チームの技術的負債に対処する計画を立てることをチームに働きかける。
口酸っぱくしていっているかなー。1年に1回くらいしかメンテしないとか、書き捨てならべつにいいけど。
スプリントごとに都度対処しているが、まとめて1週間くらいかけて返す期間も必要なんだろうな、と思っている。
「余裕ができたら」はできないから、結局返済することが少ないんだよな… 自戒。