読者です 読者をやめる 読者になる 読者になる

特別セミナー「アジャイル品質とソフトウェアパターン」参加レポート

勉強会 技術

告知ページ

特別セミナー「アジャイル品質とソフトウェアパターン」 2月22日 | Reliable Software Engineering, Washizaki Laboratory

講演1:アジャイル開発へのソフトウェア工学的アプローチ:イテレーション期間と学習ワークショップ

スライド

www.slideshare.net

経緯

  • 水曜日に台湾でソフトウェアパターンの国際会議が開かれる
  • 今週台湾に来るんだったら、日本にもお越しいただいてセミナーを開こう!(2週間前)
  • 非常にHotな品質とアジャイル開発について学んでいく

はじめに

  • アジャイル開発に関連する領域について取り組んでいるので、それについて紹介する

動機付け

  • アジャイルは科学不足
    • 他のプロセスに比べて
  • Cynefinフレームワークより
  • 横軸…解放が既知かどうか
  • 縦軸…問題が複雑か単純か
  • 第1象限…グッドプラクティス
  • 第2象限…突発・創発(Emergent)
  • 第3象限…新規(の研究)
  • 第4象限…ベストプラクティス

  • 本来扱うべきところと実際に扱う場所が異なっているのではないか

  • プラクティスなものに対して科学的裏付けをして、境界条件や本来のアジャイル開発の場所に持っていくプラクティスを探ってみるべき
  • まだそこまで出来ていないので、地道に行っていく

  • 科学的に出来ないのか

    • イテレーション期間を長く取るべきか短く取るべきか
    • ワークショップが有用なのか
  • イテレーション期間について必要ない部分をバッサリ切ってモデル化する

  • 机上の(計算機上の)シミュレーションを行ってきた結果
  • 要求の不確実性大→イテレーション期間を短めに
  • 要求間の依存関係複雑さ→イテレーション期間を眺めに

講演2:ソフトウェア信頼性予測のプロジェクト進行中の動的な活用

ソフトウェア信頼性モデルとアクションを結びつける

  • 信頼性モデルの利用
  • 開発の最後、振り返りが主な利用シーン

  • 状況のモニタリング

  • CIツール
  • R言語

  • 異常の検知

  • 信頼性モデルの解釈とアクション

欠陥と信頼性

  • 欠陥数の予測について
  • 信頼性に対して、欠陥を十分に発見できたかどうかを評価する基準
  • 欠陥数を予測し、取り除くべき欠陥数を定める
  • ソフトウェア信頼性モデル
  • どれだけテストを行えばよいか、リリース時期を測ったりする
  • 発見した欠陥を累積として日毎、週ごとに測定

  • 開発における問題

  • 欠陥を十分に発見できているか
  • 予測される欠陥数に対して今どれだけ欠陥を見つけたか

  • リリースに間に合うか判断できない

  • 開発のスコープ決定を支援
  • テスト工数、計画の支援

CIツールリポジトリシステムを用いた欠陥数予測

  • Jenkinsを用いて自動的に欠陥数を取得する
  • R言語を用いて欠陥数を予測する

リリース時期の分析

予期せぬ状況の発見

動機付け

  • ソフトウェア信頼性モデルが不一致になる場所がある
    • なぜそのようなことが起きるのか?
  • 期待を超える時期が発生する

欠陥をテストフェーズで分類

  • 継続的に問題が発生
  • いくつかの問題が再発生したので、開発者がテストを止めて他のテストを再開させた

まとめと今後

  • 今後は欠陥のデータベースを作りたい

質問

  • 未解決な欠陥については研究の対象にしていないのか?
  • していない
  • 是非とも、対象にして欲しい
  • PMが欠陥の理由を説明できない
  • 比率を見て、どんどん欠陥が減っていっているか
  • 見つかった欠陥をいつ修正されているかも研究の対象にしているところ

  • バグの影響範囲や重要度、優先度は取り入れているのか

  • 今回の研究では対象にしていない
  • バグの重複についてはフィルターをかけている
  • ユースケースで95%修正でリリースとしているが、残っているバグがクリティカルならばリリースできない

講演3:QA to AQ(Agile Quality): Being Agile at Quality

発表スライド

http://www.washi.cs.waseda.ac.jp/wp-content/uploads/2016/02/QA2AQ-Waseda-2016-.pdf

自己紹介

  • Joseph Yoder

トレードオフ

リーン開発

アジャイルとは

非機能要件

  • 非機能要件をユーザーストーリーでどのように表すか

  • 非機能要件とかも重要なのに、スケーラブルだから大丈夫…?

  • QA→QC

  • プロセス管理

  • 色々なパターンに当てはまるかどうか

  • バリアをいかに壊すか

  • 文化、言語、様々なバリアがある

    • QAが敵と考えられたりする
  • アジャイルチーム

  • QAの60%はユニットテスト

  • Tearing Down the Walls: Embedding QA in a TDD/Pairing and Agile Environment

  • Test early

  • Automate "easy" test

  • Qualify Loadmap

  • Qualify the Backlog
  • Quality Checklists

  • Quality Splints

  • Monitor Qualities

  • Usabilityをどうやって計測する?

  • "Quality Debt related to Technical debt."

  • SteveMcConnell https://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/

Agile Quality Benefits

  • Visibility
  • Effectiveness
  • Architectual Risk

Being Pragmatic

  • Do the Agile
  • Be the Agile

  • No Planning No Design...Sometimes calls Agile

  • Lot's of upfribt planning... Transitional Waterfall

  • Ultimate Agile Stories

質問

  • Agileの品質モデルはどのようなものがあるか
    • ウォータモデルならV字モデルがあったりするが…
  • Valueが出るようにすれば良い
  • Being Agileがなれば良い
  • Vモデルでも良いが、改善させていくことが大切

  • Test Baseをどのようにゲットするか

  • Agile Manifestによる
  • ドキュメントはValue
  • Agile StoryがValueになる
  • catalog, method

パターン一覧

  • 障壁の解体
  • アジャイルプロセスへの品質の組み入れ
  • 本質的な品質の発見
  • アジャイル品質シナリオ
  • 品質ストーリー
  • 測定可能な値やシステム品質の特定
  • 折り込み品質
  • アジャイルな着地点
  • 着地点の再調整
  • 品質目標の合意
  • システム品質ダッシュボード
  • システム品質ラジエータ(可視化する仕組みを用意する)
  • ロードマップの品質検討
  • バックログ上の品質検討
  • 品質チャート
  • チーム全体
  • 品質に焦点をあてたスプリント
  • 品質保証プロダクトチャンピオン
  • アジャイル品質の専門家
  • 品質のモニタリング
  • アジャイル品質保証テスター
  • 品質に関する作業負荷の展開
  • 品質熟練者の備考
  • 品質主義者とのペア