QA2AQ AgileなQualityの実践-その4-「俺たちがAQだ!」

QA2AQについての記事4日目。
QA2AQについてはこの記事をご参照ください。

今回は、俺たちがAQだ!といった感じのパレットを抜粋しました。
というより、[Becoming Agile at Quality]のパレットから抜粋しただけになってます。
ホワイトペーパーの訳ではなくを雑訳して引用していますが、私なりの解釈や整理した内容をかいたポエムのようなものととらえてください。

Whole Team

従来、QAチームは開発チームとは別組織として存在していることが多い。
また、開発後半に投入される存在のため、市場投入までの圧力により品質を妥協する場合がある。
従って、QAをアジャイルチームの一員に含めよう。
別組織からチームメンバーとなることで、チーム全体の品質意識が高まる。

QA Product Champion

チームやPOは機能提供を重視しがちになるが、品質が充足されるまでは「リリースできる状態」とは言えない。
チームがシステム品質に集中できるよう支援する役割。
プロジェクトの開始から顧客要件の理解に関与し、チームを支援する。
ビジネスアナリスト、アーキテクト、プロダクトマネージャはQA Product Championともいえる。
専門知識を普及させることで、品質の検討やテスト実施能力の向上を図る。

Agile Quality Specialist

特定のシステム品質に対する技術スキルが高い方を指す。
セキュリティの場合で言えば、セキュリティアーキテクトやセキュリティスペシャリスト。
スペシャリストは、単なる助言だけではなく実践的な直接支援を行うことでチームと協力します。

Spread the Quality Workload

QA以外も品質に関するタスクをこなすことで、作業負荷を分散させる。
プロジェクト全体に品質に関するタスクを含めることで、高品質に向かうための作業負荷を分散させる。

Shadow the Quality Expert

Expertのシャドーイングをすることで、メンター指導効果やチームの成長につながる。
QAの専門知識は高度に専門的である。

Pair with a Quality Advocate

ペア作業はペアプロだけじゃないよ。
QAの仕事はテストだけじゃないよ。
QAとペア作業することで、優れたテストの設計だけじゃなくアーキテクトが品質目標に影響を与えるかどうか検討することもできる。
ただ、ペア作業は片方向の学習だと失敗するかもしれず、双方向の敬意、理解と信頼が大事。


Specialistのシャドーイングができれば、立派なSpecialistになれると思いますが、道は険しそう。
ペア作業を通じて学習していきたいところ。
いや、そもそも自分の身近なSpecialistって誰だろう?

QA2AQ AgileなQualityの実践-その3-「品質の視える化」

QA2AQについての記事3日目。
QA2AQについてはこの記事をご参照ください。

今回は、品質の視える化に着目したパレットを抜粋しました。
ホワイトペーパーを雑訳して引用していますが、私なりに整理した解釈と考え方の解釈や整理した内容をかいたポエムのようなものととらえてください。

Measureable System Qualities

測定方法と値を決めること、当然測定可能な値であること。
測定が困難、またはコストがかかるものがあるので、必要な正確さと精度を計測するための方法を定義すること。
程度を考えた測定が行えるように上記のことを考えろということでしょうか。

System Quality Dashboard

継続的な測定と監視をすること。
考慮する点は、開発環境とダッシュボードがどれだけ統合されているかです。
ランディングゾーンの調整をした際は、ダッシュボードも更新も忘れずに実施しましょう。
ダッシュボードは必ずしもラジエーターではないが、ラジエーターの一部になることもある。
理由は、オブザーバーが理解できない詳細な情報を含むこともあるため。
継続的な監視をするために開発環境とダッシュボードを統合し、ダッシュボードを新鮮な状態に保てということでしょう。

System Quality Radiator

誰かに聞くことなく、現在集中している品質についてとその状況をわかるようにすること。
品質の条件と状況を一目で伝えることを目的としています。

Quality Checklists

システム全体で共通して一貫しているシステム品質の期待値を含むチェックリスト。
ホワイトペーパーを読む限り、本当に想像通りのチェックリストを作れということっぽいです。

Quality Chart

Monitor Qualities

上記2つは視える化に関係していると思いますが、説明なく消えたのでパレット名だけ抜粋です。


視える化は、結構すんなり入ってきました。
個人的にも、普段業務で使っているDashboardがホワイトペーパーで言及されている通りほんと開発者寄りのため、Radiatorを別途用意するならどういった形がいいのか検討したいところです。

QA2AQ AgileなQualityの実践-その2-「品質も意識して、立ち向かう」

QA2AQについての記事2日目です。
QA2AQについてはこの記事をご参照ください。

今回は、プロジェクトを進めるにあたり、機能要件だけではなく、どのように品質に対して成果をだしていくべきかに着目したパレットを抜粋しました。
ホワイトペーパーを雑訳して引用していますが、私なりに整理した解釈と考え方の解釈や整理した内容をかいたポエムのようなものととらえてください。

Agile Quality Scenarios

ハイレベルな品質シナリオを定義せよ。
定義する目的としては、重要な考慮事項であれば、ロードマップの一環として取り入れるようなストーリーを作ることにつながり、結果スプリントへ取り込むことができるようになります。
ということは業務フローの品質版?のようなものでしょうか。

Quality Stories

PBIsのストーリーは機能に焦点が当たりがちです。
重要な品質を優先順位づけして対応するため、品質を達成させるためのストーリを作成します。

Fold-Out Qualities

ユーザーストーリーの中に品質に対する基準を設けます。
ただし、必ずしも最初のacceptance criteriaというわけではない。
議論を重ね合意に達することが重要で、Quality Storiesになるものもあります。
つまり、Refinementをしていく中で、達成させるべきacceptance criteriaと分離して別のストーリーで達成させるacceptance criteriaやQuality Storiesにするなどあり得るということだと思います。

Agile Landing Zones

着地点を設定しろってことです。
最低限、ターゲット、傑出?(適切な訳がわからない)の3点設定しましょう。
一番最良な品質(傑出?)は過剰品質とまではいかない範囲でしょうか?ちょっとそのあたりが読み取れませんでした。

Agree on Quality Targets

着地点に対して合意を得る。
重要な品質要件の場合、Quality ScenariosやAgile Landing Zonesへの合意、Recalibrate the Landing Zoneの合意を得る。
機能要件もそうですが、設定したら合意得ると思うのですが、明記したということはそれだけ機能要件以外の部分はおざなりになりがちなのでしょうか。

Qualify the Roadmap

ロードマップにはマイルストーンなどが含まれているが、システムの品質とアーキテクチャは考慮されないことがしばしばあります。
システム品質に関する内容をロードマップに組み入れろ!

Qualify the Backlog

特定のBacklog、ユーザーストーリーの受入条件に重要な品質要件が含まれていると、見落とたり過小評価することがある。
品質ストーリーをバックログへ組み込む。このとき、ユーザーストーリー固有の品質要件であればFold-Out Qualitiesが含まれたBacklogとして、そうでない場合はQuality Scenarios or Quality Storiesを意味する品質固有のBacklogとなる。


"Qualify the Roadmap"と"Agile Quality Scenarios"の関係性や"Quality Stories"?"Qualify the Backlog"?とそれぞれの粒度がさっぱりわからなくて、何度もホワイトペーパーを読み直したのですが、しっかり理解できてはいないと思います。
現状の理解としては、順番の前後はありますが、"Qualify the Roadmap" "Agile Quality Scenarios"の設定、"Quality Stories" "Qualify the Backlog"や"Fold-Out Qualities"といった具体的な内容に踏み込んで"Agree on Quality Targets"と合意しながら進めていきましょう。
ロードマップ~バックログ、ユーザーストーリーのレベルまで詳細化する過程の流れの中でそれぞれ品質に関する重要事項を設定することで、検討すべき品質事項を忘れずに意識させつづけられるということでしょうか。
さらに、"Agile Landing Zones"を設定し、徐々に品質を達成させていくことも忘れずに。

QA2AQ AgileなQualityの実践「QA2AQに出会う」

品質保証にどう取り組んでいくか考える中で、海外のほうが情報があるのではないかと思い、USのGoogle検索を利用してプラクティスがないかを検索したところ、QA2AQに出会いました。

QA2AQとは?

Joseph W. Yoderさん、Rebecca Wirfs-Brockさん、Ademar Aguiarさんが発表された論文で全Part6まであります。Part3以降は早稲田大学の鷲崎教授の名前もはいっていました。 内容は、「Quality Assurance to Agile Quality」ということで従来のQAがよりアジャイルな形になるための22パターン(Part6時点。Part1からPart6に至るまでに多少変化があります)が示されています。

どこで読めるの?

ドキュメントは、RebeccaさんのWebサイト(http://www.wirfs-brock.com/)で閲覧可能です。(Resourcesページにあります)

Index

Part6まであるので、どのPartに何が載っているのかを勝手に纏めました。

Part1「QA2AQについて」QA to AQ: Patterns about transitioning from Quality Assurance to Agile Quality, by Joseph Yoder, Rebecca Wirfs-Brock, and Ademar Aquilar

Part2「品質の測定と監視」QA to AQ Part 2: Shifting from Quality Assurance to Agile Quality "Measuring and Monitoring Quality," by Joseph Yoder and Rebecca Wirfs-Brock

Part3「障壁の破壊」QA to AQ Part 3: Shifting from Quality Assurance to Agile Quality "Tearing Down the Walls," by Joseph Yoder, Rebecca Wirfs-Brock, and Hironori Washizaki

Part4「品質の優先順位付けと見える化QA to AQ Part 4: Shifting from Quality Assurance to Agile Quality "Prioritizing Qualities and Making them Visible," by Joseph Yoder, Rebecca Wirfs-Brock, and Hironori Washizaki

Part5「高まる品質意識と専門知識」QA to AQ Part 5: Being Agile At Quality "Growing Quality Awareness and Expertise," by Joseph Yoder, Rebecca Wirfs-Brock, and Hironori Washizaki

Part6「品質の有効化と注入」QA to AQ Part 6: Being Agile At Quality "Enabling and Infusing Quality," by Joseph Yoder, Rebecca Wirfs-Brock, and Hironori Washizaki

Core Patterns(Fitting Quality Into Your Process)

Patlet Name JA雑訳 reference note
Break Down Barriers 障壁の破壊 Part3
Integrate Quality 品質の統合 Part1

Identifying Qualities

Patlet Name JA雑訳 reference note
Find Essential Qualities 本質を検索 Part2
Agile Quality Scenarios アジャイル品質シナリオ Part1
Quality Stories クオリティストーリー Part1
Measureable System Qualities 測定可能なシステム品質 Part2 Part3[Specify Measurable Values or System Qualities]
Fold-out Qualities 折り込み品質 Part1
Agile Landing Zone アジャイルランディングゾーン Part2
Recalibrate the Landing Zone ランディングゾーンの再調整 Part2
Agree on Quality Targets 品質目標に同意 Part2

Making Qualities Visible

Patlet Name JA雑訳 reference note
System Quality Dashboard システム品質ダッシュボード Part2
System Quality Radiator システム品質のラジエータ Part4
Quality Checklists 品質チェックリスト Part5 Part4から登場
Qualify the Roadmap ロードマップに品質を組み込む Part4
Qualify the Backlog バックログに品質を組み込む Part4
Quality Chart Part3で消えた

Becoming Agile at Quality

Patlet Name JA雑訳 reference note
Whole Team チーム全体 Part1
Quality Focused Sprints 品質重視のスプリント Part1
QA Product Champion Part5 Part4以降[Product Quality Champion]
Agile Quality Specialist Part6 Part6[System Quality Specialist]
Monitor Qualities Part6で消えた
Agile QA Tester Part6で消えた
Automate As You Go Part6 Part6から登場
Spread the Quality Workload 品質の作業負荷を拡散させる Part6
Shadow the Quality Expert 品質熟練者と共に Part5
Pair with a Quality Advocate Part3

理解するためにメモを取っていたらボリュームが多くなったので、自分なりの解釈をまとめた記事であと3回を書きます。

VSTSの便利機能は用法用量を守って使いましょう

Visual Studio Team ServiceのGitを利用してソース管理した場合、様々な便利機能の恩恵を受けられます。
今回はPull Requestに関する便利機能は理解して使いましょう!というネタです。

Completedと同時にWork ItemsのStateを移動させる

Pull RequestをCompleteする際のウインドウにいくつかオプションがあります。

マニュアルはここにあります。

その中に、Complete linked work items after merging というオプションがあります。

このオプションは、Completeと同時に紐づいているwork itemsのstateを変更するという便利な機能です。

これにより、TaskやProduct Backlog Itemの移動し忘れ防止が期待できます。

Taskを移動させてみる

作業中のTaskがソースレビューとともに完了になると便利ですね。

f:id:feb-acchan:20180602175457j:plain

と、いうことでIn ProgressのTaskを用意しました。

f:id:feb-acchan:20180602175654j:plain

Commit or Pull Request の時にTaskを紐づけた状態の Pull Request を発行します。

f:id:feb-acchan:20180602175720j:plain

レビューする側でも、Pull Request 詳細の左上部分できちんと紐づけされているのか確認できます。

f:id:feb-acchan:20180602175757j:plain

Completeするとき、Complete linked work items after merging オプションにチェックを入れて Complete Merge を実施してみましょう。

f:id:feb-acchan:20180602180320j:plain

紐づけられていたTask2がDoneへ移動しました。

stateの移動先はどこ?

このオプションは一つ先へ移動するのか?それとも完了になるのか?

Task3、Task4を紐づけたPull RequestをCompleteしてみましたのでご覧ください。

f:id:feb-acchan:20180602180355j:plain

このように、StateはDoneへ遷移します。

Product Backlog Itemを移動させてみる

では、Backlogはどうなるのか。

そもそも、Pull Requestに紐づけるWork ItemってTaskなのでしょうか?それともBacklogなのでしょうか?

このオプションが追加されて以降、私は「MicrosoftはTaskが紐づくことを想定している」と思っています。

それはなぜか。

f:id:feb-acchan:20180602180839j:plain

CommittedのBacklogを用意したので、顛末をご覧ください。

f:id:feb-acchan:20180602180915j:plain

Task同様、Product Backlog Item 2 をPull Requestに紐づけます。

f:id:feb-acchan:20180602181025j:plain

stateはDoneへ移動しました。

段々、用法を間違えるとどうなるか察することができますね。

WIP制限の設定を有効したカンバンを利用した場合

カンバンのWIP制限を有効にした場合、Backlogはどのように動くのか。

f:id:feb-acchan:20180602181121j:plain

Committedが2/1と溢れているようです。誰か並列作業を行っていますね。 さらに Product Backlog Item 5 が後から控えています。

f:id:feb-acchan:20180602181140j:plain

Pull Requestに後から控えていたProduct Backlog Item 5を紐づけて...概要が何か訴えています。

f:id:feb-acchan:20180602181208j:plain

なんと!BacklogがWIP制限中のComittedを飛び越えて完了してしまいました。

あ、はい、わかってた結果ですね。

ご利用は計画的に

このように、Complete linked work items after mergingオプションは紐づいたWork ItemのStateをDoneにしてしまうオプションです。

私が「MicrosoftはPull RequestにTaskが紐づくことを想定している」と思ったのも、Backlogを勝手にDoneにするのはさすがにどうなの?と感じたからですね。

Sprint Reviewのタイミングで確認を行っている場合、気付かないうちに完了してしまったということがあるので、便利なオプションだからといって安易に使うと混乱を招くので注意が必要です。

Tokyo Atlassian User Group #27に参加してきた

2018年3月20日に行われた 第27回Tokyo Atlassian User Groupに参加した際の感想です。

当日の様子と登壇資料は、Togetter でまとめられていました。

アジャイルな開発の実現のためにAtlassianができること

発表内容はAgile Japanのサテライト開催で登壇されたものをAtlassianユーザー向けにしたそうです。

ソフトウェア開発を行う際、要件定義や設計等の各工程にふさわしいExcelRedmine、git、Jenkinsなど様々なツールを利用していると思います。

ツールを利用することで開発が効率化されるはずですが、実際は楽にならないことがあります。
なぜなら、これらのツールを一つ一つ理解するのが大変で、ツールによってはスペシャリストになると職に困らないシロモノもあり、さらにそのツール間の連携が必要となればより大変です。

Atlassianはどうなのか?

Jira Softwareを中心とした各種Atlassian製品を利用することで情報の整理と、プロセスとツールの紐づけ、ナビゲートをしてくれるそうです。

例えば、ConfluenceからJiraチケットの作成やJiraでBitbucketのbranchの作成ができます。

また、全Atlassian製品を利用する必要はなく、BitbucketをGitやGithubに、BambooをJenkinsに変更することができます。

Atlassian Community でツールでわからないことを聞くと世界中のユーザーだけではなく、Atlassianのエンジニアも積極的に助けてくれます。

Atlassian製品を使っている会社の実績として、10年間フリーキャッシュフローで企業活動ができているAtlassianという企業(自社じゃん!)があるだけでなく、フォーチューン誌が公開しているFortune 500に連なる企業の58%がAtlassianユーザーで、そのうちFortune 100に連なる企業の80%がAtlassianユーザーだそうです。

つまり、Atlassian製品を使えば企業の成長、成功間違いなし!(うおおすげえ)

JIRA Software + Atlassian製品 + 好きなツール + 人 = 成功が約束...されるのではないだろうか。

という話でした。

つまり、ツールを使うという作業を頑張るのではなく、ツールは楽に業務を頑張ろうよ!ということですね。

異業種に転職したら雲の上の一般ユーザーだった件

あらすじ

オンプレの管理者だったお母さんは、異世界転生(異業種転職)した結果、クラウド一般ユーザーになってしまったため管理者だったころの力がうまく発揮できない。
異世界転生って俺つえーする物語じゃなかったのか?
語彙力がなさ過ぎて小説の裏表紙に書いてあるようなことが書けない

発表資料がとても好きな感じでした。
読みやすい埋め込みフォント、ドラクエっぽいステータス表には小ネタが...rm -fr * うわあああぁぁぁ

発表内容

登壇者の会社は、会社の行動理念として「オープンを当たり前に」という感じだそうで、Confluecneの権限も最低限な制御しかしていないそうです。
正直、カオスになりそうで決断できないと感じましたが、実際はカオスなんて訪れないのでしょうか。

オンプレと違い、システム運用を考える必要性がない!バックアップも安心!しかもリテラシーが高いメンバーばかりなので使い方も大丈夫だ!と感じたそうでうs。

ただ、あまり凝った使い方はしていなかったようなので、転生前に使っていた魔法(Tipマクロやページレイアウト設定等の様々なマクロ)をコツコツと披露し、管理者になったそうです。

ただ、管理者といってもCloud版なのでソフトウェアとしての管理者です。

メンバーがConfluenceでやりたいことだった定期開催ページの自動生成を実現させるなどが主な活動だそうです。

Cloud版は結構アグレッシブで突然のテーマ変更、ロゴ変更は当たり前。しかも、困ったときはサポートに頼るしかありません。
どうやら日本法人への問い合わせよりグローバルサポートへ問い合わせたほうがレスポンスが早いそうです。
私個人は日本法人のサポートしか使ったことはありませんが、それでも1営業日内にレスポンスがあったのでこれ以上の速度を求めても英語が苦手なので享受できないかも。

発表はCloud版持ち上げで終わると思いきや...まさかの...「エンジニアはesaに飛びついた」END!
エンジニアは様々なご不満があったそうです。資料に載っていたエンジニアの要望は「わかる」「そだねー」と超共感できる内容ですし。

Cloud版もっと良くなるといいな...完

アジリティプロジェクトの紹介

Jiraの新しい機能であるアジリティプロジェクトの紹介でした。

Jiraは強力ですが、とても複雑です。
実際、Atlassianは複雑すぎるというフィードバックを数多く受けているそうです。

デザインの話

新しいJiraはデザインを現代的に、クリーンに変更したそうです。 ワイドスクリーンでも綺麗に表示されるそうです。
ごちゃごちゃしていた要素も関連する要素を近くに配置するなど改善したそうです。

Jiraは素晴らしい!...正しくセットアップできたら

私は聞いたことがなく、実際に作業もしたことがないのですが有名な話だそうです。

当然、分厚いマニュアルとともに製品をリリースしたいエンジニアがいるはずもないので、セットアップを簡単にできるようにしたそうです。

1画面で様々なことを簡単な操作でできるようにしているそうです。
デモで見せていただいたのですが、TodoとBacklogの境界線がBacklogリストで、その境界線を上下することでTodoへの出し入れが簡単、かつ描画が重たくなくスムーズにできていました。

現在進行形な機能追加

前登壇で指摘されたように突然の変化があるかもしれませんが、Feature flagが用意されているのでいつでもON/OFFが可能なので安心して利用できるとのことでした。

新機能は、SHIP IT と呼ばれる活動で様々なアイデアを実現しているそうで、Q&A時間に伝えられた要望も次のSHIP ITで実現してみるとおっしゃっていました。

まだまだ始まったばかりなので試してフィードバックしてね!というお話でした。

所感

今のチームはJiraを使っていないのでさておき、esaかぁ...ちょっと使ってみようかな。今のチームにConfluence勧めたの自分なんですがね。

と、Atlassianのユーザーグループ会に参加して他のツールに興味を持ってしまったのでした。

テストプロセスの改善 JaSST Tokyo 2018

JaSST Tokyo 2018のテストプロセス改善系セッションについての感想です。
受講したセッション

  • B2 はじめてみようテストプロセス改善
  • E4 ボトムアップによるテストプロセス改善 ~TPI NEXTを体験してみよう~

テストプロセス改善モデル概要について

テストプロセス改善技術ガイドがASTERから公開されるそうです。
関東が梅雨入りするまでには公開する予定らしいです。

詳細はガイド待ちです(非会員でも閲覧できるのかな?)

改善モデルは、段階モデルと連続モデルに分類できるそうです。

段階モデル 連続モデル
概要 組織のプロセス成熟度合い毎に改善すべきエリア・ゴールがある 最初から全エリアを対象にしていて、各エリア毎に成熟度合いが設定されている
メリット 着手するエリア・順序が明確 改善対象を柔軟に設定できる
デメリット 改善順序が組織にフィットしているか不明 最適な順序を考える必要がある
プロセス例 TMMi TPI NEXT

ISO33063も連続モデルだったかな?

各テストプロセス改善モデルについて

ざっくり概要解説がありました。

TMMiは、CMMiのテストプロセス版で補完する形になっているそうです。

ISO33063は、ISO33020のプロセス能力水準軸とISO29119-2のプロセス軸をマトリクスにした形式で改善していくため、ISO33063を理解しようと思うと、33020と29119-2を理解する必要があるそうです。

TPI NEXTは改善エリアと成熟度のマトリクス形式で、ボトムアップで改善していくモデルになっているそうです。

各モデルは、共通の改善エリアと固有の改善エリアがあるそうです。
例えば、TMMiとISO33063はレビューも改善対象ですがTPI NEXTにはありません。しかしTPI NEXTはプロセス以外が対象になっているなどの違いがあります。

プロセス改善活動の勘所

セッションの概要は以下の通りです。

なぜ、テストプロセスの改善が必要なのでしょうか?
それはテスト工程での不具合を抑制するため、テスト観点でプロダクトを作る必要があるからです。

しかし課題対策をいきなり始めても品質はなかなか上がらず、負のスパイラルに陥ります。

プロセス改善にもスキルが必要ということです。

改善のステップは3つ

  1. アセスメント
  2. 計画
  3. 実行(コントロール・フィードバック)

アセスメントの勘所

  • 着手が遅い
    → 導入で悩まずにとりあえず試すことが必要です
  • 認識合わせを怠る
    → 一人で実施せずに周囲の意見を聞くことです
  • 1回きりで終わってしまう
    → 何度も実施しましょう

主導する立場にアサインされたら一人で考えこんだり一度の実施で終わってしまうことなどはよくありがちですね。

プロセス改善計画の勘所

  • 要求・目的・ゴールが誤っている
    → 関係者の要求を確認しましょう
  • 関係者との調整怠る
    ステークホルダーには事前に話を通しておきましょう
  • 実施を意識していない計画
    → 無理のない計画と代替手段の検討も行っておきましょう

当たり前のことですね。

実行の勘所

  • 作業が停滞してしまう
    → 定期的な確認を行いましょう

  • 状況が変わって改善がうまくいかない
    → 見直しを検討しましょう

  • 改善完了で満足してしまう
    → さらなる改善をすべきです

こちらも当たり前のことですね。

所感

勘所はテストプロセスの改善に関係なく業務で必要な部分だと思います。テストプロセス改善としての勘所という感じの内容はなかったと思います。

TPI NEXT

テストプロセス改善研究会の方が翻訳してくださった日本語版アセスメントツールがあるので、実践する方は SOGETI社 よりダウンロードしてください。
使い方は、質問シートにY/Nで回答すると、マトリクス図とグラフが現状を判定してくれます。

成熟度は3段階あり、コントロールレベルが関与しているか、効率化レベルが貢献しているか、最適化レベルが開発活動全体の重要部分になっているかです。 質問が「テスト担当者は~」という感じなのでテスト担当者が関与、貢献、重要ポイントになっているかということだと思います。

ワークショップの内容は、例題をもとに関与度エリアの成熟度を検討するというものでした。

ここで、A2セッションのアセスメントの勘所が生きてきます。

例題が「テストマネージャ」を対象にしていたのに対し、TPI NEXTの質問は「テスト担当者は」となっています。マネージャは担当者か?担当者だという意見とマネジメントの立場だから担当者が別にいるはずでそいつが関与していないなどと割れます。 またプロジェクト計画への関与においても、がっつり関与してこそ「関与している」と評価すべきなのか、ほんの一部分でも関与していれば「関与している」と評価すべきなのか意見が分かれました。

所感

チームを評価する点については、質問に答えるだけでマトリクス図とグラフが判定してくれるので簡単に始められると思います。

また、販売ブースにて本が割引で販売されていたので買いました。自チームで一度やってみたいと思います。