- 考えるまでの距離を最短にする
- 常時ブラウザに固定する: Scrapbox、一時メモ、スプシ
- Slackにて、自分へのDMは、最上部に固定する
- ノートは開いておく
- スプシを開く
- タスクを洗い出す
- 1つが1日以内で終わるレベルを目安に砕く
- 不確実性を書き出す
- 不確実性を減らす
- 比較する(同規模の既存機能)
- 数える(行数、機能数、ファイル数)
- レビューしてもらう
- ptをつける
- 再見積もりタイミングを入れる
- 不具合改修 = 実装工数 * 0.2~0.3 とする
- レビュー工数を考慮する
- 設計や実装の前に、仕様確認 or テスト設計の時間と取る
- 決めきれていない仕様があることを前提とする
- 伝えたほうが多分いいことは何か?
- 今日(今週、このpjtが)失敗するとしたら、どういうことが起きた場合か?
- 誰かに協力してもらうことができる範囲はどこか?
- 例えば、毎日15分でも話す時間をブロックさせてもらうという方法がある
- 助けてもらいたい人はいるか?
- 2倍速で終わるためにできることは何か?
- 一番時間がかかりそうなことは何か?
- 一番価値があることは何か?
- 今週のMVPは誰か?(目立つ、ではなく、価値がある)
- 業務ロジック
- 値オブジェクト
- ユビキタス言語
- コアドメイン
- 集約
- 複雑な業務ロジック
- インスタンス変数はnilになりうるか?(nilかつレシーバとなる箇所はないか?)
- ぼっち演算子をつけなくて大丈夫か?
- 継承について
- 継承を用いて責務を分離できないか
- 継承していた場合、想定外のオーバーライドをしている箇所はないか
- 可視性が適切か
- 定数化できる余地と、している場合に freezeしているか
結局、手書きノートと本があってる
- 対象機能を選定
- 現状分析
- 目標設定
- 原因究明
- チューニングの方針決定
- チューニング
- 結果測定
TODO: 決め方