「反復型ソフトウェア開発」はソフトウェア工学の良書

「実践反復型ソフトウェア開発」を読んでみたら、構成管理・ビルド管理・障害管理の方法や概念、用語がうまく整理されて説明されていて、とても分かりやすかった。
僕もこんな本を書きたかった。
ラフなメモ書き。

僕がRedmineによるチケット駆動開発を見つけて、ハマった理由の一つは、ソフトウェア開発特有の技術や概念がここにある、と直感したから。
バージョン管理やビルド管理、障害管理は、ソフトウェアに関わる仕事をしている人ならば、必ずかじっている。
でも、実は、バージョン管理やビルド管理、障害管理について、正式な説明も勉強も受けたことがなく、現場で失敗を繰り返してようやく身に付けた技術が多いのではないだろうか？

ソフトウェア開発は、プログラムを書けばそれで終わりではない。
チームでソフトウェアを開発する場合、複数人の作業が衝突しないようにバージョン管理が必要だ。
クライアントアプリを配布したり、Webサーバーへモジュールをりりーするには、ソースからビルドしてデプロイないしインストーラーを作成するビルド手順を自動化ないし定形作業化した方がいい。
テスト中やリリース後に発生した障害は、BTSやITSで管理して、ソフトウェアの品質向上に役立てるようにする。

それらの作業はとても地味だけれども、プロジェクトの成功のための基盤となるものだ。
技術者で生きていく限り、ソフトウェア開発の基盤となる構成管理、ビルド管理、障害管理は常に最新の情報を追いかけるべきだ。
何故なら、それらの技術は時代とともにどんどんパワフルになっているから。
そして、それらの開発基盤は最終的には開発プロセスへ取り込まれる。
開発プロセスの品質を向上させるには、開発基盤の効率化も欠かせない。

ソースをバージョン管理するのは当たり前だが、ブランチをそれぞれの目的に応じて作って、管理しているか？
マージ作業を手作業でやって失敗していないか？
GitやMercurialのような最新のSCMを使って、メインラインとトピックブランチを使い分けているか？

複数チームで開発している場合、いきなりメインラインにコミットやマージするのではなく、段階的統合ブランチを使って、品質が安定したと分かってからメインラインに入れるようにしているか？

保守ブランチとして、リリースブランチ、リリース準備ブランチ、ユーザブランチをそれぞれの用途に応じて使い分けているか？
作業ブランチとして、フィーチャブランチ、トピックブランチ、バグフィックスブランチ、リファクタブランチなどを使い分けているか？

最新版でセキュリティパッチを当てた時、既にリリース済みの古いバージョンへパッチを当てるバックポートを意識して使っているか？

ブランチにおける指定された範囲内のリビジョンをまとめてメインラインへポートするバルクポートと、必要なリビジョンだけを選んでポートするチェリーピックポートを使い分けているか？
(これは、Gitのcherry-pickコマンドと同じ)

ベースとなるソースを更新するリベースを使っているか？

2個のブランチ間でポートを繰り返す双方向マージを行う場合、マージトラッキング機能が強力なSCMを使ってマージ機能を自動化できるようにしているか？

「実践反復型ソフトウェア開発」で興味深い箇所は、構成管理や障害管理の章で、「チケット駆動開発」という単語は出ていないけれども、チケット駆動開発に関わる概念が出ていること。
コミットフック、障害管理票とソースのリビジョンの紐づけは、No Ticket, No Commitにつながる。
BTSを障害だけでなくToDoリストへ拡張することは、Ticket Firstにつながる。
障害管理票がなければ作業を開始しないことは、No Ticket, No Workにつながる。
BTSチケットがソフトウェアかんばん、そして工場内で使われる仕掛けかんばんに似ていることは、リーンソフトウェア開発につながる。

この辺りはもっと整理してみたいと思う。