Embed Size (px)
Citation preview
いちたに としひろ
市谷 聡啓・東京でSI、受託開発(永和システムマネジメント所属)・開発現場のためのコミュニティDevLOVE主催・「リーン開発の現場」翻訳しました
twitter : @papanda2013年10月31日木曜日
正しいものを、正しく作る2013年10月31日木曜日
開発現場のためのコミュニティ・1600名・2008年から5年半運営、全142回・東京/神奈川/名古屋/仙台/大阪/四国
http://www.devlove.org2013年10月31日木曜日
・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日木曜日
調査事例における対応策
活用するプラクティスプロダクトバックログ(優先順位付け)
必要ないものを作るムダをなくす
”何がどれから(欲しい)”という要求を管理する
プロダクトとして何を作るべきかをリストで管理し、その優先順位をチームとの会話を踏まえ、プロダクトオーナーに判断してもらう。その結果、チームは何から開発を行えばよいか明確になる。 チーム全員がいつでも状態を把握できること
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日木曜日
ダイアログ
1. 普段のお仕事2. 本セミナーへの期待
自己紹介
話しあってみよう以下についてグループ内で話しあってください。1. 「コスト問題」はなぜ起きるか2. 「コスト問題」にどのような対処ができるか3. 「紹介したプラクティス」から現場でできることは何か
グループ共有各グループからどんな議論が出たか共有してもらいます。
<5分>
<20分>
<5分>
2013年10月31日木曜日
約束事・目的は、相手の意見を聴いて、 様々な見方を知る。 →自分の意見を押し付けたり、 どっちが勝ったという議論ではない・1人の人が話し過ぎない。 →目的を忘れずに・いつもより心持ち、うなずき多めに。 →うなずきがあると話しやすい
2013年10月31日木曜日
プロダクトバックログ(優先順位付け)
B社事例(2)では、プロダクトバックログの順序について、最終的な判断はプロダクトオーナーが行っていたが、管理はチームメンバーが代行していた。優先順位の基準は、インセプションデッキで作った際の、プロダクトのビジョンを用いた。
プロダクトバックログは、全体の71%の事例で適用されていた。特に中大規模では90%以上が適用していたが、受託開発での適用は約50%に滞っていた(スコープの考え方)。
C社事例(4)では、最低限なくてはならない必須機能と、あれば良いという機能を明確に分けて、プロダクトバックログで管理した。最初は、欲しいものから項目を洗い出し、プロジェクトの途中からは、予算から判断して必要な機能に絞るようにした。
G社事例(9)(10)では、プロダクトバックログアイテムの管理に、ユーザーストーリーマップ（ユーザーの行動に即してユーザーストーリーを洗い出して整理した図）を主として活用している。プロダクトオーナーとはユーザーストーリーマップを使って、コミュニケーションを取っていた。
2013年10月31日木曜日
迅速なフィードバックB社事例(2)では、共通の部屋やオンサイト顧客などのプラクティスで迅速なフィードバックを得られるようにし、開発チームとプロダクトオーナーのコミュニケーションを密にしたところ、緊急対応などの無理な要求が発生して、チームが要求の対応に追われてしまい、結果的に開発チームが集中できない状況になってしまった。
F社事例(8)では、カナリア環境と呼ぶ実行環境を用意している。希望ユーザーに機能を本実装する前のプロトタイプを利用してもらい、その機能についての要望を収集しフィードバックを得ることができる。
スプリントレビューB社事例(2)では、朝会でステークホルダーにデモをしていた。そのため、スプリントレビューは対象機能の完了を確認するのみとし、デモは行わないことにした。
B社事例(3)では、「完了」の定義を作成していなかったため、確認があいまいとなってしまった。
G社事例(9)では、デモに時間がかかり過ぎていたため、受入テストツールを使ったテストシナリオを事前にスプリントレビュー参加者に共有することで、デモの実施時間を短縮することができた。
2013年10月31日木曜日
受入テスト
A社事例(1)では、受入テストの自動化は実施しておらず、プロダクトオーナーと正常系のエンド・ツー・エンドテストを手動で行っていた。
受入テストは、全体で44%の事例で適用されていた。そのうち自動化を実現している事例はさらに少数であった。
G社事例(10)では、受入テストツールのCucumberを用いた。日本語を用いてテストシナリオを書き、それを元に受入テストの自動化を行った。テストシナリオを開発チームとプロダクトオーナーの間で合意しているため受入テストの成功がユーザーストーリー完了の条件になっていた。受入テストは何度も実施していたが、プロダクトオーナーにテスト結果を公開することはしていなかった。プロダクトオーナーが信頼して開発チームに任せていたためである。
K社事例(20)では、プロダクトオーナーからテスト作業はできないとの申し入れがあった。テストシナリオを確認することは問題ないが、膨大な量のテストは実施してはもらえないため、開発チームが受入テストを実施した。Redmineに仕様、受け入れ条件や制約を記述している。遠隔地にいるプロダクトオーナーがその内容を確認したり、印刷したりすることができるようにした。
2013年10月31日木曜日
