アジャイルな要件定義と開発スコープ
#要件定義 #仕様 #設計 #ワークフロー #エンジニアリング #設計原則 #アーキテクチャ
SaaS開発の文脈はあるのだが、ものづくり全般に言えるぐらい重要な開発スコープの話
---
要約
koushisa.icon
推測ではなく、計測した事実を元に論理的な意思決定を下したい
ビジネスである以上、自己満足な開発はしたくない
そのために「スコープ外」を明確にする必要がある
1. アジャイルな要件定義をする
早すぎる最適化を防ぐ
コア機能以外の決断を遅らせる
2. 無駄を削ぎ落とすことはステークホルダ全方位にメリットしかない
手戻りや不要な作り込みを防ぐ
情報不足な状況での不毛なコミュニケーションを減らす
3. ユーザーを巻き込んだフィードバックループを早く回す仕組みを構築する
ユーザーの反応を見て初動を確認する
プロダクト開発・改善をギャンブルではなく、市場ルールを理解した上での後出しじゃんけんに持ち込む
4. このプロセスを下支えするディレクション
リードタイムと、開発コストの全体像を捉える
開発コストを低く見積もってしまう罠にハマらない
---
具体的にどうする?
色々なプラクティスはあるが、アジャイルの本読むのが早い
問題解決の引き出しは多いに越したことはない
ここは追加開発を必ずやるのか、可能性があるのかなどを考えるとっかかりを共通認識をステークホルダ間で作る
ありえるとわかっていれば、設計の柔軟性ができる
絶対に必要なコア機能
あれば便利なプレゼンテーション機能
関心の分離はドメインとプレゼンテーションから考える(PDS)
プレゼンテーション処理を作り込むのは想像以上に工数がかかる
人間の感覚・知覚・認知に関わる処理なので泥臭い処理が多い
需要ありませんでした、で消すのは避けたい
頑張りが報われないkoushisa.icon
先にコア機能だけでリリースして、需要を確認してから作り込みたい
まずコア機能に意識を集中してデータ構造を洗練させる
いいデータ構造はいいアルゴリズムを生む
最初が一項目だったとしても関心の成長軸を作っておき、変化の際に既存の構造を変更せずに"追加"で対処できる構成を目指す
UI/UXのための処理は、アドオンで作れるように分離する
アドオンで作れるようになっているとリグレッション管理が楽である
機能は追加よりも変更したり削除するほうが難しい
ここに対するアプローチでコストパフォーマンスが良いのはトレードオフスライダー
QCD及び松竹梅を定義する
梅でコア機能を作り、ユーザーの反応を見る
2次開発での優先度に沿って竹を埋める
反応がよければさらに松を埋めるように改善していく
---
DEV Team
ソフトウェア開発は総合格闘技
ソフトウェア開発における「生産性」とは
技術者と作業員