Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AgileJapan2016 サテライト宮崎(公開版)/agilejapan2016 MIYA...
Search
t-saito
July 27, 2016
Technology
0
280
AgileJapan2016 サテライト宮崎(公開版)/agilejapan2016 MIYAZAKI
非公開部分を削除するなど、当日発表と一部異なる部分があります
t-saito
July 27, 2016
Tweet
Share
More Decks by t-saito
See All by t-saito
2019 アジャイル事業部 新年度のご挨拶 / FY 2019 greetings
tsaito
0
400
Agile Japan 2017 サテライト沖縄 / AgileJapan2017 OKINAWA
tsaito
1
940
2017 年アジャイル事業部 年始のご挨拶 LT / 2017 New Year's greetings
tsaito
0
1.3k
Other Decks in Technology
See All in Technology
AWS Summit Japan 2025 Community Stage - App workflow automation by AWS Step Functions
matsuihidetoshi
1
310
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
2
3k
Lazy application authentication with Tailscale
bluehatbrit
0
120
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
1
1.3k
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
220
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
2
3.8k
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
230
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
390
SpringBoot x TestContainerで実現するポータブル自動結合テスト
demaecan
0
130
AWS認定を取る中で感じたこと
siromi
1
110
Node-RED × MCP 勉強会 vol.1
1ftseabass
PRO
0
180
CI/CD/IaC 久々に0から環境を作ったらこうなりました
kaz29
1
200
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Docker and Python
trallard
44
3.5k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
940
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Building Applications with DynamoDB
mza
95
6.5k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
53k
Done Done
chrislema
184
16k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Transcript
こうしています ! 現場でのアジャイル開発 (公開版) 株式会社 永和システムマネジメント 齋藤 崇 at AgileJapan
2016 サテライト 宮崎 2016/07/13
アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編(顧客要望からデプロイまで) ➢ ツール編 ❖
事例 ➢ ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ アジャイル開発をさらにアジャイルに変える
永和システムマネジメント (ESM) ❖ 1980 年 創業 ❖ 本社:福井県 ❖ 東京支社
❖ 沖縄事務所 (Google Map)
None
None
Who am I ? 齋藤 崇(さいとう たかし) ❖ アジャイル事業部 所属
❖ プログラマ、現場リーダ ❖ 業務システムの受託開発を長く担当 ❖ Ruby, Rails エンジニア
アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編(顧客要望からデプロイまで) ➢ ツール編 ❖
事例 ➢ ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ アジャイル開発をさらにアジャイルに変える
スライドを切り替えます
アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編(顧客要望からデプロイまで) ➢ ツール編 ❖
事例 ➢ ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ アジャイル開発をさらにアジャイルに変える
永和流 ❖ 取り組んで 9 年余り ❖ 試行錯誤の結果 ➢ eXtream Programming
➢ Scrum ➢ … and MORE ❖ お客様とご相談の上、適宜 アレンジ 出典:Version One 社 10th Annual State of Agile
None
None
None
要求をバックログに ❖ プロダクトオーナーに作成してもらう ❖ ユーザーストーリー形式 ➢ <誰>として ➢ <何>がしたい ➢
<なぜなら>だからだ ❖ 受け入れ基準も書く ❖ 優先順位をつけておく
None
タスクに分割 ❖ 計画ミーティング(イテレーション計画会)の一部として実施 ❖ プロダクトオーナー:開発メンバへバックログ(要件)を説明 ❖ 開発メンバ:必要な作業へ落とし込み、見積もり ❖ 見積もり結果とこれまでの作業実績から、今イテレーションの作業範囲をプロダ クトオーナーと合意する
None
プログラミング ❖ テストコードも併せて実装 ❖ ペアプログラミング ❖ テスト駆動開発 (TDD) ❖ コードレビュー ❖
リポジトリへのコミットをトリガとして、ビルドとテスト実施(継続的 インテグレーション、CI)
None
受け入れテストを書く ❖ バックログの受け入れ基準をテストコードとして実装する ❖ テストコードとして実装しておくことで CI 時にテストできる
None
受け入れテストをする ❖ レビュー会でのプロダクトオーナーによるジャッジ ❖ デモを行い、プロダクトオーナーが Accept/Reject を判断 ❖ 単なる OK/NG
ではなく、フィードバックが得られる重要な場 ➢ フィードバックから生まれたアイデアがバックログとなることも
None
リリース可能なソフトウェア ❖ 製品戦略によっては内部リリースとして扱う ❖ 「いつでもリリースできる状態にある」ことが重要
None
ふりかえり ❖ よかったこと ❖ もっとよくできそうなこと ❖ 困っていること ❖ 心配していること ❖
カイゼンとしてのアクション ❖ やってみたいこと
None
次のイテレーションへ ❖ 優先順位に変動はないか ? ❖ 新たな要求はないか ?
アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編(顧客要望からデプロイまで) ➢ ツール編 ❖
事例 ➢ ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ アジャイル開発をさらにアジャイルに変える
❖ バージョン管理: Git (Git ホスティング:GitHub) ❖ バックログ/タスク管理: ➢ Pivotal Tracker
➢ Waffle.io ❖ カンバン ❖ Wiki: GitHub ❖ キャスター付ホワイトボード ❖ 付箋(強粘着だとなお良い)
❖ CI ➢ Circle CI ➢ Travis CI ❖ チャット
➢ Idobata.io ➢ appear.in ➢ Google ハングアウト ➢ Skype
アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編(顧客要望からデプロイまで) ➢ ツール編 ❖
事例 ➢ 1. ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ 2. アジャイル開発をさらにアジャイルに変える
事例 1. ❖ 会社方針としてアジャイル開発を導入、推進していく ❖ ジョイン時点でフルタイムで動けるメンバは 4 名 ❖ サービスローンチまで
1.5 ヶ月 ➢ 社内外との連携の都合上、日程調整は NG
不慣れな手法で進める ? ❖ かえってリスクとなる、と判断 ❖ 必要最低限の機能に絞り込んで開発 ❖ ウォーターフォール的に開発
前進あるのみ なかなか終わりがみえない 開発リズムがつかめない やっぱり、ここはこうしたい これいらなくなりました これは入れたい
無事、ローンチできたけど ❖ 仕様を最初に詰め切れない ❖ 要件や優先度も 1 週間後には変わっている ❖ プロジェクトの進め方をふりかえれていない(カイゼンできていない) ❖
あらためて「アジャイル開発でいこう!」
導入してみて ❖ スプリント終了時には何かしら動くものがある、という安心感 ❖ 作業にリズム ❖ 開発メンバが活発に発言するようになった ❖ 他プロジェクトから見学の申し込みも
アジェンダ ❖ アジャイル開発プロセスの基礎知識 ❖ 永和流アジャイル開発 ➢ 進め方編(顧客要望からデプロイまで) ➢ ツール編 ❖
事例 ➢ 1. ウォーターフォールで始めたプロジェクトをアジャイルに変える ➢ 2. アジャイル開発をさらにアジャイルに変える
事例 2. ❖ 開発メンバ(のべ)15 名 ❖ 3 チーム構成 ❖ アジャイル開発導入
1.5 年 ❖ 1 イテレーション 2 週間
チームに「考えるクセ」がついている
チームに「考えるクセ」がついている ❖ 新しい技術の採用 ❖ 「表示が遅くなってきてない ?」 ➢ サービスが育ってきたが故の悩み ❖ メンテナンスしやすい、よりよい実装の相談
❖ これやってみたい ➢ 勉強会のネタ ❖ ふりかえりのふりかえり
事例は、ここまで
次はあなたの番です !
チームは学び続ける よりよいやり方はないか チームで考え続け よりよい成果を出していきましょう !!!