TL;DR
昨今では、プロジェクト管理、コミュニケーション、IDE、DevOpsのツール類が成熟してソフトウェア開発は非常に便利な世の中となってきました。
ですがこれらのツールを使いこなす前に各フェーズ毎の心得を並べてみました。各プロジェクトでフェーズは様々だと思いますが、2週間から1ヶ月くらいのスプリントでチームではなく個人に割り振られたタスクをこなすための心得としています。
工数見積
ソフトウェア見積りの主目的は、プロジェクトの結果を予言する事ではない。見積りを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである。（スティーブ・マコネル）
- 仕様書／チケットなどは必ず全て読む、不明点は理解するまで確認する。 （依頼者が記載することで伝えたと思っているケースが多い。ボリュームが大きい場合は依頼者と相談し報告時に確認した箇所を伝える）
- 見積もりは粒度を細かくすることで精度が向上する。ただ細かくすることで見積もりに時間がかかるため状況に応じて行う。
- 技術的不安要素がある場合はここで報告する。(改修案件であればソースの確認を怠らないこと)
- 過去に類似の案件があった場合、算出した工数に乖離がないか確認する。
- 目的を理解し完成形をイメージする。
- 工数には設計する時間を考慮する。 （ボリュームによるが、ある程度の設計までイメージできれば尚良い）
- 報告時には完了見込みスケジュールを添える。（自身の検証も終わりリリースできる状態）
開発
- 最初に手を動かさず設計から着手し、開発する順序、効率化を検討する。（テストコードを用意する前提ならこの段階で検討する）
- 新規モジュールを作成する際は他モジュールを必ず参考にする。 （スタイルガイドがあれば遵守する）
- コメントはソースを翻訳するのではなく、意味／経緯などを記載する。（コメントも間違っていれば不具合）
- リリースできる状態をイメージする。（ボタンの位置などの細部は後で行うではなく、基本的にその場で行う。不足機能があっても主となる機能が完成していれば先行リリースが可能となる）
- スケジュール遅延または工数超過の報告は事後でなく出来る限り早めに相談する。（スコープ内に収まる建設的な提案ができれば尚良い）
- 技術調査に1時間以上かかる場合は相談する。
- 開発ボリュームが大きい場合は適度なポイントで進捗を報告する。
検証
- 基本的にこのタイミングではソースファイルを変更してはならない。（検証の意味がなくなる）
- CIなどテストコードによるテストは主にリグレッションやデータ不整合をカバーするもので仕様バグは防げないことを留意する。
- 作成ソースのカバレッジは基本的に100%を目指す。
- 俯瞰的に確認を行い、実際のユーザーが利用する流れ（主目的）は必ず実施。
- 境界値、水平検証などを検討し工数に見合った検証を行う。
- 検証は細かく行う方が安心だが、工数に見合った検証を行う。
- 既存／類似ソースの改修時は必ずDiffを確認する。
リリース
- 出来る限り手作業を減らす。
- リリース後の影響は予め考慮する。
- リリース後はユーザーに影響が出ない範囲で確認を実施する。
- リリース後は振り返り、次回に活かす。
さいごに
アジャイルサムライにて3つの真実として以下が記載されていました。
- プロジェクト開始時点に全ての要求を集めることはできない
- 集めたところで要求は必ず変わってくる
- やるべき事は与えられた時間と資金より多い
上記を見直すと矛盾があり、全てをきちんと行うことは酷であるとも思います。
また各フェーズには様々なツールや手法がありますが、根本は同じで誰もが安心して効率よく品質のよいソフトウェアを開発するためのものです。プロジェクトは多種多様でいろいろな局面がありますが、これら心得を参考にしていただけたら幸いです。