【1】開発の殆どの現場はIT化されていない 「ソフトウェア開発をIT化する」という言葉は自己矛盾な気もする。 しかし、SIerの開発の現場をのぞくと、作業は実は殆どIT化されていない事実に気づく。 プロジェクトリーダーならば、顧客や上司から下記の報告をいつも求められているはずだ。 1-1・プロジェクトで開発する全機能のうち、今、進捗は何％で、後何％残っていますか？ 1-2・システムテストで上がったバグは今いくつで、後いくつ残っていますか？ 1-3・明日のリリースの前に、今残作業はいくつで、その優先度はどうなっていますか？ 1-4・見積の工数と実績工数の差はどれくらいですか？ 上記の数値を一瞬で出せる現場は、実は殆どないのではなかろうか？ 理由は、顧客や上司が求める数値は引き算で要求されるので、一旦現状の数値をメモリに保持して計算しないといけないから。 プロジェクトリーダーは、上記の数値を毎

TestLinkはオープンソースのWebのテスト管理ツール。 TestLinkがExcelのテスト仕様書よりも素晴らしい点を書く。 【0】インストールが超簡単 XAMP＋TestLinkが一体化されたパッケージがある。 解凍して起動するだけ。 USBメモリに入れて持ち歩くことさえできる。 【1】テストケースを再利用しやすい シナリオベースのテストケースは、運用保守や2次開発でも頻繁に使う。 実際は、1次開発で使ったテストケースを複製して、仕様変更や追加機能を反映させる。 この時、Excelのテスト仕様書から該当のテストケースを抽出したり、変更するのに手間がかかる。 また、テストケースは書く人によって、粒度や書式が大きく異なる時が多い。 後の保守で再利用できなかったりする。 TestLinkの場合、テストケースはDBにあるから複製が簡単。 また、TestLinkの入力フォーマットが固定されて

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が

最近思うのは、ソフトウェア開発のプロジェクト管理とは、ソフトウェア構成管理と表裏一体ではないか、ということ。 プロジェクトリーダーの仕事を見てみよう。 彼らの実際の仕事は、ガントチャートを作って、日々の進捗をガントチャートに反映するのに半日以上かける。 結合テスト以降は、業務シナリオ単位でテストケースを作成し、仕様変更や仕様漏れに対しテストケースを何度も保守する。 そして、テストで出てきたバグに対し、優先順位と期限を決めて、修正担当者・テスト担当者・検証担当者をアサインして回す。 それらのプロセス管理のために、進捗状況やバグ情報、バグが発生した要件を手作業で情報収集している。 プロジェクトリーダーの仕事は本来マネジメント業務なのに、マネジメントの判断材料をそろえる作業に1日の90％以上をかけていないだろうか？ 日本人はプロセス改善が大好きだ。 製造業の影響を受ける組み込み系の人達は、プロセ

Subversionを使ったブランチモデル、バージョン管理戦略がだいぶ分かってきたのでまとめてみる。 ＃走り書きなので後でロジカルにまとめる。 元ネタは下記の記事。 複数のアジャイルチームでのバージョン管理 【1】Subversionブランチが作られるタイミングは、2つある。 一つは、本番リリース直後に作るリリースブランチ。 他方は、突然やってきた大きな機能追加に対応するタスクブランチ。 【1-1】リリースブランチは普通で頻繁に作る。 リリースブランチのライフサイクルは、下記の通り。 これがVer1.0, 2.0とバージョンアップするたびに作られる。 Create：本番リリース直後にtrunkから切られたTagから作る。 ↓ Update：緊急のバグ修正を反映する。当然、trunkにもマージする。 ↓ Delete：次のバージョンが本番リリースされた直後に廃止される。 ここで重要なポイント

TracやRedmineの運用を前提にしたチケット駆動開発は、従来のウォーターフォール型開発のプロジェクト管理とは手法が違う。 下記のBlogを読んで考えたことを書く。 【元ネタ】 プロジェクト管理ツール検討失敗 【1】SW開発ではガントチャート保守のコストが高い 汎用機＋CobolによるSW開発は、プログラミングやビルドのコストが高いから、ウォーターフォール型開発で十分だった。 最初に作った計画が変更されることはない。 しかし、特にWebシステム開発では、実際の受入テストでバグ修正だけでなく、大量の改善要望が発生して、当初の計画や見積もりと食い違う時は多い。 だから、XPなどのアジャイル開発は、小規模リリースというプラクティスを実践して、小さく作って小刻みにリリースして、顧客からフィードバックを受けて更に開発するやり方を取る。 ウォーターフォール型開発なら、ガントチャートを途中で大きく変

デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす

【1】チケット駆動開発は、まちゅさんが最初に提唱されている。 チケット駆動開発 ITpro Challenge のライトニングトーク 上記では「チケット無しのSVNコミットは不可」という思想が強調されている。 これは、本番リリースしたモジュールはチケット無しの場合修正不可、あるいは、プロジェクト内部の作業はチケットを作ってアサインして初めて稼動する、とも言い換えられる。 つまり、チケット駆動開発をプロジェクト管理の基本とすると、チケットに作業プロセスと作業担当者をアサインするのが前提条件になる。 そして、このチケットをバージョン単位にグループ化し、小刻みにリリースするのがチケット駆動開発。 僕がこの手法を運用して、強く意識するものは、チケットの取捨選択だ。 実際のプロジェクトでは、当初の計画した時のチケットの枚数と同じぐらい、バグ修正作業時にチケットが発生する。 つまり予期しない作業が、納