「アジャイル型開発におけるプラクティス活用リファレンスガイド」の勘所と活用方法

いちたに としひろ 市谷 聡啓 ・東京でSI、受託開発(永和システムマネジメント所属) ・開発現場のためのコミュニティDevLOVE主催 ・「リーン開発の現場」翻訳しました twitter : @papanda 2013年10月31日木曜日

正しいものを、正しく作る 2013年10月31日木曜日

開発現場のためのコミュニティ ・1600名 ・2008年から5年半運営、全142回 ・東京/神奈川/名古屋/仙台/大阪/四国 http://www.devlove.org 2013年10月31日木曜日

• https://github.com/esminc/jobs

監訳 角谷信太郎 共訳 市谷聡啓 藤原大 ・10月26日発売 ・電子版もあります ・リーン開発の実践記 ・現実的な作戦 ・大規模プロジェクト ・カンバンの活用 ・平鍋健児の解説 2013年10月31日木曜日

課題からみるプラクティス実践例1 2013年10月31日木曜日

よくある課題 ソフトウェア開発を 襲うコスト問題。 なぜ、開発コストは 超過してしまうのか？ 2013年10月31日木曜日

よくある課題 ソフトウェア開発を 襲うコスト問題。 なぜ、開発コストは 超過してしまうのか？ 要するに想定以上のことをしている 2013年10月31日木曜日

よくある問題 開発が想定を超えてしまう理由 2013年10月31日木曜日

よくある問題 開発が想定を超えてしまう理由 ①作ったモノが顧客にとって必要 では無かったことが作ってから判 明する。やり直しになる。 ②顧客にとって必要なモノの定義 があいまいでやり直しが終わらな い。 2013年10月31日木曜日

リファレンスガイドの 「5. 活用のポイント」を参考にする 2013年10月31日木曜日

事例から学ぶ 作ったモノが顧客に とって必要では 必要ないものを 作るムダをなくす 無かったことが 作ってから判明する。 作るモノへの認識の 相違を無くす 顧客にとって 必要なモノの定義が あいまいでやり直しが 終わらない。 2013年10月31日木曜日 作っているものが ”正しいモノ” か検証する

事例から学ぶ 作ったモノが顧客に とって必要では 必要ないものを 作るムダをなくす 無かったことが 作ってから判明する。 作るモノへの認識の 相違を無くす 顧客にとって 必要なモノの定義が あいまいでやり直しが 終わらない。 2013年10月31日木曜日 作っているものが ”正しいモノ” か検証する

事例から学ぶ 作ったモノが顧客に とって必要では 必要ないものを 作るムダをなくす 無かったことが 作ってから判明する。 作るモノへの認識の 相違を無くす 顧客にとって 必要なモノの定義が あいまいでやり直しが 終わらない。 2013年10月31日木曜日 作っているものが ”正しいモノ” か検証する

事例から学ぶ 作ったモノが顧客に とって必要では 必要ないものを 作るムダをなくす 無かったことが 作ってから判明する。 作るモノへの認識の 相違を無くす 顧客にとって 必要なモノの定義が あいまいでやり直しが 終わらない。 2013年10月31日木曜日 作っているものが ”正しいモノ” か検証する

調査事例における対応策 必要ないものを 作るムダをなくす ”何がどれから(欲しい)” という要求を管理する 活用するプラクティス プロダクトバックログ(優先順位付け) プロダクトとして何を作るべきかをリストで管理し、その優先順 位をチームとの会話を踏まえ、プロダクトオーナーに判断しても らう。その結果、チームは何から開発を行えばよいか明確にな る。 2013年10月31日木曜日

Pivotal Tracker 2013年10月31日木曜日

カンバンボード http://ja.wikipedia.org/wiki/かんばん̲(ソフトウェア開発) 2013年10月31日木曜日

• http://ja.wikipedia.org/wiki/かんばん_(ソフトウェア開発)

調査事例における対応策 必要ないものを 作るムダをなくす ”何がどれから(欲しい)” という要求を管理する 活用するプラクティス プロダクトバックログ(優先順位付け) プロダクトとして何を作るべきかをリストで管理し、その優先順 位をチームとの会話を踏まえ、プロダクトオーナーに判断しても らう。その結果、チームは何から開発を行えばよいか明確にな る。 2013年10月31日木曜日 チーム全員がいつでも状態を把握できること

調査事例における対応策 作るモノへの認識の 相違を無くす 認識の相違が生まれる 期間をできるだけ 短くする 活用するプラクティス 迅速なフィードバック アウトプットが適切かどうかわかりにくい時は、迅速なフィードバックを心掛ける。その 結果、現状把握と軌道修正がしやすくなる。 オンサイト顧客 開発者と顧客が常に会話ができる環境で仕事をしよう。その結果、顧客と開発者のコミュ ニケーション量が増えて、顧客が望むソフトウェアが作られやすくなる。 スプリントレビュー イテレーションの終わりに完了したものを関係者にデモをする。その結果、チームは次の イテレーションで何をするべきかフィードバックを得る。 2013年10月31日木曜日

調査事例における対応策 作っているものが ”正しいモノ” か検証する 正しさの基準(顧客の意 図する働き)を作り 機能の仕様が合致して いるか確認する 活用するプラクティス 受入テスト ユーザーストーリーが完了したかを判定するために、プロダクト オーナーと合意した受入テストを作成する。その結果、ユーザー ストーリーの完了条件が明確になり開発チームとプロダクトオー ナー間の認識の齟齬がなくなる。 2013年10月31日木曜日

2013年10月31日木曜日

<サンプル> 2013年10月31日木曜日

<サンプル> ユーザーストーリー ＜ユーザーの種類＞として ＜達成したいゴール＞したい なぜなら＜理由/動機＞だからだ 完了条件 2013年10月31日木曜日

調査事例における対応策 作っているものが ”正しいモノ” か検証する 正しさの基準(顧客の意 図する働き)を作り 機能の仕様が合致して いるか確認する 活用するプラクティス 受入テスト ユーザーストーリーが完了したかを判定するために、プロダクト オーナーと合意した受入テストを作成する。その結果、ユーザー ストーリーの完了条件が明確になり開発チームとプロダクトオー ナー間の認識の齟齬がなくなる。 完了条件が明確になっている=開発準備ができている 2013年10月31日木曜日

開発準備OK 開発対象の機能について、 ・関連ドキュメントがどれか分かっている。 ・連絡窓口が決まっている(対象について業務知識 が豊富な人)。 ・顧客に価値をもたらすこと。 ・チームによって見積もられていること。 ・受け入れテストのシナリオが 書かれていること。 「リーン開発の現場」より 2013年10月31日木曜日

ダイアログ <5分> 自己紹介 1. 普段のお仕事 2. 本セミナーへの期待 話しあってみよう <20分> 以下についてグループ内で話しあってください。 1. 「コスト問題」はなぜ起きるか 2. 「コスト問題」にどのような対処ができるか 3. 「紹介したプラクティス」から現場でできることは何か グループ共有 各グループからどんな議論が出たか共有してもらいます。 2013年10月31日木曜日 <5分>

約束事 ・目的は、相手の意見を聴いて、 様々な見方を知る。 →自分の意見を押し付けたり、 どっちが勝ったという議論ではない ・1人の人が話し過ぎない。 →目的を忘れずに ・いつもより心持ち、うなずき多めに。 →うなずきがあると話しやすい 2013年10月31日木曜日

プロダクトバックログ(優先順位付け) プロダクトバックログは、全体の71%の事例で適用されていた。 特に中大規模では90%以上が適用していたが、受託開発での適用 は約50%に滞っていた(スコープの考え方)。 B社事例(2)では、プロダクトバックログの順序について、最終的な判断はプロダクト オーナーが行っていたが、管理はチームメンバーが代行していた。優先順位の基準は、 インセプションデッキで作った際の、プロダクトのビジョンを用いた。 C社事例(4)では、最低限なくてはならない必須機能と、あれば良いという機能を明確に 分けて、プロダクトバックログで管理した。最初は、欲しいものから項目を洗い出し、 プロジェクトの途中からは、予算から判断して必要な機能に絞るようにした。 G社事例(9)(10)では、プロダクトバックログアイテムの管理に、ユーザーストーリー マップ（ユーザーの行動に即してユーザーストーリーを洗い出して整理した図）を主とし て活用している。プロダクトオーナーとはユーザーストーリーマップを使って、コミュニ ケーションを取っていた。 2013年10月31日木曜日

迅速なフィードバック B社事例(2)では、共通の部屋やオンサイト顧客などのプラクティスで迅速なフィード バックを得られるようにし、開発チームとプロダクトオーナーのコミュニケーションを 密にしたところ、緊急対応などの無理な要求が発生して、チームが要求の対応に追われ てしまい、結果的に開発チームが集中できない状況になってしまった。 F社事例(8)では、カナリア環境と呼ぶ実行環境を用意している。希望ユーザーに機能を 本実装する前のプロトタイプを利用してもらい、その機能についての要望を収集し フィードバックを得ることができる。 スプリントレビュー B社事例(2)では、朝会でステークホルダーにデモをしていた。そのため、スプリントレ ビューは対象機能の完了を確認するのみとし、デモは行わないことにした。 B社事例(3)では、「完了」の定義を作成していなかったため、確認があいまいとなって しまった。 G社事例(9)では、デモに時間がかかり過ぎていたため、受入テストツールを使ったテ ストシナリオを事前にスプリントレビュー参加者に共有することで、デモの実施時間を 短縮することができた。 2013年10月31日木曜日

受入テスト 受入テストは、全体で44%の事例で適用されていた。そのうち自 動化を実現している事例はさらに少数であった。 A社事例(1)では、受入テストの自動化は実施しておらず、プロダクトオーナーと正常系 のエンド・ツー・エンドテストを手動で行っていた。 G社事例(10)では、受入テストツールのCucumberを用いた。日本語を用いてテストシナ リオを書き、それを元に受入テストの自動化を行った。テストシナリオを開発チームと プロダクトオーナーの間で合意しているため受入テストの成功がユーザーストーリー完了 の条件になっていた。受入テストは何度も実施していたが、プロダクトオーナーにテスト 結果を公開することはしていなかった。プロダクトオーナーが信頼して開発チームに任せ ていたためである。 K社事例(20)では、プロダクトオーナーからテスト作業はできないとの申し入れがあっ た。テストシナリオを確認することは問題ないが、膨大な量のテストは実施してはもら えないため、開発チームが受入テストを実施した。 Redmineに仕様、受け入れ条件や制約を記述している。遠隔地にいるプロダクトオー ナーがその内容を確認したり、印刷したりすることができるようにした。 2013年10月31日木曜日