プロダクトの基礎 · 中級
仕様から始められるタスクへ
一行でいうと: 良いタスクは実行してチェックできる結果で終わり、一〜二日かかる——一週間でも一時間でもなく。
正しく切る方法
価値で切り、レイヤーで切らない。「画面」「サーバー」「データベース」は、すべてが終わるまで何も提供しない三つのタスクだ。「ユーザーが下書きを保存できる」は三つのレイヤーに触り、見せられるもので終わる一つのタスクだ。
タスクが大きすぎるとき、バリエーションを探す:最初にハッピーパス、後でエッジケース;最初に一人のユーザー、後で多数。
カードに必要なもの
一行のコンテキスト——誰がこれを必要としてなぜか。一貫した形式の受け入れ基準。依存がある場合はそれ。それを生み出した仕様や議論へのリンク。
不要なもの:詳細な解決策。すべてのカードが実装を指示するなら、開発者を雇う理由を排除したことになる。
切り方が悪いサイン
サイクル間で転がるタスク、三日間「ほぼ完了」なタスク、他の三つなしにテストできないタスク。すべての場合、切り方は技術的な構造によるもので、結果によるものではなかった。
さらに深く
コードを書き始める前に受け入れ基準を書く——それはテストを定義する。受け入れ基準を定式化できないタスクは通常、変装したリサーチであり、そのように定義するのが良い:時間が区切られた枠、定義された質問、書かれた成果物。