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
小さなチームが始めたアジャイル開発 / small team begun agile move...
Search
Kazuki Higashiguchi
June 04, 2020
Technology
3
10k
小さなチームが始めたアジャイル開発 / small team begun agile movement
BASE BANK株式会社の開発チームで始めたアジャイル開発について話しています。
Kazuki Higashiguchi
June 04, 2020
Tweet
Share
More Decks by Kazuki Higashiguchi
See All by Kazuki Higashiguchi
インフラコストとセキュリティ課題解決のためのリアーキテクチャリング / srekaigi2025
hgsgtk
3
4.3k
Design of a Stateful system for Robust Deployment and Observability
hgsgtk
0
1.2k
A guide to joining operational work in your new DevOps team
hgsgtk
1
1.3k
HTTP Tunneling in Go
hgsgtk
0
1.4k
ブラウザ自動操作技術の深層へ、直接触れて学ぶ WebDriver と Chrome DevTools Protocol
hgsgtk
3
6.5k
HTTP Server on random available port in Go
hgsgtk
0
970
Agile Testingを夢見たテスト自動化 〜ATDDへの挑戦から始まる 1年間の試行錯誤〜 / dreaming agile testing at basebank
hgsgtk
14
7.7k
Create Go WebDriver client from scratch
hgsgtk
1
2.2k
PHPでWeb Driver Clientを自作する〜己の手でブラウザ操作自動化を完全理解する方法〜 / phpcon2021
hgsgtk
2
2.5k
Other Decks in Technology
See All in Technology
Microsoft Ignite 2024 最新情報!Microsoft 365 Agents SDK 概要 / Microsoft Ignite 2024 latest news Microsoft 365 Agents SDK overview
karamem0
0
190
あなたはJVMの気持ちを理解できるか?
skrb
5
2k
Amazon Location Serviceを使ってラーメンマップを作る
ryder472
2
160
extensionとschema
yahonda
1
100
パフォーマンスとコスト改善のために法人データ分析基盤をBigQueryに移行した話
seiya303
1
100
論文紹介 ”Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG” @GDG Tokyo
shukob
0
270
インシデントキーメトリクスによるインシデント対応の改善 / Improving Incident Response using Incident Key Metrics
nari_ex
0
4.1k
第27回クラウド女子会 ~re:Invent 振り返りLT会~ 宣言型ポリシー、使ってみたらこうだった!
itkr2305
0
290
Power BI は、レポート テーマにこだわろう!テーマのティア表付き
ohata_ds
0
120
例外処理を理解して、設計段階からエラーを「見つけやすく」「起こりにくく」する
kajitack
12
3.8k
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
120k
Skip Skip Run Run Run ♫
temoki
0
360
Featured
See All Featured
Being A Developer After 40
akosma
89
590k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
192
16k
Unsuck your backbone
ammeep
669
57k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Optimising Largest Contentful Paint
csswizardry
33
3k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
Transcript
None
“あれから14年が経ち、私たちは行き先を見失っています。 ”アジャイル”という言葉はスローガン化し てしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまっ たとすら言えます。 といった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重 ねるといった、口先だけのアジャイルの狂信者がたくさんいるのです。 ” https://postd.cc/the-failure-of-agile/ アジャイルの破綻―原因、そして新たな提案 (”The
Failure of Agile” の翻訳)
“初心者がこれに対応する唯一の方法は、コンテキストのない簡単なルールに従うことです。例えば、「これが起こったら、あれ をする」といったようなルールです。ご丁寧なことに、アジャイル開発手法には初心者用にいくつかの具体的なプラクティスが提 供されているため、 彼らは、アジャイルの原則やアジャイル宣言の概要を尊重することなく、鉄則となっているプラクティスを入手するだけで、それ 以上何もしないのです。 ” https://postd.cc/the-failure-of-agile/ アジャイルの破綻―原因、そして新たな提案 (”The Failure
of Agile” の翻訳)
• チーム開発について考える際に、「アジャイル開発」のエッセンスを取り入れ ることは、思いつきがちだろう • しかし、 なことは、The Failure of Agile でも示されている
• 様々な現場で実践されている分、 だろう • そんな今、アジャイル開発を始めるために役に立つのは、正誤あるにしろ、 の事例ではないか
• • • • ◦
None
※ 2020年6月4日時点
• 資金調達サービス「YELL BANK」など金融サービス (機能)を開発・運用 • から、稼働中サービスの など • 半 (backend/infra/frontend
...etc) ※ 適宜他チームと協同しながら ※ サービス実現のためのカバー範囲を広げていく方向へ お急ぎ振込 お急ぎ振込
https://www.oreilly.co.jp/books/9784873119090/ Matt LeMay 著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳、及川 卓也 まえがき みんなでアジャイル ――
変化に対応できる顧客中心組織のつくりかた “成功するアジャイルの適用は、常に厳しく正直に現状を見ることから 始まる。何がうまくいっていて、何がうまくいっていないのか。アジャイ ルを今の仕事のやり方をちょっと変えるだけのことと思っているなら、 アジャイルから得られるメリットもちょっとだけになるだろう。” (2章 自分たちの北極星を見つける)
None
fukabori.fm 32. みんなでアジャイル w/ ryuzee https://podplayer.net/?id=104223290 季節が移り変わっても北極星の位置が変わらないように、状況 が変わり時間が経っても変わらない、自分たちが大事にしたい ・目指したい目標。
社内Docに怪文書を投げかけ チームで議論したり
そのために次のことを取り組む • 個々人の納得感と達成感のあるマイルストーン • 重要マイルストーンに対するブレークダウンと見積もりの 継続的評価 ※ 2020/6/4時点 (成果を出せている感覚) (関係各所に宣言し、PJの現在地点を適宜振り返り、その状況を適切に共有する)
※ まだ文章としては正確な表現になっていない気もしています
• COVID-19 の感染拡大防止による WFH の開始 • WFHでのプロジェクト遂行については、 • になりがちな潜在課題
「組織の構成要素は人ではない! 」 渡邉 信光 / https://b-p-i-a.com/?p=709 “経営学者チェスター・バーナードが述べた3要素 1. 共通の「ゴール」(共通目的) 2. 協働意欲
3. コミュニケーション” 改めて、これらの要素にしっかり向き合う必要性が高まっていた
None
“プロセスやツールよりも を、 包括的なドキュメントよりも を、 契約交渉よりも を、 計画に従うことよりも を” Manifesto for
Agile Software Development / https://agilemanifesto.org/
“アジャイルチームの基本的な仕事の進め方 ” https://book.mynavi.jp/ec/products/detail/id=22141 Mike Cohn 著 安井 力、角谷信太郎 訳 /
アジャイルな見積りと計画づくり 価値あるソフト ウェアを育てる概念と技法
• 仕事の進め方は、 に大きく寄与する • は、関係各所との に寄与する • 方針は、 にマッチしそう
• 「アジャイル開発をしましょう」 • アジャイル開発がやりたいわけではなくて、チーム課題を解決 したい •
None
自分たちの優先度に沿って、「まずこれを始めよう」とピックアップして始めた • イテレーション(スプリント) • スプリントレビュー • ストーリーポイント ※ 既に実施していたこと •
デイリースタンディング • プランニングポーカー
• ◦ エンドユーザーに実際に届ける粒度 • ◦ このくらいの期間に「ここまでいければ」というまとまり ◦ プロジェクトごとに適応した形で設定しようと試みている ◦ ex.
画面リニューアルPJ => n回のイテレーションで実現したい ユーザーストーリー を設定 • ◦ 現在は 1 week で設定している ◦ 最初はフィードバックを回すために 2 days を小さくやってみ た
Sprint Review
• カンバンには、 を利用 • 課題解決スコープをあくまで (ビジネス的なIssueについては 対象外へ) ◦ 「 」精神
◦ そのため、Developerの使い勝手などを重視 • ストーリーポイントの可視化は、 というブラウ ザ拡張を利用 ◦ https://github.com/banyan/github-story-points
• banyan/github-story-points では、[1pt] とissue/pr/cardのタイトルに設定 することで、ストーリーポイントとして可視化する • 毎イテレーションごとにレーンを残して消化ポイントを記録、のちのベロシ ティ計測へ活かす
• アジャイルでは、フェーズは基本的には設けないが、モデリングなど薄い フェーズを設けることはある • プロジェクトによっては、既存コードの確認・大まかなプロト的実装による 「どのような要素があるか」・「それぞれのIssueになるうるものの大きさはな にか」について • ちょうど新しいメンバーの方に来ていただいたタイミングもあり、 としても設定
https://www.oreilly.co.jp/books/9784873119090/ Matt LeMay 著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳、及川 卓也 まえがき みんなでアジャイル ――
変化に対応できる顧客中心組織のつくりかた 2. 組織の個人は、自分のチームやサイロの居心地のよさのなかでいちばん簡単に 完了できる仕事を優先する。 3. 進行中のプロジェクトは、プロジェクトを承認した最上位者の決定がない限り 続く。
• イテレーション中に発生した、問い合わせ対応やバグフィックスは、 • 「チームの速度の阻害要因」と捉えてしまわないように • 当初の計画に大きな支障がでたら、そのスプリントレビューで対策を考える方 向にしている(今のところは顕在化していない)
• スプリント期間終了時に、振り返りを行う • 複数PJ横断するチームにおけるスプリントレビューの主目的を定義 ◦ はとにかく大事にする ◦ 自分たちにとってのなぜ: プロジェクト終了毎じゃなくて して、チームと
して強くなっていこうぜ”
• 毎回KPTをする ◦ ツールに や を使用、オンラインでのホワイトボードとしてうまく ワークしてる • その中でマイルストーンの見直しや解像度の高まりを計画に反映 •
(これから)プロダクトの成果に対するフィードバックループを構築する必要性もPJに よっては感じている ◦ → 必要なPJに対して取り組んでいく
None
期間・規模が大きいPJ中盤で中だるみ PdMが開発Directionまでやっているが、 そろそろ厳しい(特定ロールの負荷) PJメンバー間の仕様や状況の認識ブレ 良くも悪くも、個人の馬力でリリースス ケジュールを実現している ロールと個人が疎結合になり、個人がボトルネックにな りにくくなった
まだ、よちよち歩きだが、概ね打ち手として機能しようとしてい る (後日談: この資料のレビューを通して、改めて「うまくいけてるか?」という議論に なった。 )
• 、目指す方向を定め、それとアジャイル宣言・ 原則は同じ方向を向いていることを確認した • ことで、いま自分たちがやっていることはうま くできているか、について • 必要なことを最小限に行う発想、手法の実施アプローチとして は といえるのでは
• WFHの状況において、 に は、コミュニケーションを武器にするアジャイル開発は上手くハマった • オンラインでのKPTでの共同ワークは、ドメインモデリングなど
• チーム開発にてアジャイルを取り入れるにあたり、現場で「どう考え たか」という思考プロセス、をお伝えした • 現場でチーム開発を考えている人に役立てば幸い
• アジャイルの破綻―原因、そして新たな提案 (”The Failure of Agile” の翻訳) ◦ https://postd.cc/the-failure-of-agile/ •
Matt LeMay 著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳、及川 卓也 まえがき / みんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた ◦ https://www.oreilly.co.jp/books/9784873119090/ • Manifesto for Agile Software Development ◦ https://agilemanifesto.org/ • fukabori.fm 32. みんなでアジャイル w/ ryuzee ◦ https://podplayer.net/?id=104223290 • Mike Cohn 著 安井 力、角谷信太郎 訳 / アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技 法 ◦ https://book.mynavi.jp/ec/products/detail/id=22141 • 「組織の構成要素は人ではない! 」 渡邉 信光 ◦ https://b-p-i-a.com/?p=709