More Related Content Similar to はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して (20) More from Rakuten Group, Inc. (20) はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して 1. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
はじめてのスクラム体験ワークショップ ∼ アジャイル時代のテスターを目指して
楽天株式会社 川口恭伸
1.本研修の目的
日本においても、アジャイル開発プロジェクトは、もはや珍しいものではなくなりまし
た。テストエンジニアのスキルとアジャイル開発はどのように交わっていくのでしょう
か。アジャイル開発において、品質保証はどのように行われていくのでしょうか。
本セッションでは、アジャイル開発におけるテストについて議論した後、アジャイルの基
本といえるスクラムのチーム運営について学んでいきます。
2.アジャイルとは
2001年 ボブ・マーティン1 の呼びかけで、軽量で実践的なソフトウェア開発プロセスを
実践している人々が、米国ユタ州ソルトレイクシティ近郊のSnowBirdという山荘に集ま
りました。ここで有名な「Manifesto for Agile Software Development
(通称: アジャイルマニフェスト)」がまとめられ、以後、様々なソフトウェア開発手法や、
その文化に「アジャイル」という呼称が用いられるようになりました。2
アジャイルソフトウェア開発宣言3
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck, Mike Beedle, Arie van Bennekum. Alistair Cockburn
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
1 Robert C. Martin 『Clean Code』『Clean Coder』等の著者、通称 Uncle Bob (ボブおじさん)
2 http://d.hatena.ne.jp/wayaguchi/20110213/1297531229
3 http://agilemanifesto.org/iso/ja/
2. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
12の原則
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8.アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
アジャイルは様々な方法論を含む総称としてつけられたラベルのため、「アジャイル開発
をしている」という場合にも、その実体としてどのようなプラクティスを採用しているの
か、どの程度行っているかによって、大きな多様性があります。
3. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
3. アジャイル・テスティング
ソフトウェア開発プロジェクトをアジャイルで行う際の、テスターや品質保証(QA)のスキ
ルを持つ人の役割を定義したのが、リザ・クリスピンとジャネット・グレゴリーによるア
ジャイル・テスティング Agile Testing です。
従来の品質保証担当は、製品開発の最終段階におけるチェックを主に行ってきました。仕
様書を(開発者とは別に)読み解き、テストケースを作成し、主に手作業で実施する...。し
かし、テストの自動化が進展した現在では、そのあり方も変化しています。
TDD (テスト駆動開発) は、ケント・ベックらXPコミュニティで発展してきた技法です。
開発者自身がユニットテストとソースコードをセットで書くことで、仕様の理解を明確に
し、リファクタリングを用いてコードの品質を洗練していきます。テストコードのカバ
レッジを計測し、ユニットテストが用意されていないコードをなるべく無くすことを目指
します。ペアプログラミング(2人一組でのプログラミング)によって、仕様の明確化と
コードレビューを同時に行うこともあります。
CI (継続的インテグレーション) 用のサーバを用意し、ソースコードとテストがソース
コード管理システムにコミットされたらすぐに、ビルドとテストを自動実行して後退(リグ
レッション)がないことを確認します。
このように、開発者自身が自動テストを書くようになれば、時間のかかる品質保証(QA)
は不要になるのではないか?という意見もアジャイルコミュニティにはあったようです。
しかし、TDDで記述するテストはあくまで「開発の足がかりになるもの」にとどめるのが
一般的です。その一方で、求められる品質を確かめようとすれば、必要なテストは多岐に
わたります。ですから、包括的なテスト設計のために、テスターの 役割とスキル が重
要になります。
テスト自動化ピラミッド ( Mike Cohn ) (c)2012 Lisa Crispin, Janet Gregory
4. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
アジャイルテスター
アジャイルチームの中に、テストについての十分なスキルを持った人が必要です。リザと
ジャネットはそういった人を「アジャイルテスター」と定義しました。アジャイルテス
ターになるためには、アジャイルチームの文化や振る舞いを知り、参加していく必要があ
ります。
アジャイルチームは業務に近いところで作業を行い、要求の詳細を理解していま
す。チームが何を提供できるかに焦点を当て、昨日の優先順付けの決める多くの要
素を把握しているのです。テスターは座って待っているのではなく、開発サイクルを
通してチームに役立つことを探しています。 4
アジャイルでは、テスターや品質保証の人たちだけが、品質に責任を持っているわ
けではありません。「組織の壁」は気にせず、最高の製品を作り出せるスキルと要員
だけを考えています。アジャイル開発の肝は高品質のソフトウェアを作り出すことで
す。しかも、ビジネス価値を最大化するようなスピード感覚でソフトウェアを作り出
します。これがチーム全体で進める仕事であり、テスターや任命された品質保証の
専門家だけでやるものではありません。アジャイルチームにいる人はみな、「テス
ト好き」になります。単体テスト以降のテストはコーディングを促進し、アプリケー
ションがいかに稼働すべきかを理解し、タスクまたはストーリーが完了したことが
分かります。 5
アジャイルチームが生み出すソフトウェアの品質は、チーム全体で責任を持ちます。 です
から、アジャイルテスターはチームの一員として、製品の品質を高めることに寄与しま
す。
ドキュメントで受け渡すプロセス(左上)と、
アジャイルのクロスファンクショナルチーム(右下)
4 『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』 (2009) P.12
5 『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』 (2009) P.15
5. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
4.スクラム : 最も普及したアジャイル・チーム・マネジメントの枠組み
スクラムはアジャイルのチームマネジメントのフレームワークとして、現在、最も普及し
ている手法です。90年代前半に、ジェフ・サザーランドとケン・シュウェイバーによって
作られ、96年に発表されました。この両名もアジャイルマニフェストの策定に参加してい
ます。スクラムは技術的なプラクティスを一切削ぎ落とし、チーム・マネジメントに
フォーカスしたプラクティスのみを残した フレームワーク としました。その結果、様々
な分野/プロダクトで利用可能な汎用性を持っています。
また、スクラムが参考にした論文の一つに、 日本人の竹内弘高・野中郁次郎の The
New New Product Development Game (1986) があります。これはホンダやキャノ
ン、富士ゼロックスの新製品開発の事例を研究したものです。従来の開発工程をフェーズ
毎に明確に区切るプロセスに対し、開発工程をオーバーラップさせ、全体を1チームとし
て作業を進める過程を採用していました。竹内と野中は論文中でその過程をラグビーの
「スクラム」と表現しました。
The New New Product Development Game Hirotaka Takeuchi, Ikujiro Nonaka (1986)
7. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
(3)3つのロール
スクラムではチームが主体ですが、チームを支援する2つのロールを定義しています。
3つのロール(役割)
・チーム Team :
スクラムの主体となる自己管理されたチーム。
理想的にはプロダクトを作るのに必要な全ての能力を備えている。
・プロダクトオーナー Product Owner(PO) :
チームが生み出すプロダクトの方向性を決定する役割。舵取り役。
プロダクトバックログを適切にメンテナンスする責任を持つ。
不確実な将来に対し、投資判断を行う。
・スクラムマスター Scrum Master(SM) :
チームとプロセスの健康状態をチェックし、チームの前進と成長を促す。
チームドクター。ミーティングのファシリテーションも行う(適宜)。
前進への障害物を確認して、チームや外部 に除去を働きかける。
次のスクラムマスターを育てる。
@IT 開発チームを改善するためのスクラムTips
最終回 5分で分かる、「スクラム」の基本まとめ
(4)3つのアーティファクト
チーム内の共通理解(common sense)を手助けするのがアーティファクトです。
3つのアーティファクト(道具)
・プロダクトバックログ Product Backlog :
プロダクトの要件を優先順位漬けされたリストにしたもの。
一つ一つの項目をプロダクトバックログ項目(PBI)という。
各PBIは、実現したときの価値をプロダクトオーナーが見積もり、
実現のための作業規模をチームが見積もる。
優先順位付け(並べ替え)はプロダクトオーナーが行う。
8. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
・スプリントバックログ Sprint Backlog :
当該スプリントで完成する見込みのプロダクトバックログの一部。
規模見積もりとベロシティ(推定される作業量)によって予測到達点を推測する。
スプリント計画第一部で合意し、第二部で詳細に作業計画を行う。
・バーンダウン・チャート Burndown Chart:
スプリント内の残作業量をプロットする右下がりのグラフ。
スプリントバックログ内のPBIをスプリント期間内にすべて完了することが
できるか、視覚的に把握する。
Henrik Kniberg “塹壕よりScrumとXP(Scrum and XP from the Trenches)”7
7 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches
10. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
げることは不可能になってきています。そこで、アジャイルでは、カードを媒介すること
で、チームの中央に知識を置き、多様なスキルを持つメンバーが集まり、効率的な要件定
義を行うのです。紙のカードは同時に複数のメンバーが書いたり、操作したりすることが
できます。
8
あわせて、完了までに確認が必要な項目(受け入れテスト項目)について検討します。具体
例で考えることで、利用者にとっての価値を共有し、完了までに必要な作業の規模をより
正確にし、スプリント開始後に確実に着手できるようにします。
テスト自動化による品質の作り込み
テスト自動化には2種類の取り組みがあります。TDD(テスト駆動開発)はデベロッパーテ
ストとも呼ばれ、開発者自身の作業の足がかりとしてテストを書いていくものです。各メ
ソッドの振る舞いをテストするコードを先に書き、テストに合格するようにメソッドの実
装を書いていきます。結果的にはコードとともに、十分な量のユニットテストが生み出さ
れ、いつでも確認できるようになります。また、テストを壊さないようにコードを洗練さ
せるリファクタリングも行っていきます。
一方で、受け入れテストレベルでの自動化を行うのがATDD(受入テスト駆動開発)や
BDD(ビヘイビア駆動開発)です。 受け入れテストを定義したり実施するのはプロダクト
オーナーや顧客の役目です。このため、FitNesse や Selenium、Cucumber などのツー
ルでは、非プログラマでも理解/記述できるよう、自然言語に近いドメイン特化言語や
HTML表などでテストケースを記述できるようになっています。スプリントの開始前にど
のような受け入れテストを実施するのかを決め、その実行のための環境を整備しておくこ
とが重要です。
アジャイルテスターにとって、受け入れテスト項目を洗い出し、自動テストに落とし込む
こと、また自動テストを適切に管理することは必須スキルといってよいでしょう。
8 http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-
template
11. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
テストの全体像を俯瞰する
製品の品質を確保するには、自動化できるテスト以外にも、多様なテストがあります。
アジャイルテストの四象限 ( Brian Marick ) (c)2012 Lisa Crispin, Janet Gregory
第1象限(左下) : テスト駆動開発(TDD)です。
第2象限(左上) : 機能レベルで受入条件をテストします。ATDDやBDDが支援します。
第3象限(右上) : 期待に合っているか、競合に対して価値があるかなどを確認します。
第4象限(右下) : 非機能要件やセキュリティをテストします。
テスト環境、テストデータの整備
スプリントを始める前に、テストやリリースのための環境を確認し、できる限り整備して
おくべきです。また、各ユーザーストーリーの完了基準を考えておく必要もあります。
見える化の仕組みを検討する
テストの進捗や自動テストのカバレッジなどを、チームから見える場所に表示しておく方
法を整備しておきます。
16. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
成功への鍵
最後に、『実践アジャイルテスト』より、リザ・クリスピンとジャネット・グレゴリーの
挙げる成功への鍵を紹介します。
・1 : チーム全体のアプローチ (whole team approach)
・2 : アジャイルテストの考え方を採用する
・3 : 自動リグレッションテスト
・4 : フェードバックを与え、受ける
・5 : コアプラクティスの基礎を築く (CI, テスト環境、技術的負債の管理)
・6 : 顧客と共同作業する
・7 : 広い視野を持つ
もしかすると、企業の中にはさまざまな組織の壁があり、簡単にはチーム全体のアプロー
チができないと感じることもあるかもしれませんが、一つ一つ分析し、実験を積み重ね、
できることを増やしていっていただくことを祈っております。
謝辞
本原稿は、執筆の過程で山口鉄平氏、木村卓央氏、細谷泰夫氏の助言をいただきました。
また、本研修は森崎修司氏よりきっかけをいただきました。ジャネット・グレゴリーさん
には東京での研修の開催を通じて多くのことを教えていただきました。
ここに感謝を申し上げます。