チケット駆動開発でアジャイルに開発しながら、「チケットではなくイテレーションで進捗やリスクを追跡する」意味が何となく分かってきた。 それについてメモ。 【1】チケット駆動開発の基本は、チケットファースト。 チケットがXPのタスクカードに相当する。 担当者は、チケットへ作業内容を記入してから、作業を開始する。 開発者は実際、チケットをToDoカードのように用いている。 SW開発のタスクは単にプログラミングだけではない。 お客様へ納品する設計書を作ることも必要だし、テスト仕様書を作ることも必要。 更には、ビルド環境を作ることも必要だし、テストデータを準備することも必要。 すると、チケットは終了するペースよりも登録する方がどんどん増える。 何もしなければ、チケットは乱発されて、放置状態になり、収拾が付かなくなる。 僕が初めてTracを運用した時、マイルストーンやバージョンが曖昧なままチケットを登

チケット駆動開発の戦略part2として、BTSをプロジェクト管理の汎用フレームワークとして使うアイデアをメモ。 #走り書きは後でまとめる。 【元ネタ】 【バグ管理の作法】Trac徹底活用！　第2回：なぜTracの導入に失敗するのか？ 質問「BTSについて教えて下さい」に対するgaryoさんの回答 【1】BTSはシステム開発に特化したToDo用のワークフローとgaryoさんは言っている。 --------↓引用開始↓----------- BTS自体は非常に使いやすいToDo用のワークフローシステムです。 「バグ」として登録している所を「機能(追加・要求)」にすれば開発管理（要求管理）になりますし、汎用的に「タスク」と捕らえればプロジェクト管理になります。 流れとしてはBTS→BTS+プロジェクト管理　となっていくと思います。 ---------↑引用終了↑---------- BTSのチケ

チケット駆動開発(TiDD)について考えていることを書く。 ※注意：チケット駆動開発(Ticket Driven Develpment)の略語は、「TDD」だとテスト駆動開発(Test Driven Develpment)と間違えやすいので、「TiDD」と以降呼ぶことにする。(命名者：えと～さん) 【元ネタ】 チケット駆動開発は、まちゅさんによって提唱されている。 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) 【1】チケット駆動開発のプラクティス チケット駆動開発は定義そのものがあやふやなのだが、僕は下記4個ののプラクティスがあると思う。 ※注意・下記のプラクティスはあくまでも僕個人の考えであることを断っておく。 【1-1】チケット・ファースト(Ticket First) プロジェクト内部の作業は、チケットを受け取ってから始まる。 つまり、工数が発生す

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

「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。 ＃あくまでもメモ書き。 【元ネタ】 ■[development][trac]構成管理ツールをいかにして導入するか ■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？ ■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 ソフトウェア構成管理 【1】バージョン管理が無かった頃 今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。 その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理　にその理由が書かれている。 ほっておくと自然増殖してくるのが、下記のような形式のドキュメント

SIerはお客様の業務をIT化するのがお仕事なのに、自分たちの業務は意外とIT化しきれていない。 大量の印刷した紙、手作業の多い仕事に囲まれている。 ソフトウェア開発のインフラを考えると、最低3個の環境は必須だ。 一つは、ソースコード管理。 二つ目は、検証可能なビルド環境。 そしてBTS。 この3つについて考えてみる。 【1】ソース管理 プログラミングで仕事するならば、ソース管理(SCM)は必須だ。 ソース管理システムの本質は、前回のプログラムへUndoができること。 つまり、プログラムの履歴が残っているからこそ、前バージョンへUndo、Redoができる。 ソース管理は、MSならVSS、普通は、CVSかSubversionを使うのが普通だろう。 ソース管理で重要な作業はブランチやタグ付けができること。 ブランチは、枝分かれしたバージョンツリー。 タグは、ある時点でバージョン付けられたソース

チケット駆動開発の戦略part1として、BTSを構成管理ツールとして使うアイデアをメモ。 #走り書きは後でまとめる。 元ネタは、下記の記事。 チケット駆動開発 ITpro Challenge のライトニングトーク Tracの最大の利点はSubversionとの連携にあり 【1】トレーサビリティ Redmineのチケット管理をずっと続けると、要件からソースコードまでのトレーサビリティをすごく意識する。 実際の運用は下記になっている。 要件・仕様書・テスト仕様書のリンク、説明書き、作業履歴 ←→チケット ←→SVNリビジョン 何度も思うことは、本番リリース後のシステム開発は、リアルタイムに保守されない仕様書よりも、バグ有りで動くプログラムが正しいことだ。 しかも、お客も、バグありの機能を知った上の運用フローを組んでいる。 設計者は、XPのように、動くプログラムを正として、プログラムから機能仕様

Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。 下記の記事を読んで考えたことを書いてみる。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 元請SIerがTracのような環境を提供できない３つの理由 - なからなLife 元請け企業が用意すべきもの - T/O 【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者 構成管理の基本は、任意のバージョンのシステムを再現できること。 今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。 CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。 今でも、Excelなどの設計書はバージョン管理で制

昔、XPlannerというXPのアイデアを実現したWebアプリがあった。 そのソフトは、XPのタスクカード単位で進捗管理できるのがウリだった。 でも、正直使い勝手は良くなかった。 そして、最近、Redmineを触って初めて、XPを実現できそうなプロジェクト管理ツールだと直感した。 Redmineによるチケット駆動開発のアイデアをまとめてみる。 【1】Redmineの特徴は、プロジェクトの進捗の可視化 Redmineの最大の特徴は、ガントチャート。 チケットに作業内容と開始日、終了日を入れると、すぐにガントチャートが出来上がる。 これを初めて見た時は感動した。 プロジェクトリーダーは、ガントチャートを作って保守するために、殆どの時間を費やしている。 WBSさえ作って入力すれば、ガントチャートを自動生成してくれるのだ！ 他に、カレンダーもある。 開発時だけでなく、運用保守時にリリースする日やD

ソフトウェア開発の初期コストと保守コストのグラフの良い記事があったのでメモ。 Miros?aw Jedynak - professional .NET blog: 6 steps to successful Continuous Integration (引用)それぞれの方法について，初期コストと維持コストの対比が提示されているところが印象的。感覚的だけど，このグラフは同意できる。 6つの観点の比較だが、経験的に非常に共感する。 この記事の主張は、「統合ビルドは重要！」の一言。 1. Use source code repository (引用)「SCM使えって当たり前だろ」と思いつつも，未だにOSのファイル共有だけってのもあるからなぁ。現実は小説より奇なりダ。 これは鉄板。SCM使う発想がない時点で，そのプロジェクトは終わってる。 非常に同感。 開発の現場は、教科書よりも奇なり。 SCM

XPのプラクティスの一つが常時統合(CI・Continuous Integration)。 別名、デイリービルドと言われる。 第2世代CIツールと言われるHudsonを使って運用して、常時統合の概念について改めて書く。 #Hudsonの全機能はまだ使いこなせてないので念のため。 【1】バージョン管理(SCM)＋常時統合(CI)＋テスト駆動開発(TDD)で、初めてアジャイル開発が可能になる 【元ネタ】 バージョン管理と常時結合 豆蔵：継続的インテグレーション（CI）をしましょう Subversionでbranches/tags/trunkでソース管理したら、次に行うべき環境構築はビルド環境。 Javaなら、Ant/Mavenでワンクリックでビルドできるようにスクリプトを作る。 今でもビルドする時に、Eclipseから手作業でビルドしているプロジェクトもままある。 ローカルマシンで手作業でビル

OpenPNEというオープンソースのSNSのブランチの説明があったので、メモ。 非常に参考になる。 OpenPNEレポジトリ構造 OpenPNEソースコードは主に4種類のブランチで成り立っています。 1.最新の開発版を反映するトランク 2.リリースの安定版を反映するリリースブランチ 3.将来本線に取り込まれることを予定した、プロジェクトブランチ 4.開発者がバグ修正時や研究時に利用するワークブランチ 最近のソフトウェア開発は、短い期間でリリースしなくてはならない。 特に、1次開発後に機能追加して拡張していく場合、最近はリリース間隔が非常に短くなっている時が多い。 基本的な戦略は、バグ修正と機能追加のバージョン管理を上手に使い分けること。 一つの解決策としては、リリースブランチでバグ修正しながら裏では、trunkで機能追加しながら品質を確保する2系統戦略があるだろう。 例えば、奇数バージョン

バージョン管理システムにはCVSやsubversionなど様々なものがありますが、サーバーのセットアップに抵抗がある人もいるのではないでしょうか？ しかしながら実際のところ、パッケージ化されているので驚くほど簡単にできてしまいます。 今回は、もっとも簡単な手順でSubversionのレポジトリサーバーを構築する方法を紹介したいと思います。 動作環境 今回の手順の動作環境は下記のとおり。OSをインストールしたままの、まっさらな状態を想定しています。 OS Debian Linux etch Protocol http Web Server Apache2.2.3 それでは早速いきましょう。本当に10分間で構築できます。 パッケージのインストール 下記の作業はすべてrootで作業をするものとします。(まっさらな状態を想定しているため、sudoは利用していません。) それでは必要なパッケージをイ

とりあえず、「タスク管理」という言葉がない職場にツールを適応してみている。 やったこと。 プロジェクト管理ツールTracを適応 バージョン管理システムVSSをSubversionに変更し、post-commitでメール配信する 仕様書を全文検索エンジンHyper Estraierの対象にする 予定。 SCRUMのスタンドアップミーティングの適応 CIツールHudsonの適応 これだけでも随分違うんじゃないかな、という感触。 まだ立ち上げ段階だから解らないけれど、 ワークフローという概念が出現し、 ちょうど、Trac 0.11のワークフローカスタマイズが意味を持ってきていてちょうどいい感じ。 trac.iniからしか編集できないのは辛いけれど、 でも、まぁ、ワークフローの意味とか重要さとかが伝われば幸い。 それぞれの効能。 Tracの適応 あれやって、これやってがすべて口頭でタスクが意味不明

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. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が

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

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