開発プロセスの改善について
目次
- よくある開発プロセス
- 改善後の開発プロセス
- よくある開発プロセスから改善後の開発プロセスにするメリット・デメリット
- よくある開発プロセスから改善後の開発プロセスにするには
- よくある開発プロセスから改善後の開発プロセスにする際の段階ごとの変更
- 結論
よくある開発プロセス
以下は、よくある開発プロセスだと思う。今回はこれに一石を投じてみたい。
要件定義書作成
↓
要件定義書レビュー
↓
実装
↓
実装レビュー
↓
単体テスト試験項目書作成
↓
単体テストレビュー
↓
単体テスト
↓
結合テスト試験項目書作成
↓
結合テストレビュー
↓
結合テスト
↓
総合テスト試験項目書作成
↓
総合テストレビュー
↓
総合テスト
↓
顧客受け入れテスト
↓
リリース
改善後の開発プロセス
以下は、改善後の開発プロセスである。
以下のことが実現されている。
- テストファーストの実現
- 自動テストの導入
- テスト駆動開発の導入
- ペアプログラミングの導入
- ペア要件定義、ペア設計の導入
- リファクタリングの導入
- 継続的ビルドの導入
- ストーリーの導入
- CLEANコードの導入
ペアストーリー作成
↓
ストーリーレビュー
↓
ペア総合テスト自動テスト作成
↓
総合テスト自動テストレビュー
↓
ストーリー削除
↓
ペア結合テスト自動テスト作成
↓
結合テスト自動テストレビュー
↓
[繰り返し]
ペア単体テスト自動テスト作成
↓
ペアプログラミング(Clean Codeを教える)
↓
リファクタリング
【繰り返し終わり】
↓
実装レビュー
↓
単体テスト自動テスト
↓
結合テスト自動テスト
↓
総合テスト自動テスト
↓
継続的ビルド
↓
顧客受け入れテスト
↓
リリース
よくある開発プロセスから改善後の開発プロセスにするメリット・デメリット
メリットは以下である
- デグレが減る
- 開発者が自動テストというセーフティネットの中で開発できる。つまり、バグが減るし、開発者の心理的安全性が上がる。
- 開発速度が上がる
- 早期にバグを発見できる
- 作りの共有が開発者間で出来る
- 仕様の共有が開発者間で出来る
- 認識不足によるバグが減る
- 要件定義の段階でミスが減る
- 設計の段階でミスが減る
- ソースコードの保守性が高いままになる
- ブランチの管理をしなくていい
- 要件がより明確になる
- ソースコードの保守性が更に高い物になる
<デメリットは、以下である>
- これまでと同じ方法で開発できない
- 一時的に開発ペースが落ちる可能性がある
- マネージャーや経営層を納得させるのが大変
メリット・デメリットだけ見るとメリットの方が大きいように見えますが、最後のデメリットがとても大きいのが分かります。
よくある開発プロセスから改善後の開発プロセスにするには
技術的にはそれほど問題にはならない。
せいぜい、自動テストの箇所くらいが問題となるくらいである。
それ以上に、マネージャーや経営層への調整が大変になる
なぜ、自動テストやペアプログラミングが必要になるか、説明しないといけない。
また、なぜ今の商品でそれを行う必要があるか説明が必要になる。
残念ながら、私はこの説明責任を為せなかった。納得させられなかった。
そのため、他の人はこの調整業務に気を付けて実施してほしい。
よくある開発プロセスから改善後の開発プロセスにする際の段階ごとの変更
【Before】
要件定義書作成
↓
要件定義書レビュー
↓
実装
↓
実装レビュー
↓
単体テスト試験項目書作成
↓
単体テストレビュー
↓
単体テスト
↓
結合テスト試験項目書作成
↓
結合テストレビュー
↓
結合テスト
↓
総合テスト試験項目書作成
↓
総合テストレビュー
↓
総合テスト
↓
顧客受け入れテスト
↓
リリース
【After 1度目 テストファーストの導入】
要件定義書作成
↓
要件定義書レビュー
↓
総合テスト試験項目書作成
↓
総合テストレビュー
↓
結合テスト試験項目書作成
↓
結合テストレビュー
↓
単体テスト試験項目書作成
↓
単体テストレビュー
↓
実装
↓
実装レビュー
↓
単体テスト
↓
結合テスト
↓
総合テスト
↓
顧客受け入れテスト
↓
リリース
【After 2度目 自動テストの導入】
要件定義書作成
↓
要件定義書レビュー
↓
総合テスト自動テスト作成
↓
総合テスト自動テストレビュー
↓
要件定義書削除
↓
結合テスト自動テスト作成
↓
結合テスト自動テストレビュー
↓
単体テスト自動テスト作成
↓
単体テスト自動テストレビュー
↓
実装
↓
実装レビュー
↓
単体テスト自動テスト
↓
結合テスト自動テスト
↓
総合テスト自動テスト
↓
顧客受け入れテスト
↓
リリース
【After 3度目 テスト駆動開発の導入】
要件定義書作成
↓
要件定義書レビュー
↓
総合テスト自動テスト作成
↓
総合テスト自動テストレビュー
↓
要件定義書削除
↓
結合テスト自動テスト作成
↓
結合テスト自動テストレビュー
↓
【繰り返し】
単体テスト自動テスト作成
↓
実装
【繰り返し終わり】
↓
実装レビュー
↓
単体テスト自動テスト
↓
結合テスト自動テスト
↓
総合テスト自動テスト
↓
顧客受け入れテスト
↓
リリース
【After 4度目 ペアプログラミングの導入】
要件定義書作成
↓
要件定義書レビュー
↓
総合テスト自動テスト作成
↓
総合テスト自動テストレビュー
↓
要件定義書削除
↓
結合テスト自動テスト作成
↓
結合テスト自動テストレビュー
↓
【繰り返し】
単体テスト自動テスト作成
↓
ペアプログラミング
【繰り返し終わり】
↓
実装レビュー
↓
単体テスト自動テスト
↓
結合テスト自動テスト
↓
総合テスト自動テスト
↓
顧客受け入れテスト
↓
リリース
【After 5度目 ペアプログラミングの発展】
ペア要件定義書作成
↓
要件定義書レビュー
↓
ペア総合テスト自動テスト作成
↓
総合テスト自動テストレビュー
↓
要件定義書削除
↓
ペア結合テスト自動テスト作成
↓
結合テスト自動テストレビュー
↓
【繰り返し】
ペア単体テスト自動テスト作成
↓
ペアプログラミング
【繰り返し終わり】
↓
実装レビュー
↓
単体テスト自動テスト
↓
結合テスト自動テスト
↓
総合テスト自動テスト
↓
顧客受け入れテスト
↓
リリース
【After 6度目 リファクタリングの導入】
ペア要件定義書作成
↓
要件定義書レビュー
↓
ペア総合テスト自動テスト作成
↓
総合テスト自動テストレビュー
↓
要件定義書削除
↓
ペア結合テスト自動テスト作成
↓
結合テスト自動テストレビュー
↓
【繰り返し】
ペア単体テスト自動テスト作成
↓
ペアプログラミング
↓
リファクタリング
【繰り返し終わり】
↓
実装レビュー
↓
単体テスト自動テスト
↓
結合テスト自動テスト
↓
総合テスト自動テスト
↓
顧客受け入れテスト
↓
リリース
【After 7度目 継続的ビルドの導入】
ペア要件定義書作成
↓
要件定義書レビュー
↓
ペア総合テスト自動テスト作成
↓
総合テスト自動テストレビュー
↓
要件定義書削除
↓
ペア結合テスト自動テスト作成
↓
結合テスト自動テストレビュー
↓
【繰り返し】
ペア単体テスト自動テスト作成
↓
ペアプログラミング
↓
リファクタリング
【繰り返し終わり】
↓
実装レビュー
↓
単体テスト自動テスト
↓
結合テスト自動テスト
↓
総合テスト自動テスト
↓
継続的ビルド
↓
顧客受け入れテスト
↓
リリース
【After 8度目 ストーリーの作成】
ペアストーリー作成
↓
ストーリーレビュー
↓
ペア総合テスト自動テスト作成
↓
総合テスト自動テストレビュー
↓
ストーリー削除
↓
ペア結合テスト自動テスト作成
↓
結合テスト自動テストレビュー
↓
【繰り返し】
ペア単体テスト自動テスト作成
↓
ペアプログラミング
↓
リファクタリング
【繰り返し終わり】
↓
実装レビュー
↓
単体テスト自動テスト
↓
結合テスト自動テスト
↓
総合テスト自動テスト
↓
継続的ビルド
↓
顧客受け入れテスト
↓
リリース
【After 9度目 Clean Codeの教授】
ペアストーリー作成
↓
ストーリーレビュー
↓
ペア総合テスト自動テスト作成
↓
総合テスト自動テストレビュー
↓
ストーリー削除
↓
ペア結合テスト自動テスト作成
↓
結合テスト自動テストレビュー
↓
【繰り返し】
ペア単体テスト自動テスト作成
↓
ペアプログラミング(Clean Codeを教える)
↓
リファクタリング
【繰り返し終わり】
↓
実装レビュー
↓
単体テスト自動テスト
↓
結合テスト自動テスト
↓
総合テスト自動テスト
↓
継続的ビルド
↓
顧客受け入れテスト
↓
リリース
結論
よくある開発プロセスから改善後の開発プロセスにするには技術的には正しい方向だと思う。
ただし、マネージャーや経営層がそれで納得するかと言うと別問題なので、調整の必要がある。