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.4k
Other Decks in Programming
See All in Programming
破壊せよ!データ破壊駆動で考えるドメインモデリング / data-destroy-driven
minodriven
16
4k
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
390
『ドメイン駆動設計をはじめよう』のモデリングアプローチ
masuda220
PRO
8
440
Vitest Browser Mode への期待 / Vitest Browser Mode
odanado
PRO
2
1.7k
役立つログに取り組もう
irof
26
8.6k
macOS でできる リアルタイム動画像処理
biacco42
7
1.8k
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
130
Vue SFCのtemplateでTypeScriptの型を活用しよう
tsukkee
3
1.5k
2万ページのSSG運用における工夫と注意点 / Vue Fes Japan 2024
chinen
3
1.3k
Go言語でターミナルフレンドリーなAIコマンド、afaを作った/fukuokago20_afa
monochromegane
2
140
のびしろを広げる巻き込まれ力:偶然を活かすキャリアの作り方/oso2024
takahashiikki
1
410
Tuning GraphQL on Rails
pyama86
2
1k
Featured
See All Featured
Unsuck your backbone
ammeep
668
57k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2.1k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Building Adaptive Systems
keathley
38
2.2k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
Visualization
eitanlees
144
15k
KATA
mclloyd
29
13k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.2k
GitHub's CSS Performance
jonrohan
1030
460k
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 • チームの細分化、ローテーション、ロールチェンジ • 振り返りの振り返り 今後やっていきたいこと