プロセス改善活動における二刀流的アプローチ
プロセス改善活動において、テストの自動化や継続的デリバリーの確立などの技術的なアプローチは代表的な打ち手の一つです。
かたやアジャイル的アプローチでプロセス改善活動を推し進める際、スクラムなどに代表される「組織の構成やそれに付随する約束事的アプローチ」に注目されがちとの思いもあります。
今回私がプロセス改善を目的とする「SPI(Software Process Improvemnet)グループ」と、テストの自動化を推進する「Automationチーム」を兼任した1年半のプロセス改善活動で経験したことを実例を交えて紹介し、組織全体の流れに手を入れながらピンポイントで自動化エンジニアリングが出来ることの有用性や課題、展望について展開することにより、プロセス改善エンジニアの動き方の一つとして皆さまに一考していただくことを目的としたセッションです。
Outline/Structure of the Talk
- プロセス改善の打ち手
- 二刀流的アプローチ
- 実例
- 兼任の強みと弱み
- スキルセットとマインドセット
- 課題と展望
Learning Outcome
- プロセス改善に関わる方には、その打ち手のバリエーションの一つとして参考にしていただけるかもしれません。
- SETとして動いている方には、自身の活動がプロセス改善の一環でもあるという新たな視点を獲得いただけるかもしれません。
Target Audience
・アジャイル・DevOps志向において、プロセスの改善に興味のある方やSETの方
Prerequisites for Attendees
- ソフトウェア開発に携わったことのある経験が必要です
- アジャイル開発やDevOpsに関わる用語の理解が必要です
schedule Submitted 1 year ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Yuya Kazama - 開発が加速していくために、テストコードを書き始める前から考えるべきテストの話
45 Mins
Talk
Beginner
システム開発において、テストは切っても切り離せない存在です。
しかし、「カバレッジを満たすために書いている」「テストコードは書いたが、本番でトラブルが多発している」となっていませんか?
実は、テストコードを書き始める前に既に勝負は決まっています。
本セッションでは、実際に例題を使って皆さんにも考えてもらいます。そして、作業ではないテストについて“体験”し“実感”してもらいます。
本セッションの体験を通じて、「開発エンジニア」「テストエンジニア」がともに考えて作り出す、一歩先行くテストの世界をご紹介します。 -
keyboard_arrow_down
Yuichi Tokutomi - ゲームのように学ぶアジャイル開発
20 Mins
Talk
Beginner
アジャイル開発に興味のあるみなさん、どうやって学んでいますか?
XP の白本から始まったアジャイル開発。その後、たくさんの本が出版されてます。本に書いてあることは良さそうなのですが、実際にやろうとすると分からないことだらけだったりしませんか? スクラム開発をやってるとつもりだった自分のプロジェクトが "ミルクボーイがアジャイルを説明したら" のネタになっててハッとしたりしませんでしたか?
そんなアジャイル開発の入り口にいる人たちに向けて、私がどうやって学んできたのか? 学び続けているのか? XP 白本の発売から 20 年の道のりをお話したいと思います。入り口から一歩進むきっかけにしていただければ幸いです。
-
keyboard_arrow_down
Jumpei Ito - アジャイル環境における品質プロセス - Janet Gregory & Lisa Crispin(動画放映)
90 Mins
Track Keynote
Beginner
テスターを含むチーム全体(Whole-Team)で、プロセスやプロダクトに品質を作り込む(Build quality in)にはどうしたらよいでしょうか。
Janet Gregory とLisa Crispinによるこの動画では、W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」と、それをアジャイルな職場で実践する方法について詳しく学べます。W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」で以下の2つの原則はJanetのお気に入りです。
- quality is everyone's responsibility(品質はすべての人の責任)
- improve quality you automatically improve productivity(品質を向上させれば、自動的に生産性も向上する)
また、Janetがオリジナルで提唱する原則が以下の2つです。
- if you focus on quality the speed will come(品質にフォーカスすればスピードが出る)
- if you focus on speed the quality gets lost(スピードにフォーカスすれば品質が失われる)
アジャイル環境において品質を考えると、「プロダクト品質」と「プロセス品質」の関係が重要となります。
JanetとLisaは以下のような内容で特にプロセス品質についてトークします。
1.Question Askerであるべき
2.例やテストを使って開発をガイドする
・magic bubble(魔法の泡) コード・テスト・自動化
・Acceptance Testのループ(受け入れテスト作成→テストの拡大→自動化担当者とペア→テストメソッドの作成→何をテストするのかを明確化→TDDサイクル→ハッピーパスが通るまでリピート→探索的テスト)
3.エクササイズ(ユーザーストーリーからテストを考える)
4.アジャイルテスティングの4象限を使ってテストを把握する
5.探索的テスト、品質属性のテスト、スライディング・スケール
6.コアプラクティスを使う
・継続的インテグレーション
・テスト自動化
・機能やストーリーの優先順位付け
・ビジネス価値を頻繁にデリバリー(いつでも出荷可能なリリース候補を用意する)
・品質をデリバリー(コアプラクティスを用いて、会社やチームのあらゆる部分で品質を構築) -
keyboard_arrow_down
Yasuharu Nishi / Azuma Miwa / Kaori Tokiwa / Kunio Yamamoto / Naoki Kojima / Takefumi Iseki / Yusaku Tokuda - 品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu NishiAssistant ProfessorThe University of Electro-Communications, TokyoAzuma MiwaGeneral ManagerSCSK CorporationKaori Tokiwaチームプロセス支援コンサルタント/ファシリテーターGraatKunio YamamotoNaoki KojimaQAエンジニアリンクアンドモチベーションTakefumi IsekiQAエンジニア / テストエンジニアテストの街「葛飾」Yusaku Tokudaschedule 1 year ago
45 Mins
Talk
Intermediate
スクラムで品質に悩んでいるチームや組織へのアプローチを整理する話をします。
品質を向上するためにテスターやQAエンジニア、SETやSREを増やそうとする組織は多いですが、スキルセットやキャリアパスをどのように決めていけばよいのかについて困っているところも多いと思います。また、当面はテストを外部発注してしのぐとしても、どう内製化するか、どうスケールするか、どう組織全体に根付かせていくか、について悩んでいる組織も多いと思います。
そうした悩みを解決するために、本プレゼンテーションではQMファンネル(3D版)を使って整理するお話を紹介します。
頂点が下向きになっている三角錐を想像してください。まず三角錐の側面はエンジニアのスペシャリティ(得意技)です。スペシャリティをTE(Test Engineer、いわゆるテスター)、QA(Quality Assurance、いわゆる品質保証)、DA(Delivery Accelerator、いわゆるSETやSRE)の3つに分けて整理します。もちろん、それぞれのスペシャリティがサイロ化しないように、側面の境界をスムーズにするような境界的なスペシャリティも考えないといけません。
次に、三角錐の深さはレンジ(範囲)になります。レンジを、外部発注したり専門組織によるサービスという役割分担から、スクラムチームの内部だけで頑張るインプロセス、チームと一緒に開発しながら高度なスペシャリティを浸透させるコーチ、それぞれのチームの外部からスペシャリティを移転するコンサルタント、組織全体にスペシャリティを浸透させていくプロモーターといった5つのレンジに分けて整理します。
品質を向上するには、TE、QA、DAの3つのスペシャリティが全て必要です。これらをまとめてQM(品質マネジメント)として捉えることで、バランスのよい品質向上が実現できます。同時にオールレンジの活動を意識することで、組織全体でバランスよく品質向上を浸透させることができます。
またQMファンネルは、伝統的なプロジェクトのようにPMとエンジニアを区別する考え方ではないという点にも注意する必要があります。スクラムチームでは、テスト計画・テスト設計・テスト実行を分割してサイロ化させるのは得策ではありませんし、コンサルタントやプロモーターが偉いわけでもありませんので。
私たちのQMファンネル(3D版)について聞いて頂いて、皆さんの組織の品質がスムーズに加速できればとても嬉しく思います。たくさん議論させてくださいね!