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
afbのリニューアル、 3_4ヶ月くらい経ったけど 進捗どうですか?
Search
Forit_tech
October 07, 2022
Programming
1
190
afbのリニューアル、 3_4ヶ月くらい経ったけど 進捗どうですか?
Forit_tech
October 07, 2022
Tweet
Share
More Decks by Forit_tech
See All by Forit_tech
フォーイット_デザイナー向け会社紹介資料_Forit_Company_Profile.pdf
forit_tech
0
270
フォーイット_エンジニア向け会社紹介資料_Forit_Company_Profile.pdf
forit_tech
0
1.5k
Other Decks in Programming
See All in Programming
最新TCAキャッチアップ
0si43
0
140
Contemporary Test Cases
maaretp
0
130
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
110
Better Code Design in PHP
afilina
PRO
0
120
Realtime API 入門
riofujimon
0
150
Jakarta EE meets AI
ivargrimstad
0
600
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
1
100
リアーキテクチャxDDD 1年間の取り組みと進化
hsawaji
1
220
Kaigi on Rails 2024 〜運営の裏側〜
krpk1900
1
200
AWS Lambdaから始まった Serverlessの「熱」とキャリアパス / It started with AWS Lambda Serverless “fever” and career path
seike460
PRO
1
260
Flutterを言い訳にしない!アプリの使い心地改善テクニック5選🔥
kno3a87
1
170
Amazon Bedrock Agentsを用いてアプリ開発してみた!
har1101
0
330
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
28
2k
What's new in Ruby 2.0
geeforr
343
31k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
How to Ace a Technical Interview
jacobian
276
23k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
For a Future-Friendly Web
brad_frost
175
9.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Testing 201, or: Great Expectations
jmmastey
38
7.1k
Transcript
2022/07/29(金) 18:00~18:30 afbのリニューアル、 3~4ヶ月くらい経ったけど 進捗どうですか?
• 今までやってきたこと ◦ 4月、5月、6月、7月 • 目指していたこと ◦ アジャイルについて • わかってきたこと
◦ XPについて ◦ スクラムについて • 今後やっていきたいこと 今日話すこと
今までやってきたこと 〜4月〜 はじまりのMiro@2022/03/29 • ディレクトリ構成 • n対nのフロント、バック(API) 03/28 リニューアル キックオフ
4月にやったこと • アーキテクチャ決定 • バックエンド技術選定 • フロント技術選定 • API(バックエンド)コンテナ準備 •
開発環境爆誕 ずーっとPoC(Proof of Concept) とりあえず作ってみよう 3~8人で1日2~4時間くらい 今までやってきたこと 〜4月〜
今までやってきたこと 〜5月〜 afb_renewalチーム 初めての振り返り@04/28 プロジェクトの スケジュール感があいまい、、、 誰がいつ何をやっているの??? 結局何をどう作ればいいのか、、、 (当時は各自が空き時間に 黙々とやってました)
今までやってきたこと 〜5月〜 • クリーンアーキテクチャの採用 ◦ 18:30から毎日勉強会 • E2Eフレームワーク決定 • テスト戦略決定(TDD)
• アジャイル説明会 • スクラムの本格導入 ◦ スプリント計画 ◦ ユーザーストーリー見積も り ◦ 振り返りの実施 • Discordお試し運用 • フロント技術検証 • 認証/認可基盤、権限定義 • admin機能使用状況調査 • デザインチームロードマップ策定 ←4/28(金) ↓06/03(金)
今までやってきたこと 〜6、7月〜 • 全隊開発開始 ◦ 現在総勢16名 • SREチーム爆誕 ◦ 現在4名
• IntelliJ使用開始 • ドメイン定義 • ストーリー出し • クリーンアーキテクチャ実装 • モブプロ開始 ◦ 2週間くらい、全員で • チーム開発開始 ◦ 3人4チーム • 現在開発中 ◦ Afb API ◦ Auth API ◦ Migrate API
細かい歴史の話をすっ飛ばして 僕が感じたアジャイルの2つの必須条件 • あいまいさを許容すること • コミュニケーションを取りまくること 詳しくは「アジャイルソフトウェア開発宣言」 「アジャイルソフトウェア開発の12の原則」 目指していたこと 〜アジャイルについて〜
XP(Extreme Programming)とは 開発のためのベストプラクティス集 • 計画 • プログラミング • 全員同席 •
インテグレーション ざっくりこんなカテゴリ 取捨選別は結構自由 「単独でもワークするけど、組み合わせた方 がもっとワークするよ」的なスタンス わかってきたこと 〜XPについて〜 afb_renewalでは 主に以下を採用 • ユーザーストーリー • 週次サイクル • ペアプロ • テストファースト • CI(継続的インテグレーション) • チーム主体
わかってきたこと 〜XPについて〜 治療と予防と健診 治療:バグの早期発見、改修 検査:TDD、E2E、CI 予防:クリーンアーキテクチャ リファクタリング、ペアプロ 大切なのは、循環すること
スクラム(Scrum)とは、組織のための ベストプラクティス集 • 役割 • アクティビティ • 作成物 • ルール
ざっくりこんな感じのカテゴリ 「どれかだけやってもあんま意味ないから、で きたら全部やった方がいいよ」なスタンス わかってきたこと 〜スクラムについて〜 afb_renewalでは 以下はまだできていない • スプリントレビュー • バックログリファインメント • 「完了」(リリース可能)の定義 →すべてプロダクトオーナーとの 協働が必要
スクラムマスターって何やってん の? →実際僕もよくわかんないです とりあえず1日、1週間がすぐ終わる わかってきたこと 〜スクラムについて〜 スクラムマスターとは 何ではないのか? • 開発者でありません
• マネージャーではありません • 秘書ではありません • プロダクトオーナーではありま せん
僕のイメージ マネージャー=キャプテン わかってきたこと 〜スクラムについて〜 スクラムマスター =(部活や芸能人の)マネージャー
よくある地獄 わかってきたこと 〜スクラムについて〜 マネージャー(中間管理職)パターン • 上司と現場で言ってることが違う • そもそも上司と現場の仲が悪い • マネージャーが上司の要望、現場の意
見、新人の面倒の三重苦に陥る • 結果マネージャーはコードを書く時間 が1ミリもなくなる • なのに、ベテランになるほどマネージ ャーにならければいけない • そしてマネージャーが辞めていく... 上司 現場 新人 マネージャー
• スクラム(チーム)については、すべて スクラムマスターが責任を持つ • それぞれ役割と、スクラムマスターで 調整を行う マネージャーというか、鞄持ちというか、 御用聞きというか、雑用係というか サーバントリーダーというか →肩書きなんてなんでもよくて、チームがワ
ークすればなんでもいい! わかってきたこと 〜スクラムについて〜 スクラム プロダクト オーナー 開発者 新人 スクラムマスター ペア
最近思った仮説 「優れたアーキテクチャと優れた組織 はまったく同じである」
コンウェイの法則 「組織の設計するシステムには... その組織のコミュニケーション構造を そのまま反映した設計になる制約がある」 という経験則というか格言
優れたアーキテクチャと優れた組織 治療と予防と健診 大切なのは循環すること 治療:バグの早期発見、改修 検査:TDD、E2E、CI 予防:クリーンアーキテクチャ リファクタリング、ペアプロ プロダクト オーナー 開発者
スクラムマスター 新人 治療: スプリントレビュー 予防: 1on1、振り返り 検査: スプリント計画 リファインメント
• あいまいさを許容すること • コミュニケーションを取りまくること 大切なのはバグがないこと、問題が起きないことではなく • システムによってバグを発見し、容易に修正できること • 仕組みによって問題を発見し、容易に解決できること 目指していたこと
〜アジャイルについて〜
• 認証認可基盤(Auth API) • レガシー(現行)adminからモダン(リニューアル)afbへのデータ移行(Migrate API) • ビジネスサイドとの密なコミュニケーション ◦ プロダクトオーナーの巻き込み
◦ ステークホルダーの要求ヒアリング ◦ スプリントレビューの実施 ◦ スプリント計画、1部&2部制度 • デザインチームとの密なコミュニケーション • ベロシティからの開発見込みの逆算 ◦ スコープ、完了条件をどこに設定するか • 大規模スクラムへの移行、LeSS、S@S、SAFe • チームの細分化、ローテーション、ロールチェンジ • 振り返りの振り返り 今後やっていきたいこと