« 2009年3月 | トップページ | 2009年5月 »

2009年4月

2009/04/27

Redmineの運用例その2

Redmine運用例の記事があったのでメモ。

【元ネタ】
[Think IT] 第2回:ProjectKeeperに見る開発方法論 (1/3)
[Think IT] 第2回:ProjectKeeperに見る開発方法論 (2/3)
[Think IT] 第3回:SIOS Applicationsの過去未来 (1/3)
[Think IT] 第3回:SIOS Applicationsの過去未来 (2/3)
[Think IT] 第3回:SIOS Applicationsの過去未来 (3/3)

【特徴】
プロジェクト管理ソフトウェアProjectKeeperのタスク管理にRedmineを使っているらしい。
WebSphere+DB2で動作するから、IBM系列と思われる。
記事を読むと下記の運用ルールがあると思われる。

1・Redmineには、製品ロードマップ、顧客要望、バグ情報などが一元管理されている。
 変更管理/構成管理は、Excel+CVSからRedmine+Subversionへ移行した。

2・トラッカーは「要望」「機能拡張」「障害」の3種類がある。

3・「要望」はストーリーカードのような位置づけ。「承認済み」ステータスになると「機能追加」のチケットへタスク分割される。

4・「要望」は下記のステータスになる。
オープン→承認待ち→承認済み→対応中→対応済み

5・「機能拡張」「障害」は下記のステータスになる。
オープン→アサイン済み→開発中→確認アサイン済み→確認中→終了

6・全てのソース修正にはチケットを必要とするルールがある。


7・単体テストと結合テストのテストケースはTestLinkでテストケース、実施記録を一元管理している。

8・TestLinkを導入したが、担当者が手動でテストを実施している。テストの自動化はできていない。


興味深いのは、「要望」を要件管理、「機能追加」は実際の開発のタスク管理に使い分けていること。
しかも、要望のチケットが承認後に、タスクに当たる機能追加のチケットが作られていること。

ストーリーカードが決定されたタイミングで、タスクカードが作られる運用がされているようだ。
これは、RedmineのScrumプラグインと同じ機能だ。
この機能が実現されなければ、変更管理、要件管理を制御するのは非常に難しいだろう。

また、TestLinkも導入しているのが興味を惹く。
TestLinkを運用している利点の一つは、過去のテストケースを再利用しやすいこと。
どこまで運用されているのか分からないが、この利点が品質向上につながってるのだろう。

惜しむらくは、Redmineサマリが公開されていないこと。
Ruby1.8やSKIPのように、Redmineサマリが公開されていれば、そのチームの運用ルールは一目で分かる。

Redmineチケットの属性にあるトラッカー、カテゴリ、バージョンをどのように決めるか、という点は、まさにRedmineサマリという進捗報告のために存在すると言っても過言でない。

| | コメント (0) | トラックバック (0)

2009/04/26

金曜にバグを発生させるコミットが多い

昨年7月のSEA関西プロセス分科会で教えてもらったソフトウェア工学の論文「When Do Changes Induce Fixes? (On Fridays.)」をもう一度読み直している。

プログラマの思索: ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する

論文は、下記で公開されている。

【PDF1】
When Do Changes Induce Fixes? (On Fridays.)

【SlideShare】

【PDF2】
Don’t Program on Fridays! How to Locate Fix-Inducing Changes

上記の論文の主張は「ApacheやEcipse(又はMozilla)プロジェクトでは、金曜にバグを発生させるコミットが多く、金曜はバグ修正のリスクが高い。金曜はプログラムを書くな!」というもの。
SlideShareでは、「Fridays are Risky, Tuesdays are not ;-) 」というタイトルもある。

すごく面白い。

今の自分のプロジェクトで、SVNリポジトリやTestLinkでメトリクスを出力しているのだが、上記の論文の主張が当てはまるような気がしている。

少なくとも、SVNコミットのピークが金曜の場合、そのプロジェクトで開発しているシステムの品質は経験的に良くない。
TestLinkに溜め込んだテスト実績から曜日別のテスト結果を出力すると、品質に問題があったテスト計画では、金曜にテスト実施数や失敗テストケース数のピークが来ているようだ。

理由を考えると、色んな諸条件でSW開発の生産性が低いため、学生症候群のように、週後半に作業のピークが来るように経験的に感じる。

こういうソフトウェア工学の知識を持っているだけでも、SW開発のリスク管理は大きく異なる。
こういう経験値をSW開発のプロジェクト管理、リスク管理に応用できないか?

そして、チケット駆動開発へ上記のようにSW工学の基盤を理論的に付与できないか?


| | コメント (0) | トラックバック (0)

Javaから関数型言語へ

ジョエルのWikiはいつ読んでも面白い。
JavaよりもScheme、Haskellなどの関数型言語の習得が何故必要なのか、を説明している。

【元ネタ1】
Javaスクールの危険 - The Joel on Software Translation Project


(前略)
関数プログラミングを理解していなければ、GoogleをあれほどスケーラブルにしているアルゴリズムであるMapReduceは発明できない。
MapとReduceという用語はLispと関数プログラミングから来ている。
純関数プログラムは副作用がなく容易に並列化できるということを6.001に相当するプログラミングの授業で聞いて覚えている人には、MapReduceは容易に理解できる。
GoogleがMapReduceを発明し、Microsoftが発明しなかったという事実は、Microsoftが基本的な検索機能についてキャッチアップの途上にあり、一方Googleは次なる課題へと進んでいることを示している。
世界最大の並列スーパーコンピュータを構築しているのだ。
この流れの中でいかに遅れを取っているかをMicrosoftがちゃんと理解しているとは思わない。
(後略)


最近のプログラミング技術の傾向として、関数型言語の発想が必要になる場面が増えたように思う。
例えば、Googleの検索エンジンの背後にあるアルゴリズムMapReduceだけではない。
Amazonのレコメンドエンジンの背後にあるアルゴリズム協調フィルタリングも、同様だ。

WebもマルチコアCPUも、並列処理、分散処理のアイデアを使えば劇的に変わる可能性がある。


ジョエルのWikiには、関数型言語で再帰を使う問題が載っている。

【元ネタ2】
試してみよう - The Joel on Software Translation Project


1a. (MIT-Scheme) 次の関数

(define (accumulate combiner null-value l)
(if (null? l)
null-value
(combiner (car l)
(accumulate combiner
null-value
(cdr l)))))

を用い、リストの平方和を計算するsum-of-squaresを実装せよ。

例:(sum-of-squares '(1 2 3 4 5))

1b. (JavaScript) Schemeなんか知らないかもしれないね。次の問題は1aをJavaScriptにしたものだ。

次の関数

function accumulate(combiner, nullValue, l)
{
if (l.length == 0)
return nullValue;
var first = l.shift();
return combiner(first, accumulate(combiner, nullValue, l));
}

を用い、リストの平方和を求めるsumOfSquaresを実装せよ。

例:sumOfSquares([1,2,3,4,5])


Schemeは取っ付きにくいけれど、JavaScriptなら別だ。

関数脳のつくり方のように、リストを元ネタとして、リストに関数を適用する発想が必要だ。



| | コメント (0) | トラックバック (0)

2009/04/20

変更管理の基盤は構成管理が支えている

SW開発には、たくさんの落とし穴や地雷がある。
地雷原を走り抜けてゴールにたどり着くまでに慎重に進むと、時間切れになる。

アジャイル開発をRedmine上で実践して気付いたことは、変更管理プロセスを制御できるかどうかという観点がプロジェクト管理の殆どを占めていることだ。
仕様変更、タスクの優先度など、SW開発は路線変更が多く、それを制御するのが難しい。
顧客と合意した要件で開発してリリースしても、その後に膨大な改善要望がくる時すらある。

以下メモ書き。

【1】顧客要求を安易に受けてしまう人の良いSE- @IT自分戦略研究所

スコープのずれがコスト増にすぐにつながる。
アジャイル開発の肝はスコープ管理だ。
スコープ、コスト、納期の3つのバランスのうち、スコープでしか調整しづらいのがSW開発の最大の特徴。

スコープ管理の一例としては、CCBなどの変更管理会議で変更管理プロセスを制御することがある。
つまり、仕様変更など開発対象のスコープにつながるものは全て、顧客・SIer・開発者などのステークホルダーが全て集まって合意を経ないと、変更できないようにする。

しかし、僕の経験では、人数が多い会議ほど時間がかかるだけで何も決まらない。
CCBに出るステークホルダーは、業務やシステムに詳しい人とは限らない。
全員の合意を得るのは難しい。

大規模プロジェクトになるほど、ステークホルダーが増えるので、指数関数的に変更管理プロセスの難易度は上がる。
チケット駆動開発を応用しても、運用のハードルは高いだろう。

【2】【福井信二が語る:第3回】構成管理・プロジェクト管理の原理原則 - 組み込み開発 - Tech-On!


「構成管理とは同じ成果物の状態の変化を管理すること」というフレーズにアンテナが響いた。
SW開発では、一つの成果物が設計・開発・テストの工程を経るごとに、中身も状態も変化する。
記事で紹介されているように、成果物は段階的に詳細化されていくのだ。

要件は、設計工程で、システムの一つの仕様に落ちる。
そして、その仕様はプログラムで実装されて、初めて目の前で動く。
しかし、たくさんのテストをこなすたびに、一つの仕様には、たくさんのパッチが当てられて、ソースコードはどんどん複雑になっていく。

その過程を制御するのが構成管理だ。
つまり、要件からソースコードまで一貫したトレーサビリティを保証するインフラが構成管理。
しかし、Rational製品が提供するツールは重くて実用的ではない。

チケット駆動開発では、チケットとソースコードのリビジョンを紐づける運用がある。
その運用のおかげで、チケットという仕様に紐づくソースコードの履歴を辿ることができる。
逆に、ソースコードの変更履歴からチケットの仕様を探り出すこともできる。

僕が考えているプロジェクト管理サーバーでは、

HudsonビルドNo
→SVNリビジョン
→RedmineチケットNo
→TestLinkテストケースID
→TestLink要件ID

のトレーサビリティを作れるから、リリースされたモジュールにあるパッチから、要件まで辿ることができるはず。

上記の記事にあるベースラインの概念は、Redmineのバージョン、Subversionのリリースタグ、XPのイテレーション、Scrumのスプリントに相当するように運用できると思う。

変更管理と構成管理は密接に絡んでいる。
チケット駆動開発は、二つのプロセスをコントロールしやい開発プロセスだろうと思う。


| | コメント (0) | トラックバック (0)

2009/04/19

アート・オブ・プロジェクトマネジメント

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」は、色んなPM本の中でもベスト3に入ると思っている。
全て目を通したけれど、全て理解できてない。
自分が理解できた文章を中心にメモ書き。


【1】私の一番好きな単語は「How」(どのように)です

「はじめに」の冒頭にこの文章がある。
僕はこのフレーズが好きだ。

IT技術者は、システム化がお仕事であって、コンサルタントでもないし、営業でもないし、経営者でもない。
きちんとした要件定義書があったとしても、それをシステム化するには、設計もプログラミングもサーバー運用技術も必要とする。
それらは、全て「どのように実現するか?」という問題そのもの。
プログラムに落とせない仕様は、Howが突き詰め切れていないだけ。

【2】スケジュールとは確率なり

「アジャイルな見積もりと計画づくり」にも同じフレーズがある。
スケジュールはコミットメントではない。
見積もりはコミットメントではない。
将来を見通した推測に過ぎない。
そう思えば、スケジュールを開発中に保守し続ける意味が腑に落ちる。

【3】優れた見積もりは優れた設計から生み出される

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、エンジニアリングにおける優れた見積もりは、優れた情報と優れたエンジニアという二つが揃って初めて生み出されるのです、とも書かれている。

大規模プロジェクトが破綻しやすい理由は、膨大な仕様を、整合性の取れたサブシステムへ分割し切れていないのが殆どではないかと思う。
その根本原因には、モデリング力の不足があると思う。


【4】優れた意思決定が悪い結果をもたらしたとしても、その意思決定を行ったPMが非難されることのないように注意すべきだ

SW開発を一人ではなくチームで行う時、メンバーには役割と責任が明確にされている。
そのチームには、チームを一つの人格と思えるように、チームの代表となるリーダーが必ず存在する。
そのリーダーが優れた技術力や経験を持っていたとしても、その意思決定で失敗する時はある。

失敗よりも重要なことは、復元力があること。

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、意思決定前における彼のロジックや思考プロセスがしっかりしていたのであれば、そのロジックと思考プロセスは意思決定後であっても変わらずしっかりしているはずです、とも書かれている。

リーダーには一貫性が重要なのだと思う。

【5】信頼を明確にする。説得は命令よりも強い。

チームが有機的に動くには、メンバーにチームにおける役割を明確にして、その行動を信頼すること。
特にSW開発では、信頼関係が重要だ。
その信頼関係は、その人の性格もあろうが、源泉はその人の技術力にある。
駄目なチームは、メンバー同士に信頼関係がない。
XPでは、ペアプロはメンバー同士の信頼関係を強固にする方向へ発展させる。

リーダーとなるべき人に最も要求される能力はアカウンタビリティ(説明責任)だと思う。
何故そんな作業指示を出すのか、何故彼にそんな役割を期待するのか、ロジカルに、そして彼が納得できるレベルまで説明する責任がある。
駄目なリーダーは、メールや口頭で指示を投げるだけで、信頼関係を基盤にしていない。

【6】ファシリテーション:ものごとを容易に、あるいはさらに容易にする行為のこと

こんな本で、ファシリテーションの定義が出てくるとは驚きだった。

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、多くの意思決定が共有され、多くの作業が協調して行われるため、優れた関係を築くことなしにコミュニケーション量を増やしても意味がないのです、とも書かれている。
信頼関係を構築すること、そのインフラがあってコミュニケーションが活性化して、チームも開発プロセスも改善していく。


【7】リーダーはフィードバックプロセスを定義する

駄目なチーム、駄目なプロジェクトには、フィードバックプロセスがない。
同じ失敗を何度も繰り返し、成長が見られない。

プロジェクトファシリテーションが提唱する「ふりかえり」は強力なマネジメントツールだと思う。
ふりかえりによって、メンバーだけでなくチームも学習する。
要件漏れ、仕様漏れ、バグ修正、リリース作業漏れなどの失敗を糧にできる。

チケット駆動開発ならば、イテレーションで開発したモジュールリリース後に「ふりかえり」を行えば、メンバーから有用な意見が出てくるだろう。
アジャイル開発とふりかえりは相性がいいと思う。
理由は、イテレーション単位にリリースするリズムがあるから、ふりかえりをやろうという雰囲気が自然に出てくるから。

【8】優先順位は力なり。PMは優先順位付けマシンとなるべし。

マネジメントとは選択することだ、とどこかの本で読んだことがある。
SW開発のプロジェクトは、五月雨式の仕様変更ですぐに迷走してしまう。

チケット駆動開発で一番重要なスキルは、チケットの取捨選択だ。
わずか2~4週間のイテレーションに入れるチケットはどれか、をいつも考えなければ、すぐにチケットは溢れてしまう。
基本は、優先度の低いチケットは捨てる。
リリースできないシステムは動かないガラクタと同じで無意味。

【9】中盤の戦略~コーディングのパイプラインはバグ修正のパイプラインとなる

「中盤の戦略」「終盤の戦略」という章が僕は好きだ。
まさにプロジェクトマネジメントそのものだと思う。

新規開発中の場合、開発者とテスターがペアになって作業しているだろう。
それが結合テスト、システムテスト、と経てどんどん納期に近づくにつれて、バグも増えてくる。
また仕様変更もあるだろう。

プロジェクト後半の作業も、開発者とテスターが、バグ修正とバグ検証のパイプラインで対応できれば、チーム内の役割を殆ど変えることなく、進められる。

RedmineとTestLinkの両方を運用した場合、まさにバグ修正のパイプラインというワークフローがようやく分かった。

TestLinkのテストケースはテスターがこなす。
テスターは、バグが出たら、テストケースを失敗に更新して、Redmineチケットへバグ登録する。
開発者はRedmineチケットに基づいてバグを直し、解決ステータスにする。
テスターは、TestLink上でチケットの解決ステータスを確認して、再テストし、OKならば、RedmineチケットをCloseし、TestLinkのテストケースも成功へ更新する。

このワークフローに管理者が関わらないことに注意して欲しい。
最終的には、このワークフローを承認する作業は残っているが、管理者は、開発者とテスターが交互にバグ修正とバグ検証をやり取りしている様子を、TestLinkやRedmine上でリアルタイムにモニタリングできる。

【10】終盤の戦略~降下角度に気をつけろ

プロジェクト終盤では、残作業のボリュームと納期までの期間から、降下角度を見極める。
降下角度が急ならば、メンバーに負担をかけさせるため、チームは混乱しやすい。
チームが許容できる降下角度の最大値はやはりある。

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、懸案事項はトリアージ、残作業はバグのマネジメントへ移行すべし、とも書かれている。

【11】マネジメントの行動はどれも政治的だ。つまり、マネジメントの行動は、何らかの方法で権力を再配分するか補強するかのいずれかだ。

SW開発も一つのビジネス。
そこには、容認しがたい政治というものも存在する。
SEは、調整と言う名の作業もある。

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、政治とはある種の問題解決である、とも書かれている。
この言葉で何となく理解できたような気がした。


アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には他にも良い話がたくさんある。
少しずつ理解していきたい。



| | コメント (0) | トラックバック (0)

PHP版のRedmine

下記の記事が気になっている。

RedmineをCakePHPに移植する「candycane」プロジェクトの開発合宿に参加してきました : akiyan.com

Ruby on Railsで作られたRedmineをPHP版で作ろうという野心的なプロジェクト。
僕は、Redmineは世界中で現在一番優れているBTSだと思う。
でも、Rubyが稼動するサーバーがそれほど多くないから、Redmineは広く普及されているとは言い難い。

しかし、PHP版Redmineが存在するならば、その気になれば、普通のプロバイダでも運用できる。
また、PHPならば本番運用するノウハウはいくらでもあるから、実際のビジネスシーンでもPHP版Redmineを使うハードルは下がるに違いない。

今後目が離せないプロジェクトの一つ。


| | コメント (0) | トラックバック (0)

2009/04/18

Web2.0の本質はデータマイニングにあり

レコメンドエンジンの話を知りたくて、「集合知プログラミング」という本を買ってみた。
内容はいわゆるデータマイニング。
全て読めてないけど、すごく面白かったので、考えていることをメモ書き。
#後でロジカルに書く。


【1】僕が「集合知プログラミング」を読んで思ったことは「Web2.0の本質はデータマイニングにあり」。

【元ネタ1】
プログラマーに最適なデータマイニングの教科書 『集合知プログラミング』 - 図書館情報学を学ぶ

集合知プログラミングが凄すぎる件について - プログラマになりたい

オープンソースのレコメンドエンジン Taste - プログラマになりたい

オープンソースのレコメンドエンジン Taste


Web2.0の成功例としては、Amazonの関連商品、iTunesのお勧め曲表示、はてなブックマーク、GoogleのpageLankによる検索エンジンなどがあげられるだろう。

これらの本質は、データマイニングにある。
売れた商品データ、売れた音楽データ、ネット上にあるリンク情報など、大量に溜まったトランザクションデータから、関連性のある情報を吸い取り、ユーザーに提示する手法。

この手法が面白いのは、一つは、プログラミングとマーケティングが直結すること。
もう一つは、プログラミングのアルゴリズムが面白いこと。

前者は、優れたプログラミング技術があれば、経営層や営業マンが気付かないマーケティング情報を数値で出力できること。
よく言われる例は「紙おむつとビールが良く売れる」というもの。
この手法が進むと、昔から言われていたエキスパートシステム、エージェント、人工知能につながるだろう。
今まで特別な人しかできないと思われていた高度なマネジメント手法を、誰でも手軽に使える可能性が広がるかもしれない。

後者は、大量のトランザクションデータを解析するには、それなりの数学的知識やコンピュータ科学を必要とすること。

いわゆるレコメンドエンジンのアルゴリズムは殆どは、協調フィルタリングと呼ばれるものだろう。
僕が理解している内容では、例えば、ユーザーIDとユーザーが購入した商品IDのハッシュマップをリストで保持し、複数のユーザのリストを並べて、色んな観点(アルゴリズム)で類似性を導き出すというもの。

このレコメンドエンジンのアーキテクチャは例えば、バッチ処理で売上データTblから類似性のある情報を計算して、フロント側にある画面からHTTP経由で、XML化された関連する商品データを取得するものが多いだろうと思う。
つまり、バッチ処理とWebサービスを組み合わせるやり方がレコメンドエンジンの殆どの実装方法と言えるだろうと思う。

このアーキテクチャにする理由は、一つは、大量の売上データを解析するのは時間がかかるため、バッチ処理の方が向いていること。
更に、Webサービス経由で関連商品情報を取得できるインターフェイスならば、他サブシステムからもHTTP経由で簡単にXMLを取得できるから。

でも、本来はバッチ処理ではなく、リアルタイムに計算できるようにしたい。
今はコンピュータ資源がいくらでもあるから、大規模分散計算のアルゴリズムMapReduceをフルに使えば、より質の高い情報をもっと速く提供できるのではないか?

技術的に面白いのは、リストで比較して類似性を計算する手法は、関数型言語と相性がいいこと。
HaskellとかScalaで実装できないのか?

オープンソースのレコメンドエンジンとしては、Tasteとかあるらしい。

【2】僕がデータマイニングを一番使いたい場面は、プロジェクト管理やSW工学だ。

【元ネタ2】
[Think IT] 第1回:エンピリカルソフトウェア工学を学ぶ前に (1/3)

森崎修司の「どうやってはかるの?」 エンピリカルとは : ITmedia オルタナティブ・ブログ

エンピリカルソフトウェア工学とは、エンピリカル:ソフトウェア工学への実証的アプローチ - nobusueの日記にもあるように、「"experimental"と"experienced"を合成したものだそうです。文字通り、「事実に基づくソフトウェア工学の構築」を目指したもので、ソフトウェア開発に対して科学的にアプローチしようという試みです」。

チケット駆動開発の仕掛けはBTS(バグ管理システム)にある。
データマイニングを使って、BTSに溜まった情報から、プロジェクトの進捗やシステムの品質に関するメトリクスを出力し、管理者が意思決定する情報として使いたいのだ。

丁度、経営者が毎月の売上データ、四半期ごとの決算書を予定・実績で比較検討した後に意思決定するように、チケット駆動開発のインフラであるBTSから出力された情報をプロジェクトのリスク管理として使いたい。
データマイニングの仕掛けは、協調フィルタリングではないだろうが、その発想は応用できるはずだ。

Redmineならば、サマリの画面で、トラッカー(チケットの種類)・担当者・バージョン(イテレーション又はマイルストーン)・カテゴリ(コンポーネント)などの観点でチケットのステータスを自動集計して表示する機能がある。
更に、ガントチャートやカレンダーをリアルタイムに出力できるし、そして、月別にバージョンで実績工数をクロス集計する機能もある。
これらの機能を使えば、プロジェクトの作業進捗やすぐに分かるし、そこからリスクを嗅ぎ取り、是正対策を取ることもできる。

statSVNというツールを使えば、Subversionリポジトリから、コミット日や開発者毎のLOCやコミット回数などを集計してくれる。
この結果から、システムのLOCがどのように増大しているか、開発者の貢献度は?などが分かる。

又、テスト管理ツールTestLinkを使えば、溜まったテスト実績から、テスト進捗や、バグの数からテスト工程の品質が分かる。
要件カバレッジの機能もあるから例えば、この要件はバグが多いので注意しよう、などの対策を取ることができる。

これらの手法をもっとお手軽に一つのパッケージとして提供できないか?


集合知プログラミング」の本では、たくさんの例とたくさんのアルゴリズムがPythonで説明されている。
JavaやRubyに慣れている人ならば問題なく読めるのではないだろうか?
この本の読書会は開かれていないのかな?


| | コメント (0) | トラックバック (0)

2009/04/17

マネージャ層の技術が遅れている

下記のBlogを読んで、最近の技術のトレンドにプログラマよりもマネージャ層が遅れているような気がしてきた。

【元ネタ1】
脱Excelのための… - Talking Nonstop

『ずっと受けたかったソフトウェアエンジニアリングの新人研修』続き - 思っているよりもずっとずっと人生は短い。

ずっと受けたかったソフトウェアエンジニアリングの新人研修」を実際に本屋で立ち読みしてみて、すぐに飽きた。
この本の内容を覚えたとしても、実際の業務では正直役に立たないだろう。

少なくともプログラミングには役立たない。
業務システムの開発でも、定型化されたプロジェクトならまだしも、昨今のように短納期・大規模なプロジェクトでは、業務モデリングすら間に合わないだろう。
今までのSW開発の技術の進歩から外れている。

上記のBlogにあるように、大手SIerが下請けに下流工程を投げるための技術の一つに過ぎないのかもしれない。
彼らがSW工学を必要とする理由は、下請けに自分たちの開発プロセスを押し付けて管理したいからだろう。

チケット駆動開発がSW開発の全ての問題を解決するとは思わない。
むしろ、チケット駆動開発は、現場の経験から編み出された開発手法の一つに過ぎず、その概念すらもきちんと定義されていない。
だから、チケット駆動開発がどんな問題をどのように解決しようとしているのか?をはっきりさせていくのが大事だと思う。

チケット駆動開発を実践して気づいた事は、BTSはSW工学の宝庫。
BTSに溜まった情報から、システムに関する作業進捗や品質などのメトリクスを色んな観点で入手でき、そこからSW工学の新しい知見を得ることができる。


【元ネタ2】
ソーシャル化するOSS開発者たち

Gitによって開発プロセスそのものが改善された事例として興味深い。
メインラインモデルによる並行開発では、ブランチとtrunkの間のマージ作業の精度と簡便さが鍵を握る。
Subversionと比較すると、Gitはマージに特徴があるようだ。
Gitのマージの精度は半端でないらしい。

僕はプロジェクト管理も技術の一つだと思う。
ツールが開発プロセスを改善する。
技術力で開発プロセスを大幅に改善できるはずだ。

| | コメント (0) | トラックバック (0)

2009/04/14

【公開】脱Excel! Redmineでアジャイル開発を楽々管理

下記の記事を公開した。

脱Excel! Redmineでアジャイル開発を楽々管理 - @IT自分戦略研究所

上記の記事では、僕が過去1年間、Redmineを運用して経験したこと、考えたこと、そして確信したことについて書いた。

一番言いたかった事は、Redmineによるチケット駆動開発が、XPのプラクティスの一つである小規模リリースを実現するプロジェクト管理のインフラになることだ。
その仕組みは、XPのタスクカードをBTSチケットとしてデジタル化することにある。

そのおかげで、チケットとソースのトレーサビリティによる変更管理、メインラインモデルによるSWプロダクトラインのような並行開発、チケットの自動集計によるメトリクス出力などの興味深い機能もある。

Redmineによるチケット駆動開発こそが、アジャイル開発を運用するハードルを下げてくれると確信している。

他に、東さんの記事

VMwareとっておきの使い方 - @IT自分戦略研究所

や太田さんの記事

快適なWeb開発環境を構築する、Firefoxアドオン10選 - @IT自分戦略研究所

もSEやPGにとってすぐに役立つノウハウが書かれているので、併せて読んで欲しい。


| | コメント (0) | トラックバック (0)

2009/04/12

TestLinkのテスト実績からメトリクス出力

TestLinkに溜まったテスト実績を下記ツールで分析してみたら、面白い傾向に色々気付いた。
以下メモ書き。

【EXCEL試験書からのXMLファイル変換マクロ】
v37b_TestLinkCnvMacro.tar.gz ダウンロード - TestLinkTools - SourceForge.JP

【主な機能】

(中略)

6 テスト結果の統計データのエクスポート
・指定された期間のビルド単位の試験結果の推移をグラフ化できます。
・試験者を指定した試験結果の推移をグラフ化できます。
・試験結果の累計数は、各テストケースでの最後に実施した結果の累計数です。

7 要件カバレッジのエクスポート
・プロジェクト内の全要件のカバレッジを、EXCELシートに取込めます。
・要件カバレッジは、指定されたビルドの各テストケースでの最後に実施した結果より求めています。
・要件カバレッジは、要件にアサインされているテストケースの「成功」の割合です。

・仕様カバレッジは、要件仕様にアサインされているテストケースの「成功」の割合です。
・全仕様カバレッジは、全要件仕様にアサインされているテストケースの「成功」の割合です。
・これらは、要件仕様ないで重複してアサインされているテストケースを1個としてカバレッジを求めています。

8 要件カバレッジの統計データのエクスポート
・指定された期間のビルド単位の全要件仕様カバレッジの推移をグラフ化できます。
・要件仕様を指定した要件仕様カバレッジの推移をグラフ化できます。

9 時間帯別の試験結果の統計データのエクスポート 
・指定された日のビルド単位の時間帯別の試験結果をグラフ化できます。
・試験者を指定した時間帯別の試験結果をグラフ化できます。

10 試験結果のピーク時間帯の統計データのエクスポート
・指定された期間のビルド単位の試験結果のピーク時間帯の推移をグラフ化。
・試験者を指定した試験結果のピーク時間帯の推移をグラフ化できます。

11 曜日別の試験結果の統計データのエクスポート
・指定日または、指定期間のビルド単位の曜日別の試験結果をグラフ化できます。
・試験者を指定した曜日別の試験結果をグラフ化できます。

12 時間当り実施数の統計データのエクスポート
・指定期間のビルド単位の時間当り実施数の推移をグラフ化できます。
・試験者を指定した時間当り実施数の推移をグラフ化できます。

13 試験者別時間当り実施数データのエクスポート
・指定期間のビルド単位の試験者別時間当り実施数をグラフ化できます。
・指定した試験者の指定期間の時間当り実施数をグラフ化できます。

【感想】
【1】上記と似たものとして、SVNリポジトリから、コミット日単位でLOCを表示したり、開発者ごとに曜日・日時単位のコミット数などをHTML出力する下記ツール「statSVN」がある。
#同様に、CVSリポジトリ統計出力するstatCVSもある。

StatSVN - Repository Statistics - Introduction

僕が重宝するのは、開発者ごとに曜日・日時単位のコミット数などを出力する下記の画面。

StatSVN - Repository Statistics - StatSVN Developers

上記ツールをクーロンで定時にHTML出力する運用をした所、下記の特徴があるという経験をした。

1・駄目なプロジェクト、生産性の低い開発者
・18時以降にコミット回数が多い。
 最悪なのは、夜中1時以降にコミットしている。
 つまり、低い生産性を残業でカバーしようとしている。
・コミット回数の山が金曜や土曜、日曜に来る。
 進捗の遅れを休日出勤でカバーしているから。

2・生産性の高いプロジェクト、開発者
・18時以降のコミットは殆ど無い。
・11時、17時にコミット回数の山が来る。
 おそらく昼前、退社前にコミットするから。
・コミット回数の山が水曜に来る。
 そうしないと、金曜までに作業が終わらない。
 休日出勤しないので、当然、土日はゼロ。

テスト工程も同様の特徴があるだろうと思う。
特に結合テストやシステムテストは元々、コストやスケジュールに余裕が無いので、1のパターンになりやすいと思う。

【2】時間帯別の試験結果グラフを見ると、品質があまり良くなかったテスト計画(イテレーション)では、納期前ほど18時以降にテストが多く、更に全般的に、18時以降のテストは失敗数が多い傾向があった。

又、曜日別の試験結果グラフを見ると、品質が良いテスト計画(イテレーション)では、火曜や水曜など週の前半に山が来る傾向があった。

理由を類推すると、テストケースをどんどん消化できる場合はそもそも18時以降まで残業してテストする必要はない。
テストが遅れると18時以降まで残業し、そこでバグを見つけてしまい、バタバタしてしまうから。
更に、バグを潰していっても、最後の一つのバグが納期直前までなかなか直せない場合が多かった。

逆に、テストケースを順調に消化できる場合は、午前中などで早めにバグを見つけて、18時までに解決しているパターンが多かった。
テスト進捗が順調だから、残業してまでテストする必要はない。


【3】statSVNでSVNリポジトリのコミットする時間帯・曜日別をいつも見る理由は、開発者やテスターの作業負荷を見たいから。

作業負荷が高まると、18時以降に残業してカバーするようになり、休日出勤でカバーするようになり、どんどん状況は悪化していく。

生産性の低さを残業や休日出勤でカバーしようとすると、月曜や火曜のような週の初めや、午前中などの早い勤務時間の生産性がすごく低くなる。
金曜の夜に進捗の遅れがあっても、土日でカバーすればいいや、という学生症候群が生まれてしまう。

そうなるまでに、現場リーダーとしては、対策を考えて手を打ちたい。
上記の資料があると、会社の上層部にも現状を説明しやすくなる。

【4】TestLinkのテスト計画をアジャイル開発のイテレーション単位に対応付ければ、イテレーションをこなすたびにテスト実績がたまっていく。
過去のテスト計画にあるテスト実績を上記マクロで、データマイニングして、メトリクス出力するのは非常に興味深く、又色んな気付きが得られる。

これは、Redmineによるチケット駆動開発でも同様。
ExcelではなくDBにあれば、好きなようにデータを集計して、色んな観点で、プロジェクトを分析できる。

TestLinkでテスト実績をためながら、上記マクロで出力したメトリクスをメンバー全員でKPTでふりかえり、プロセス改善できれば、強力だろう。

アジャイル開発とRedmine、TestLinkは非常に相性がいいと思う。

| | コメント (0) | トラックバック (0)

2009/04/11

プロジェクト管理サーバーとは

僕が考えているプロジェクト管理サーバーについて良い記事があったのでメモ。

【プロジェクト管理サーバーのイメージ】
そろそろプロジェクト管理ツール群について一言言っておくか - Talking Nonstop

プロジェクト管理サーバーの目的は、SW開発で必要なインフラを提供することにある。

基本は、タスク管理(Redmine・Trac)とバージョン管理(Subversion)。
タスク管理の目的は、プロジェクト内部の作業全てを見える化して、一元管理すること。
RedmineやTracの運用の鍵は、タスクをチケットにどこまで分割して、アジャイル開発のイテレーションへどのように落とし込むか、という点にある。
つまり、分割したチケットをリリース単位にまとめて、小規模リリースできるか、という観点が大事。

バージョン管理の目的は、プロジェクト内部で発生する全ての成果物を一元管理すること。
バージョン管理の本質は、エディタのように成果物のUndo/Redoができることにある。
対象は、ソースコードだけでなく、ExcelやWordなどの仕様書やビルドスクリプトなども含まれる。
仕様書を「画面定義書_yyyyMMdd.xls」と書いている時点で、バージョン管理すべき対象なのだ。

そして、ビルド&リリース管理のHudson。
ビルド作業やリリース作業は、ジョエルテストにもあるように、ワンクリックでビルドできてリリースできるべき。

TestLinkは、結合テスト以降のテスト、特に受入テストで使う。
僕の経験では、設計から、開発、単体テストまでの作業はRedmineのチケットで管理するが、リリース前の受入テストに入ると、TestLinkでテスト作業を一括管理する。
受入テストでは、テストケースの実施数が作業実績になるからだ。

他には、プロジェクト内部で出てくる業務用語や技術用語はMediaWikiで管理するとか、SVNリポジトリの統計を出力するstatSVNを使う。

他に試したいものは、HyperEstraierというMixiで使われているらしい検索エンジン。
Subversionにある成果物一式をいつでもWebで検索できるようにしたいから。
そうすれば、開発者自ら、仕様の不明点を探して、自力で設計書を作れるようになる。

【プロジェクト管理サーバーの作り方】
Vine Linux 4.2 で Trac + SVN + Hudson + TestLink 環境を簡単に構築するスクリプト - かおるんダイアリー

プロジェクト管理サーバーは、複数のオープンソースの管理ツール群を組み合わせたもの。
上記は、スクリプトで一式インストールする。
Trac + SVN + Hudson + TestLinkだけあれば、少なくともプロジェクト管理に困ることはあまりないだろう。
できれば、上記ツール群をVMwareイメージにしてくれると、初期設定込みになるから、より簡単になるだろう。

しかし、プロジェクト管理サーバーがあるからといって、それだけでプロジェクト管理が楽になるわけではない。
ツールに合わせた開発プロセスで運用する必要がある。
ツールの機能を十分に知り尽くして運用しなければ、逆に生産性が落ちることもあるだろう。

僕の経験では、プログラマやテスターは上記のツールにすぐに馴染んでくれて、プロセスを大幅に改善できた。
彼らは新し物好きだし、これらのツールによって、自分のタスクが見える化しただけでなく、自発的にバグをチケットへ登録するなど、自発的に作業するようになった。

しかし、従来のマネージャ職の人達がなかなか上記ツールに馴染んでくれない。
そもそもSubversionの使い方を知らなかったり、チケット駆動開発で現れるワークフロー管理、そしてアジャイル開発のタスク管理という概念に馴染んでいなかったりする。
どうやら、従来のExcelによるプロジェクト管理に固執しているみたい。

でも、僕は、プロジェクト管理サーバーは特にアジャイル開発のプロジェクト管理を補強してくれるはずと確信している。


| | コメント (1) | トラックバック (0)

2009/04/10

Windowsエクスプローラーが不安定になる原因の一つはTorotiseSVNか?

最近、エクスプローラーが不安定になっていて気になった時に下記の記事を見つけたのでメモ。

tortoise svn 入れたらディスクが遅くなったような気が (株式会社ディア Dear inc.)

原因は、TorotiseSVNはデフォルトで、Cドライブなど全てのローカルディスクへのディスクアクセスを監視する設定になっているかららしい。
対策は、TorotiseSVNの設定画面で、「アイコンオーバーレイ」から「ドライブの種類」のチェックを全て外して、「含めるパス」にSVNのローカルディレクトリを設定すればよい。

確かに劇的に速くなったような気がする。

今やWindowsのSVNクライアントとして、TorotiseSVNはデファクトスタンダードだから試してみる価値はあるかもしれない。


| | コメント (0) | トラックバック (0)

2009/04/04

プロダクトバックログとスプリントバックログの違い~要求マネジメント

成功する要求仕様 失敗する要求仕様」の最後に、要求マネジメントに関するクイックレシピがある。

その方法が、Scrumのプロダクトバックログとスプリントバックログを上手に使い分けるのと同じように思えたのでメモ。

【1】あるシステムを作るために、要件定義をしているとしよう。
その時、「成功する要求仕様 失敗する要求仕様」のクイックレシピによると、以下の手順が必要になる。

1.ブレーンストーミングで要求をまず洗い出す。
 要求の実現性は問わない。
 要求の優先度や重要度も洗い出す。
 
2.ブレーンストーミングで洗い出した要求リストから、要求か否かを決定する。
 実現できる要求のトリアージを行い、要求の候補を決定する。
 但し、この段階では、コストやスケジュールは未決定。
 
3.リリース計画を作る。
 実現可能なスケジュールと予算を作り、リリース計画へ入れる要求を足していく。
 
 但し、作成中のリリース計画では不満がある場合、次のリリースで対応することを考える。
 例えば、Ver2.0のリリースでは機能が不十分な場合、Ver2.1というつなぎのリリースで対応する。
 あるいは、Ver1.4をリリース済みで、Ver2.0へ向けて開発中の場合、Ver1.5で早めに部分的なリリースで対応する。

4.要求文書を作成する。
5.要求文書を品質測定する。
6.要求をベースライン化する。
7.ステークホルダー全員へ要求を周知する。

8.ベースライン後に、要求を変更・追加する場合、変更管理会議(CAB)でリリース計画を立てる。

【2】上記のやり方の特徴は、要求をトリアージして要求の候補を作ることと、リリース計画へその要求をアサインすることの2点にある。

トリアージして要求の候補を作ることは、Scrumのプロダクトバックログにストーリーカードを入れることと同じ。
つまり、プロダクトバックログにあるストーリーカードは、開発予定の機能であるが、どのバージョンで反映されるかは未決定の状態。

要求をリリース計画へアサインすることは、Scrumのスプリントバックログへストーリーカードを入れることと同じ。
つまり、プロダクトバックログからスプリントへストーリーカードを移したら、そのストーリーカードはそのスプリントで実装することになり、リリース計画に組み込まれる。
スプリントにあるストーリーカード全ては、スプリントバックログになる。

【3】RedmineのScrumプラグインは、上記の機能を実現している。
下記のBlogでは、そのインストール手順が書かれている。

【元ネタ】
プログラマの思索: RedmineへScrumのアイデアを注入

scrumalliance's redmine at master - GitHub

ストーリーとタスク - cougerの日記


一応動いた…けど、
 ・スプリントバックログとプロダクトバックログの違いって何?
 ・ストーリーってチケットをまとめてくれるものじゃないんだ?
プロダクトバックログに入れてたストーリーにバージョンがついてなかったので、付けてみたら…
 ・プロダクトバックログから、スプリントバックログに移動した!

ScrumやXPにせよ、それらの概念やプラクティスは抽象的過ぎて、実際の現場ではどう運用してよいか分からない時が多い。

しかしながら、上記のようなRedmineのScrumプラグインを使えば、要求のトリアージやリリース計画へ要求のアサインを、Redmine上で実現できる。
つまり、実際の要求マネジメントをRedmine上で行っているのと同じなのだ。

ツールを上手に使いこなせれば、ツールが開発プロセスを改善してくれる。
そうすれば、チームは自然に成長している。

| | コメント (0) | トラックバック (0)

Codestrikerのインストール方法

Perl製コードレビューWebシステムCodestrikerをインストールできたのでメモ。
但し、ReviewBoardに比べると、インストールははるかに難しかった。。

【元ネタ】
Perl製のソースコードレビューソフトウェア「Codestriker」

Codestriker: Homepage

Codestriker:Metrics Report

ソースコードレビューツール「Codestriker」

CodeStrikerとSubversionの連携設定

CodeStrikerでコードレビューをする


CodeStrikerでコードレビューをする~その2

【必須環境】
以下、CentOS上で下記ツールはインストール済みとする。

Perl
Apache

下記のCPANライブラリ:

LWP::UserAgent(any)
CGI(v2.56)
Net::SMTP(any)
MIME::QuotedPrint(v2.14)
DBI(v1.13)
Template(v2.07)
HTML::Entities(any)
File::Temp(any)
XML::RSS(v1.05)
Encode::Byte(any)
Encode::Unicode(any)
DBD::mysql(any)
Authen::SASL(any)

上記のCPANを全てインストールするのがかなり面倒。。
ソースからインストールするよりも、yumやapt-getで入れた方が早いだろう。

【1】インストール方法
1.ソースを持ってくる。

tar zxvf codestriker-1.9.7.tar.gz
mv codestriker-1.9.7 codestriker
ln -s codestriker /var/www/cgi-bin/codestriker

2.MySQLへDB作成

mysql -u root
CREATE DATABASE codestrikerdb CHARACTER SET utf8;

GRANT SELECT,INSERT,UPDATE,DELETE,INDEX,ALTER,CREATE,DROP,
REFERENCES ON codestrikerdb.* TO codestriker@localhost
IDENTIFIED BY 'codestriker';

FLUSH PRIVILEGES;

3.CodeStrikerの設定ファイル「codestriker.conf」を編集する。

14行目:
$db = 'DBI:mysql:dbname=codestrikerdb;host=localhost;
mysql_socket=/var/lib/mysql.sock';

28行目:
# Database user.
$dbuser = 'codestriker';

# Database password.
$dbpasswd = 'codestriker';

$admin_users = [ '管理者のメールアドレス' ];
・・・・・

104行目あたりから、連携するバージョン管理システムを設定する。

4.インストール実行。
Railsのように、MySQLへテーブルが作られる。

./bin/install.pl

足りないCPANライブラリはメッセージ表示される。

5.Apacheのhttpd.confへ下記を追加する。
CodestrikerはPerlなので、CGIの設定方法と同じ。


ScriptAlias /codestriker/ /var/www/cgi-bin/codestriker/cgi-bin/
Alias /codestriker/html/ /var/www/cgi-bin/codestriker/html/

<Directory "/var/www/cgi-bin/codestriker/cgi-bin/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
SetHandler cgi-script
</Directory>

<Directory "/var/www/cgi-bin/codestriker/html/">
AllowOverride None
Allow from all
</Directory>

Apacheを再起動後、
http://IPアドレス/codestriker/codestriker.pl
で表示可能!


【2】Webシステムとしての使い勝手、色合いなどのUIは、ReviewBoardの方がいいと思う。
しかしながら、Codestrikerには下記のようなレビュー記録のメトリクスを出力する機能がある。

Codestriker:Metrics Report

上記は、実施日ごとに、レビューのステータス(完了、解決、無効)とレビューコメント数を集計する。
この集計から、レビューの活発具合、レビューの貢献具合を見ることができる。


コードレビューWebシステムをレビュー工程の一プロセスへ含むように運用するには、いくつかのハードルを越える必要がある。
だが、レビューをもっとお手軽に行えて、更にはDBにあるレビュー記録からメトリクスを出力して、品質を測定できる可能性がある。

色々試してみたい。

| | コメント (0) | トラックバック (0)

最小限のチケット駆動開発の運用方法

営業の人がRedmineでチケット駆動開発を実践した記事があったのでメモ。

【元ネタ】
redMineで仕事のディレクション・進行管理 | 陽のあたらない美術館 -人間再生-


上記Blogを見ると、下記の内容のようだ。

・Redmineのバージョンは、0.6.4。

・Web制作のタスク管理にRedmineを運用している。

・バージョンには、「受注フェーズ」「企画・仕様」「ベータ版公開」「正式公開」が登録されている。
 つまり、マイルストーンを工程単位にしている。

・チケットには「見積書提出」「契約」「企画書提出」「仕様詳細検討」「開発1」「動作確認1」「サーバ設定」「調整」などのタスクが登録されている。
 これらのチケットを工程であるバージョン単位にまとめている。

・ガントチャートやカレンダー、ロードマップでチケットの進捗を管理している。

・ステータスは「新規→担当→解決→終了」のため、Redmineのデフォルトと思われる。

・ワークフローとしては、タスクを追加して、タスクを解決して、タスクを終了する最も基本的なパターン。
 あまり複雑なワークフローは想定していない。

上記の運用は非常によく考えられていて、非常に上手だと思う。
理由は、バージョンをマイルストーン代わりに使うため、タスクの全体の進捗の見通しが良い。
チケットの粒度も、成果物単位、作業単位のため、担当者一人に割り当てられる粒度だから、ToDo管理しやすい。
ワークフローも最もお手軽なフローのため、少人数の営業チームで運用しやすいだろう。


チケット駆動開発の対象はSW開発だけではないし、Subversionのような構成管理ツールが必須条件であるわけではない。
上記のやり方は、SW開発でも、いわゆる契約の管理やベンダー問合せやFAQなどのインシデント管理にも使えると思う。

つまり、最小限のチケット駆動開発は、シンプルなタスク管理なのだと思う。


| | コメント (0) | トラックバック (0)

ReviewBoardのインストール方法

Python製コードレビューWebシステムReviewBoardをインストールできたので、その設定方法をメモ。

【元ネタ】
Documentation - reviewboard - Documentation for Review Board - Google Code

Review Board | Take the pain out of reviewing code

ReviewBoardのインストール | Ryuzee.com

monospace blog ? オンラインソースコードレビューツールのReviewBoardをインストールしてみた

monospace blog ? ソースコードレビューツールReviewBoardの使い方メモ 前編

monospace blog ? ソースコードレビューツールReviewBoardの使い方メモ 後編

monospace blog ≫ ReviewBoardを使ったコードレビューのワークフロー

【必須の環境】
以下、CentOSで下記ツールはインストール済みとする。

Python version 2.4 or higher
Django version 0.97 or higher
PIL - The Python Imaging Library
patchutils
MySQL 5.0.31 or higher
MySQL-python
Subversion
pysvn

【1】インストール方法

1.MySQLでReviewBoard用データベース作っとく。

mysql -u root
create database reviewboard character set utf8;

ついでに、ReviewBoard用ユーザも作る。

grant create, select, insert, update, delete, alter, lock tables on reviewboard.* to 'reviewboard'@'localhost' identified by 'reviewboard';
flush privileges;

2.ReviewBoardのソースを持ってくる。

svn checkout http://reviewboard.googlecode.com/svn/trunk/reviewboard reviewboard
chmod -R 777 reviewboard

次に初回アクセスだからディレクトリを作る。

cd reviewboard
mkdir htdocs/media/images
chmod -R 777 htdocs/media

3.設定ファイルへMySQL設定を追記する。

cp -ip settings_local.py.tmpl settings_local.py

DATABASE_ENGINE = 'mysql' # 'postgresql', 'mysql', 'sqlite3' or 'ado_mssql'.
DATABASE_NAME = 'reviewboard' # Or path to database file if using sqlite3.
DATABASE_USER = 'reviewboard' # Not used with sqlite3.
DATABASE_PASSWORD = 'reviewboard' # Not used with sqlite3.
DATABASE_HOST = '' # Set to empty string for localhost.
DATABASE_PORT = '' # Set to empty string for default.

SECRET_KEYの生成は1行で書けます。

python -c "import random;CHARS = 'abcdefghijklmnopqrstuvwxyz0123456789%^&*(-_=+)';print ''.join([random.choice(CHARS) for x in range(50)])"

これをSECRET_KEYの値として設定する。

# Make this unique, and don't share it with anybody.
SECRET_KEY = 'p8923yaernva4tqkwdavo8qi2v7349qc3q23479-p123youwidhoq8923yco'

ついでに、時間と言語も設定する。

TIME_ZONE = 'Asia/Tokyo'
LANGUAGE_CODE = 'ja'

4.初期化テーブルの作成で下記コマンドを実行。
RailsみたいにMySQLにテーブルが作られます。

python manage.py syncdb

djangoサーバをノーハングアップで稼動させる。

nohup python manage.py runserver IPアドレス:8000 &

http://IPアドレス:8000/dashboard/
で起動する

これでようやく画面が出る。
ID・PW:reviewboardでログインできる。


但し、ログを見ると、下記ライブラリも必要みたい。

Pygments
 ハイライト表示機能
Installing PyLucene
 全文検索機能
memcached
 メモリキャッシュ

【2】他Blogを見ながら、管理画面で色々設定する。
下記に色々説明がある。

Review Board | Media and Links

Review Board - a set on Flickr

ReviewBoardで興味を惹いたのは、バグ管理システムと連携できる点だ。
コードレビューのコメントを書く時、バグ管理IDを入れると、該当チケットにリンクする。
この機能のおかげで、コードレビューで修正やリファクタリングが発生したら、チケットで作業状態を追跡できる。

つまり、チケットの発生源はReviewBoard、実際のタスク管理はRedmineで行う運用になる。
おそらく下記の記事のような運用フローになるだろう。

monospace blog ≫ ReviewBoardを使ったコードレビューのワークフロー

TestLinkでも似たような運用になる。
つまり、バグの発生源は普通、テストケースをテストして判明するから、TestLinkの失敗したテストケースにバグ管理IDを紐づける機能がある。
このおかげで、テスト工程やバグ発生源はTestLink、実際のバグ修正の管理はRedmineのように運用できる。

従って、変更管理プロセスはRedmineでやるが、変更要求はTestLinkやReviewBoardから発生するという流れになる。

最近強烈に感じるのは、ツールの運用で開発プロセスが大きく改善されることだ。
コードレビューはペアプロの代替手段という効用もあるから、色々試してみようと思う。


|

コードレビューWebシステムが必要な理由

最近、コードレビューWebシステムに興味を持っている。
アイデアをメモ。

【元ネタ】
プログラマの思索: ソースインスペクションを真面目にやるGoogle、MS

プログラマの思索: コードレビューはペアプログラミングの代替手段

プログラマの思索: レビューはペア作業であるべき


最近思うのは、SW開発でレビュー工程が最大のボトルネックになっていること。

レビューは、設計書を作成完了した後、設計書に従って実装完了した後に行われる。
レビューの目的は二つあると思う。
一つは品質チェック。
他方は、チーム全体で仕様や設計思想を情報共有すること。

しかし、レビューがうまく機能していない。
実際は、レビューが品質強化につながっておらず、むしろ、要件定義の代替プロセスになっていたり、ソースチェックで自動化できるぐらいのレベルでしか、情報共有できてない。

僕の考えでは、XPのペアプロのように、レビューは二人のペアで、レビューイーのPCの前でレビュー結果を即反映していく方がはるかに生産性が高いと思う。
理由は、レビュー結果は紙ベースで残すため、伝言ゲームになりがちで、せっかくの仕様が漏れやすいから。
また、レビュー指摘事項を記録に残して、レビュー結果をいつ反映したか、というレビュー作業ステータスを管理するのは、又もやExcelのため、ステータスの追跡やステータス集計がやりにくい。

そこで、コードレビューWebシステムを導入してみることを考えている。
特にコードレビューは、場所や時間が離れた場でもレビューできる状況がBetterだと思う。

Perl製のソースコードレビューソフトウェア「Codestriker」

VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」

上記は、コードレビューをWebシステム上で行うもので、僕としては画期的だと考える。
理由は、場所や時間が離れていても、誰でも簡単にレビューをコメント(チケット)として書いて残せること、更には、レビュー結果がDBにあるため、色んなメトリクスを出力できるから。

ReviewBoardには、二つのソースのDiff画面で、任意の場所にコメント(チケット)を付加できて、そのチケットのステータスを追跡できる仕組みがある。
この仕組みは、チケット駆動開発によるタスク管理と同じ発想。
つまり、レビュー指摘のチケットのステータス(未着手・レビュー修正中・レビュー反映完了)を追跡できるため、レビューのワークフロー管理を行うことができる。

Codestrikerには、レビュー指摘件数とレビュー作業のステータス(未着手・レビュー修正中・レビュー反映完了)を実施日でクロス集計して表示する機能がある。
この仕組みは、レビュー実績の信頼度成長曲線のようなもの。
つまり、ある程度のボリュームでレビューの指摘が上がり、それに対応していくと、ある時点でレビュー指摘件数が減り、最終的には品質が歩溜まりに達するだろうと考えられる。

だが、上記のコードレビューWebシステムが良いと思うのは、誰もが気軽にレビューコメントをチケット登録できることだ。
普通、レビューワーは業務知識を知り尽くしている人、プログラミング技術に長けている人がその役割を担うが、チームに新規加入した人や新人も気軽に質問できるような雰囲気が出てくる。

例えば、Googleにおけるコードレビュープロセスの概念では、信頼関係の強化が含まれている。
つまり、レビューワーとレビューイーがレビュー工程を通して、お互いの信頼関係を高めながら、仕様や技術を共有していくことが含まれている。
レビューは単なる欠陥のあら探しではないのだ。
レビューを通じて、チーム全体で設計思想を共有することで、どのメンバーでもシステムの運用保守をできるような環境を作る。
このような環境作りがあれば、特に、新人や新規加入メンバーのスキルアップに非常に役立つ。

しかしながら、コードレビューWebシステムを稼動できたものの、実際の運用はハードルが高かった。
特にコードレビューしていくと、リファクタリングに関係するチケットが増えてゆき、それらは内部課題やリスク管理のようなイテレーションに含まれてしまい、一般に優先度が低くなる。
だから、即修正する場合があまり増えない時がある。
理由は、まずチームにレビューというプロセスが無かったり、コードレビューの作業と、Redmineチケットの関係付けが曖昧だったから。

でも最終的には、レビューはペアプロとして実装され、そのレビュープロセスは、チケット駆動開発の一プロセスとして組み込まれるべきだと思っている。


| | コメント (0) | トラックバック (0)

2009/04/03

AmazonがMapReduceを公開

AmazonがMapReduceのAPIを公開していたのでリンクしておく。

Amazon Elastic MapReduce

昨年のkansai.pmで、はてなの伊藤さんがMapReduceの講演をした時の感想もメモ。

プログラマの思索: MapReduceメモ

プログラマの思索: 【感想】Kansai.pm第9回ミーティング

| | コメント (0) | トラックバック (0)

アジャイル開発の弱点をプロジェクト管理サーバーが助ける

Redmine、TestLink、Hudsonなどの各種ツールを運用してみて、これらはアジャイル開発を補強するツール群なのだと直感した。
アイデアをメモ。

【元ネタ】
Redmine - Overview

TEF有志によるテスト管理システムTestLink日本語化プロジェクト

Hudsonを使ったアジャイルな開発入門:第1回 Hudsonの導入|gihyo.jp … 技術評論社

Perl製のソースコードレビューソフトウェア「Codestriker」

VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」

【1】アジャイル開発の利点

XPを代表とするアジャイル開発の有用性は、昨今、色々知られてきた。
アジャイル開発の中で最も有名と思われるXPで最も重要なプラクティスは、小規模リリースだと思う。

小規模リリースとは、イテレーションという短いサイクルで小さく作りこんで小刻みにリリースしながら、システムを機能拡張し、品質を向上していくプロセスを指す。
緊急のバグ修正、突然の仕様変更に対しても、次のイテレーションに取り込む手法で、柔軟に対応していく。

小規模リリースのプラクティスは、メインラインモデルと呼ばれる構成管理と密接に関係する。
メインラインモデルとは、本番環境で稼働中のモジュールと、裏で新規開発中のモジュールの2つのコードラインを並行開発するソース管理手法。
メインラインモデルのおかげで、バグ修正のbranchと機能追加のtrunkの2つのコードラインを小刻みにバージョンアップしながら、品質保持と機能拡張という矛盾した開発スタイルを可能にする。

また、イテレーションは2~4週間のリリース単位でもあるから、一つのイテレーションで実装可能な機能の数は限られる。
従って、ストーリーカードのサイズはおのずと分割され、更に、優先順位付けされて、イテレーションに取り込まれていく。
つまり、高度なマネジメント手法を小規模リリースは必要とする。

又、イテレーションを一つずつリリースしていくうちに、ビルド作業やリリース作業の重大な欠陥、仕様漏れや要件漏れをすぐに判明でき、そのフィードバックをノウハウとして蓄積していく。
これがプロセス改善になり、ナレッジデータベースにつながる。

【2】アジャイル開発の弱点

しかしながら、アジャイル開発を実際の現場に運用するのは難しいと思う。

小規模リリースを実現するには、メインラインモデルと言う高度な構成管理手法を必要とする。
Subversionを骨の髄まで知り尽くしておかねばならない。

小規模リリースしていくには、どの機能をどのイテレーションでリリースしていくか、というイテレーション計画を作らねばならない。
しかし、イテレーション計画は、緊急のバグ修正や突発的な仕様変更に対応せざるを得ないため、頻繁に変わる。
だから、タスク漏れしないようなリアルタイムなタスク管理のインフラを必要とする。
Excelによるスケジュール管理だけでは、イテレーションを管理するのは非常に難しい。

また、XPが提唱する継続的インテグレーションを実現するには、ビルド作業やリリース作業を自動化することが大事。
継続的インテグレーションは、コードラインの品質を保証してくれる重要なプラクティス。
継続的インテグレーションが実現されなければ、回帰テストが難しくなるから、テスト駆動開発のメリットも半減する。

そして、プログラマがあまり重要視していないXPのプラクティスの一つである受入テストが、実は大きな弱点の一つだと考える。
テスト駆動開発は単体テストの観点で、品質を保証するだけ。
XPでは、結合テスト以降のシナリオベースのテストの観点がは弱い気がする。
特に、普通の受託開発では、結合テスト以降のテスト工程で開発人員が最大化するため、メンバーの管理だけでマネージャは忙しくなる。
受入テストの進捗管理や品質管理の観点が弱いと思う。

そして、ペアプロのプラクティスもその重要性や有用性が直感できるにも関わらず、実際の現場では根付かない。
ペアプロの本質は、レビュー工程の代替手段にある。
しかしながら、普通のSW開発では、レビュー工程が実は最大のボトルネックになっていると思う。
設計書のレビュー工程は、要件定義の代替プロセスと化しており、実際の設計の品質向上につながっていない。
実装のレビュー工程は、レビューワーが業務ロジックを知り尽くしていないから、単なるコーディングルールのチェックに過ぎない。
また、従来のレビューでは、複数人が大量の紙を印刷して持ち寄って、長時間議論して、紙ベースでレビューの記録を残すから、レビュー漏れが発生しやすい弱点がある。

【3】プロジェクト管理サーバーがアジャイル開発の弱点を助ける

僕が考えるプロジェクト管理サーバーの概念は、SW開発のプロジェクトを立ち上げる時に必要な構成管理ツール群が乗っているVMwareイメージをWebサーバー上で動かすことだ。
つまり、現場リーダーがSW開発を運営するのに必要な開発インフラが、プロジェクト管理サーバーの機能を持つWebサーバーであるイメージ。

Redmine、Tracでチケット駆動開発を実践することで、イテレーション計画を制御し、小規模リリースを実現するためのタスク管理の役割を担う。

メインラインモデルの実現は、SubversionあるいはGitなどのバージョン管理を使う。
もちろんソースだけでなく、ExcelやWordの仕様書もバージョン管理する。

AntやMavenなどのビルドツールと、CIツールHudsonを組み合わせて、ビルド管理やリリース管理を自動化する。

TestLinkで受入テスト工程を管理することで、テスト工程の進捗管理と、発生したバグ修正をRedmineのようなBTSと連携する。

また、コードレビューはコードレビューWebシステムで行う。
例えば、VMWareの開発でも利用されているソースコードレビュー共有ソフトウェアReviewBoardやPerl製のソースコードレビューソフトウェアCodestrikerなどを使ってみる。

これらのツールの最大の特徴は全てWebシステム上で実現されること。
Webシステムであることの利点は二つある。
一つは、いつでもどこでも誰でもアクセスさえすれば、必要な情報を取得できて更新できること。
もう一つは、実績や作業履歴がDBに残るため、データマイニングを使って、品質や進捗に関するメトリクスを簡単に出力できること。

特に、メトリクスを出力できることは、高度なマネジメントを行うのに決定的に有効だ。

昨今、テスト駆動開発やRuby on Railsなどのように下流工程で大幅な技術革新が生まれているのに、プロジェクト管理やテスト管理は10年前と同じようにExcelで手作業で集計するなど、上流工程でボトルネックになっていることが多くないだろうか?

プロジェクト管理サーバーを導入することで、SW開発のうちで特にプロジェクト管理の部分を強化してみよう。

| | コメント (0) | トラックバック (1)

2009/04/02

All In One Redmineの作り方

Fedora10上でTestLinkとBugzillaのVMwareイメージがあったので、更にRedmineをインストールしてみたら、正常動作できた。
このVMイメージさえあれば、All In One Redmine(正しくは、All In One Redmine+TestLink)として使える。

作成方法をメモ。

【必要なもの】
ダウンロードURL-Fedora7にTestLinkとBugzillaをインストールしたVMwareのイメージ-PukiWiki - TEF有志によるテスト管理システムTestLink日本語化プロジェクト


VMware Player


【戦略】
上記のFedora10には、既に下記がインストールされている。

Java 1.6.0_0(但しJREであってJDKではない)
php 5.2.6
perl 5.10.0
python 2.5.2
MySQL 5.0.67
Apache 2.2.0
Subversion 1.5.4
TestLink 1.7.4
Bugzilla 3.2rc1

故に、RubyやRedmineさえインストールすれば、殆どのツールが動く。
さっそくVMwareイメージにRedmineをインストールしてみる。

【前提条件】
1.VMPlayerをWindows上でインストール済み。
2.上記のFedora7にTestLinkとBugzillaをインストールしたVMwareのイメージをダウンロード済み。
※2Gあるので注意。

【作成手順】
1.上記のVMwareイメージを開く。
 ID・PWともtestlinkでログイン。
 更に、rootユーザ(パスワード:testlink)で入っておく。

2.Rubyをインストールする。
yum install ruby ruby-devel rdoc irb

ruby 1.8.6が設定される。

3.RubyGemsをインストールする。
yum install rubygems

rubyGems 1.3.1が設定される。

4.Redmineをダウンロードする。

wget http://rubyforge.org/frs/download.php/52944/redmine-0.8.2.tar.gz
tar zxvf redmine-0.8.2.tar.gz
mv redmine-0.8.2 redmine
chown -R testlink:testlink redmine
chmod 777 redmine

5.Railsをインストールする。
Redmine0.8.2は、Rails2.1.2が推奨のため、バージョンに注意する。

cd redmine
gem install rails -v=2.1.2

6.RedmineのDBを作る。

mysql -u root -p
create database redmine default charset='utf8';

7.Redmineの設定ファイルを修正する。

cd config
cp email.yml.example email.yml
cp database.yml.example database.yml

mysqladmin -u root -p variable | grep socket
でソケットを探し、database.ymlのproduction部分へ
socket: /var/lib/mysq/mysql.sock
を追加

8.Railsのおまじないを実行する。

rake db:migrate RAILS_ENV="production"
rake load_default_data RAILS_ENV=production

9.Webrickを起動したら、、

ruby -Ku script/server -e production -d
※-dを付けるとデーモンになる

http:localhost:3000
でRedmineの表示に成功!

10.ID・PW:adminでログインして、アカウントのリンク押下後、日本語を選択する。
すると、日本語が設定される。

以後は、ユーザを追加するなり、プロジェクトを作るなり、カスタマイズすればいい。

VMwareイメージはWindowsでもUnix上でも使えるから、上記のAll In One Redmineは、SW開発プロジェクトの立ち上げ時にそのまま使える。
何故なら、Redmineだけでなく、SubversionやTestLinkもあるため、SW構成管理の環境がほぼ揃っているからだ。
後は、JDKをインストールしてHudsonを入れたり、色々入れてみればいい。
僕としては、プロジェクト管理サーバーとしてAll In One Redmineを使いたかったから、すごくありがたい。

今後のプロジェクト管理は、Excelではなく、TracLightningやAll In One Redmineが主流になるのかもしれない。

| | コメント (0) | トラックバック (0)

« 2009年3月 | トップページ | 2009年5月 »