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 MIYAZAKI
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
310
Agile Japan 2017 サテライト沖縄 / AgileJapan2017 OKINAWA
tsaito
1
820
2017 年アジャイル事業部 年始のご挨拶 LT / 2017 New Year's greetings
tsaito
0
1.1k
Other Decks in Technology
See All in Technology
チームでロジカルシンキングに改めて向き合っている話 〜学習環境と実践⽅法〜
sansantech
PRO
3
2.6k
SIEMを用いて、セキュリティログ分析の可視化と分析を実現し、PDCAサイクルを回してみた
coconala_engineer
0
330
ServiceNow Knowledge Learning Rise up
manarobot
0
210
一生覚えておきたい「システム開発=コミュニケーション」〜初めての実務案件振り返りLT〜
maimyyym
1
160
DMM.com アルファ室採用案内資料
hsugita
1
160
require(ESM)とECMAScript仕様
uhyo
3
770
生成AIの変革の時代に、直近1年で直面した課題とその解決策
ktc_wada
0
310
プロンプトエンジニアリングでがんばらない-Agentic Workflow へ-近藤憲児
kenjikondobai
3
860
地理空間データ可視化・解析・活用ソリューション Pacific Spatial Solutions (PSS)
pacificspatialsolutions
0
290
GraphQL 成熟度モデルの紹介と、プロダクトに当てはめた事例 / GraphQL maturity model
mh4gf
7
1.3k
家族アルバム みてねにおけるGrafana活用術 / Grafana Meetup Japan Vol.1 LT
isaoshimizu
1
770
AOAI をきっかけに 社内の Azure 管理を見直した話
recruitengineers
PRO
1
300
Featured
See All Featured
Teambox: Starting and Learning
jrom
128
8.4k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
7
1k
A designer walks into a library…
pauljervisheath
200
23k
Practical Orchestrator
shlominoach
182
9.7k
Mobile First: as difficult as doing things right
swwweet
216
8.6k
Embracing the Ebb and Flow
colly
80
4.1k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
125
32k
Done Done
chrislema
178
15k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
227
16k
Designing for Performance
lara
601
67k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
20
1.9k
Building Your Own Lightsaber
phodgson
99
5.7k
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 週間
チームに「考えるクセ」がついている
チームに「考えるクセ」がついている ❖ 新しい技術の採用 ❖ 「表示が遅くなってきてない ?」 ➢ サービスが育ってきたが故の悩み ❖ メンテナンスしやすい、よりよい実装の相談
❖ これやってみたい ➢ 勉強会のネタ ❖ ふりかえりのふりかえり
事例は、ここまで
次はあなたの番です !
チームは学び続ける よりよいやり方はないか チームで考え続け よりよい成果を出していきましょう !!!