プロダクトの基礎 · 中級

仕様から始められるタスクへ

一行でいうと: 良いタスクは実行してチェックできる結果で終わり、一〜二日かかる——一週間でも一時間でもなく。

正しく切る方法

価値で切り、レイヤーで切らない。「画面」「サーバー」「データベース」は、すべてが終わるまで何も提供しない三つのタスクだ。「ユーザーが下書きを保存できる」は三つのレイヤーに触り、見せられるもので終わる一つのタスクだ。

タスクが大きすぎるとき、バリエーションを探す:最初にハッピーパス、後でエッジケース;最初に一人のユーザー、後で多数。

カードに必要なもの

一行のコンテキスト——誰がこれを必要としてなぜか。一貫した形式の受け入れ基準。依存がある場合はそれ。それを生み出した仕様や議論へのリンク。

不要なもの:詳細な解決策。すべてのカードが実装を指示するなら、開発者を雇う理由を排除したことになる。

切り方が悪いサイン

サイクル間で転がるタスク、三日間「ほぼ完了」なタスク、他の三つなしにテストできないタスク。すべての場合、切り方は技術的な構造によるもので、結果によるものではなかった。

さらに深く

コードを書き始める前に受け入れ基準を書く——それはテストを定義する。受け入れ基準を定式化できないタスクは通常、変装したリサーチであり、そのように定義するのが良い:時間が区切られた枠、定義された質問、書かれた成果物。