第5章 より効果的なアジャイル:チーム構造
自己管理できる機能横断的チームでは、通常は少なくとも次の専門性が求められる。
■アプリケーションのさまざまなレイヤー(フロントエンド、バックエンドなど)を経験していて、異なる専門知識(アーキテクチャ、ユーザーエクスペリエンス、セキュリティなど)を持つ開発者
■アプリケーションのさまざまなレイヤーのテスト技術者
■テクニカルライター
■実践している開発プロセスのエキスパート(スクラムマスター)
■特定分野のエキスパート
■ビジネス理解、ビジョン、ROIをチームにもたらすビジネスエキスパート(プロダクトオーナー)
この一覧わかりやすいなー。
繋がっていた
繋がっていた!
5~9人編成のチームでは、専門知識の数に限りがある。一般的な適応策は、2~3回のスプリントごとに、ユーザーエクスペリエンスやアーキテクチャといった分野の専門家に臨時メンバーとしてチームに加わってもらうことである。
現実的な対処例かー。まぁこんなものかもしれない?2週間スプリントが多いと考えると、月1で聞くことになると予想すると、経験とも合致するな。
アジャイルの実践の成否は、意思決定のほとんどを自分たちだけで下すのに必要な人材をアジャイルチームに積極的に配属するかどうかにかかっている。
言い切ったな。。。
スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
Scrum Guide 2020 Japanese
つまり、5つの価値基準を満たしながら、意思決定を自分達で下せる人材がいるかどうかで見ると良さそうなのかな?
開発者によるテストはアジャイル開発におけるテストの基盤だが、テスト技術者が付加価値を与えることは依然として変わらない。テスト技術者の役割を廃止している組織では、本来ならテスト技術者に分類されていたはずのメンバーが統合テスト、負荷テスト、およびその他の横断的なテストに重点的に取り組むことがわかっている。
確かになー。これ、デザインだと明らかにそう思えるのに、テストだとそうならないっていうのツールの問題とかもあるんだろうな。。。
こういうテスト技術者と仕事をしてみたい。。。
テストは一番スキルがいらないと思っている人が自分の組織では多いので、このようなテスト技術者と是非働きたい。あと、テスト技術の重要性に気が付いてもらうための道筋を知りたい。。
プロダクションサポートの組織化
組織のリーダーであるあなたには、チームへのインプットとチームからのアウトプットを見ることができるが、チームの内部事情にあまり首を突っ込むべきではない。
言いたいことはわかるのだけれど、これは難しそう。本当にブラックボックスならいいけれど、見えてしまうので。。。
計画、実績、成果物、顧客満足度 が見えていれば文句言われないのでは?
マネージャーがやるべきことは、チームの方向性が明確であることを確認し、チームが責任を持ってその方向に向かうように働きかけることである。
本当にこれ
検査
■チームの構成を見直す。決定の大部分を自分たちだけで下せるだけの専門知識がチームにあるだろうか。
特定の仕事についてはそうかなーって思う。そうではない仕事もあるかなぁ。。。
これはそう。チームメンバー以外がいないと決定できないことはない。勿論、よりよい意思決定を行うためにもっと学びたい知識はあるけれど。。
できないことを認めた上で決めてしまって失敗するように仕向けてしまうかも。そこから学ぶなり詳しい人を知るきっかけになったり。
■チームメンバーにインタビューを行い、チームの事実上の(組織図に示されているものとは別の)テストの組織を理解する。あなたのチームは実質的に自己完結型のチームと言えるだろうか。テストの専門家が含まれているかどうかに関係なくテストを自分たちで行っているだろうか。
自分達でやっているかなー。専門家をチーム内に雇うようになったプロダクトもある。
自分たちでやっている。けれども、QAを中心とした方々の話を聴いたり本を読むと、スキルの足らなさを実感するので、専門家と仕事したい。
自分たちでやっている。
適応
■上記のチーム構成の見直しに基づき、ギャップ分析を行う。自己管理できるチームになるためにはどのようなスキルを養う必要があるだろうか。
パワポ作るのがめっちゃ上手なコンサルですかね。
やっぱりテスティングスキルかなあ
テスト、フロントエンド、デザイン
■各チームが自分たちだけで決定を下せるようになり、本当の「自己管理できるチーム」になるための呼び水として、チームの構成を見直したり、足りないスキルを養ったりするための計画を立てる。
テスティングスキルを養う計画、難しいな。。まずはテスティングスキルの概観が掴めるような本を読んで、足りない所を考えてみる所からかな。。?あとは、本当の「自己管理できるチーム」になれているか、はチームに聴いてみて、なれていないならどんなスキルが足りないかをチームで考えてみてもいいのかも。適応を考えていて思ったけど、計画立てるのがへたくそだなあー
目的、メトリクス(KGI)、手段、見積もり
ゴール指向
GQM (Goal-Quetion-Metric)
GQM + Strategy
スプリントバックログ
開発計画
OKR
Impact Mapping
■テストの役割が開発チームにとって不可欠な部分として組み込まれるような計画を立てる。
チームを組成するときのチェックリスト的なものがいくつかあるよなーっていう話をしていて、そういったReadyの定義みたいなもの作ろうとしているけど、なかなかまとめきれていないですね。このテストについてもその一部だなー。
うーむ。。計画のイメージがあまり湧かないのが正直な所。。好奇心が旺盛で向上心があるメンバーは多いから、まずは本とかを読んだりプレゼンを見て、どんなスキルがあるといいのか考える所からかなあ。それかテストのエキスパート的な人に来てもらって、テストの重要さと奥深さ、高度なスキルが必要なことを身をもって体感するとか。
専門家の話を聞く、相談してもらうところからなのかな。