Recommended
More Related Content
What's hot
What's hot (20)
Similar to 2017/4/25 『小規模開発アジャイル導入の気づき』
Similar to 2017/4/25 『小規模開発アジャイル導入の気づき』 (20)
2017/4/25 『小規模開発アジャイル導入の気づき』
- 1. 1
- 2. 2 平野 竜希 鈴木 康士郎 所属：ボルラボ 趣味：アプリ開発、スノーボード 所属：アプリシステム開発第２G 趣味：バンド、スノーボード Ryuuki Hirano Koushiro Suzuki 田口 玲子 所属：ボルラボ ReikoTaguchi スクラムリーダー エンジニア
- 3. 3 宮前 宏一 Kouichi Miyamae 所属：ボルモ マネージャー 趣味：今はゼルダ プロダクトオーナー
- 4. 目的 ◦ 背景 アジャイル開発とは ◦ アジャイル開発とWF ◦ スクラム開発 ◦ スクラムの役割について ◦ チケット駆動開発 実践準備 ◦ 理解するために 実践 ◦ 実践する為に ◦ アジャイル開発を始める為に 品質と達成 ◦ スプリント内の品質保証(システム) ◦ スプリントの達成とは ◦ 品質と達成 プロジェクトの崩壊を防ぐ ◦ 目的を見失う理由 ◦ 目的を見失わない為に 連携 ◦ 連携をスムーズにする為に チームの適正 ◦ チームの理想 継 続 実 践 準 備 ・理 解 4
- 6. 準備・理解 6
- 7. 《agile development》ソフトウエアやコンピューターシステムの開発手法の 一。顧客の要求案件や経営環境の変化に対し、俊敏かつ柔軟に対応することに 主眼を置く。 ◦ 顧客とエンジニアによる少数の共同開発チーム ◦ 開発範囲全体を短い範囲（約２週間程度）でできると思われる 範囲に区分。そしてタスク優先度を付け着手順を決定 ◦ 期間内にその範囲の要求の決定、実装、テスト、修正、リリース ◦ リリースした機能や残プロセスから、次に着手する優先すべき 区分を分析・決定 準備・理解 7 出典：http://www.nec-solutioninnovators.co.jp/column/01_agile.html
- 8. メリット ◦ 業務(タスク)が確定された、優先度の高い重要な機能から着 手できる ◦ 顧客が実際に動く画面、機能を試せる為、仕様の間違いや 要求漏れに早い段階で気付ける 準備・理解 8
- 9. メリット ◦ 要求と実際のプロダクトの間に誤りが発生した場合、原因を 分析することで顧客とエンジニアの情報の伝え方、確認の方 法が向上していく ◦ 開発途中で業務プロセスが変更になった場合、未着手の部 分は変更された内容で実装できる。すでに実装済みの場合 でも修正の影響範囲が限定される ＝要件をすばやく柔軟に反映しながら開発できる 準備・理解 9
- 10. デメリット ◦ 全体のスケジュールや進捗が把握し難い 小単位で開発の全てを繰り返す上、流動的である為 ◦ 長期的な見通しが出来ない スプリントを何回繰り返すかは決められていない為、いつ完了す るのか分からない 準備・理解 10
- 11. デメリット ◦ WF思考から移行する際の習得が困難 後述 ◦ チーム全員に共に一定の基礎スキルが求められる 後述 ◦ 顧客との対等性が必要 顧客も同じチームであり、互いにディスカッションが大切 準備・理解 11
- 15. プロダクトオーナー（PO） ◦ プロダクトに対する、最終決定権と責任を持つ人 ◦ プロダクトの機能優先順を常に最新状態に管理する責任 ◦ プロダクトに対する情熱を持ち、チームと綿密な議論を交わし、 プロダクトの価値を最大限にしようと常に努力する使命を持つ 準備・理解 15
- 16. スクラムマスター ◦ スクラムの理解と実践を推進し、プロダクトを円滑に進める責 任を持つ ◦ スクラムをスクラムチーム全員が正しく理解した上で開発を 実践していることを常にチェック ◦ チームの自律的な行動を引き出し、成果を最大限に引き出 すことに注力 準備・理解 16
- 17. スクラムマスターに対するよくある勘違い ◦ プロジェクトマネージャーは存在しない ◦ トップダウンで意思決定や作業指示を行うことはせず、POと 開発チームがプロダクトを円滑に進めるためにサポート 問題が起きた時、もしくは事前に、POと開発チームが意思決定 出来る場を設け、プロダクトが止まってしまうことを回避させるこ とが仕事 ウォーターフォール型開発のPMではない 準備・理解 17
- 18. 弊社での話 ◦ チケットをプロダクトの情報の中心に ◦ チケットによる作業の割り振りと進捗管理 この二つの概念を取り入れ を使って管理 チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開 発手法の一種で、作業や要件をタスクに分割しバグ管理システムのチケットに 割り当てて管理を行う開発スタイル。細かな修正作業の多い従来開発の中で生 まれたが、アジャイル開発との親和性が高い。 Tｒｙ 準備・理解 18 https://ja.atlassian.com/software/jira
- 20. 20
- 21. ワタシドラマ立ち上げ ◦ 制作プロセスの決定 小刻みに作る 更新/改良を確実に行っていく ◦ 仕様はほぼ存在しない 情報は参考アプリを元に “「○○」のようなものを作る” だけ ボルテージとしてのエッセンス は作りつつ模索 準備・理解 21
- 22. 準備・理解 22
- 23. チームの意識合わせ ◦ アジャイル開発＝概念・考え方 1つの方法がないため意識合わせが不可欠 同じ本を読んでアジャイルについて意識を合わせる Tｒｙ 開発手法について”正しい”を議論するのは不毛 事例の理解と、アジャイルの雰囲気をつかむ 準備・理解 23出版: 翔泳社 (2013/2/13)
- 24. 経験者から学ぶ ◦ 宮前Mgrがプロダクトオーナーとして先導 進行におけるブレが非常に少なく安心して進められた SF子会社でのアジャイル経験を共有 成功した進め方や失敗談など 振り返り会で全員の認識を軌道修正 ◦ 進行上の疑問などをスプリント毎に振り返り解決へ 徐々にチームに合わせたフレームワークへ 詳細後述 準備・理解 24
- 25. 開発の考え方の+α ◦ 仕様は機能 基本的に仕様は 「機能名」+補足 ◦ 最小工数でできる限り 工数を最重要視 削った機能は次スプリントに ◦ チケット（仕様/要件）を満たす事だけを考える 汎用性や将来性を必要以上に考え込まない、作り込まない ⇒どうせ変わる & 工数の無駄 準備・理解 25
- 26. 共通認識の構築 ◦ 1スプリントの期間は？ ◦ 実践のための準備は？ ◦ 持っている工数は？改修期間は？ 長期のゴールを握って、ある程度共有 ◦ いつまでにどのくらいのKPIの商品をつくるのか？ 数ヶ月/週単位のマイルストーンを設定 ◦ プリプロはいつまでに何を達成するのか？ ◦ アルファ、ベータはいつ、何を持って完成とするのか？ 利害関係者の理解を得る ◦ いつまでに”どんな機能ができる”とコミットしない ◦ KPIなど指標ベースで、要件は問わないコミュニケーションをする 実践 実践における環境を以下のように用意 26
- 27. 27
- 28. 要件定義 ０→１を生みだす段階 作りたいイメージを制作/システムで可能な限り意識合わせ 要件リスト(バックログ)の作成 実装する機能の一覧を作成 スプリントを進めて行く上で実装したいものはここに追加 都度優先順位を決めてこのリストからスプリントに組み込んで行く 開発者レベルの自発的な提案が多く必要になるため、 要件の意図までなるべくチームで共有する 実践 28
- 29. ワタシドラマの場合 ◦ 作りたいものの仕様が明確に決まっていない ◦ ざっくりとした仕様を元にサンプルを作り 本当に作りたいもの/ボルテージのエッセンスを検討 Tｒｙ 機能一覧をいくつかの参考アプリから洗い出し 実践 29
- 30. ・・・・ 仕様共有会(1h) ◦ 次回スプリントで行うチケットを決める バックログを元に優先順位の高いチケットから スプリントに組み込む 合わせて優先度/チケット要件・工数が適正かを全員で 判断・修正するためチーム全員参加 実践 30 チケットＺ 工数:3ｈ １ ス プ リ ン ト 作業者 総工数：96h チケットＡ 工数:3ｈ チケットＢ 工数:8ｈ 優先度 ・・・・
- 31. Tｒｙ 仕様共有会の開催頻度をフェーズ毎に調整 ◦ 立ち上げフェーズ サンプル作成時期、要件/機能が流動的 1スプリント2回開催し、短いスパンでイメージの擦り合わせを行った ◦ 本開発フェーズ 方針がある程度確立、要件/機能が固定的 １スプリント１回開催で作業時間を確保 仕様共有会前に前準備をすることで効率化 実践 31 PO：事前に次回スプリントのチケットを割り当て 開発者：上記チケット内容の確認(主に要件/仕様) 実装調査が必要そうな部分は軽く確認をする
- 32. デイリースクラム(朝会) ◦ チーム全員参加 ◦ カンバンを見ながら進捗・今日の作業確認 ◦ トピックがあればここで共有 夕会 ◦ システムのみ ◦ 仕様ベースの詳細な進捗確認 ◦ 成果物の共有 実践 32 https://ja.atlassian.com/software/jira
- 33. 実践 33
- 35. チケットに割り振られた工数が要 ◦ その中で最大限の品質を目指す ◦ 満たせない問題は必ず発生する 短期間のスプリント内でリリース ◦ ◦ チケットとしてビルド/テスト/リリース工程を切り出しルーチン化 チケットに対する品質は100％にすること +α(汎用性や提案)は工数内でガンガン 早期にPOと相談 チケットを分割し、実現レベルを調整する Tｒｙ 実践 35
- 36. PO(制作)レビューの実施 ◦ 開発完了時にPOが動くものを見てレビュー チケットが満たされているかをチェック 細かなUIなどチケット記載外は実装者に任されていた 否定的な意見は開発が仕様を求める傾向になりがち ◦ システム内レビューの実施 夕ブリ等に実機を持ち寄ってアイデア出し 仕様共有効果・品質向上 提案力向上、バグの早期発見 Tｒｙ 実践 36
- 37. コードレビューの実施 ◦ コーディング力向上 ◦ 記述の統一化 ◦ 属人化防止(仕様確認) 仕様書がほぼ無い為、細かな仕様共有はここで巻き取る ◦ 仕様漏れの発見 システム観点で抜け漏れが無いか バグの早期発見 ◦ コーディング力差があると問題がある 時間がかかりすぎる場合は非効率 可読性重視のコードを書く等の工夫 Tｒｙ 実践 37
- 38. 改修期間の確保 ◦ ２週間の中で最後の数日は改修期間として保持 バグやチケット未達成箇所の修正期間 POレビュー反映のバッファ QA/テスト 約2日は修正バッファこの間にビルド一時完成 リリース １ ス プ リ ン ト テスト項目は開発期間内に作成する 実践 38
- 39. ビルドの作成 ◦ スプリントの最後には必ずビルドを提出する 動かないはダメ 振り返り会 ◦ 毎スプリント終了時にPO/制作含め全員で行う プロジェクトを進める上で良かった事、進め難かった事などを挙 げて解決策を出す。 ⇒次スプリントで解決策を実践！！ 溜め込まない 実践 39 イテレーション１ 計画 設計 実装テスト
- 41. ジャッジ ◦ ビルドを元に次スプリントの方針・計画を決定する ジャッジ会の実施 上層部のみで行う場合はPOやスクラムマスターが しっかりと方針の “意図” をチームに浸透させる 指示書が無く、一人一人が考え・提案・開発する 意図が不明では、見当違いな物を… 不毛な循環を作りだすこと必至 実践 41
- 42. 仕様変更/差し込み案件について ◦ 仕様共有会で決めた”要件”を満たすように対応 ◦ スプリント中の工数追加になる差し込みはしない それらはすべて次回以降のスプリントへ ◦ 急遽必須となる場合は、対応予定案件とトレードオフ 改修期間に空きが出たり、改修工数によっては対応するなど 工数内での対応は柔軟に。 実践 リソース内に収める 42
- 43. スプリント内に改修工数を確保 ◦ 見積もりは変わるもの ◦ 仕様の認識ズレは必ず起こる ◦ バグは必ず潜んでいる ことを前提にしておく 実践 8営業日 2営業日 開発 改修 上記で、スプリントが期間内に終了（＝リリース）ができることを担保する。 43
- 44. POはどうすればマイルストーン（スプリントのゴール） を達成できるか？にフォーカスし、細かい最適化や仕 様変更は開発者に任せる AAAという機能を実装したい AAAという機能を実装する AAAという機能を実装したい ABBという機能を実装する XXXというゴールを達成したい × ○ XXXというゴール達成XXXというゴール達成 / 未達成 実践 上記により、 「AAAが実装できないとリリースできない」ということを排除する。 44
- 45. 継続 45
- 46. 崩壊パターン ◦ 今のチケットでこの機能も欲しいなー…追加仕様で！ ◦ レビュー時にバグを発見！すぐに修正だ！ ◦ ちょっと時間押すけど作りこんだほうが汎用性あがる！！ 継続 ・ ・ ・ 46 ちょっと待った！！！
- 49. 崩壊パターン ◦ 今のチケットでこの機能も欲しいなー…追加仕様で！ ◦ レビュー時にバグを発見！すぐに修正だ！ ◦ ちょっと時間押すけど作りこんだほうが汎用性あがる！！ 継続 49 チケット肥大化、工数通り終わらない チケット優先度崩壊、他チケットの遅延 チケット工数増加、他チケットの遅延
- 50. 見失う理由 どこまで作りこむかの線引きが曖昧になりやすい ◦ 「最小工数で作ること」と「品質/汎用性を求めること」の バランスをチームでとる必要がある チケットのボリュームが肥大化しがちになる レビューでの手戻りが多くなる 小さく積み上げ、確実な改善を繰り返す事 継続 50
- 51. 方針/品質の認識をチームで一致させることが最も重要 チームで方針/品質の意識共有 ◦ 開発側・制作側（レビュー） 共に求める品質認識を合わせる ◦ 認識以上はお互い求めない 継続 ‣ 品質の認識合わせを制作・システム間で密に行った ‣ チケット毎に小さい機能単位で仕様記述をしてもらい、 追加仕様は別チケにすることを徹底した Tｒｙ 認識以上の品質を求める場合は同じチケットにはねじ込まず、 別チケットとして、再度優先度で判断する ワタシドラマでは 51
- 52. 方針/品質の認識をチームで一致させることが最も重要 レビューの手戻りが多い 追加仕様が多い ◦ 上記に当てはまる場合はチームでの認識が合っていない 方針や品質を再度話し合い、認識の差を解消することが大事 継続 席を近づけてすぐに疑問を解消 コミュニケーションを図れる体制を敷くとやりやすかった Tｒｙ ワタシドラマでは 52
- 53. 継続 (再)POはどうすればマイルストーン（スプリントのゴー ル）を達成できるか？にフォーカスし、細かい最適化 は開発者に任せる 低クオリティでも、ゴール達成かどうかが判断基準 ◦ ある程度バグOK ◦ ある程度考慮漏れOK リソース（特に時間）のマネージメントをしっかり ◦ 実験作なのでやればやるだけ成果になる訳ではない ◦ スプリント×∞の長期戦なので、疲弊しない組織にする POとして、上記をブレずに判断する。 53
- 54. 54
- 57. [仕様について] 細かい仕様を出し過ぎない ◦ あくまで、マイルストーン/スプリントゴールが重要 仕様は20%決まった段階くらいでシェア ◦ 最小工数でゴールを達成できる仕様を開発も入れて決める [コミュニケーションについて] POに気軽に話しかけやすい雰囲気をつくる 現場同士のコミュニケーションを後押しする 開発に集中するため、簡単な質問や依頼はチャットで（隣に居るのに） 仕様に関するコメントは、JIRAに記載で漏れ防止 継続 57
- 58. 開発メンバーの適性 ◦ 順応性が高く、頭の切替がすぐにできる ◦ 反省するのが得意で、前向きにとらえられる ◦ チケットの要件から、実装方法のバリエーションが提案できる ◦ 問題があった際、本質を捕らえ解決策を出せる ◦ チームで成果を出すため、チームプレイが得意 ◦ 自ら作業を取りに行く姿勢を持っている ◦ 自分の開発物に責任を持てる（メンバー各人が責任者） 継続 58
- 59. プロダクトオーナーの適性 ◦ アジャイル開発経験者が望ましい ◦ 常に目標がブレない、または変更や軌道修正ができる ◦ 経営者との調整が得意 ◦ スクラムを邪魔する壁(社内ルールなど)を壊せる推進力を持つ ◦ 2週間、スクラムを任せて（我慢して）傍観できる ◦ 開発の作業をある程度理解している 継続 59
- 60. スクラムマスターの適性 ◦ 課題に対して常にメンバーと共に改善する姿勢を持っている ◦ チームにとって何が適切か見極めることができる ◦ 障害をすぐに取り除くことができる ◦ プロダクトオーナーがブレた時に軌道修正ができる ◦ 人助けが好きな人 継続 60
- 61. 61
- 62. アジャイルを始めるには ◦ 経験者から学ぶ。手法について”正しい”を議論しない。 実践 ◦ 仕様共有会 作るものの意識合わせ 品質 ◦ アプリ品質は少しづつ。チケットは確実に。 達成 ◦ ジャッジ会と振り返り会 スプリントを活かした反省と実践。 連携 ◦ コミュ量増やしてコストを減らす。 関係者はスプリント駆動で統一。 崩壊させないためには ◦ 方針と品質の認識一致。チーム全員の対等性。 62
- 63. 63
- 64. 64
- 66. アジャイル開発を取り入れる べき プロジェクトは？ 66
- 67. 67