本文書は、実現したい機能に対してリソース（時間）が足りないときの開発ポリシーをまとめたものである。これらのポリシーを一律にプロジェクトに適用するのが難しい場合は、機能毎に個別に適用を検討する。各項目には、機能実現の代償となるものも書き添える。
機能の実現に直接関係ない実装をしない。例えば、ページ遷移せずにJavaScriptでデータや画面を操作するなど。工数の少ない代替案がある場合は、開発者が仕様を提案する。
UIの反応速度、意匠性など。
バグや制限事項を以下の基準で分類する。分類した上で、trivialやminorを許容する。実装中に許容される課題だけが残った場合、デリバーしてよい。
- 主要な機能やデータに影響がある
- 代替手段がないか、あっても簡単でない
- 副次的な機能やデータに影響することがある
- 不便を感じることがある
- 簡単な代替手段がある
- 機能やデータに影響はない
- 不便を感じることはない
- 代替手段の必要すらない
- 例: 画面内に不自然な余白がある
完成度が低く見える場合がある。
大多数のデータ／ユースケースで正常に動作する場合、残りの僅かなケースのための実装をしない。
サポートしないケースで機能を使用できない。
開発環境の整備は長期的には価値が高いが、短期的にはコストになるので避ける。また、機能の実装の際も、新しい（または未経験の）ライブラリなどの使用を避け、素朴で既知の方法を選択する。
継続すると開発環境やコードが陳腐化する。
テストコードは書くが、リファクタリングはしない。
開発速度が徐々に低下する。また、開発者のストレスを増大させる。
© 2013 @irohiroki
この文書はクリエイティブ・コモンズ 表示 3.0 非移植 ライセンスの下に提供されています。
