Advertisement
「Agileごっこ」で終わらせないために(仮)
Aug. 24, 2014•0 likes•2,109 views
9 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Technology
DevLOVE甲子園2014 西日本大会 での発表資料です。
Taku YajimaFollow
Software Engineer at Ateam inc.Advertisement
Advertisement
Advertisement
「Agileごっこ」で終わらせないために(仮)
- 【Agileごっこ】で 終わらせないために (仮) 2014/08/23 DevLOVE甲子園 西日本大会 Taku YAJIMA (@quindim)
- きんちゃん です
- 自己 紹 介
- 矢島 卓Taku YAJIMA(@quindim) ■お仕事（2011～） 【株式会社エイチーム】 ■Webアプリ開発 ■Androidアプリ開発 ■Webインフラ構築運用 ■アジャイル開発支援 ■社外コミュニティ活動 ■DevLOVE名古屋 ■人生を変えた出会い ■カポエィラ ■DevLOVE(本家) ■IT現場のリーダー塾
- 感謝
- 宣伝
- エッセンシャル スクラム スクラムを 知るならコレ！ の一冊 翻訳レビュー 参加しました
- 宣伝 終了
- 本日 お話する事
- 普通のエンジニアが 普通の会社で アジャイルな開発に 取り組んでみた 3年間の話
- • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- 今日の結論
- 【Agileごっこ】 から始めても いいじゃない。 だけど、 やめんな。
- • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- アジャイル 開発
- ？
- •【アジャイル開発】という言葉 •「やった事がある・やっている」人 •むしろ人に教える立場です
- ありがとう ございます
- ソフトウェア 開発手法
- アジャイル マニフェスト
- • プロセスやツールよりも 人と人同士の相互作用を重視 • 包括的なドキュメントよりも 動作するソフトウェアを重視 • 契約交渉よりも 顧客との協調を重視 • 計画に従うことよりも 変化に対応することを重視
- いまいち ピンと来ない…
- そんな時は アジャイルソフトウェア開発の 原則 を見てみる
- 私たちは以下の原則に従う: 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。
- 要求の変化を歓迎 短い時間間隔でリリース ビジネスの人と開発者が 日々一緒に働く 意欲に満ちた人々 信頼 フェイス・トゥ・フェイス 持続可能な開発 優れた設計 自己組織的 定期的な振り返り
- ここらへんの事が 実現できていれば 「アジャイルな開発」 であろう
- • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- •2軸のWeb系事業で成長中 –エンターテインメント事業 –ライフスタイルサポート事業 •経営理念 –みんなで幸せになれる会社 –今から100年続く会社
- 内製中心 開発スタイル
- 良くある チームの スタイル
- 例：ライフサポート系 Product Owner Sales Design Planning & Promotion Programming
- 例：ライフサポート系
- 例：スマートフォンアプリ Promotion Customer Support
- 例：スマートフォンアプリ
- 開発スタイル 運用開発 S-IN メンバー(ほぼ)固定
- 僕の 立ち位置 ＝ 【間接部門】
- アジャイル 開発
- 要求の変化を歓迎 短い時間間隔でリリース ビジネスの人と開発者が 日々一緒に働く 意欲に満ちた人々 信頼 フェイス・トゥ・フェイス 持続可能な開発 優れた設計 自己組織的 定期的な振り返り
- 実は 弊社だと 大体できてる
- 結論 エイチームは アジャイルな 開発現場だった
- 以上
- …
- とは言え 上手く 行かない事も 多いですよね
- 要求の変化を歓迎 短い時間間隔でリリース ビジネスの人と開発者が 日々一緒に働く 意欲に満ちた人々 信頼 フェイス・トゥ・フェイス 持続可能な開発 優れた設計 自己組織的 定期的な振り返り
- 現実は
- 仕様の変化で 納期に影響が… 頻繁なリリースでバグる… 同じチームなんだけど あの人とあんまり 話さない… 意欲にバラつき 信頼？フェイス・トゥ・フェイス 行き当たりばったり 設計？何それ？ 管理ツラい 成長を感じない…
- 前職からの チームビルディング 経験を活かして アジャイルな開発に 取り組んでみた
- 残り時間 10分切っていると マズいわよ。
- • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- はじめてのScrum
- Scrum?
- Scrum とは • 自律改善型チームを育て • 優先順位の高い機能を • 繰り返し価値に変え届ける • 仕組み(フレームワーク) アジャイル開発手法の1つ
- 期間固定のスプリントを繰り返す 月 火 水 木 金 月 火 水 木 金 前 後 月 火 水 木 金 月 火 水 木 金 前 後
- 3つの役割 ・プロダクトオーナー ・開発チーム ・スクラムマスター 4つのイベント ・スプリント計画会議 ・デイリースクラム ・スプリントレビュー ・スプリントふりかえり 3つの成果物 ・プロダクトバックログ ・スプリントバックログ ・出荷可能な製品の増分
- プロダクトオーナー 優先順位・利益の責任者 スクラムマスター 規律を守り皆を促す 【Scrumの守り人】 開発チーム 自己組織化された 【生み出す人】
- プロダクトバックログ 会員登録ができる 5 会員は予約ができる 5 お知らせを登録できる 3 イベントを登録できる 3 会員は退会ができる 1 会員は決済ができる 13 優先順位付けられた機能一覧 スプリントバックログ スプリント内のタスク一覧 出荷可能な製品の増分 今回のスプリントで出来たモノ
- 月 火 水 木 金 月 火 水 木 金 朝 一 午 前 午 前 午 後 午 後 デイリースクラム（朝会）：1回15分以内 スプリント(1開発期間)内のMTG • 昨日やった事 • 今日やる事 • 問題、障害になっている事
- 月 火 水 木 金 月 火 水 木 金 朝 一 午 前 午 前 午 後 午 後 デイリースクラム（朝会）：1回15分以内 スプリント計画会議：やる事決め スプリント(1開発期間)内のMTG
- 月 火 水 木 金 月 火 水 木 金 朝 一 午 前 午 前 午 後 午 後 デイリースクラム（朝会）：1回15分以内 スプリント計画会議：やる事決め スプリントレビュー：動く物を見せる ふりかえり（KPT等） スプリント(1開発期間)内のMTG
- 月 火 水 木 金 月 火 水 木 金 朝 一 午 前 午 前 午 後 午 後 デイリースクラム（朝会）：1回15分以内 スプリント計画会議：やる事決め スプリントレビュー：動く物を見せる スプリント(1開発期間)内のMTG ふりかえり（KPT等） • Keep(良い事・続けたい事) • Problem(困っている事・問題) • Try(次のスプリントで取り組む事)
- 期間固定のスプリントを繰り返す 月 火 水 木 金 月 火 水 木 金 前 後 月 火 水 木 金 月 火 水 木 金 前 後 計画して ふりかえる 計画して ふりかえる
- •ライフ系① (2012/08～2012/12) •ライフ系② (2012/08～2013/03) •ゲーム系① (2012/10) •ゲーム系② (2012/11～2013/02) •ゲーム系③ (2014/01～2014/02) •ツール系① (2014/04～2013/07) • その他：社内アジャイル相談窓口 関与したプロジェクト
- ライフ系① – 期間 • 2012/08 ～ 2012/12(約5ヶ月) – 目的 • 「新システム化」の進捗が出ない状況を打開 – 関わった事 • 「新システム化」プロジェクトへのスクラム導入支援 – 概要 • 後述の「ライフ系②」と同時期に開始 • 開発以外の人員を巻き込めず、プロダクトオーナー不在 • RedmineのBacklogsプラグインを利用した プロダクトバックログの管理
- Keep – はじめてのScrum。何はともあれ最初の一歩 – 「Scrumやってみたい」と声を掛けてもらえた – 他部署との交流が出来た事 Problem – プロダクトオーナーを立てずに始めてしまった • 「なんちゃってプロダクトオーナー」危険 – 「Scrum」というよりは「Scrumごっこ」 • 僕自身が、ひとつひとつの判断に自信を持てなかった – 最後には、それ以前のスタイルに戻す事となった
- ライフ系② – 期間 • 2012/08 ～ 2013/03(約8ヶ月) – 目的 • 「新システム化」の進捗が出ない状況を打開 – 関わった事 • スクラムマスターとしてプロジェクトへ横断参加 – 概要 • 開始当初はプロダクトオーナー不在 • 開発3ラインの内、2ラインを独立したバックログで管理 • 後半においては、部長をプロダクトオーナーとして 巻き込む流れを作る事が出来た
- Keep – 写真で記録を残し始めた – 「○○だと思います」→「○○です」の言い切り – タスクかんばん、バーンダウンチャートの利用 – 複数ラインの状況をまとめて見える化 – 共有PCを利用したコードレビュー、ふりかえり – 新規参加メンバーも早期に業務の流れを理解 Problem – 開発メンバーの兼務により、リズムが不安定に
- ゲーム系① – 期間 • 2012/10(約1ヶ月) – 目的 • 「うまく行っていない状態」の打開 – 関わった事 • 「プロジェクトふりかえり」の実施 • 「タスクかんばん」の作成・運用・横展開 – 概要 • ヒアリングの結果、「Scrumは不向き」と判断 • 「業務の見える化」「コミュニケーション増加」に 狙いを定め、「タスクかんばん」と「朝会」のみ導入
- 「ヤバい状況が 見えていなかった」 「終始 全員が会社に 残っている感」 遅延をリカバリしたかった！ 「誰でも進捗が見れるように」 「皆で設計」 「継続的なふりかえりの実施」
- Keep – Scrumをオススメしなかった – 本当に必要な最小限に絞り改善のサイクルを作る – 「企画・開発」のタスクをまとめて見える化 – 100円ショップに毎週通うようになった – メンバーによる自律的なカンバンの再構築 Problem – 別フロアのプロジェクトであったため、 足を運ぶ頻度が少なくなってしまった。
- ゲーム系② – 期間 • 2012/11 ～ 2013/02(約4ヶ月) – 目的 • 「ゴールの共有が出来ていない」状況への対処 • 「マイルストーンごとの進捗」を【見える化】したい – 関わった事 • 「見える化」支援 → スクラムマスター – 概要 • リリース2ヶ月前の追い込みからの支援だったため、 当初は「全部入りのScrum」は避ける事を提案 • 途中、メンバーの意向からScrumの形式で進める事に • 最後の時期は、オリジナルのタスク消化手法へと変化
- 1枚=半日 画像素材の 依存関係可視化 オンライン専任
- Keep – グラフィッカー作業もスプリント内に含める – 「最初からプロダクトオーナーがいる」のは初 – プランニングポーカー→SML見積もり – 最後の追い込みの時期には、Scrumをやめた Problem – クライアント側、サーバ側の業務が違い過ぎて 技術者間での作業分担が出来ず、偏りが生まれた
- ゲーム系③ – 期間 • 2014/01 ～ 2014/02(約2ヶ月) – 目的 • 「新規アプリのプロトタイプを2ヶ月以内に作成する」 – 関わった事 • スクラムマスターとしてプロジェクトへ参加 – 概要 • プロダクトオーナーがScrumに明るい状態 • グラフィッカーが別拠点にいる関係で、画像素材の 仕様や納品に関わる各種コストが増大 →週1回、プロジェクト計画会議の場に直接参加(出張) • 2ヶ月が経過したタイミングで、開発メンバー全員が 別拠点へ → 現地スクラムマスターへと引き継ぎ
- Keep – グラフィッカー内でもプランニングポーカー – 自信を持ってツールをオススメ出来るようになった – 「すごく開発に集中出来る」と言ってもらえた Problem – 本業が多忙であったため、朝会にあまり出られず – プロトタイプの完成を見届ける前にチームを離れる
- ツール系① – 期間 • 2014/04 ～ 2014/07 (約4ヶ月) – 目的 • 「我流スクラム」を見なおし、更なる成果に繋げたい – 関わった事 • スクラムマスターとしてプロジェクトへ参加 – 概要 • 「既存運用」と「新規開発」が並行する現場で、 双方のバランスを調整しながらのスプリント計画 • スマホネイティブアプリ開発者不足をカバーすべく、 各スプリント内で徐々にネイティブ開発タスクを分担
- Keep – コンテンツ量産用の独自カンバンを作成 – ホワイトボード上で「すべての状態を見える化」 • 複数あった進捗管理（xlsx等）を排除。脱属人化 – スクラムマスターとして立ち回れるメンバーの育成 – 気が付いたら、だいたいの事をアドバイス可能に Problem – 計画会議、ふりかえり等での温度差 – 社内の異動に伴い、プロジェクトを離れる事に
- • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- Keep –コミュニケーション量が非常に活発になった –「誰が何をやっているのか不明」が激減 –「他人の実装が分からない」が激減 –メンバーからの「自発的な改善提案」が増加 –早期でのリスク回避（バーンダウンの利用） –開発者以外へも「見える化」ツールが展開 –プロトタイプアプリの開発にも親和性が高い –デジタルツール、アナログツールの使い分け
- Scrumの 各場面で Redmineを 活用
- デジタルツールで すぐに出来ない事は アナログを積極利用
- ソフトウェアを 利用しない 「見える化」や 「共同所有」は容易
- Problem –「仮想プロダクトオーナー」は危険 –ボトムアップ型での導入には注意 –余力の無いプロジェクトでは 「改善」が進みにくい –「完了の定義」を明確にしないと、 いつまでも同じタスクが終わらない –毎日リリースの運用においては、 「計画→実行→レビュー」が機能し辛い –「Scrum」はあくまでもツール
- Try – スクラムを実施する場合、プロダクトオーナーの 協力を事前に得た上で、皆で学習しながら進める – 導入についての相談をされた際には、 ビジネス的な価値への貢献を説明すると共に、 「チームの早期成長・改善」に意識を向けてもらう – 「スクラムはフレームワークに過ぎない」事を 常に意識のどこかに置いておく – 「完了の定義」が明確に出来るような仕組みづくり
- 正直な所 まだまだ 経験不足
- 今日の結論
- 【Agileごっこ】 から始めても いいじゃない。 だけど、 やめんな。
- 上手く行かなかったり 明らかに失敗するような 場面もある。 でも、 やめんな。
- まね事から始めた僕でも 3年経ってみたら そこそこの経験値 だから、 やめんな。
- 最後に宣伝
- 仕様の変化で 納期に影響が… 頻繁なリリースでバグる… 同じチームなんだけど あの人とあんまり 話さない… 意欲にバラつき 信頼？フェイス・トゥ・フェイス 行き当たりばったり 設計？何それ？ 管理ツラい 成長を感じない…
- 要求の変化を歓迎 短い時間間隔でリリース ビジネスの人と開発者が 日々一緒に働く 意欲に満ちた人々 信頼 フェイス・トゥ・フェイス 持続可能な開発 優れた設計 自己組織的 定期的な振り返り
- 自分たちの手で 変えてみよう
- 実は 弊社だと 大体できてる
- 興味を持った方は エイチーム 採用
- 以上です ありがとうございました
Advertisement