afbのリニューアル、 3_4ヶ月くらい経ったけど 進捗どうですか？

Transcript

1. 2022/07/29(金) 18:00~18:30 afbのリニューアル、 3~4ヶ月くらい経ったけど 進捗どうですか？
2. • 今までやってきたこと ◦ 4月、5月、6月、7月 • 目指していたこと ◦ アジャイルについて • わかってきたこと ◦ XPについて ◦ スクラムについて • 今後やっていきたいこと 今日話すこと
3. 今までやってきたこと 〜4月〜 はじまりのMiro@2022/03/29 • ディレクトリ構成 • n対nのフロント、バック(API) 03/28 リニューアル キックオフ
4. 4月にやったこと • アーキテクチャ決定 • バックエンド技術選定 • フロント技術選定 • API(バックエンド)コンテナ準備 • 開発環境爆誕 ずーっとPoC(Proof of Concept) とりあえず作ってみよう 3~8人で1日2~4時間くらい 今までやってきたこと 〜4月〜
5. 今までやってきたこと 〜5月〜 afb_renewalチーム 初めての振り返り@04/28 プロジェクトの スケジュール感があいまい、、、 誰がいつ何をやっているの？？？ 結局何をどう作ればいいのか、、、 (当時は各自が空き時間に 黙々とやってました)
6. 今までやってきたこと 〜5月〜 • クリーンアーキテクチャの採用 ◦ 18:30から毎日勉強会 • E2Eフレームワーク決定 • テスト戦略決定(TDD) • アジャイル説明会 • スクラムの本格導入 ◦ スプリント計画 ◦ ユーザーストーリー見積も り ◦ 振り返りの実施 • Discordお試し運用 • フロント技術検証 • 認証/認可基盤、権限定義 • admin機能使用状況調査 • デザインチームロードマップ策定 ←4/28(金) ↓06/03(金)
7. 今までやってきたこと 〜6、7月〜 • 全隊開発開始 ◦ 現在総勢16名 • SREチーム爆誕 ◦ 現在4名 • IntelliJ使用開始 • ドメイン定義 • ストーリー出し • クリーンアーキテクチャ実装 • モブプロ開始 ◦ 2週間くらい、全員で • チーム開発開始 ◦ 3人4チーム • 現在開発中 ◦ Afb API ◦ Auth API ◦ Migrate API
8. 細かい歴史の話をすっ飛ばして 僕が感じたアジャイルの2つの必須条件 • あいまいさを許容すること • コミュニケーションを取りまくること 詳しくは「アジャイルソフトウェア開発宣言」 「アジャイルソフトウェア開発の12の原則」 目指していたこと 〜アジャイルについて〜
9. XP(Extreme Programming)とは 開発のためのベストプラクティス集 • 計画 • プログラミング • 全員同席 • インテグレーション ざっくりこんなカテゴリ 取捨選別は結構自由 「単独でもワークするけど、組み合わせた方 がもっとワークするよ」的なスタンス わかってきたこと 〜XPについて〜 afb_renewalでは 主に以下を採用 • ユーザーストーリー • 週次サイクル • ペアプロ • テストファースト • CI(継続的インテグレーション) • チーム主体
10. わかってきたこと 〜XPについて〜 治療と予防と健診 治療:バグの早期発見、改修 検査:TDD、E2E、CI 予防:クリーンアーキテクチャ リファクタリング、ペアプロ 大切なのは、循環すること
11. スクラム(Scrum)とは、組織のための ベストプラクティス集 • 役割 • アクティビティ • 作成物 • ルール ざっくりこんな感じのカテゴリ 「どれかだけやってもあんま意味ないから、で きたら全部やった方がいいよ」なスタンス わかってきたこと 〜スクラムについて〜 afb_renewalでは 以下はまだできていない • スプリントレビュー • バックログリファインメント • 「完了」(リリース可能)の定義 →すべてプロダクトオーナーとの 協働が必要
12. スクラムマスターって何やってん の？ →実際僕もよくわかんないです とりあえず1日、1週間がすぐ終わる わかってきたこと 〜スクラムについて〜 スクラムマスターとは 何ではないのか？ • 開発者でありません • マネージャーではありません • 秘書ではありません • プロダクトオーナーではありま せん
13. 僕のイメージ マネージャー=キャプテン わかってきたこと 〜スクラムについて〜 スクラムマスター =(部活や芸能人の)マネージャー
14. よくある地獄 わかってきたこと 〜スクラムについて〜 マネージャー(中間管理職)パターン • 上司と現場で言ってることが違う • そもそも上司と現場の仲が悪い • マネージャーが上司の要望、現場の意 見、新人の面倒の三重苦に陥る • 結果マネージャーはコードを書く時間 が1ミリもなくなる • なのに、ベテランになるほどマネージ ャーにならければいけない • そしてマネージャーが辞めていく... 上司 現場 新人 マネージャー
15. • スクラム(チーム)については、すべて スクラムマスターが責任を持つ • それぞれ役割と、スクラムマスターで 調整を行う マネージャーというか、鞄持ちというか、 御用聞きというか、雑用係というか サーバントリーダーというか →肩書きなんてなんでもよくて、チームがワ ークすればなんでもいい！ わかってきたこと 〜スクラムについて〜 スクラム プロダクト オーナー 開発者 新人 スクラムマスター ペア
16. 最近思った仮説 「優れたアーキテクチャと優れた組織 はまったく同じである」
17. コンウェイの法則 「組織の設計するシステムには... その組織のコミュニケーション構造を そのまま反映した設計になる制約がある」 という経験則というか格言
18. 優れたアーキテクチャと優れた組織 治療と予防と健診 大切なのは循環すること 治療:バグの早期発見、改修 検査:TDD、E2E、CI 予防:クリーンアーキテクチャ リファクタリング、ペアプロ プロダクト オーナー 開発者 スクラムマスター 新人 治療: スプリントレビュー 予防: 1on1、振り返り 検査: スプリント計画 リファインメント
19. • あいまいさを許容すること • コミュニケーションを取りまくること 大切なのはバグがないこと、問題が起きないことではなく • システムによってバグを発見し、容易に修正できること • 仕組みによって問題を発見し、容易に解決できること 目指していたこと 〜アジャイルについて〜
20. • 認証認可基盤(Auth API) • レガシー(現行)adminからモダン(リニューアル)afbへのデータ移行(Migrate API) • ビジネスサイドとの密なコミュニケーション ◦ プロダクトオーナーの巻き込み ◦ ステークホルダーの要求ヒアリング ◦ スプリントレビューの実施 ◦ スプリント計画、1部&2部制度 • デザインチームとの密なコミュニケーション • ベロシティからの開発見込みの逆算 ◦ スコープ、完了条件をどこに設定するか • 大規模スクラムへの移行、LeSS、S@S、SAFe • チームの細分化、ローテーション、ロールチェンジ • 振り返りの振り返り 今後やっていきたいこと