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
9.9k
小さなチームが始めたアジャイル開発 / small team begun agile movement
BASE BANK株式会社の開発チームで始めたアジャイル開発について話しています。
Kazuki Higashiguchi
June 04, 2020
Tweet
Share
More Decks by Kazuki Higashiguchi
See All by Kazuki Higashiguchi
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.3k
ブラウザ自動操作技術の深層へ、直接触れて学ぶ WebDriver と Chrome DevTools Protocol
hgsgtk
3
6.4k
HTTP Server on random available port in Go
hgsgtk
0
920
Agile Testingを夢見たテスト自動化 〜ATDDへの挑戦から始まる 1年間の試行錯誤〜 / dreaming agile testing at basebank
hgsgtk
14
7.6k
Create Go WebDriver client from scratch
hgsgtk
1
2.1k
PHPでWeb Driver Clientを自作する〜己の手でブラウザ操作自動化を完全理解する方法〜 / phpcon2021
hgsgtk
2
2.4k
振り返りを積み上げて自分たちのプラクティスとして昇華•体得していくための仕組みと考え方 / ScrumFestMikawa2021
hgsgtk
3
2.4k
Other Decks in Technology
See All in Technology
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
430
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
360
SREによる隣接領域への越境とその先の信頼性
shonansurvivors
2
510
Engineer Career Talk
lycorp_recruit_jp
0
110
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
12k
【若手エンジニア応援LT会】ソフトウェアを学んできた私がインフラエンジニアを目指した理由
kazushi_ohata
0
150
元旅行会社の情シス部員が教えるおすすめなre:Inventへの行き方 / What is the most efficient way to re:Invent
naospon
2
330
なぜ今 AI Agent なのか _近藤憲児
kenjikondobai
4
1.3k
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
220
AWS Lambdaと歩んだ“サーバーレス”と今後 #lambda_10years
yoshidashingo
1
170
エンジニア人生の拡張性を高める 「探索型キャリア設計」の提案
tenshoku_draft
1
120
10XにおけるData Contractの導入について: Data Contract事例共有会
10xinc
5
580
Featured
See All Featured
Speed Design
sergeychernyshev
24
610
Building Flexible Design Systems
yeseniaperezcruz
327
38k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
How STYLIGHT went responsive
nonsquared
95
5.2k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Practical Orchestrator
shlominoach
186
10k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Embracing the Ebb and Flow
colly
84
4.5k
Agile that works and the tools we love
rasmusluckow
327
21k
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