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
180
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
54
フォーイット_エンジニア向け会社紹介資料_Forit_Company_Profile.pdf
forit_tech
0
910
Other Decks in Programming
See All in Programming
R言語の環境構築と基礎 Tokyo.R 112
bob3bob3
0
270
PostmanでAPIの動作確認が楽になった話
h455h1
0
180
スクラムガイドのスプリントレトロスペクティブを改めて読みかえしてみた / Re-reading the Sprint Retrospective Section in the Scrum Guide
mackey0225
3
480
Try creating your own orderedmap
kazamori
1
170
新宿ダンジョンを可視化してみた
satoshi7190
3
360
Build Apps for iOS, Android & Desktop in 100% Kotlin With Compose Multiplatform (mDevCamp 2024)
zsmb
0
420
PHPはいつから死んでいるかの調査
chiroruxx
2
410
Polars入門
daikikatsuragawa
1
160
Ruby GitHub Packages
bkuhlmann
0
640
FigmaとPHPで作る1ミリたりとも表示崩れしない最強の帳票印刷ソリューション
ttskch
43
19k
Deep Dive into React Stream/Serialize
mugi_uno
3
540
Next.js App Router
quramy
11
1.6k
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
44
6.8k
Designing the Hi-DPI Web
ddemaree
276
33k
Stop Working from a Prison Cell
hatefulcrawdad
267
19k
The Invisible Side of Design
smashingmag
294
49k
YesSQL, Process and Tooling at Scale
rocio
165
13k
Building a Scalable Design System with Sketch
lauravandoore
457
32k
Building Your Own Lightsaber
phodgson
100
5.7k
Infographics Made Easy
chrislema
238
18k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
117
18k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.6k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.6k
Making the Leap to Tech Lead
cromwellryan
125
8.5k
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 • チームの細分化、ローテーション、ロールチェンジ • 振り返りの振り返り 今後やっていきたいこと