« 2012年4月 | トップページ | 2012年6月 »

2012年5月

2012/05/30

実践アジャイルテストの講演会の感想 #secafe

実践アジャイルテストの講演会に行ってきた感想をメモ。

【元ネタ】
翔泳社 実践アジャイルテスト イベントセミナー

実践アジャイルテスト トークショーつぶやきまとめ #secafe - Yukarin'Note

僕の感想はTwitterに色々書いた。
ジャネットさんの話よりも僕がソフトウェアテストで感じている疑問やいら立ちを書いた。

Twitter / akipii: 個人的には品質の定義がアジャイルとWFで違うと思う。膨大な仕様書と照合して合致すると良いのがWF。回帰テストで確実に動くのを保証するのが良いアジャイル。同じように聞こえるが本質的に違うと思う。

Twitter / akipii: #secafe? 品質はそれ自体追いかけても手に入らないように思う。ソフトウェア特有のプラクティスを複数組み合わせた結果現れるものではないか。品質は掴み所がない。ソフトウェアの品質は特に測定しづらい。

Twitter / akipii: #secafe ソフトウェア特有のテストはポーティングテストだと思う。同じ機能なのに環境やライブラリのバージョンアップや移植ですぐに動かなくなる。システムはウォーターフォール開発で作ってもすぐに陳腐化する。回帰テストがソフトウェア開発はとても重要。

Twitter / akipii: 日本のソフトウェアテストは人海戦術。マンパワーがモノを言う。アジャイルは上流工程よりもテスト工程の自動化を優先する。発想が根本的に違うと思う。#secafe

Twitter / akipii: 仕様書に従って動くのをテストするウォーターフォール開発と確実に動くシステムを早く納品するのをテストするアジャイルはテストの考え方が本質的に違うと思う。 #secafe

Twitter / akipii:アジャイルがこの考え方であるのは理解できる。品質の意味が違う。 RT @digitalsoul0124: ソフトウェアを個別に考えるのではなく、顧客に価値を提供するソリューションの全体像として考えるべき #secafe

Twitter / akipii: 探索テストは経験者でないと効果出ない。バグの再現が難しい。@digitalsoul0124 変更がないのであればテストを自動化する必要はない。価値が提供できるならば、やり方にこだわる必要はない/探索型テストをやらなくてよいほどシンプルなシステムにであったことはない #secafe

Twitter / akipii: 日本のSI企業らしい発想。テスト工程で人を増やしリリース間近で一気に減らす。何か違う。 RT @yattom: #secafe (アジャイルテストの外注という発想がすごい。今日の話をどう聞いてたんだろう)

Twitter / shin_semiya: テストの人海戦術は「意味のある頑張り」か?改善を考えないとにかく力押しが国内には多すぎる気がするんだが。あれ顧客価値をシステム屋の都合で損ねてるだろ #secafe

Twitter / shin_semiya: 手動中心だと「直す時間がないからここは諦めようぜ」が大量に発生して結果として負債積み上がりが発生したので私は好きじゃない。自動化しようぜ。 #secafe

ソフトウェアテストでは、回帰テストがとても多い。
理由は、ソフトウェアそのものとソフトウェアを巡る環境に変化が多いから。
ソフトウェアそのものが頻繁にVerUpするのはSNSでも業務系Webシステムでも同じだ。
それだけでなく、ソフトウェアを配置している環境、つまり、OSやDB、ライブラリなどシステム基盤やミドルウェアのVerUpも頻繁に起きるため、機能がデグレードせずに正常に動くかどうかのテストも重要だ。

2000年代の10年間だけでも、WindowsOSは2000→XP→Vista→7と4つもOSがVerUpしているし、今も毎日セキュリティアップデートと称してOSのVerUpは分からないぐらい多い。
スマートフォンも、iOSやAondroidのOSのVerUpはWindows以上に激しい。
最近のスマートフォン開発では、AondroidOSのバージョンの互換性維持がとても難しく、それがSNSやスマートフォンアプリの開発の足かせになっているように思える。
RedmineもRubyやRailsのVerUpに追いつくのさえ大変だった。
他のシステムやWebアプリも同様だろう。

つまり、ソフトウェアの品質特性の中で移植性(ポータビリティ)は、作業の中身が理解しやすい割には作業がとてもまどろっこしい。
そして、移植性の維持のコストは半端なく大きい。
移植性の品質確保には、継続的インテグレーションによる回帰テストがとても有効だ。
Jenskinsでは、マルチ構成プロジェクトという機能があり、JDKやAnt、Mavenなどのライブラリのバージョンを変えて、同じモジュールを常時ビルドする機能がある。
この機能を使えば、同じソースだが、OSやJDK、C++のバージョンが違って、コンパイルしたビルドモジュールが異なる状況をテストすることが可能になる。
そうすれば、移植性のテストを自動化できる。
移植性の品質は、回帰テストの自動化ととても相性がよいと思う。

清水吉男さんが提唱されているXDDPによる派生開発は、組込製品における移植性に焦点を当てている。
例えば、組込製品はiPod/iPhone/iPadのように、似たような仕様の製品をたくさん作り、カスタマイズしながらVerUpする作業が多い。
すると、以前作ったソフトウェアを流用して移植する作業が多くなり、保守性や移植性の観点のテストが多くなる。
派生開発はそのような現場の困難な状況に対し、一つの解決方法を示している。
その意味では、現場に根ざした開発手法だと思う。

日本のソフトウェアテストは、自動化という発想があまりない。
その理由は、ウォーターフォール型開発によるV字型モデルにテストケース作成が依存しているからだと思う。
仕様がきちんと書かれた膨大なドキュメントを元にテストケースを作りたいために、仕様書をきちんと書かなければならない前提条件が課されているからだ。
確かに、仕様書が正確に書いてあれば、仕様通りに作られていることを確認するテストケースをプログラムを見ることなしで作成することができる。
この方法を中心として日本の品質管理技法は発展してきたように思える。

だが、このやり方は最近壁にぶち当たっているのではないかと思ったりする。
ビジネスの変化、ソフトウェアの変化に仕様書の変更が追いつかないので、品質の良いテストケースを作ることが難しくなっている状況があると思う。
W字型モデルは設計工程でテスト工程の観点や作業を含めて、上流工程の品質向上につなげるやり方だが、実際に動くプログラムを作るわけではないから、実運用は難しいだろうと思う。

形式手法(Formal Method)による品質向上も一部の人に注目されているが、実際の運用例を聞くと、普通では見つけにくいバグ修正や、再現しにくいバグ修正に使われている時が多い。
つまり、ある程度の品質が担保されたソフトウェアに対して、探索的テストの代わりに形式手法を使って再現しづらい細かなバグ修正を行なっているように見える。
その意味では、形式手法もテスト工程の本質的改善策ではないように思える。

アジャイル開発がソフトウェア工学で新しい観点をもたらしたもののひとつは、保守性や移植性という品質に焦点を当てたことだと思う。
リファクタリングやテスト駆動開発は保守性という品質に直結しているし、継続的インテグレーションは移植性の品質確保に役立つからだ。
そして、形式手法、派生開発などの手法もソフトウェアテストの問題の解決に役立てるために生まれたと考えることもできる。

ソフトウェアテストについては色々考えてみたい。

| | コメント (0)

2012/05/28

アジャイルソフトウェアマネジメント

@papandaさんが「アジャイルソフトウェアマネジメント」を読んでいると聞いて、ネット上で検索した結果をリンクしておく。
ラフなメモ書き。

【元ネタ】
制約理論を読みほどく - @IT情報マネジメント

アジャイルソフトウェアマネジメント - PM

日々是感謝: アジャイルソフトウェアマネジメントを考える - その①

日々是感謝: アジャイルソフトウェアマネジメントを考える - その②

日々是感謝: アジャイルソフトウェアマネジメントを考える - その③

日々是感謝: アジャイルソフトウェアマネジメントを考える - その④

日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑤

日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑥

日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑦

日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑧

日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑨

日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑩

制約理論を読みほどく - @IT情報マネジメントを読むと、TOCで出てくるリソースごとのスケジュールのボトルネックを探す手法を使って、ソフトウェア開発プロセスをバリューチェーンとみなして分析するやり方みたい。
バリューチェーンは、リーンソフトウェア開発のバリューストリームマップと同等だろう。
すると、どの工程で待ち時間が多くて、価値を生み出す時間が短くなっているのかを探すことができる。

ScrumやXPの分析では、スプリントないしイテレーションによるタイムボックス開発がそれらのボトルネックを小さくする意味があることが書かれている。
でも、FDD(フィーチャ駆動開発)がお勧めと言う。
多分その意味は、日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑩に書かれている「プロダクト指向」「フィーチャ指向」という考え方から来ているのだろう。

(引用開始)
そして、アジャイルソフトウェア生産システムによる、望ましい適応性のある振る舞いとは、”顧客にとって価値がある正常に機能するコード”で示されるのです。
でした。
これは、アジャイルソフトウェアマネジメントが、完全にプロダクト志向であることを意味しています。
昨日、私はこのように述べました。
でもクライアントにとって重要なのは、時間とコストを費やしたという結果ではなく、クライアントにとって必要なソフトウェア(プロダクト)が、どれだけのスコープでどこまでの品質を確保してデリバリされたかということ。
つまり顧客にとって意味を持つのは、顧客にとって価値がある正常に機能するコード、でしかないのです。そして、顧客にとって価値があるとは、顧客の要求を満たしているものに他なりません。
よってアジャイルソフトウェアマネジメントにおいては、”顧客の要求=フィーチャー”がすべてのベースラインとなるのです。従って、フィーチャー駆動型開発であるべきなのです。
だからアジャイルソフトウェアマネジメントは、完全に顧客志向の、よってプロダクト(成果物)志向の、フィーチャー駆動型の、さらに言い換えると品質駆動型のアプローチなのです。
品質とは誰かにとっての価値である。
ワインバーグ
(引用終了)

もう少し調べてみる。

| | コメント (0)

2012/05/26

Antを見直す

SW構成管理において、ビルド管理はバージョン管理と表裏一体の関係。
ワンクリックビルドできないプロジェクトは、テスト工程の障害管理でリリース漏れやコミット漏れが多発して、進捗や品質に問題が出ているはずだ。

また、継続的インテグレーションを実践するには、ワンクリックビルドするためのビルドスクリプトが必要不可欠。
JenkinsのようなCIツールを使いこなすには、目的に応じたビルドスクリプトが必要になってくる。
最新版のモジュールをビルドするだけでなく、単体テストを実施したり、JavaDocや単体テスト結果を報告したり、FindBugsやLintなど各種メトリクスを出力するなど、ビルドスクリプトには色んな目的がある。
昔から使われてきたビルドツールはmakeだろうが、JavaならAntやMaven、Rubyならrakeが普通に使われているだろう。

Antを使う機会があったので、もう一度見直してみた。
個人的には、Javaを使う環境では、ビルド管理はMavenよりもAntの方が気軽に書けるので好きだ。

【1】AntはXMLで宣言的に書くのだが、逐次実行的に書くこともできる。
ファイルをコピーしたり、消去したり、コンパイルしたり、jarやwarにパッケージ化したりする処理を順番に実行すればいい。
だから、Antを書く気分はシェルライクだ。

Antメモ

もちろん、AntでIf文も書くことができる。Conditionタスクを使えばいい。

AntでConditionタスクを使った条件分岐を行う - てんぷらメモ

Conditionタスク

Antでループ処理を使うには、Ant-Contribライブラリを読みこめばいい。

Ant-Contrib Tasks
Ant-Contrib Tasks

だが、「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」にあるAntのリファクタリングカタログでは、If文やループ処理は書かないことを推奨している。
本来AntはXMLなので、データを記述するために存在しているからだ。

ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」にあるAntのリファクタリングカタログは、Antを書くのにとても役立つ。
特に、ビルドするTask名を処理名よりも成果物名にすべきという考え方はオブジェクト指向に似ている気がする。

Antリファクタリングカタログ: プログラマの思索

【2】AntからMavenへ置き換えられていくだろうと言われてきたが、実際はそこまでMavenが普及しているようには思えない。
Mavenはライブラリのバージョン管理や依存関係を厳格に記述している利点はあるが、IDEによる補完機能やチェック機能がなければシェルライクに書くことはできないだろう。
InfoQでも下記の議論がある。

InfoQ: 議論:Mavenはビルドに適したツールか?

「私にとってのMavenは、ビルドシステムにおけるEJB2です。:複雑すぎて、技術的すぎて、知識を要しすぎます。」という指摘がまさにその通りだと思う。
JavaもEJBやJ2EEにこだわり過ぎて、袋小路にはまった。
Javaはオブジェクト指向やテスト駆動開発(JUnit)を学ぶのにとてもよい環境だが、今はRubyに技術革新の熱気が移っている。

Antでも、Ivyを使えばMavenのようなライブラリ管理が可能。
ビルドスクリプトを自由自在に書きたいならば、こちらのやり方のほうがいいかもしれない。

Ant + Ivy vs Maven - 達人プログラマーを目指して

Ant使いでもMavenのライブラリ管理ができるIvyとは (1/2) - @IT

| | コメント (0)

ストーリーポイントとファンクションポイント法の比較

ストーリーポイントに関するInfoQの記事をまとめたのでリンクしておく。
ラフなメモ書き。

【元ネタ】
InfoQ: ストーリーポイントは複雑さや時間と関係があるか?

InfoQ: ストーリーポイントとは何か?必要ものなのか?

InfoQ: タスクに費やした時間ではなく開発速度をトラッキングする

InfoQ: 価値とベロシティ、そしてバリューベロシティの比較

InfoQ: ストーリーポイントの間違った使い方。

今振り返ってみると、ストーリーポイントの概念はXPが提唱して生まれ、Scrumがアジャイルな開発プロセスに組み込んで厳密に定義したように思える。
ストーリーポイントは、従来のソフトウェア開発から考えると奇妙な考え方だろう。
ソフトウェアの開発規模を表すが相対比較になっているので、厳密な開発規模の単位にはならない。
あくまでも固有のプロジェクトでしか通用しない規模の単位。

元来、開発規模は、ファンクションポイント法で厳密に測定する手法は既に知られている。
また、オブジェクト指向分析では、ユースケースポイント法として読み直す。

下記では、各業界のシステム開発において、1人月で何FP作れるのか、例示されている。
システム開発の見積りのための実践ファンクションポイント法」によれば、15FP/人月がよく使われるらしい。

Sync-K : ファンクションポイントの換算値

だが、ファンクションポイント法の最大の弱点は、測定する工数がかなりかかること。
熟練した経験者でなければ、意味ある測定値を計算できないだろう。
もう一つの弱点は、開発規模をファンクションポイント法で測定して見積もったとしても、予定工数や予定される納期へ変換するには、COCOMOのような汎用的な経験値を使うか、実際のプロジェクトでリリース間際まで経なければ分からないこと。
COCOMOのような経験値を使って工数見積もりしたとしても、その見積りの正当性はかなり怪しい。
そもそも前提条件となるプロジェクトの状況(開発者の能力、チームの能力など)がCOCOMOのような経験値にぴったり当てはまるかどうか怪しいからだ。

それに対して、ストーリーポイントはメンバー全員で相対比較してとにかく早く見積もる。
そして、すぐにイテレーションを実施すれば実績工数が得られるから、Velocityを計算することができる。
つまり、Focus Factor=実際に作った規模/実績工数が計算できるので、
Velocity(見積もったVelocity)=予定稼働工数*Focus Factor
で計算できる。

すると、開発対象のシステムのストーリーポイントを機能単位に洗い出して合算した値から、Velocityで割れば開発期間を見積もることができる。
しかも、実施した1イテレーションでまず見積もれる。
この見積の数値は、COCOMOよりも説得力があると思う。
何故なら、実際にチームが短期間とはいえ1イテレーションで経験した工数を含んでいるから、少なくともその時点のチームの能力を表しているからだ。
そして、イテレーションをこなすたびにVelocityを測定していけば、チームの能力に見合った見積りを測定することができるだろう。

アジャイル開発の利点は機能単位の小刻みな小規模リリースだけではなく、チームの現在の能力に見合った見積りを提示できる点にもある。
顧客に、現在のチームの能力ではこれぐらいの期間でこれぐらいの機能(規模)を提供できます、とイテレーションのたびに説明できるのは、ウォーターフォール型開発よりもとても有利だ。

特に「アジャイルな見積りと計画づくり」で提示されたScrumによるストーリーポイント見積りは、見積りが計画づくりの重要な作業であることを認めた上で、見積りの手法やその注意点を細かく説明している点がとても優れている。

アジャイル開発の見積りで面白いのは、実績工数よりもVelocityを追跡することに注力することだ。
予定していたVelocityと実績のVelocityを各イテレーションで計測しながら、次のイテレーションの見積りに使う。
実績工数にこだわると、いかに時間をかけずに仕事するか、に開発者の意識が寄ってしまって、手抜き作業が起きる可能性もあるからだろう。
また、実績工数は規模や難易度によって大きく変わるから、あまり当てにならない。
Velocityの計測を追跡することによって、チームの能力をいつも気にかけるようになり、XPの言う「持続可能な開発ペース」を保持するのにも役立つ。

ストーリーポイントやVelocityはアジャイル開発特有の概念であり、その概念の意味はとても奥深い。
Redmineによるチケット駆動開発を通じて、WF型開発でよく使われるFP法やEVMとは全く違うこともよく分かった。
こういうメトリクスを計測できる環境をチケット駆動開発は提供してくれるからこそ、色々思索することもできる。

| | コメント (0)

2012/05/23

個人タスク管理ツール かんばりすと

平鍋さんのツイートから、個人タスク管理ツールを知ったのでリンクしておく。

【元ネタ】
Twitter / hiranabe: 個人タスク管理ツール、「かんばりすと」 http://bit.ly/Lgu2Iy

かんばんりすと

volpe28v/kanban-list

Railsで作られた簡単な個人的なかんばん。
アジャイルなツールは何故かRailsと相性が良いのかなあと思ったりする。
Redmine、Fulcrum、PivotalTrackerなど。

他にもTrelloというツールがあるらしい。
こちらの方が運用しやすいかもしれない。
Joel on Softwareで有名なJoel Spolsky氏が作ったらしい。

Log In | Trello from Fog Creek Software

タチット: Trelloを業務で使ってみた

オフィスのホワイトボードを止めて「Trello」を使うべき理由【増田(@maskin)真樹】 : TechWave

最近思うのは、アイデアが優れたWebのツールが増えた気がする。

チケット駆動開発を元に僕がソフトウェア開発のプロジェクト管理で色々実験できるのも、Redmineという優れたツールがあり、色んな場面で適用できるからだ。
しかも、ソフトウェア開発の3種の神器のように、ツールを組み合わせれば、新しい使い方が生まれて、更に新たな考え方を手に入れることもできる。
ソフトウェアがようやく時代に追いついたという気がする。

上記のツールも、入力されたチケット(PostIt)をどのようなViewで見せると個人のタスク管理で効果的なのか、という発想を元に実現しているように見える。
その場合、ワークフローは微妙に違うようだ。

Pivotal TrackerのワークフローはFeature、Bug、Supportなどいくつかあるが、それぞれで微妙にワークフローが違うらしい。

Pivotal Tracker におけるストーリーの状態遷移 - ursmの日記

その理由はもちろん、それぞれのワークフローを使う場面が違うからだろう。

色々考えてみる。

| | コメント (1)

2012/05/19

第3回品川Redmine勉強会の感想 #47redmine

本日開催された第3回品川Redmine勉強会をUstで見た感想をメモ。

第3回shinagawa.redmine勉強会 : ATND

第3回勉強会 - shinagawa.redmine

shinagawa.redmine 第3回勉強会 - Togetter

【1】Redmineコミッタの@marutosijpさんが、RedmineをRuby1.8→1.9, Rails2.3→3.2へVerUpした経緯やその作業内容について解説してくれた。
僕としては、既存機能をデグレードさせずに環境周りをVerUpするいわゆるポーティング作業は地味だけれども難しい作業だと経験的に思う。

ポーティングとは【porting】(移植) - 意味/解説/説明/定義 : IT用語辞典

RedmineがVer2.0でRails3へ移行予定: プログラマの思索

Twitter / @akipii: #47redmine ポーティングの例としてはCentOS5→6、JDK1.4→6、Apacheのセキュリティパッチ当て、WindowsUpdateなどたくさんあって、どれも結構神経を使う割には頭を使わない。面白くない作業だけどシステムの延命を考えるととても重要。

ポーティング作業の難しさは、テスト工数と納期のバランスを取ること、OSやライブラリのバージョンアップによってソースの修正が発生するバージョン管理の2点にあると思う。
既存機能に影響がないことをテストするために回帰テストすればよいが、古いシステムほどテスト自動化などないので、手作業のテストになり、どこまでテストすれば良いのか、判断を下しづらい。
だから、この機能は既にテストされたので品質は担保されている、などといった「みなしOK」の判断を下して、テスト工数を削減したりする。
でも、みなしOKの判断を誤ってテスト漏れが発生したりするから、サジ加減が難しい。

また、バージョンアップ前と後のソースを別々にブランチ管理する作業があったり、バージョンアップ前のソースからどのソースを最新の環境に持っていくべきか精査する作業が発生するため、バージョン管理が面倒になる。
だから、前者ではベンダブランチのような並行開発が必要になってくる。
後者は手作業で逐一ソースを精査するしかない。

でも厄介なのは、既存バグを発見したけれども、VerUp後のソースで直してしまうと、既存のソースにもバックポートする作業が発生する時だ。
特に、古い環境と新しい環境を並行稼動するような業務システムの例では、バックポートの作業を忘れると、せっかく直したバグ修正をバグとみなされてしまい混乱してしまう。
だが、古い環境で本番運用されている場合、すぐにバックポートの作業ができるわけではないから、既存バグをきちんと記録しておき、並行運用中に直すというやり方を採用するときもあるだろう。

バックポートとは【backport】 - 意味/解説/説明/定義 : IT用語辞典

他に、下記のような意見もあり、僕はすべての現場を知らないので何とも言えない。
でも、他の言語やフレームワークなどのポーティング作業(例:CentOS、JDK、Apache、Androidなど)は、今はそんなに楽になっているのだろうか?
例えば、MSがWindowsOSの後方互換性の維持にこれだけ大きな手間をかけているのを見ると、ポーティング作業がそれほど楽なようには思えない。
最近では、AndroidOSのバージョンの違いや後方互換性で、スマートフォンメーカーが苦しんでいるように見える。
とは言え、RailsはVerUpで大きく変わりすぎたし、Redmineインストールに苦しんでいる人が多いのを見るとそうなのかもしれない。

Twitter / @sakaba37: 同意! RT @akipii: Rubyだからこそアジャイルに開発できたのかも RT @kondoujp: Redmine 2.0 はよく頑張った! って思うし、素直に褒め称えられる。しかし、背景を考えると Ruby や Rails 捨てた方がいいようにしか思えない。

Twitter / @kondoujp: @akipii アジャイルなスタイルで開発を行うことと仕様の不安定さは全く層が異なる話です。はっきり言って、ユーザーとしては使いたいものはサービスであって、Ruby であるとか Rails であるというのはどうでもいいんです。その点で「よろしくない」と思いますよ。

Twitter / @kondoujp: @akipii 他の言語/フレームワークでは、バージョンアップにここまで手間がかかる事の方が不思議なんですけど。「これだけ短期間に VerUp できた」ではなく「VerUp にここまで時間がかかった」という認識です

【2】@tech_machiiさんのLotusNotesからRedmineへの移行作業の事例も興味深かった。
僕の感想は下記に書いた。

Twitter / @akipii: #47redmine Redmineは中途半端に万能・・なるほど。Redmine導入はERP導入やCMMI導入に似ているなあと後で思います。導入工数と運用のバランスかなあ。。

Twitter / @akipii: #47redmine redmineのRails3.2へのポーティング、現行業務をチケット駆動へデータ移行という発表を聞くと、こういう地味な開発が現場の業務システム開発でも多いのに気づきます。人の話は役立ちますね。

RedmineはOSSの割には高機能なので、何でもできそうなイメージがあるが、実際はどの業務をRedmineで代用し、他の業務を従来の手運用ないしExcel運用でカバーするか、という切り分けが難しい。
移行作業の工数は無限にあるわけでもないし、納期もあるから、いかに短期間で成果を出していくか、という戦略が大切になる。
似たような話として、ERP導入やCMMI導入では、導入や運用の失敗事例の話が山ほどある。

Redmine導入はERP導入に似ている #tidd: プログラマの思索

ポーティング作業や移行作業の事例を聞くと、業務システムの受託開発に似ているなあと思う。
案件は、いつも綺麗な新規開発ではなく、ポーティングやデータ移行などの地味でつまらない案件も多い。
でも、そのような案件は特にプロジェクト管理の質が良くないと失敗しやすいように思う。

【3】IPAの定量的プロジェクト管理ツールのお話もあった。
RedmineやTracを定量データの収集場所とみなし、データを集計してプロジェクト管理に役立てる発想として作られたらしい。
過去のソフトウェア工学やエンピリカルアプローチは、本来はこのようなツールを基盤として研究されるべきではなかったのか、と思う。
何故なら、RedmineやTracのようなツールがなければ、データ収集に工数がかかりすぎて肝心のプロジェクトの進捗に害があるからだ。

IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索

Twitter / @akipii: #47redmine redmineの利点:SCMリポジトリとBTSの両方のデータを一括集計できる。更新履歴が必ず残るのでシステム監査や追跡に使える。Webのデータマイニング機能で、開発者の作業ログを緩やかに収集・集計する仕組みがある。

Twitter / @akipii: #47redmine RedmineやTracが無かった頃の人は、どうやって定量データを収集してメトリクスを集計していたのか気になります。多分帳票やExcelを自ら手作業で収集して、手作業でExcel集計(又は手計算)していたのだろうなあ。。昔の人はよくやっていたと思う。

チケット駆動開発の面白さは、アジャイル開発と相性が良い点だけでなく、マネージャをサポートするソフトウェアメトリクスの出力という一面もある。
メトリクスの分析や使い方は罠や癖があるけれども、見える化の一部として使えるだろうと思う。

メトリクスを使った品質管理の技法は、従来の日本の製造業が得意とする開発スタイルだ。
RedmineでWF型開発を行う場合、メトリクスを使う品質管理は相性が良いだろうと思う。

【4】@g_maedaさんのお話も興味深かった。
Redmine.jpにはいつもお世話になっています。

Redmine.JP

Home | Redmine.JP Blog

Twitter / @hell0_wor1d: 前田さんの優しい話し方、Redmine愛を感じる #47redmine

Twitter / @akipii: #47redmine OSSの貢献はソースコードの公開だけでなく、ツールの紹介や情報公開もあるというお話。実際に行動されているだけあって説得力あります。

Redmineが日本でこれだけ普及した理由の一つは、Redmine.jpがポータルサイトとなっていて、初心者から上級者まで誰もが参考に出来る情報が発信されていることだと思う。
単なるリンクの羅列、Wikiの日本語訳、VerUpされた内容の掲載だけでもとても役立つ。

Redmineコミュニティの利点は、日本人コミッタ(@marutosijpさん)がいることと有用な情報が一箇所に集まっているポータルサイト(Redmine.jp)があることだと思う。
コミュニティがツールの発展を支える良い事例の一つになっているのかなあと思う。

他にも@tkusukawaさん、@basyuraさんのお話も興味深かったです。

【5】個人的には、ChiliProjectがA Successful branch modelを採用して一部混乱した時があったという指摘、そして、Redmineではrebaseを多用してtrunkのリビジョンが一直線になるメインラインモデルを採用して混乱なくVer2.0をリリースできたという事実について、その背景を聞きたかった。

Twitter / @cointoss1973: 今日の #47redmine の個人的テーマ: Redmineと連携するリポジトリは、(Gitよりも)Mercurialがオススメという理由がよく理解できていないので、まるやまさんに聞いてみたい

Twitter / @akipii: 明日の予習。いかにRedmineのメインラインを守ってきたのかというバージョン管理の考え方が分かる。 Redmine 2.0 リリース ? shinagawa 20120519 v0.1 documentation http://goo.gl/PvRds

Twitter / @akipii: trunkはrebaseを使うべきだ、ChiliProjectのRevision graphはdirtyと言う指摘に対し、git-flowモデルだから同意しないという回答。価値観の違い。ChiliProject - Bug #127 http://goo.gl/cTxI9

Twitter / @akipii: git-flowのバージョン管理手法は小規模プロジェクトでしか通用しない。pull requestは大規模オープンソースプロジェクトにはそぐわない。メインラインモデルが一番という指摘がある。明日のRedmine勉強会資料は参考になる http://goo.gl/PvRds

A Successful branch modelの考え方はgit-flowというGitツールで実装されている。
その考え方はとても面白かったので、いろいろ考えていた。

git-flow による構成管理とRedmineの関係: プログラマの思索

しかし、そのモデルは小規模プロジェクトでしか通用しないという理由がきちんと分かっていないので、経験者から聞いてみたかったなあと思う。
実際、GitHubにあるChiliprojectとredmineをクローンしてコミット履歴を見れば、その違いがよく分かる。

Twitter / @akipii: GitHubからChiliprojectとredmineをクローンしてgit logを見た。Chiliprojectのリビジョンブラフは分岐が多くたくさん手が入って複雑。redmineのリビジョングラフは一直線でコミットログにマージ作業が書かれているので分かりやすい。

この点は資料を解読してみる。

| | コメント (0)

2012/05/17

EVMとバーンダウンチャートは本質的に違う

EVMとバーンダウンチャートは本質的に違うことを指摘している記事を見つけたのでメモ。
ラフなメモ書き。

【元ネタ】
バーンダウンチャート / バックロググラフっていいね。 - 遅れなんか見たくない。いつ終わるかを見たいんだ。: 円山貫’s EYE on high-tech development

【1】
(引用開始)
■ 縦軸に見積もり工数を取った場合、工数ベースのEVMS(*)をひっくり返した形に近い。
(中略)
※(バーンダウンチャートでは)プロット毎に残作業を見積もるということは、過去作業の作業効率から完成時コストを延長推定する(簡易)EVMSよりも本質的には厳密なもの。アジャイル精神、開発チームが作業をコントロールするためのツールとして使うのは楽しいが、超精密管理感覚で上から強制実施すると、むちゃくちゃ苦しくなりそうな、危ないグラフでもある。(※追記:2005.7.26)
(引用終了)

バーンダウンチャートはEVMの工数を残工数へひっくり返した形である指摘は、僕も同じ意見だ。
アジャイル開発の方が管理作業は第三者から見れば楽そうに見えるが、アジャイル開発の方が作業の終了基準が厳しいため、「超精密管理感覚で上から強制実施すると、むちゃくちゃ苦しくなりそうな、危ないグラフでもある」。

(引用開始)
■そもそも、EVMSとバックロググラフ(バーンダウンチャート)では、根本的な発想が違う。
EVMSは、計画(WBS)を絶対視したうえで期間と費用の計画偏差を是正しようとする。ベースライン計画に如何に収束させるか、という発想で、予算化した計画を動かすことはほとんど拒否する。
バックロググラフでは、期間固定で、計画(WBS)が流動するものとする。一定期間内に出来ることでとにかく切りをつけよう、という発想になる。
(引用終了)

EVMSとバーンダウンチャートは根本的に発想が違う指摘は全く同意。
PMBOKにせよ、WF型開発にせよ、最初に立てた計画から実績がどれだけずれているかを追跡して、いかにその変化を抑えこむか、という発想でコントロールする。
しかし、アジャイル開発はその発想がそもそも無い。
イテレーション計画は当然作るが、イテレーション実施中に、イテレーション計画の作業順序は頻繁に変わるし、流動的だ。
2~4週間という短い期間で全ての作業を終了させるには、計画にしがみつくよりも、その実績に応じてやり方を変えていく。

計画を立てて実績のズレを検証し、その内容をフィードバックしていくという仮説検証スタイルはアジャイル開発だけでなく、WF型開発でもよく言われている。
検証した結果、計画が間違っていたら計画を修正ないし、新しく作りなおせばいい。
しかし、計画を変更してしまうとWF型開発では当初の予算も変わってしまうため、修正することがとても難しい。

そんなことを考えながら、「アジャイルな見積りと計画づくり」や「ソフトウェア見積り―人月の暗黙知を解き明かす」を読み直すと、計画と見積りは密接に関わっている事実、更にそこにはもっと深い考えがあるような気がしている。

【2】@daipresentsさんのredmine_version_burndown_charts画面では、Scrumの考え方をさらに注入して、面白いメトリクスを表示してくれる。

理想ラインが加わったredmine_version_burndown_charts画面: プログラマの思索

(1)「予想ライン」が予定工数から計算される残工数、「実績ライン」が実績工数と進捗率から計算される残工数。
(2)理想ラインは、該当バージョンの開始日から期日に向けて残工数がまっすぐ下がっていく残工数。
(3)上限ライン・下限ラインは、予定工数の±20%という設定から計算される理想ライン。管理図のようなもの。
(4) 本来のバーンダウンチャートは、理想ラインの付近で表示されるのが望ましい。理想ラインから離れるほどタスクがあふれていることを示している。

また、バーンダウンチャートの下がり具合を調べると、チームの成熟度や能力を予想することもできる。

バーンダウンチャートのパターン集: プログラマの思索

上記の「上限ライン・下限ライン」枠内にバーンダウンチャートが収まっているならば、そのチームはそのイテレーションを完全にコントロールできていると言えるだろう。
でも実際のプロジェクトでは、「上限ライン・下限ライン」枠外に残作業が残ってしまって、アップアップになってしまう状況も多い。

また、バーンダウンチャートをRedmineで実際に運用するのは、結構面倒だ。
チケットに開始日、終了日、予定工数、実績工数を毎日正確に入力してもらわないとチームの実情にあったグラフにならないからだ。
この辺りの運用はまだまだ改善の余地はある。

| | コメント (0)

2012/05/12

チケット管理は商品管理のモデルと同等なのか

RedmineでWebショップの商品管理を実現した記事を見つけたのでメモ。

【元ネタ】
Redmine でWEBショップの商品管理をしてみる | まったり覚書

(引用開始)
$REDMINE_HOME/config/locales/ja.ymの文言をそれっぽく修正します。
プロジェクト→ショップ
チケット→商品
作業時間、時間→売上
トラッカー→商品種別
バージョン、ロードマップ→納品計画
ワークフロー→商品の流れ
開始日→納品日
期日→回収日
題名→商品名
予定工数→売上目標
時間を記録→売上(税込)
報告したチケット→登録した商品
(中略)
1. 作業時間を金額として利用する場合に、そのままだと1000までしか入力できないので、桁数のチッェクを外します。
2. 時間表示部分を金額表示に変更します。
(中略)
ステータス(商品の状態)とワークフローを商品管理っぽく設定します。
使いそうなカスタムフィールド(納品先、納入価格など)を追加します。
扱う商品種別(トラッカー、例:アクセサリなど)を設定します。
商品のカテゴリ(チケットのカテゴリ)を設定します。
(引用終了)

面白い点は、プロジェクト管理ツールの概念を商品管理のモデルに変換できるという事実だ。
チケットを商品と同じ概念とみなした場合、チケットの各属性は商品の属性に置き換えられる。

チケットNo→商品ID
題名→商品名
説明→商品の説明
開始日→納品日
終了日→回収日
カテゴリ→商品の分類
ステータス→商品の状態(未納品、納品準備中、納品済、販売済、入金済、返品)
トラッカー→商品の種別(アクセサリ、雑貨、家電AV、パソコン)
バージョン→毎月の締め日
予定工数→売上目標
実績工数→日々の売上

つまり、工数集計の機能が売上集計の機能に置き換えることもできるだろう。

UMLモデリングの本質」では、アナリシスパターンの勘定パターンが在庫モデルに適用できることを説明しているが、それは、会計と在庫という概念モデルとしては性質が異なるはずなのに抽象的なモデルでは構造が似ていることを意味している。
同様に、チケット管理のモデルも商品管理とモデル的に同等なのかもしれない。

チケット管理のモデルは、基本はデータを蓄積するモデルだと思う。
イメージは、大量のチケットが蓄積される仕組みが前提であり、その蓄積された情報をガントチャート・タスクボード・バーンダウンチャートなどの各種ビューで分析できる仕組みを提供するモデル。
これはいわゆる情報系システムと同じ構造だと思う。

商品管理の場合、毎月の売上集計が単に蓄積されていくだけならば、チケット管理のモデルと同じ。
だが、商品管理に会計モデルの概念を導入すると、フロー(売上・費用)だけでなくストック(資産・負債)という概念も出てくるので、チケット管理の仕組みだけでは実現できない部分も出てくるだろうと思う。

エリック・エヴァンスのドメイン駆動設計の本では、船舶の輸送モデルをドメイン分析していくと船荷証券(つまり荷為替手形ないし未着品)のような概念が出てきた例や、利息サービスの計算をドメイン分析していくと発生主義会計(つまり経過勘定科目、例えば未払利息や受取利息など)の概念が出てきた例が載っている。
それらが意味するのは、プログラムやシステムという実在の動く論理モデルを抽象化すると、以前から知られている概念と同等になるということなのだろう。
すると、ドメイン駆動設計とは、システムのアーキテクチャをビジネスで知られている概念に結びつけて、本質的な意味を与えるものなのかな、とか思ったりする。

Agile開発に足りないもの~モデリング技術: プログラマの思索

【告知】SEA関西ではOOA、関西IT勉強宴会はDOAの勉強会あります: プログラマの思索

広中平祐著の「学問の発見」の一節に、フィールズ賞を受賞した業績である定理を証明する時、恩師の方から、問題をもっともっと難しくして理想的な形にすれば解けますよ、とアドバイスされたそうだ。
我々IT技術者も、現実のビジネスモデルを抽象化したモデルにマッピングして設計していく時、違う業界のモデルが同等に見えるレベルまでどんどん抽象化していくのがいいのかもしれない。

【追記】
@hino666さんのつぶやきから、平鍋さんが以前説明されていたモデルの4象限を思い出した。
問題→解へいきなり解くには難しい場合、問題→分析モデル→設計モデル→解の道に進む方法もある。
モデリングは、児玉公信さんが言われている「モデルの揺さぶり」が大事だと思う。
作ったモデルに対して、色んな仕様変更を想定しながらモデルをより汎用的に抽象化して、洗練させていく。

Twitter / @hino666: 具象(業務問題) →抽象(モデル) →具象(解決システム) ≫ チケット管理は商品管理のモデルと同等なのか: プログラマの思索 http://forza.cocolog-nifty.com/blog/2012/05/post-67d5.html

Twitter / @masayh: 分析モデル、設計モデル、実装モデルの違いは平鍋さんのブログをご覧ください。http://blogs.itmedia.co.jp/hiranabe/2010/12/vsug-architect.html アーキテクトの思考法にもなっている非常に重要なものです。4象限の絵。

VSUG アーキテクトアカデミーで講演しました:An Agile Way:ITmedia オルタナティブ・ブログ

| | コメント (0)

2012/05/11

「アジャイルソフトウェアエンジニアリング」におけるプロダクトバックログの考え方

アジャイルソフトウェアエンジニアリング」が発売されるらしいのでリンクしておく。
サンプルとして9章がフリーで読める。

【元ネタ】
『アジャイルソフトウェアエンジニアリング』発行記念 | 日経BP社 ブックス&テキスト Online

[書籍] アジャイルソフトウェアエンジニアリング | 長沢智治のブログ | 一伝入魂

「アジャイルソフトウェアエンジニアリング」という本が出版されます - かおるんTFSダイアリー

アジャイルソフトウェアエンジニアリング」はMicrosoftのTFSを題材とした本。
MSのようにソフトウェア開発にとても経験のある企業でさえも、Conwayの法則から逃れられないという経験則は興味深い。

サンプルの9章を読んで興味深かった点は、プロダクトバックログの作成方法だ。
それ以外のアジャイルな考え方は、多分普通だろうと思う。

MSでもフィーチャ(機能)を基本として、フィーチャをタスクに分割してソフトウェアを開発する。
その弱点は、知らないうちに過剰生産してしまうこと。
つまり、無駄に機能が増えて使いづらいUIになったりする危険があること。
リーンソフトウェア開発でも言われているように、製品の過半数の機能はユーザが使い方を知らない機能ばかりになって複雑化してしまう。

そこで、フィーチャに階層構造を導入して、開発者の観点だけでなく顧客やビジネスの観点も入れるようにした方法が書かれている。
上記では、シナリオ>エクスペリエンス>フィーチャという階層構造でまとめる。
シナリオは、製品を使った場合に具体的な顧客価値を定義する。「もし○ができたら購入したい」というイメージ。
エクスペリエンスは、開発者が顧客へ具体的な価値を提案する。「○のやり方を教えましょうか」というイメージ。
フィーチャは、ユーザストーリーないし実際の機能。

アジャイルな見積りと計画づくり」にあるエピック>テーマ>ストーリーの概念と上記のシナリオ>エクスペリエンス>フィーチャは1対1に対応するように作られているらしい。
MSがアレンジしているのは、シナリオに「基本項目」「顧客の不満因子の除去」というカテゴリも入れていること。

基本属性シナリオの例として、互換性、信頼性、パフォーマンス、グローバル対応などが挙げられているが、これは品質特性を意味しているのだろう。
つまり、顧客にとって価値ある機能は目に見える使い勝手だけではなく、製品全体を貫く品質特性(信頼性、可用性など)も当然含まれるわけだ。

顧客の不満因子の除去シナリオの例として、優先順位の低いバグや小さい便利なフィーチャを指している。
わざわざ顧客の不満因子の除去というシナリオを作っている理由は、これらのフィーチャは個別にトリアージした場合通常は修正対象外となるが、積もり積もれば大きな障害やユーザ離れの原因になるので、一つのシナリオにまとめて、他のシナリオと同じレベルで優先順位付けできるようにしたいから。
このやり方は、要件のトリアージで見落としがちな顧客価値を敗者復活戦で復活させる重要な仕組みなのだろう。
そういう意味では、MSはプロダクトバックログの良さと悪さを十分に経験しているように思える。

TFSは個人ではとても購入できるツールではないが、その考え方はチケット駆動開発にも適用できる。
チケットをストーリーカードに対応付けて、エピック>テーマ>ストーリーの階層構造を親子チケットで表現して、それぞれの階層で観点を使い分ければいい。
PivotalTrackerやFulcrumのようなストーリー駆動のタスク管理ツールと併用すれば、より面白いかもしれない。

アジャイルソフトウェアエンジニアリング」は良い本のような気がする。

| | コメント (0)

2012/05/09

チケット駆動開発に分散バージョン管理を組み合わせるアイデア

チケット駆動開発に分散バージョン管理を組み合わせるアイデアについてラフなメモ書き。

【元ネタ】
TiDDとgit-flowを合わせた開発手法について | Technology-Gym

gitとRedmineと連携させるgitサブコマンド: git-ticket - みずぴー日記

Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技:ゆめみスタッフブログ)

PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み: プログラマの思索

git-flow による構成管理とRedmineの関係: プログラマの思索

Mercurialによるチケット駆動開発は強力だ!: プログラマの思索

Mercurial以前と以後のチケット駆動開発: プログラマの思索

RedmineのVer1.4からマルチSCMリポジトリ機能が実装されたことによって、trunkとトピックブランチなどの派生ブランチも一つのプロジェクトに含めることができる。
すると、トピックブランチ上で修正したパッチをtrunkへマージしてもらう時に、GitHubのPull requestと同様の機能をRedmine上でも事実上実現できる。
すなわち、trunkからトピックブランチを派生する場合は、folkするチケットを作ればその作業履歴が残るし、トピックブランチをPullする場合は、どのリビジョンのソースをとり込んだのかをコミットログのチケット番号に書いておけば、チケットにコミット履歴が残る。

特に、@haru_iidaさんが作られたCodeReview Pluginには、チケットの属性にリビジョンがあるので、folkやpullする場合にCodeReviewプラグインを使ってもいいかもしれない。
そうすれば、チケットのリビジョンにコミット履歴が残るようになり、後から検索しやすくなる。

Redmineのリポジトリ参照画面では、GitやMercurialのような分散バージョン管理の場合、git log --graphやhg log --graphのような色つきブランチが表示されるので、どのようの派生してマージされたのかが分かりやすい。

以前の僕は、Redmineのバージョンが古くて機能が限られていたため、Redmineの複数プロジェクト機能を並行開発に適用して、ブランチ単位にプロジェクトを割り当てるように運用していた。
この手法は、確かに製品単位のタスク管理には有効だが、トピックブランチのようにブランチの生存期間がとても短い場合はあまり向かない。
つまり、ブランチの生存期間と製品の生存期間が対応している場合は、複数プロジェクト機能を使ってプロジェクトを分割した方がいいが、分散バージョン管理のように実験的なブランチをどんどん作る場合にはあまり向かない。

だから、一つのプロジェクトで、派生したブランチは全てまとめる方がチケット駆動開発に向いているかもしれない。
git-flowのように、各種ブランチを目的を持って作り、最後はmaster(trunk)へマージして育てていく開発スタイルには、チケット駆動開発を組み合わせればより強力になるだろうと思っている。

| | コメント (0)

2012/05/08

Redmineのチケット一覧でラベルが消えてしまう症状

IEでRedmineのチケット一覧画面を開くと、チケットのタイトルなどのラベルが消えてしまう質問を受けた。
下記にもその事例や対応方法が書かれていたのでメモ。

【元ネタ】
日々是精進。: チケットが消えちゃう??

徒然さめざめ Redmineのチケット一覧で文字列が消えちゃう件についての対応

原因は、IEで使用するcontext_menu.jsの処理がおかしいことらしい。
FirefoxやChromeでは正常動作するので、IE特有のバグらしい。

| | コメント (0)

2012/05/06

Subversion・Git・Mercurialの比較

Subversion・Git・Mercurialの比較のために過去の記事や関連資料をリンクしておく。

【比較】
SVN / Git / Hg 比較表 ? TortoiseGit Japan

【Subversion】
Subversion によるバージョン管理 svnbook.ja.pdf

Subversionを見直せ: プログラマの思索

Subversion/運用方法 - ピノキヲ IT Wiki

【Git】
Pro Git 日本語版: プログラマの思索

A successful Git branching model: プログラマの思索

git-flow による構成管理とRedmineの関係: プログラマの思索

【Mercurial】
Mercurialの資料: プログラマの思索

hgbook 日本語版のHTML公開: プログラマの思索

CVS→SVN→Git・Mercurialへ至る歴史を振り返ると、ソフトウェア開発を誰もが気軽に始められるようになったのが分かる。
達人プログラマー―システム開発の職人から名匠への道」はプログラマの心構えを書いた本で僕は一番良い本と思うが、2003年頃に読んだ頃はバージョン管理はCVSやVSSが主流だった。
しかし、SVNそしてGit・Mercurialが出現して、プログラミング技術も大きく変わったように思う。

Redmineによるチケット駆動開発を実践して、アジャイル開発に適用してみて、いつも感じる疑問は「ソフトウェア構成管理とは何なのか?」。
バージョン管理は構成管理の一部にすぎないけれど、この10年で最も大きく進歩した技術だと思う。
その疑問をずっと考えている。

| | コメント (0)

2012/05/03

msysGitがUTF-8 をサポート

msysGitがUTF-8 をサポートしたらしいので、インストールしてみた。

【元ネタ】
msysGit(Git for Windows)がいよいよ公式に UTF-8 をサポート! - てっく煮ブログ

UTF-8 対応の msysGit 1.7.10 リリース! いよいよ Windows で git できるよ!!! - てっく煮ブログ

Techno Pocket - Technical Memo - Git勉強環境 on Windows 構築メモ

msysgit v1.7.10 のインストールと日本語入力の暫定対応 - アジャイルSEを目指すブログ

小粋空間: Github を Windows で利用する(Git GUI編)

Windows 上に Git 環境を構築する方法(TortoiseGit と msysGit) | 日本Symfonyユーザー会

Git/一人で使ってみる(msysgit編) - 俺の基地

コマンドプロンプト上で日本語ファイルもコミットできるし表示もできる。
サーバーのGitリポジトリにPushしてもうまくいくみたい。

git init
git add テスト.txt
git commit -m "テスト.txtをコミット"
git log --graph
git log --stat

Mercurialの方が慣れているけれども、Gitでも違和感はない。
分散バージョン管理の考え方はどちらも同じだから。

こういうツールに触れて思うのは、XPが提唱したプラクティスを実現するツールがようやく生まれて、アジャイル開発というアイデアが時代に追いついたことだ。
XPのプラクティスである継続的インテグレーションがJenkinsというツールを生み出し、小規模リリースという概念をサポートするためにTracやRedmineというツールが必須なように、ソースの共同所有はGitやMercurialというバージョン管理ツールを必要とする。

バージョン管理は単なるソースのバックアップではない。
達人プログラマー―システム開発の職人から名匠への道」の初版に書かれているように、ソース修正のUndoやRedoをサポートするために存在するツールなのだ。
修正履歴をたどれるから、誰がこの行を変更したのか、今のバージョンと先週のバージョンは何が違うのか、などを探すことができる。
つまり、バグの追跡や監査、品質管理に大きく役立つ。
チケット駆動開発は「No Ticket, No Comimt」のルールによって、この性質をトレーサビリティまで拡張した点に意義がある。

更に、タグを振ることで、ソフトウェアのリリース番号を管理することもできる。
継続的インテグレーション入門 開発プロセスを自動化する47の作法」では、タグのことを「リポジトリ資産にラベル付けする」という言葉で紹介しているが、これはITILの構成管理における構成管理データベース(CMDB)の構成管理アイテム(CI)を連想させる。
つまり、タグは単なるスナップショットではなく、ベースラインでもある。

GitやMercurialで重要な機能は、強力なマージ機能と修正履歴の改変機能だ。
マージ作業もUndo、Redoができることによって、複数のブランチ管理も怖くなくなる。

Mercurialの黒魔術: プログラマの思索

rebaseのイメージ: プログラマの思索

色々触ってみる。

| | コメント (0)

2012/05/02

Redmineチケットの階層化の実装方法

Redmineチケットのテーブルissuesテーブルにlft, rgtというカラムがVer1.0からあって、何に使うのか分かっていなかったが、下記の記事を読んでようやく理解した。
ラフなメモ書き。

【元ネタ】
【Redmine】issuesテーブルのlft・rgtって? | Roppi.net

SQLアタマアカデミー:第5回 SQLで木構造を扱う~入れ子集合モデル (1)入れ子集合モデルとは何か |gihyo.jp … 技術評論社

SQLアタマアカデミー:第5回 SQLで木構造を扱う~入れ子集合モデル (2)入れ子集合モデルにおける検索 |gihyo.jp … 技術評論社

SQLアタマアカデミー:第5回 SQLで木構造を扱う~入れ子集合モデル (3)入れ子集合モデルにおける更新 |gihyo.jp … 技術評論社

SQLアタマアカデミー:第6回 SQLで木構造を扱う~入れ子区間モデル (1)もしも無限の資源があったなら |gihyo.jp … 技術評論社

SQLアタマアカデミー:第6回 SQLで木構造を扱う~入れ子区間モデル (2)稠密性について|gihyo.jp … 技術評論社

SQLアタマアカデミー:第6回 SQLで木構造を扱う~入れ子区間モデル (3)フラクタルとしての入れ子集合|gihyo.jp … 技術評論社

Redmineでは、チケットやプロジェクトの階層を無制限に作ることができる。
モデリングにおいて、階層構造とはツリー構造のことであり、再帰構造になる。
ツリー構造はソフトウェアでは普通によく出る。
データモデリングでも、組織構造や部品表、工程表などの生産管理でツリー構造のモデルはよく出る。

RDBでは、ツリー構造の実装方法が面倒な事は以前から知られていた。
よくある例は、自分の親に当たるキーをセットして、Oracleなら再帰SQL(CONNECT BY)を使って問い合わせする。
しかし、階層構造が深くなると、再帰SQLの性能はすごく悪くなるため、テーブル構造を非正規化するバッドノウハウでモデリングする時も多かった。

再帰SQL: プログラマの思索

再帰SQL part2: プログラマの思索

PostgreSQLの再帰SQL: プログラマの思索

業務システム設計に関する本: プログラマの思索

上記の記事を読むと、階層構造は入れ子集合を使うと、ツリー構造をRDBに綺麗にマッピングできるらしい。
issues.lft, rgtは入れ子集合でツリー構造を表現した時、2次元の円の両端の座標を表している。
すると、チケットBの親がチケットAである場合、チケットA.lft<チケットB.lft<チケットB.rgt<チケットA.rgtという関係が成り立つので、このルールを使ってガントチャートを階層化して表示しているわけだ。

興味深い点は、上記の記事によれば、ドナルド・クヌースの古典的な教科書『The Art of Computer Programming』において、上記のアルゴリズムは既に提示されているのに、今まで誰もうまく使いこなせていなかったこと。
RDBMSを作った人達は、ツリー構造を再帰構造で表現することにこだわりすぎて、昔から知られているアルゴリズムに気付かなかったのかもしれない。

上記の記事を読むと、lftとrgtを整数から有理数へ拡張することによって、ツリーへの挿入や削除の処理の性能が良くなる点も指摘している。
その時の考え方として、数学に出てくる「稠密性」がある。
「稠密性」の例としては、古代ギリシャのゼノンのパラドックス「アキレスは絶対に亀に追いつけない」「飛ぶ矢は静止している」がある。
要は「無限」という概念の性質を表しているわけだが、こんな所でそういう考え方が出てくるとは思わなかった。

そんなことを考えると、Redmineのコミッタは、チケットやプロジェクトの階層化の実装方法について、とてもよく考えて作った事がよく分かる。

【追記1】なお、渡辺さんがRedmineのテーブル構造について参考になる記事を書かれているのでリンクしておく。

「強制されたサロゲートキー」の事例を眺める: 設計者の発言

また、RailRoadと言うツールを使うと、Railsのコントローラやモデルなどの関連図を自動生成してくれる。

Redmineのアーキテクチャ: プログラマの思索

【追記2】
上記の記事はミックさんが書かれたらしい。
ミックさんのHPにもSQLでツリー構造を扱う内容が書かれている。

SQLで木と階層構造のデータを扱う(1)―― 入れ子集合モデル
SQLで木と階層構造のデータを扱う(2)―― 経路列挙モデル

プログラマのためのSQL 第2版」や「達人に学ぶDB設計 徹底指南書」にも入れ子集合モデルの話が掲載されている。

| | コメント (0)

« 2012年4月 | トップページ | 2012年6月 »