先週、アサインされたタスクが結構サクッと進めることができました。この流れを再現できるように、自分なりに工夫したことを書き残しておこうと思います。

前提

前提として、今のチームでは次のようなサイクルで開発をしています:

一工夫その1: 作業サイクルに基づいて開発計画を立てる

少し前に、実装に手間取ってしまった結果、レビューとQAエンジニアによるテストが後ろにズレて、リリース前に大慌てになった出来事がありました。この対応として、タスクに着手する前に、先の開発サイクルに基づいて「これくらいのスケジュールで進めよう」という開発計画を立てるようになりました。例えば…

こういうさっくりした粒度であっても、ないよりは全然マシでした。毎日の朝会でも進捗の共有がしやすくなりましたし、「予定よりもスムーズに行っているので、次のタスクの着手が早まりそうです」とか、「少し手間取っているので、予定より遅れそうです」といったアラートも出しやすくなりました。

タスクはIssueに書かれていて、「このような機能を実装したい」という要件や、デザインのモックなどが記載されています。これをもとに開発を進めたのに、QAエンジニアによるテストの段階で、仕様やエッジケースの考慮漏れが原因となるフィードバックを大量にいただくことがありました。

これを防ぐために、検証項目をめちゃくちゃ丁寧に書くようにしました。これによって、

仕様を「検証項目」の形で、改めて整理することができる
- 結果として、齟齬の発生を防ぐことに繋がる
レビュワーが機能のイメージを持ちやすくなる（検証項目を通して、どのような操作が可能かが伝わる）
- エッジケースの考慮漏れなどにレビューの段階で気づいてもらえる
当初のIssueから意図的に変更した点について、QAエンジニアに伝えることができる
- 実装中に得た気づきやフィードバックによって変更した点を、当初のIssueに転記しそこねる（結果としてQAエンジニアへの共有が漏れる）ことが何度か起きてしまった
  - そのときに、「Issueの仕様との差分は意図的なものですか？」と確認いただいていた…
- 「検証項目」を用意する際に、「ここは当初のIssueから差分があります」と記載することで、QAエンジニアにもれなく伝えることができた