クソボケ！設計書もないしスケジュールもないなんて！

単なる愚痴。
切り込んで課題の棚卸と線引きなおしを自分でやるっきゃ騎士。

品質を上げるメモ
標準化について
・画面設計規約の作成（UIの枠。この辺で使用フレームワークも決まる）
・コーディング規約の作成
（SQL、Java、JSP、Javascript、CSS）
・単語、用語集の作成
・性能基準
（件/sec）
・PG設計規約の作成
（使用するライブラリ、バージョンの縛り）
・標準開発環境の作成
(上記に関連)
詳細に決めること。PGを迷わせたり考えさせたら負けぐらいの勢いで考える。
またそれらをみんな更新できるような状態を作成すること。
（開発しないと発覚しないパターンもある。素早く対応し、素早くメンバーに通知する）

単体テストについて
・単体テストのフェーズを分ける
（MVCを意識し、モデル層（ビジネスロジック）のテスト、ビュー層（画面）のテストの2段階で考える。）
・モデル層（ビジネスロジック）のテスト
・レビューの徹底化
（ビジネスロジックの再確認。設計ミスを防ぐ。特にチェック関連の処理は必須）
・C1レベルのカバレッジ
・データベースとの連携
（SQLの評価。テストデータ標準化）
・イテレーションの徹底化
（作りながらテスト。コーディング→テスト→評価の繰り返し。XPなどアジャイル開発でなくともイテレーションは必須。）

イテレーションも含めスケジューリングする。
（細かいレベルは実装者に任せる）
また必ず一括実施を行うこと。
（修正箇所の影響度を必ずチェック。共通なメソッドの仕様に影響が出てないかチェック）

・ビュー層（画面）のテスト
・上記と同様
・UIを動的に変更する箇所のチェック
（disable化など）
・ページ切り替えテストの徹底化
（遷移、遷移後に戻れるかなど）

上記をセットで行う。

レビューについて
レビューの効率化を図るのであればテストコードのみんもレビューでも可。
但し、テストコードに対して基準の設定が必須。

おまけ
大規模プロジェクト、仕様が未確定でよく変わる場合には必ずイテレーションを行うこと。
（ここでのイテレーションはどこまで実装するかなど実装スケジュールの見直しを指す）
　・サイクル間隔の目安
　１ｗが適当。これ以上長い場合は再度仕様を確認し、スケジュール調整すべし！

全体を見通せるようテスト結果はまとめること。
そして必ずプロジェクトメンバーにも見える所に置き、各自確認してもらうこと。
（品質への意識を高める。各自が声を掛け合うようになり円滑に作業が進む）

注意
　単体テストが失敗していても恐れない。
　障害は修正してなんぼ。
　見つけることに意義がある。
　修正したらテストする癖をつける。
　（結果として戻り工数の減少につながる）
　テストケースは残すべし
　テストケースのコード自体は汚くてもOK
　テストコードは原則修正を行わないようにする
　（テストコードは仕様を必ず満たしている）
　テストコードは追加する一方ぐらいの勢い
　（やればやるほどコードは増える）
　ステップ数で図るべからず
　（図るのはケース数である。カバレッジと併用して徹底的に潰すべし）
　TDDではなくレビューでつぶすのがベスト
　（テストすればいいやという考えだけでは厳しい。仕様に問題がある可能性を示唆せよ）

なーんてね。できれば苦労しねえっつーの！とか言ってみたり
うくく。