「反復型ソフトウェア開発」はソフトウェア工学の良書
「実践反復型ソフトウェア開発」を読んでみたら、構成管理・ビルド管理・障害管理の方法や概念、用語がうまく整理されて説明されていて、とても分かりやすかった。
僕もこんな本を書きたかった。
ラフなメモ書き。
僕が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チケットがソフトウェアかんばん、そして工場内で使われる仕掛けかんばんに似ていることは、リーンソフトウェア開発につながる。
この辺りはもっと整理してみたいと思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
「Redmine」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
「ソフトウェア工学」カテゴリの記事
- なぜInfrastructure as Codeが必要なのか?(2021.04.18)
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
「Mercurial」カテゴリの記事
- GitHubはオープンソースのプロセスを標準化した(2015.06.11)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
- Mercurialに取り込まれたコミュニティ由来の機能一覧(2013.01.12)
- WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg(2012.12.07)
- RedmineでSubversion リポジトリ表示を高速化する方法(2012.11.23)
「Git・構成管理」カテゴリの記事
- なぜInfrastructure as Codeが必要なのか?(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
「チケット駆動開発」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
「Agile」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
「Jenkins」カテゴリの記事
- 第12回東京Redmine勉強会の感想 #redmineT(2017.05.14)
- 技術的負い目の記事がすごい(2016.01.03)
- RedmineとGitLabを連携すると、RedmineをGitHub化できるか(2014.10.17)
- 「チーム開発実践入門」が発売されている(2014.04.08)
- 最近、ツールとプロセスを組合わせたソフトウェア開発手法の本が増えている(2014.04.03)
コメント