現場実践主義としてのリーン開発とアジャイル
Post on 31-Oct-2014
8 Views
Preview:
DESCRIPTION
TRANSCRIPT
現場実践主義としての リーン開発とアジャイル
Mar/13/2014
Hiroyuki Ito
IT Department, Rakuten, Inc.
http://www.rakuten.co.jp/
2
情報技術部
プロセス・品質課
テスト駆動開発グループ
@hageyahhoo
Hiroyuki Ito (伊藤 宏幸、The Hiro)
3
今回のテーマ
• リーン開発
• アジャイル
4
問1.リーン開発とは?
5
(解答例1) リーン開発の原則
Optimize the Whole
Energize Workers
Eliminate Waste
Learn First
Deliver Fast Focus on Customers
http://www.poppendieck.com/
Build Quality In
Keep Getting Better
6
(解答例2) かんばん
http://www.slideshare.net/daipresents/kanban-and-lean-from-the-trenches
7
問2.アジャイルとは?
8
(解答例) アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/
個人と対話を プロセスやツールよりも
顧客との協調を 契約交渉よりも
変化への対応を 計画に従うことよりも
動くソフトウェアを 包括的なドキュメントよりも
9
https://www.flickr.com/photos/ptofnoretrn77/22896629/
10
結局何をすれば
よいのか分からない。
11
ならば 現場のホンモノを お見せしましょう。
12
アジェンダ
1. 現場の概要
3. 結論:現場の最前線で得たもの
2. 問題解決の事例
13
1. 現場の概要
3. 結論:現場の最前線で得たもの
2. 問題解決の事例
14
チーム構成
ビジネス
アナリスト
アジャイルコーチ
(私)
UI/UX
デザイナー
開発者
15
(概要) プロダクト開発の流れ
要件定義
開発 • プログラミング
• 単体テスト
• 結合テスト
受入テスト
操作性テスト
これを1ヶ月毎に繰り返す
(スプリント・イテレーション)
スワイプの方が
操作しやすいよ
ここにリンク置いて
ユーザを誘導しよう while (homura) { 出来てるかな~?
16
1. 現場の概要
3. 結論:現場の最前線で得たもの
2. 問題解決の事例
17
仕事が全体的に遅い
最初の課題
18
最初の課題
• システムの機能追加/修正の頻度が高い
• 機能追加/修正の都度、
「回帰テスト」(既存システムに影響がないことの確認)を
手動で実施していた
• 機能追加/修正の都度、
「ステークホルダー」(ビジネスアナリストらプロジェクト関係者)の
端末に、最新版のアプリを1つ1つ手動でインストールしていた
仕事が全体的に遅い
19
要件定義
開発 • プログラミング
• 単体テスト
• 結合テスト
受入テスト
操作性テスト
プロダクト開発の流れ
20
数値計測による仮説検証
• インストール作業時間 : 0.5時間(+α)/回 • 6人(延べ) × 5分
• バージョンミスなどがあった場合はやり直し
• 回帰テストの実行時間 : 4.0時間(+α)/回 • 一人がかかりっきりで、半日はかかる
• バグを見つけた場合はやり直し
• 機能追加/修正の頻度 : 3回/週
13.5時間/週
21
解決策:ビルド・テスト・リリースの自動化
更新のチェック
(1時間おき) 私のノート PC
毎日の朝礼で、
最新版のアプリを
ステークホルダーにデモする
チームメンバー全員に
最新版のアプリを配信
ビルドと回帰テストを自動実行
22
23
• インストール作業時間 : 2分/回 • 人数に関係なく、一律同じ時間で実施可能
• 回帰テストの実行時間 : 3分/回
• 機能追加/修正の頻度 : 3回/週
15分/週
数値計測による仮説検証 (施策実行後)
24
ビルド・テスト・リリース
を自動化した!
25
思っていたよりも
楽になっていない?
26
数値計測による現状把握
• スプリントの最初に計画したタスクのうち、
実に75%のものがスプリント内に終えられなかった
• 割り込み率 : 50% • Stash(GitHub) でのマージミスや既存サービスのトラブル対応などで、
チーム外からチームメンバーに対して
多くの割り込み作業があることが分かった
• タスクの完了率 : 25%
27
作業に
集中できないことで、
プロダクト開発が
阻害されている
28
ボトルネックが
移動している (´・ω・`)
要件定義
開発 • プログラミング
• 単体テスト
• 結合テスト
受入テスト
操作性テスト
29
解決策
• 割り込み作業依頼の内容を精査し、
本当に緊急なもの以外はお断りするようにした
• トラブル対応を出来る人をチーム外に増やし、
チームメンバーの負荷を分散した
• 誰にいつ何回割り込み作業依頼があるかを
チームメンバー全員に見えるようにした • メンバーの負荷を他メンバーが把握できるようにすることが目的
• 改めて確認してみると、実際には緊急でないものも
「緊急」として依頼されていることがあった
30
• 割り込み作業防止の効果アリ
• 一方で、まだ半分のタスクを終えられない原因が他にありそう
• 割り込み率 : 20% • 安直な「緊急」依頼は激減した
• 本当の緊急対応も、ほぼチーム外だけで解決できるようになってきた
• タスクの完了率 : 50%
数値計測による施策の検証 (1月後)
31
作業に
集中できるように
なり始めてきた!
32
何かがおかしい?
33
とある機能で
バグが頻発している
34
数値計測による現状把握
• 元々難易度が高い機能だった
• 既存の単体テストレベルの自動回帰テストでは検知できなかった
• 機能追加/修正の頻度 : 5倍 • 最初から要件が確定しておらず、やりながら決めていこうとした
• 作っていくうちにやりたいことが見えてきたため、修正が頻発した
• 「あれもこれも追加したい」と、要望が止まらなくなってきた
他の機能と比較して…
• デグレードの頻度 : 5倍
• バグ報告件数 : 3倍
• 既存の単体テストレベルの自動回帰テストでは検知できなかった
35
ボトルネックが
移動している orz
要件定義
開発 • プログラミング
• 単体テスト
• 結合テスト
受入テスト
操作性テスト
36
解決策
• 変更要望の受付期限を設けた
• ATDD(≒受入テストの自動化)を導入し、
この機能のテストを重点的に整備した • 画面遷移やユースケースの一連の処理の流れもテストできる仕組みを、
これまでの単体テストとは別に導入した
• 発見したバグやデグレードは、全て ATDD のケースとして整備し、
問題が再発しても即検知できるようにした
• ステークホルダーに対して、
要望を無制限に出してくることに歯止めをかけた
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
数値計測による施策の検証 (1月後)
• ATDD による自動回帰テストを整備した成果
• 機能追加/修正の頻度 : 1.5倍 • 歯止めは必要だった
他の機能と比較して…
• デグレードの頻度 : 2倍
• バグ報告件数 : 1倍
• デグレード自体はまだ発生することがあったが、
あっても即検知・対応できるため、
対応時間は以前の1/5程度になった
39
1. 現場の概要
3. 結論:現場の最前線で得たもの
2. 問題解決の事例
40
1) 答えは一つではない
現場は難しい
2) 事前に予測不可能な問題が多発する
• 唯一絶対の答えはまずない
• エンジニアリングだけでは解決できない問題が無数にある
3) 何らかの改善を行なっても、
問題は無くならずに移動していく
• 全てを事前に予測・計画し、その通りに実施するということは非現実的
• 特に新技術ではなおさら
41
1) 自分たちが発見したものを答えにできる
現場は面白い
3) 問題を1つ1つ解決していく毎に、自分・メンバー・ チームが成長していくことがはっきりと分かる
2) 少しずつ試しながら変えていくことが出来る
• 工夫次第で、いかようにも問題の解決が可能
• 試しながら答えを見つけていくことが面白い
• 短期の予測ならば、当たる可能性はまだ高い
• 短期での失敗なら、すぐにリカバリー・改善できる
• やり方次第で、状況をコントロールすることが可能になる
42
自動化の恩恵に全力であずかろう
43
数値を計測して行動し、成果を確認しよう
テストの実行時間 機能追加/修正の頻度
デグレードの頻度 バグ報告件数
残タスク数 テスト網羅率
割り込み率 タスクの完了率
などなど…
44
「振り返り」によるチームの学習の促進
45
いずれも現場で試しながら 考え行動し見つけた答え。 答えは現場にある。
現場実践主義
46
現場実践主義
≒
• リーン開発
• アジャイル
47
更なる新技術の登場
https://www.flickr.com/photos/taedc/9276625962
48
無限とも言える選択肢
https://www.flickr.com/photos/3059349393/3786855827/
49
やってみないと
分からない
50
ならば、
やってみれば
いいんです。
51
今回のテーマ
• リーン開発
• アジャイル
52
1つ1つ試しながら
考え行動し続け、 あなたの答えを
みつけてみましょう。
53
楽しく 天下を
top related