AgileJapan2016 サテライト宮崎（公開版）/agilejapan2016 MIYAZAKI

非公開部分を削除するなど、当日発表と一部異なる部分があります

Transcript

1. こうしています ! 現場でのアジャイル開発 （公開版） 株式会社 永和システムマネジメント 齋藤 崇 at AgileJapan 2016 サテライト 宮崎 2016/07/13
2. アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編（顧客要望からデプロイまで） ➢ ツール編 ❖ 事例 ➢ ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ アジャイル開発をさらにアジャイルに変える
3. 永和システムマネジメント (ESM) ❖ 1980 年 創業 ❖ 本社：福井県 ❖ 東京支社 ❖ 沖縄事務所 （Google Map）
6. Who am I ? 齋藤 崇（さいとう たかし） ❖ アジャイル事業部 所属 ❖ プログラマ、現場リーダ ❖ 業務システムの受託開発を長く担当 ❖ Ruby, Rails エンジニア
7. アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編（顧客要望からデプロイまで） ➢ ツール編 ❖ 事例 ➢ ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ アジャイル開発をさらにアジャイルに変える
8. スライドを切り替えます
9. アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編（顧客要望からデプロイまで） ➢ ツール編 ❖ 事例 ➢ ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ アジャイル開発をさらにアジャイルに変える
10. 永和流 ❖ 取り組んで 9 年余り ❖ 試行錯誤の結果 ➢ eXtream Programming ➢ Scrum ➢ … and MORE ❖ お客様とご相談の上、適宜 アレンジ 出典：Version One 社 10th Annual State of Agile
14. 要求をバックログに ❖ プロダクトオーナーに作成してもらう ❖ ユーザーストーリー形式 ➢ ＜誰＞として ➢ ＜何＞がしたい ➢ ＜なぜなら＞だからだ ❖ 受け入れ基準も書く ❖ 優先順位をつけておく
16. タスクに分割 ❖ 計画ミーティング（イテレーション計画会）の一部として実施 ❖ プロダクトオーナー：開発メンバへバックログ（要件）を説明 ❖ 開発メンバ：必要な作業へ落とし込み、見積もり ❖ 見積もり結果とこれまでの作業実績から、今イテレーションの作業範囲をプロダ クトオーナーと合意する
18. プログラミング ❖ テストコードも併せて実装 ❖ ペアプログラミング ❖ テスト駆動開発　(TDD) ❖ コードレビュー ❖ リポジトリへのコミットをトリガとして、ビルドとテスト実施（継続的 インテグレーション、CI）
20. 受け入れテストを書く ❖ バックログの受け入れ基準をテストコードとして実装する ❖ テストコードとして実装しておくことで CI 時にテストできる
22. 受け入れテストをする ❖ レビュー会でのプロダクトオーナーによるジャッジ ❖ デモを行い、プロダクトオーナーが Accept/Reject を判断 ❖ 単なる OK/NG ではなく、フィードバックが得られる重要な場 ➢ フィードバックから生まれたアイデアがバックログとなることも
24. リリース可能なソフトウェア ❖ 製品戦略によっては内部リリースとして扱う ❖ 「いつでもリリースできる状態にある」ことが重要
26. ふりかえり ❖ よかったこと ❖ もっとよくできそうなこと ❖ 困っていること ❖ 心配していること ❖ カイゼンとしてのアクション ❖ やってみたいこと
28. 次のイテレーションへ ❖ 優先順位に変動はないか ? ❖ 新たな要求はないか ?
29. アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編（顧客要望からデプロイまで） ➢ ツール編 ❖ 事例 ➢ ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ アジャイル開発をさらにアジャイルに変える
30. ❖ バージョン管理： Git (Git ホスティング：GitHub) ❖ バックログ/タスク管理： ➢ Pivotal Tracker ➢ Waffle.io ❖ カンバン ❖ Wiki: GitHub ❖ キャスター付ホワイトボード ❖ 付箋（強粘着だとなお良い）
31. ❖ CI ➢ Circle CI ➢ Travis CI ❖ チャット ➢ Idobata.io ➢ appear.in ➢ Google ハングアウト ➢ Skype
32. アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編（顧客要望からデプロイまで） ➢ ツール編 ❖ 事例 ➢ 1. ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ 2. アジャイル開発をさらにアジャイルに変える
33. 事例 1. ❖ 会社方針としてアジャイル開発を導入、推進していく ❖ ジョイン時点でフルタイムで動けるメンバは 4 名 ❖ サービスローンチまで 1.5 ヶ月 ➢ 社内外との連携の都合上、日程調整は NG
34. 不慣れな手法で進める ? ❖ かえってリスクとなる、と判断 ❖ 必要最低限の機能に絞り込んで開発 ❖ ウォーターフォール的に開発
35. 前進あるのみ なかなか終わりがみえない 開発リズムがつかめない やっぱり、ここはこうしたい これいらなくなりました これは入れたい
36. 無事、ローンチできたけど ❖ 仕様を最初に詰め切れない ❖ 要件や優先度も 1 週間後には変わっている ❖ プロジェクトの進め方をふりかえれていない（カイゼンできていない） ❖ あらためて「アジャイル開発でいこう！」
37. 導入してみて ❖ スプリント終了時には何かしら動くものがある、という安心感 ❖ 作業にリズム ❖ 開発メンバが活発に発言するようになった ❖ 他プロジェクトから見学の申し込みも
38. アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編（顧客要望からデプロイまで） ➢ ツール編 ❖ 事例 ➢ 1. ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ 2. アジャイル開発をさらにアジャイルに変える
39. 事例 2. ❖ 開発メンバ（のべ）15 名 ❖ 3 チーム構成 ❖ アジャイル開発導入 1.5 年 ❖ 1 イテレーション 2 週間
40. チームに「考えるクセ」がついている
41. チームに「考えるクセ」がついている ❖ 新しい技術の採用 ❖ 「表示が遅くなってきてない ?」 ➢ サービスが育ってきたが故の悩み ❖ メンテナンスしやすい、よりよい実装の相談 ❖ これやってみたい ➢ 勉強会のネタ ❖ ふりかえりのふりかえり
42. 事例は、ここまで
43. 次はあなたの番です !
44. チームは学び続ける よりよいやり方はないか チームで考え続け よりよい成果を出していきましょう !!!