アジャイル開発を支えるテクニカル面を掘り下げてどこかで話したい

この記事はAgile Tech EXPO Advent Calendar 2020 20日目の記事であり、こんな話ができるぞという売り込みでもあります。

はじめに

2019年に「もっと外に出て発信・情報集めしないとダメだな」と認識を改め、勉強会やカンファレンスに出ることが増えました。特に2020年からは「発信を頑張っていこう」という思いの元、7件の外部登壇を行いました。

内容を分類すると組織・文化の話が2件、マネジメントの話が2件、プロジェクトマネジメントが1件、その他アジャイル開発関連で2件です。毎度違う話ができたことは自分でもよかったと思っていますが、アジャイルの「ライトウィング」と「レフトウィング」で分けるといずれもレフトウィング(チーム環境)寄りだと言えます。会社ではマネージャーという立場とは言え、開発部門を盛り上げていく役目ですのでライトウィング(開発環境)寄りのプレゼンスも上げていきたいところです。

今年はアジャイル関連のカンファレンスに一通り出席しましたが、プロセスや心構え、文化の話が多かったように感じています。たまに見かける技術の話・記事であっても「テスト駆動開発」「モブプログラミング」「DevOps」ぐらいのざっくり粒度、またはそれらを取り入れるときの心構え的なものが多く、「マインドやフレームワークに加えて、技術の最新動向をお届けするカンファレンス」を目指すAgile Tech EXPOには期待をしています。

ということで前置きが長くなりましたが、Howをもっと細かくした発表をどこかでしたいなと思っております。

(仮題)アジャイルに進めることに向き合った結果、技術ってこうなりますよね

設計

当たり前だけどきちんとやる。アジャイルは設計しないなんてことはない。
クリーンアーキテクチャとか、クラス構成とか、実装言語とか、最新技術を話す前にすることがある。
ユースケースをきちんと拾い上げて正常系・異常系を網羅できているのかきちんと確認する。
- 関係者をきちんと呼んでやる、総務・営業・企画・CS・QAなど
責務が適切かとか見る。
PRを出してから設計議論を始めない。どう実装するかを先に議論し、認識を合わせておく。

構成管理

ブランチを切りたくない。
短くマージして統合し続ける。
トランクベース開発

ライブラリ更新

Dependabot (Renovate)を入れて楽をしましょう。

リファクタリング

システムを作り直せば問題が解決するなんてことはほとんどない。
リファクタリングの時間が取れないという言い訳
毎コミットリファクタリングする
あなたが知っているすごいプログラマは「リファクタリングしていいですか」なんて許可とっていない
バグ修正・機能追加の最後に「リファクタリングタスク」積んでみたら?

コードレビュー

バグを見つけるプロセスではない。
「読みにくいんですけど」という率直な指摘

テスト

単体テストを書けばバグがでなくなるという幻想
多ければ良いという物ではない。失敗しないテストは書く意味がない。
最後に起きた障害は単体テストがあれば防げていた物ですか?
サービス全体で落としてはならない正常形をテストし続ける。

リリース

リリーストレインという考え方。含める機能を決めてリリース日をずらすのではなく、リリースに間に合った機能を随時出していく。
フィーチャーフラグを仕込んでおく。本番環境で動かす機能を制御できるようにする。

監視

計測せよ
警告・エラーを0にする。
毎日見る、みんなで見る。

ドキュメント・引継ぎ

ドキュメントで引き継げるという幻想
タスクを手分けして属人化を防ぐ。

おわりに

ということでオファーお待ちしております。

tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録