現場実践主義としてのリーン開発とアジャイル
•
26 recomendaciones•36,336 vistas
2014-03-13（木）の、情報処理学会 第７６回全国大会のセッション『ビッグデータ時代に立ち向かうイノベイティブなシステム開発～Agile, Big-data, Cloud, DevOpsのプラクティスから ～』の発表資料です。 http://www.ipsj.or.jp/event/taikai/76/event_1-6.html 現場は難しく、面白いです。 唯一絶対の答えはなく、予測不可能な問題が多発し、何らかの改善を行なっても、問題はなくならずに移動していきます。 一方で、適切な知識・情報を見つけて行動することで、いくらでも変えていくことが出来る可能性も持っています。 このセッションでは、日々プロジェクト・プロダクトを俯瞰し、課題を見つけて解決策を講じるサイクルを短く繰り返して現場を改善していった、現場でのリーン開発とアジャイルの実践について、アジャイルコーチとしての自身の経験・事例に基づいてお話させていただきます。 現場毎に答えが異なることと、それゆえの面白さがあることとを、皆さんと共に考えていければと思います。
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a 現場実践主義としてのリーン開発とアジャイル
Similar a 現場実践主義としてのリーン開発とアジャイル (20)
Más de Rakuten Group, Inc.
Más de Rakuten Group, Inc. (20)
現場実践主義としてのリーン開発とアジャイル
- 1. 現場実践主義としての リーン開発とアジャイル Mar/13/2014 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/
- 2. 2 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo Hiroyuki Ito （伊藤 宏幸、The Hiro）
- 5. 5 （解答例１） リーン開発の原則 Optimize the Whole Energize Workers Eliminate Waste Learn First Deliver FastFocus on Customers http://www.poppendieck.com/ Build Quality In Keep Getting Better
- 12. 12 アジェンダ 1. 現場の概要 3. 結論：現場の最前線で得たもの 2. 問題解決の事例
- 13. 13 1. 現場の概要 3. 結論：現場の最前線で得たもの 2. 問題解決の事例
- 15. 15 （概要） プロダクト開発の流れ 要件定義 開発 • プログラミング • 単体テスト • 結合テスト 受入テスト 操作性テスト これを１ヶ月毎に繰り返す （スプリント・イテレーション） スワイプの方が 操作しやすいよ ここにリンク置いて ユーザを誘導しよう while (homura) { 出来てるかな～？
- 16. 16 1. 現場の概要 3. 結論：現場の最前線で得たもの 2. 問題解決の事例
- 18. 18 最初の課題 • システムの機能追加／修正の頻度が高い • 機能追加／修正の都度、 「回帰テスト」（既存システムに影響がないことの確認）を 手動で実施していた • 機能追加／修正の都度、 「ステークホルダー」（ビジネスアナリストらプロジェクト関係者）の 端末に、最新版のアプリを１つ１つ手動でインストールしていた 仕事が全体的に遅い
- 19. 19 要件定義 開発 • プログラミング • 単体テスト • 結合テスト 受入テスト 操作性テスト プロダクト開発の流れ
- 20. 20 数値計測による仮説検証 • インストール作業時間 ： ０．５時間（＋α）／回 • ６人（延べ） × ５分 • バージョンミスなどがあった場合はやり直し • 回帰テストの実行時間 ： ４．０時間（＋α）／回 • 一人がかかりっきりで、半日はかかる • バグを見つけた場合はやり直し • 機能追加／修正の頻度 ： ３回／週 １３．５時間／週
- 22. 22
- 23. 23 • インストール作業時間 ： ２分／回 • 人数に関係なく、一律同じ時間で実施可能 • 回帰テストの実行時間 ： ３分／回 • 機能追加／修正の頻度 ： ３回／週 １５分／週 数値計測による仮説検証 （施策実行後）
- 26. 26 数値計測による現状把握 • スプリントの最初に計画したタスクのうち、 実に７５％のものがスプリント内に終えられなかった • 割り込み率 ： ５０％ • Stash(GitHub) でのマージミスや既存サービスのトラブル対応などで、 チーム外からチームメンバーに対して 多くの割り込み作業があることが分かった • タスクの完了率 ： ２５％
- 28. 28 ボトルネックが 移動している (´･ω･｀) 要件定義 開発 • プログラミング • 単体テスト • 結合テスト 受入テスト 操作性テスト
- 29. 29 解決策 • 割り込み作業依頼の内容を精査し、 本当に緊急なもの以外はお断りするようにした • トラブル対応を出来る人をチーム外に増やし、 チームメンバーの負荷を分散した • 誰にいつ何回割り込み作業依頼があるかを チームメンバー全員に見えるようにした • メンバーの負荷を他メンバーが把握できるようにすることが目的 • 改めて確認してみると、実際には緊急でないものも 「緊急」として依頼されていることがあった
- 30. 30 • 割り込み作業防止の効果アリ • 一方で、まだ半分のタスクを終えられない原因が他にありそう • 割り込み率 ： ２０％ • 安直な「緊急」依頼は激減した • 本当の緊急対応も、ほぼチーム外だけで解決できるようになってきた • タスクの完了率 ： ５０％ 数値計測による施策の検証 （１月後）
- 32. 32 何かがおかしい？
- 34. 34 数値計測による現状把握 • 元々難易度が高い機能だった • 既存の単体テストレベルの自動回帰テストでは検知できなかった • 機能追加／修正の頻度 ： ５倍 • 最初から要件が確定しておらず、やりながら決めていこうとした • 作っていくうちにやりたいことが見えてきたため、修正が頻発した • 「あれもこれも追加したい」と、要望が止まらなくなってきた 他の機能と比較して… • デグレードの頻度 ： ５倍 • バグ報告件数 ： ３倍 • 既存の単体テストレベルの自動回帰テストでは検知できなかった
- 35. 35 ボトルネックが 移動している orz 要件定義 開発 • プログラミング • 単体テスト • 結合テスト 受入テスト 操作性テスト
- 36. 36 解決策 • 変更要望の受付期限を設けた • ATDD（≒受入テストの自動化）を導入し、 この機能のテストを重点的に整備した • 画面遷移やユースケースの一連の処理の流れもテストできる仕組みを、 これまでの単体テストとは別に導入した • 発見したバグやデグレードは、全て ATDD のケースとして整備し、 問題が再発しても即検知できるようにした • ステークホルダーに対して、 要望を無制限に出してくることに歯止めをかけた
- 37. 37 （例） ATDD のテストケース Feature: Input Scenario: Input today’s data Given I kick drumroll Then drumroll show today When press next Then I should see ”xxx" screen When I press keys and calculator should show like this: | 2 | 2 | | 0 | 20 | | 0 | 200 | | * | 200 | | 3 | 3 | | = | 600 | Then take photo … テストケースの名称です このレベルの記述で 自動実行できます 読みやすさを考慮した 記述ができます
- 38. 38 数値計測による施策の検証 （１月後） • ATDD による自動回帰テストを整備した成果 • 機能追加／修正の頻度 ： １．５倍 • 歯止めは必要だった 他の機能と比較して… • デグレードの頻度 ： ２倍 • バグ報告件数 ： １倍 • デグレード自体はまだ発生することがあったが、 あっても即検知・対応できるため、 対応時間は以前の１／５程度になった
- 39. 39 1. 現場の概要 3. 結論：現場の最前線で得たもの 2. 問題解決の事例
- 40. 40 1) 答えは一つではない 現場は難しい 2) 事前に予測不可能な問題が多発する • 唯一絶対の答えはまずない • エンジニアリングだけでは解決できない問題が無数にある 3) 何らかの改善を行なっても、 問題は無くならずに移動していく • 全てを事前に予測・計画し、その通りに実施するということは非現実的 • 特に新技術ではなおさら
- 41. 41 1) 自分たちが発見したものを答えにできる 現場は面白い 3) 問題を１つ１つ解決していく毎に、自分・メンバー・ チームが成長していくことがはっきりと分かる 2) 少しずつ試しながら変えていくことが出来る • 工夫次第で、いかようにも問題の解決が可能 • 試しながら答えを見つけていくことが面白い • 短期の予測ならば、当たる可能性はまだ高い • 短期での失敗なら、すぐにリカバリー・改善できる • やり方次第で、状況をコントロールすることが可能になる
- 49. 49 やってみないと 分からない
- 53. 53 楽しく 天下を