アジャイル開発のインフラ
SIerはお客様の業務をIT化するのがお仕事なのに、自分たちの業務は意外とIT化しきれていない。
大量の印刷した紙、手作業の多い仕事に囲まれている。
ソフトウェア開発のインフラを考えると、最低3個の環境は必須だ。
一つは、ソースコード管理。
二つ目は、検証可能なビルド環境。
そしてBTS。
この3つについて考えてみる。
【1】ソース管理
プログラミングで仕事するならば、ソース管理(SCM)は必須だ。
ソース管理システムの本質は、前回のプログラムへUndoができること。
つまり、プログラムの履歴が残っているからこそ、前バージョンへUndo、Redoができる。
ソース管理は、MSならVSS、普通は、CVSかSubversionを使うのが普通だろう。
ソース管理で重要な作業はブランチやタグ付けができること。
ブランチは、枝分かれしたバージョンツリー。
タグは、ある時点でバージョン付けられたソース一式。ブックマークみたいなもの。
普通は、本番リリースや納品時にタグ付けして、バージョンをFixする。
そうすれば、同じモジュールを再リリースすることがいつでも可能になる。
ブランチを使うケースは、バグ修正と新規開発が並行して走っている場合。
特に運用保守フェーズでは、裏で仕様追加に伴う新規開発をしながら、緊急のバグ修正もこなさなければならない。
この時に本番モジュールと新規開発モジュールを区別するために、2系統のソース管理が必要になる。
普通のプログラマなら上記のことは行っているだろうが、実は、Webデザイナーの人たちにはソース管理と言う概念が無い。
だから、HTMLやCSSなどのViewソースは、実はソース管理がすごく難しい状況がある。
彼女たちにもSubversionをマスターさせればいいだけなのだが、彼女たちには難しいらしい。
【2】ビルド環境
ビルド環境の本質は、すぐにリリース可能なモジュールが作れること。
正しく動くプログラムを複製するソフトウェア工場のイメージに近い。
だめなプロジェクトは、すぐにビルドできない。
だから、バグ修正をすぐに反映できない。
結局、すぐに検証できないので、いつまで経ってもプロジェクトが収束しない。
最近のビルドは、単なるコンパイルだけでなく、ユニットテストも通すのが普通だろう。
つまり、回帰テストも通す。
これは、コンパイルの概念を拡張したものに相当する。
つまり、プログラミング言語体系に沿っているだけでなく、ユニットテストという仕様にプログラムが正しく合致しているか、Evaluateしているということ。
だから、最近のビルドは結構時間がかかる。
【3】BTS(バグ追跡システム)
BTSの本質は、アジャイル開発そのもの。
ドキュメント駆動ではなく、動くプログラムにどんどん手を加えて、多種多様な環境やフローにも耐えうるように品質を上げていくプロセスを補強する。
よくありがちなのは、BTSがないプロジェクト。
BTSがないプロジェクトは、結合テスト以降の開発がすごく弱い。
バグ報告からバグ修正、そして検証、リリースに至るまでのプロセスの状態と担当者をプロジェクトリーダーがきちんと把握できていない。
詰まる所、そのプロジェクトはおそらく殆どの場合、ウォーターフォール型開発。
だから、たくさんのバグ報告と修正に追われて、収束が付かなくなる。
Redmineには、バグ修正のステータスに特徴がある。
普通は、下記のバグ修正のフローだろう。
新規(Open):テスト担当者がバグ報告する
↓
担当(Assigned):プロジェクトリーダーがPGをアサインする
↓
解決(Resolved):PGがバグ修正する
↓
検証(Verified):テスト担当者がバグ修正を検証する
↓
終了(Closed):プロジェクトリーダーがバグ修正内容を確認する
Redmineでは、更に「却下」「フィードバック」というステータスがある。
「却下」とは、バグ報告を修正せずに終了すること。
例えば、「このバグは仕様なのです」みたいなケースだろう。
「フィードバック」とは「差し戻し」。
例えば、バグ修正して検証したら、実はバグが直っていなかった場合、PGへ差し戻しになる。
上記2項目がデフォルト設定されているRedmineは、実に良く考えられている。
最後に、おそらく上記の3つのうち一つでも欠けたら、多分そこからプロジェクトは炎上する。
ソース管理、ビルド環境、BTSはアジャイル開発のインフラ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
「Redmine」カテゴリの記事
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
「Git・構成管理」カテゴリの記事
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
- 第19回Redmine大阪の見所 #redmineosaka(2019.01.26)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
コメント