プログラム

日時：2018年9月7日（金）　18〜20時キーワード：アジャイル品質保証の知識体系、パターン、形式工学、組織変革ほかプログラム： - 18:00-18:10 アジャイル品質保証の知識体系 SQuBOK 2020 予定より - 18:10-18:40 基調講演: アジャイル品質保証パターン: Quality Assurance から Agile Quality へ - 18:40-19:05 招待講演: OODAと品質保証 - 19:05-19:30 招待講演: 高生産性と信頼性におけるアジャイル形式工学手法 - 19:30-19:50 招待講演: ソフトウェア工学の観点から見たアジャイル - 19:50-20:00 招待講演: “アジャイル組織への変革”と“アジャイル開発の成功・定着”のポイント

各公演の資料は以下を参照ください。qiita中の画像は全て講演資料の引用になります。 https://smartse.jp/information/2018/0705201707/

アジャイルって何？って方は以下を参照ください。アジャイルソフトウェア開発宣言　…　http://agilemanifesto.org/iso/ja/manifesto.html

アジャイル品質保証の知識体系 SQuBOK 2020 予定より

SQuBOK2020へアジャイルを追加すること、アジャイル開発のパターンランゲージをさらっと説明。後段の講演でそれぞれ深堀する。

SQuBOK2020にアジャイルの品質体系を追加予定
品質の概念…バリュー・チーム全体・バグ即修正・改善活動
マネジメント…アジャイル品質保証パターンQA2AQ、アジャイルスキル体系SFIA
品質技法 …アジャイルメトリクス、品質ダッシュボード
アジャイル品質保証パターンQA2AQ(Quality Assurance to Agile Quality)とは
従来の品質保証（ウォーターフォール）からアジャイルな形にするための方法を集めたもの。下にあるように色々な要素から成り立っている。

f:id:ruzxas:20190310185707j:plain

※補足：そもそもWFとアジャイルの品質保証の違いについてはこちらを参照ください。

所感：障壁の解体・品質の組み入れ・品質の可視化いずれも実施できていない箇所だった。そもそもだが、アジャイル品質保証とWF品質保証で、メトリクス的な役割とゲート的な役割の違いは大きいと思った。ゲートを定めていない分アジャイルは特に可視化が重要なのかなと。

アジャイル品質保証パターン: Quality Assurance から Agile Quality へ

アジャイル品質保証パターンQA2AQの紹介。 QA to AQ: Quality Assurance から Agile Quality への紹介と重複する部分は割愛。以下の説明がしっくりきた。

核心は「組織の壁を壊すこと」と、品質をプロセスの最後に「分離」せずに全体の中に「組入れる」こと。そして、そのために、品質面での習慣化(1)を支援するパターン、品質を特定し(2)、そして、それを可視化する(3)パターンという構成です。とてもわかりやすいですね。

品質でアジャイルになる。行為ではなく習慣である
同じチームとして価値のある情報を提供すること
チーム全体が品質に取り組む
プロダクト、マネジメント、品質保証、アーキテクトの相互作用
システムの品質(最後の四つが開発スピードに影響)
パフォーマンス
セキュリティ
スケーラビリティ
可用性
信頼戦
保守性
進化性
テスト容易性
デプロイ容易性
バリューがプラクティスを駆動する（？）
責任時点を計画する
さまざま判断は最大限遅らせたうえで選択する
視認性が重要
計画・ラジエーターなど諸々の可視化
CI(継続的インスペクション)でコードの匂いを検出。メトリクスを自動で計測する
バックログに品質を積んで定期的に実行
改善には余分な時間が必要。計画に組み込んで時間の確保すべき

所感：先の講演とつながる部分は多かった。新しく出たもので開発スピードも考慮すると、テスト自動化や最悪ソフトウェア動きについて仕様は整理しておいた方がよさそう。また、バックログに品質に関するタスクを積んで実施する（余分な時間を設ける）ことも明示されなければ後回しそうだ。

OODAと品質保証

OODAループを品質（テスト）に取り込む

OODAとは…観察 (Observe)、情勢判断 (Orient)、意思決定 (Decide)、行動（Act））の略
近いものでPDCAが思い浮かぶか、より機敏に実施し学びが蓄積されやすい
OODAをテストに適用する
動くところからシステムテストをしてしまう
早期のフィードバックで、後段で起こりうる類似のバグをつぶせる！

ソフトウェアパターン界の「パターンプリンセス」からQAとしてアジャイル開発へのかかわり方へのアドバイス

f:id:ruzxas:20190310190527j:plain

stealthでいること
回りから見えない存在・透明人間
邪魔にならない存在
早いうちから巻き込め
設計者とともに、システムやフィーチャを学ぶ
要求仕様や設計ドキュメントのレビューに参加する
テスト計画のレビューに設計者を招待する
まずは見守る。
リスクセンサー…朝会の観察
- 障害の発生
  - 新たな要求：バックログが増える
  - 進捗の遅れと原因
  - 新たなタスクの発生：バックログのSPが増える
  - 技術的な質問、課題が発生
  - 新たなインペディメント（障壁）の発生
  - 技術的負債の発生
  - “待ち“は発生していないか
  - 課題をメンバーで共有しているか
- 対策確認
  - チームでフォローアップできているか
  - SMはインペディメントを取り除く
  - 発生したインペディメントは取り除かれているか
  - 認識された課題が解決されているか
メトリクス…まずは開発の負担にならないよう出来る範囲ですすめる
- まずはGitLab等手軽な箇所からデータを収集し、問題を見える化・仮説を立てたり分析してみる。
  - 問題：システムテストが終わらない、もしくは漏れがある
  - 仮説：バックログの先送り
  - 観測：完了したスプリントの内訳
  - 行動： OODAにより品質の情報を“早く“フィードバックしバグをコントロール

結論：OODAにより品質の情報を“早く“フィードバックし、品質の埋め込みできるアジャイルが好きだ

所感：開発者と協調することは引き続き意識する。バグを観察し観点を早期にフィードバックし改善することによるバグの収束もアジャイルのメリットなので、活用していきたい。

JSTQB　行動規範

同僚 - ソフトウェアテスト担当者は、同僚に対し公正かつ協力的でなければならず、ソフトウェア開発者と協調しなければならない。

高生産性と信頼性におけるアジャイル形式工学手法

Agileを取り入れるにはプロジェクトが小さい（プロジェクト期間が5ヵ月・5000LOC）又はクリティカルでないものがよい
Agile manifesto
プロセスやツールよりも個人と対話
包括的なドキュメントよりも動くソフトウェア
契約交渉よりも顧客との協調
計画に従うことよりも変化への対応
Agile SOFL(Agile Formal Engineering Method) を利用することでアジャイルの欠点を克服できるのか？できる
要件やシステムの潜在的な動きを理解する3段階のアプローチ
- Informal Specification
- Gui design And animation (e.g.　PowerPoint)
- Hybrid Specification

所感：アジャイルと対極にある形式手法からといって敬遠せず、スケールしていく開発の中で破綻しないようカッチりドキュメントを書いてたり自動化するなど、ソフトウェア工学的な観点も取り入れていくことも大事。

ソフトウェア工学の観点から見たアジャイル

アジャイルの学び
フィーチャーチーム
権限移譲
心理的安全性
仮説検証型アプローチ
動くコード
レトロスペクティブ
アジャイルとソフトウェア工学の違い
ソフトウェア工学
- 管理：フレデリックテイラー（科学的管理法、マネジメントの原点）
- 手法：トップダウン（理論・プロセス・合理的）
- アジャイル
  - 管理：エルトン・メイヨー（人間的経営、ホーソン実験）
  - 手法：ボトムアップ（ぷラックティス、チーム、人間的）