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
230
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
1
2k
フォーイット_デザイナー向け会社紹介資料_Forit_Company_Profile.pdf
forit_tech
0
330
Other Decks in Programming
See All in Programming
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
20
3.7k
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
320
LINEヤフー データグループ紹介
lycorp_recruit_jp
0
990
PicoRuby on Rails
makicamel
2
110
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
160
データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7
y_ken
0
320
Result型で“失敗”を型にするPHPコードの書き方
kajitack
4
500
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.6k
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
110
C++20 射影変換
faithandbrave
0
540
Benchmark
sysong
0
270
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
200
Featured
See All Featured
Facilitating Awesome Meetings
lara
54
6.4k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Become a Pro
speakerdeck
PRO
28
5.4k
Writing Fast Ruby
sferik
628
62k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
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 • チームの細分化、ローテーション、ロールチェンジ • 振り返りの振り返り 今後やっていきたいこと