« 2011年7月 | トップページ | 2011年9月 »

2011年8月

2011/08/29

【告知】デブサミ関西が開催されます #devsumi

毎年、目黒雅叙園で行われるデブサミがついに関西でも開催されます。
是非ご参加ください。

Developers Summit 2011 kansai

会期 2011年9月7日(水)
会場 神戸国際会議場(兵庫・神戸)
主催 株式会社 翔泳社
お勧めする方 技術者、ソフトウェア開発者、システム開発者、ネットワーク管理・運用者、IT教育担当者、 ITマーケティング・セールス担当者、IT関連部署マネージャ、プロジェクト関連マネージャ
参加費 無料

タイムテーブルはコチラ。
10th Anniversary Count Down Developers Summit 2011 Kansai

懇親会も下記で開催されるそうです。
関西のITコミュニティも続々参加されるようなので、楽しめると思います。

9月7日 デブサミ関西懇親会(兵庫県)

又、別会場にて、Scrum Boot Camp in 関西も開催されます。
Scrumに興味がある人、Scrumを運用してみたい人は、参加してみると気付きが得られると思います。

Developers Summit 2011 Kansai:Scrum Boot Camp in 関西

9~10月は下記のようにITイベントが続々と続きます。
今年の関西は秋が熱いです!

9/3(土) XP祭り(東京)
9/7(水) デブサミ関西(神戸) Developers Summit 2011 kansai
9/8(木) 品川Redmine(東京) 第1回品川Redmine勉強会 : ATND
9/17(土) DevLove関西(大阪) DevLOVE関西2011CONNECT
9/22(木) 関西Jenkins(大阪) 第1回大阪Jenkins勉強会 : ATND
9/24(土) 関西Kinect(大阪) 関西Kinect勉強会vol.1 : ATND
10/8(土) AgileTourOsaka(大阪) AgileTourOsaka2011

| | コメント (0)

【告知】第1回品川Redmine勉強会を開催します #47redmine

9/8(木)に第1回品川Redmine勉強会を開催します。

【詳細】
第1回品川Redmine勉強会 : ATND

shinagawa.redmine - 第一回勉強会 - Redmine

【追記】
関東近辺のRedmineファン有志と共に、関西のRxtStudyに続いて、関東でもRedmineコミュニティを立ち上げることになりました。
@nobiinu_andさん曰く、「東のTrac、西のRedmine」らしいので、関東ではRedmineを使っている人は少ないのかなあと思ってました(笑)

Twitter / @nobiinu_and: ですね! USTあるとイイなぁ… 実は東のtrac、西のredmineという状況だったりして RT @akipii: @nobiinu_and Redmineでのタスク管理を考える勉強会@大阪で議論できると思います。http://atnd.org/events/17268 #RxTstudy

今回の品川Redmine勉強会の一番の目玉は、日本人のRedmineコミッタ @marutosijpさんが発表されることです。
RedmineがVer1.2のリリースに到るまでに色んな困難があったにも関わらず、ここまで発展してきた背景について講演されるかと思います。
是非、当日の勉強会を楽しみにお待ち下さい。

なお、参加者多数のため既に応募締め切りしています。
追加申し込みはありませんのでご注意ください。

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

2011/08/28

インフラやデータ移行の自動化~アジャイル開発の最後の問題

牛尾さんが書いた記事を@ryuzeeさんが絶賛されていたのでメモ。

【元ネタ】
アジャイルなインフラのつくり方とデータマネジメント - メソッド屋の日記

Twitter / @ryuzee: これは素晴らしい記事だ / アジャイルなインフラのつくり方とデータマネジメント - メソッド屋の日記 .

XPが提唱したテストの自動化、ビルド作業の自動化によって、開発工程は確実にスピードも品質も上がる。
しかし、受入テスト環境へのデプロイ作業(リリース作業)でいつも手間取る。
本番環境は開発環境とは違って、環境そのものも違うし、データも違うから、モジュールの配置以外の作業が大変なのだ。

「アジャイル開発は開発環境ではとても有効だが本番環境ではその恩恵があまりない」という指摘は「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」において「ラストマイル問題」として既にあげられている。
※拙著「Redmineによるタスクマネジメント実践技法」の290ページにも、「ラストマイル問題」について触れています。

プロジェクト管理やテスト工程をクラウド化する: プログラマの思索

Agile開発が指摘したソフトウェア開発の特徴: プログラマの思索

牛尾さんの記事によれば、AmazonEC2でクラウド化するだけでなく、Rubyライブラリveewee、Vagrantを使って仮想環境の立上げ・設定・テストを自動化ができるらしい。
つまり、本番環境と同等な環境を仮想マシンで複製しておき、それを立ち上げるようにすればいいのだろう。

また、本番環境で稼働させる時には必ずデータ移行が発生し、そのために移行ツールを別途作ったり、移行元データをクリーニングする面倒な作業が発生する。
データベース・リファクタリング」では、データ移行期間を用意して、データ移行するためのノウハウをリファクタリング作業のパターンとして提唱している。

リリース作業の問題のレベルをソフトウェアで解決できるレベルに変換すれば、それはAgile開発が得意とする所だ。
テストやビルドの自動化だけでなく、デプロイやデータ移行の自動化も今後のアジャイル開発の課題になるだろう。

| | コメント (0)

2011/08/26

チームは加速するのか~Velocityの使い方 #agilesamurai

先日、アジャイルサムライ渋谷道場に行ってきた。
Velocityについて議論しているとき、速度という概念があるなら加速度みたいなものはあるのか?という質問があった。
そこから考えて、@daipresentsさんのBlogの意味がやっと分かったのでメモ。
間違っていたら後で直す。
※追記:Focus FactorやTargeted value Increaseの定義も解釈も間違っているので、後日直す。

【元ネタ】
Redmineでアジャイルチームのスピードやパワーを見える化する | 世界 - @daipresents

XP with Kanban instead of Scrum | Zsolt Fabo'k's Page

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

【1】Velocityとは、1スプリントでチームが開発できる開発規模(ストーリーポイント)を表している。

渋谷道場でScrumを実践している人は、1週間で12ポイントぐらいのVelocityですね、と言っていた。
1チーム4人とすれば、1週間で3ポイント/人の開発速度なのだろう。

見積もりには、規模見積もりと工数見積もりの2種類がある。
Scrumは規模見積もりと工数見積もりの2種類を計画作りのプロセスに入れて、スプリント終了時に規模見積もりを工数見積もりへ変換して、補正係数(Velocity)を得る仕組みがある。

ScrumのVelocityが従来のSW開発の見積もりよりも優れている点は、定期的に見積もり結果を評価して、規模見積もりを工数見積もりにすぐに変換できるために精度を上げることが可能なことだと思う。
見積もりの精度がスプリントを経るごとに上がれば、計画作りも楽になる。
詳細は下記に書いた。

Scrumの見積りと計画づくりは何故優れているのか?: プログラマの思索

従来開発では、FP法でいくら厳密に開発規模を見積もっても、実際にどれだけの工数がかかるのか、を知るのは難しい。
COCOMO2を参考にして、規模見積もりを工数見積もりへ変換したとしても、チームのメンバーの能力、開発言語や開発環境などの要因が考慮されていないから、見積りの正当性がない。見積りの評価は、1年後の本番リリースで初めて分かるから、規模見積もりがすぐに役立たない。

InfoQ: ストーリーポイントは複雑さや時間と関係があるか?では、見積もりのゴールについて書いている。

(前略)
見積りのゴールは、「いつ完了するんですか?」や「期日までにどれくらいの機能ができるんですか?」という疑問に答えることです。もしこれが正しければ、どんな単位で見積ろうとも、どんなアプローチをとろうとも、それは時間に関係がある必要があります。
(後略)

見積もりの目的は、いつまでに完了するのか、期限までにどれくらいの機能をリリースできるのか、をおおよそに知りたいこと。
見積もり作業そのものにあまり時間がかかっても意味が無い。
だから、Scrumではストーリーポイントでラフに計測して、PDCAサイクルを早く回して検証して精度を高めていくことを重視しているのだろう。

【2】@daipresentsさんのBlogによれば、各スプリントのVelocityを蓄積すれば、チームの成長度合いを測定できるようだ。
Scrumの資料を漁ってみると、Focus FactorとTarget Value Increaseというメトリクスがある。

(2-1) Focus Factor = 実績のベロシティ / 予想のベロシティ

※注意:@daipresentsさんのBlogでは、分母と分子が逆になっているが、多分、@daipresentsさんの間違いだと思う。

Focus Factorは、予想と実績のVelocityの割合を指す。「達成度」みたいなものだろう。
Focus Factor(FF)の定義から、下記が導かれる。

FF < 1 →実績のVelocityが予定よりも悪いので、開発パフォーマンスが悪い
FF > 1 →実績のVelocityが予定よりも良いので、開発パフォーマンスが良い

個人的には、PMBOKのEVMのCPI(コストパフォーマンス)ないしCR(危険度指数)に似ていると思う。
だから、FFを時系列にグラフ化すれば、チームの成長度合いをより見える化できるだろう。

普通は、初期のFFは数値が低く、スプリントの回数を多く経験するほど、FFは1に近づいて安定するだろうと思う。

(2-2) Target Value Increase = 実績のベロシティ / Sprint1のベロシティ

Targeted Value Increaseは、初期のスプリントからチームがどれだけ成長しているかを示す。
普通の新規開発案件ならば、初めての顧客、初めての技術、初めての開発環境作りなどのリスク要因が大きいから、初期のスプリントの成果物量(出来高)は少ないだろう。
そして、スプリントを経るごとに、顧客の要望の癖が分かったり、フレームワークの癖をメンバーが理解してコーディング量が増えたり、開発環境を安定して使えるようになって、成果物量(出来高)も増えていくだろう。

Targeted Value Increase(TVI)の定義から、下記が導かれる。

TVI < 1 →実績のVelocityがSprint1のベロシティよりも悪いので、開発パフォーマンスが悪い
TVI > 1 →実績のVelocityがSprint1のベロシティよりも良いので、開発パフォーマンスが良い

普通に考えると、最初から数回のスプリントはTVIが徐々に増加して、一定期間後のスプリントになるとTVIは安定するのだろうと推測する。

(2-3) Estimated Velocity = Velocity x Focus Factor

次回スプリントの予定のVelocityは、平均値のVelocityにFocus Factorを乗算したもので出力される。

FFの定義からして、FF < 1ならVelocityは減るし、FF > 1 ならVelocityは増える。
つまり、平均値のVelocityに補正係数を加味して、直近の開発パフォーマンスを反映させている。
次回スプリントのVelocityは、直近の開発パフォーマンスを引きずっているはずだろうから、その分、Velocityの精度は上がり、計画を立てやすくなるだろう。

【3】Focus FactorやTarget Value Increaseの使い道としては、@daipresentsさんのBlogに書かれている通り、Velocityの傾向からチームの開発の傾向が分かることだと思う。

例えば、「過去最高のVelocity」「過去最悪のVelocity」には必ず何らかの原因がある。メンバーが休んだり、初めての技術を使ったり、顧客が今までにない改善要望を出してきた、などの場合があるだろう。
「GWのように祝日の多い週のVelocity」は、普通のスプリントよりも期間が短いのだから、Velocityも期間が短い分に比例して小さくなるはず。
調べてみると色々気づきが出てくると思う。

ScrumのFocus FactorやTarget Value Increaseについてあれこれ考察してみると、PMBOKのEVMに出てくるCPI、SPIの概念に似ているなあ、と思う。
CPI、SPIも、1よりも小さいならパフォーマンスが悪いし、1よりも大きいならパフォーマンスが良い。
PMBOKのEVMは、規模見積もりは無く工数見積もりだけだが、EV(出来高工数)という概念によって、EVを成果物量とみなして、各種のメトリクスを出力して、コストやスケジュールを予測する。

だが、Scrumの方が、見積もりの複雑さをストーリーポイントという仮定された単位で割り切って、より簡単にしているのが面白い。

これらの概念を理解して実運用されている@daipresentsさんはすごいなあ、と思ったりする。
色々考えてみる。

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

ソフトウェアが世界を動かす時代

Appleのジョブズ氏がCEOを辞任するニュースを見つけた。
そのニュースから、池田さんの記事を連想したのでメモ。

【元ネタ】
池田信夫 blog : ソフトウェアが世界を食う - ライブドアブログ

米アップルのジョブズ氏がCEO辞任-後任にティム・クック氏(4) - Bloomberg.co.jp

IT新時代-APPLEジョブズ氏退任を受けて|HATのブログ

上記の記事を読むと、ソフトウェアが世界の主役に躍り出た事実を意味していると思う。
Amazonは本を、Appleは音楽を、Googleは広告を、Skypeは電話をソフトウェアに変えた。
TwitterやFacebookはコミュニケーションをソフトウェアに変えた。
そして、それら会社のビジネスモデルは成功して、既存の古い企業をどんどん駆逐している。

でも、まだまだソフトウェアには可能性がある。
他のビジネスモデルももっとあるはず。
個人的には、電子書籍(epub)に期待している。

現実の問題をソフトウェアで解決できるレベルに落とせれば、あっという間に問題を解決できるだろうし、新たな観点を示すはず。
チケット駆動開発も同様に、プロジェクト管理をIT化して、ソフトウェアで解決できる問題に変換することを目指している。

あらゆる問題がソフトウェアで解決できるならば、Agile開発が得意とする場面が増えるし、ソフトウェア開発はもっと楽しくなるだろうと思っている。

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

2011/08/24

Scrumの見積りと計画づくりは何故優れているのか?

ソフトウェア見積り」を読みながら、「アジャイルな見積りと計画づくり」「アジャイルサムライ」に書かれている見積り技法が何となく理解できてきた気がするのでメモ。
ラフなメモ書き。
間違っていたら後で直す。

【1】Scrumの見積りは、規模見積り(ストーリーポイント)と工数見積もり(理想時間・理想日)の2種類がある。
初期のスプリント計画では、ストーリーカードに対して、規模見積りをまず行う。
その時、ストーリーポイントの単位で、フィボナッチ数列の数値で相対比較する。
そして、更に実作業であるタスクカードへ分割する場合、各タスクは理想時間、つまり割込みがなく集中して作業できる最短工数を見積る。

スプリントを実施してリリース後、実際の実工数や作業期間が確定する。
つまり、初期のスプリント計画で見積もった規模見積りに対して、納品したストーリーポイント数、実際に作業した実績工数、納品までにかかった期間が確定するので、ストーリーポイントから工数や期間に換算して、補正係数を得ることができる。

以下、「ソフトウェア見積り」の153ページを参照する。
例えば、1スプリントで3週間、4人のチームで12人週かかって27ストーリーポイントの機能をリリースしたと仮定しよう。
すると、下記の補正係数が計測できる。

平均実績工数=27ストーリーポイント/12人週=2.25ストーリーポイント/週=0.45ストーリーポイント/MD
平均スケジュール=27ストーリーポイント/3週間=9ストーリーポイント/週=1.8ストーリーポイント/日

上記の数値がまさにVelocityそのものだ。
このVelocityを使って、180ストーリーポイントのシステム規模の開発をすると仮定しよう。
すると、下記のような推測が成り立つ。

平均実績工数=180ストーリーポイント/2.25ストーリーポイント/週=80人週
平均スケジュール=180ストーリーポイント/27ストーリーポイント/3週間=20週

つまり、1スプリント=4週間でイテレーティブな開発をする場合、5スプリントは必要で、1スプリントで36ストーリーポイントを実装できるだろうと見積もれる。
そして、36ストーリーポイントを16人週、つまり4人のチームで4週間かければ開発できるだろうと見積もれる。

【2】従来のWF型開発でも、規模見積りはファンクションポイント法で既に理論化されている。
そして、FP法で見積もられた規模見積りをCOCOMO2で工数見積に換算する手法も既に知られている。
しかしながら、WF型開発では、実際の開発規模がどれくらいの工数に落ち着くのかを知るには、実際に開発工程に入って、最後の本番リリースまで見届けないと分からない。
つまりWF型開発では、規模見積りから工数見積に換算するタイミングは、1年後の本番リリースの時まで待たねばならない大きな弱点がある。

Scrumが従来のWF型開発よりも優れている点は、規模見積りから工数見積もりへ換算するタイミングがスプリント終了時ゆえに頻繁に存在すること。
実際、1スプリントは4週間だから、1ヶ月おきに規模見積りから工数見積もりへ換算した係数(つまりVelocity)を何度も追跡できるから、精度は理論上良くなっていく。

【3】僕も以前FP法で実システムを計測してみたことがあった。

FP法で業務モデルを計測する: プログラマの思索

FP法は業務システムの規模見積りで有効で、モデルのCRUD表が完成すれば即座に計算できる。
だから、OOAやDOAなどのモデリング技法とFP法は相性が良いと思っている。

しかしながら、実際のシステムのFPを計測しても、そこからどれくらいの工数がかかるのか、は結局WBSレベルの作業へ詳細化しなければ工数見積もりできなかった。
COCOMO2などを使って規模見積りから工数見積もりへ換算できたとしても、その工数に妥当性があるかどうか、顧客や上司に説得できるだけの自信はなかった。
それはあくまでも参考値であり、現在の開発チームの実績から得られた見積り工数ではないから、誰も信用しない。
だから、FP法はあまり役立たないな~と思っていた。

だが、Scrumは規模見積りも考慮に入れていて、それを工数見積へ換算する仕組みを持っているのがとても素晴らしい。
しかも短いスプリントをなんども繰り返せば、Velocityの数値はぶれが収まっていくはずだから、顧客や上司へも見積りの正当性を説明しやすい。
何故なら、過去のスプリントの実績値がVelocityに含まれているから、現状の開発チームの開発ペースはVelocityで求められた数値です、と実データで説明できるからだ。
見積りの正当性も、実際のスプリントで計測した工数でなければ、誰も納得はしない。

アジャイルな見積りと計画づくり」ではこの辺りの話が書かれておらず、僕の頭にピンとこなかったけれど、「ソフトウェア見積り」を読んでようやく理解できた。

【4】上記で得られたVelocityの使い道は、「アジャイルサムライ」ではVelocity駆動のリリース計画づくりとして詳しく説明されている。
アイデアは下記に書いた。

Velocity駆動のイテレーション計画の作り方とは: プログラマの思索

ScrumやXPが教える所では、Velocityを元に作業量を調整するのがマネジメントの基本。
スコープ・コスト・納期のマネジメントの三角形において、コスト(要員)や納期(スプリント)は固定だから、スコープを調整するしかない。
つまり、過去の実績値から得られたVelocity(チームの開発ペース)から類推して、4週間で終われるような作業量をあらかじめ準備するのがスコープ管理なのだ。

駄目なプロマネは、チームの人数を増やしてVelocityを見かけ上大きくして、開発チームがこなせる作業量以上の作業負荷を課して、納期に間に合わせようとする。
このやり方は人月の神話で知られているように、工数(コスト)を予想以上に浪費して開発チームを疲弊させる。

あるいは、開発チームがこなせる作業量以上の残作業をこなすために、納期を延ばす手段をとる時もある。
この場合も、Velocityは変えないのだから、納期を延ばすのは自然だが、人間はリズムで生きる生物だから、スプリントの期間が不安定だとあまり成功しないように思う。
実際、僕の数少ない経験でも、納期を延ばしたとしても、残業が延々と続くだけなので高い作業負荷が続いて、開発チームのペースも予想よりも落ちやすい。
結局、当初予定した納期よりも更に遅れる場合が多い。

この辺りの話は「アジャイルサムライ」の8章で詳しく述べられている。
この章は僕が経験とフィットして、一番好きな章だ。

見積りは計画プロセスで最も大切な技法の一つ。
まだまだ研究する余地がある。

| | コメント (0)

2011/08/23

チケット駆動開発が進むべき道part4~チケット駆動開発がもたらした新しい観点 #tidd

チケット駆動開発が従来のどんな問題を解決して、どんな新しい観点をもたらしたのか、考えを整理してみる。

【元ネタ】
Twitter / @akipii: ツールの背後にあるチケット駆動開発の意義を汲み取って欲しい。RT @yusuke_kokubo 自分が管理してメンテナンスするならRedmineだけど自分が使う側だったらTracでもJIRAでもなんでもかまわない。ちゃんと使えれば

Twitter / @akipii: #redmine ツールの背後にあるチケット駆動開発が従来のどんな問題を解決して、SW開発にどんな新しい観点を提示したのか?を汲み取って欲しいのです。

【1】SW開発の難しさは、結合テスト以降の障害管理ではっきり現れてくると思う。
WF型開発であれAgile開発であれ、ある程度動くモジュールに対して、機能を追加して品質を向上していくプロセスは、そう簡単なものではない。

そもそもBTSを導入していないチームは、バグ情報がメールやExcelに散乱しているから、メンバー同士の情報共有すらできていない。
バグが発生した環境や操作手順を開発者に伝わらないために、バグの再現性に関する議論が延々と続いたりする。

又、せっかく見つけたバグも50個、100個と増えてくれば、バグの担当者はたらい回しにされたり、一部の担当者にバグ修正の負荷が集中したりする。
最悪な場合は、バグそのものが放置されて、どんどんバグが増えてプロジェクトそのものが破綻する。

特に、バグの再現性を確認しても、モジュールがどの時点で修正したバージョンなのか、をきちんとコントロールして検証しないと、バグを直したことにはならない。
ビルド管理、リリース管理で、Excelのソース管理台帳を見ながら、ソースのリビジョン1個ずつに対して手作業でタグ付けする場合、リリース漏れが発生しやすい。
最悪な場合は、ソースが先祖帰りして、せっかく直したバグが再現されてしまうデグレが起きる。そうすると、メンバーのモチベーションがガクンと落ちる。

【2】チケット駆動開発の意義は、それらの問題点に対して、一つの解決方法を示している。

まず、バグだけでなく、プロジェクト内部の作業は全てチケットへ集約する。
実績工数が発生するタスクは全てチケットに起票することで、メンバー全員が作業履歴を残し、それを誰もが検索して共有できる環境を作る。
チケットには作業内容だけでなく、進捗や構成管理の情報も付与するから、ソースからチケットへ変更理由も探すことができる。
それらは「Tikect First」「No Ticket, No Work」「No Tikcet, No Commit」という運用ルールで表現される。

次に、Redmineなど高機能化したITSには、柔軟なワークフロー管理機能がある。
この機能を使えば、バグだけでなく、ソフトウェア開発全般のタスク管理に拡張できる。
つまり、開発や設計書作成、リリース作業、更にはプロジェクト内部で発生した課題、顧客からの問合せ、インフラチームからベンダーへの質問などあらゆる情報は全てチケットに起票できれば、チケットの背後にあるワークフローによって、ステータスが一意に決まる。
バグやタスクだけでなく、問合せも課題もエスカレーションした問題も全て、何らかのワークフローの上に載っているのだから、チケットから最新状態を追跡できる。
TiDDでもっとも有効な隠れた機能が柔軟なワークフロー管理であり「Ticket Tracking」という運用ルールで表現される。

更に、ITS・SCM・CIというツールを組み合わせると、顧客の改善要望から開発、ビルド、リリースまでの作業を一貫して補強できる。
例えば、XPのイテレーション=Redmineのバージョン=SCMのリリースタグ=CIのビルド番号のように連携すれば、リリース済みバージョンが自然にリリース履歴となり、ロードマップはリリース計画、その短期計画が自然にイテレーション計画に対応できる。

【3】ITS・SCM・CIの3つのツールを@haru_iidaさんはSW開発の3種の神器と呼ばれた。
その言葉の背後には、従来のツールを連携して組み合わせると、「No Tikcet, No Commit」のような新しい使い方が生まれて、ソフトウェア開発の生産性を上げてくれる事実を示している。

上田さんはこの事実から、チケット駆動開発はAjaxみたいだね、と言われた。
つまり、チケット駆動開発は、従来から知られている古いツール(BTS)から新しい使い方(Agile開発)を提示したことを言っていると思う。

チケット駆動開発が新しい観点をもたらしたのは、従来のKKD(山勘、経験、度胸)によるプロジェクト管理をツールによるプロジェクト管理へ変換して、ソフトウェア工学に基づいたプロジェクト管理へ脱皮できること。
例えば、BTSにためられたチケットは、集計機能によって、ガントチャートだけでなく、バーンダウンチャート、信頼度成長曲線、PMBOKのEVMなど各種の進捗や品質のメトリクスで出力できる。
それらの情報はプロマネの意思決定をサポートしてくれる。

更には、プロジェクト管理の問題をツールの一機能による実装に置き換えることで、プログラミングの問題に変換したこと。
BTSに機能が足りないと思うなら、実装してしまえばいいだけ。
特にRedmineならRailsで作られているので、テーブル設計もURLも綺麗だから、初心者でもCoCに慣れれば簡単に機能拡張できる。
プログラミングの問題に落とし込めれば、後は実際に動く機能を作ればいいだけのことだ。
Howの問題に変換できれば、Agile開発なら一瞬で問題解決できる。

RedmineでもTracでもMantisでも、チケット駆動開発は実践できると僕は経験した。
それらのツールの背後にはチケット駆動開発があり、チケット駆動開発は、ソフトウェア開発のマネジメントの権限をプロマネからプログラマへ移行させたことに一番意味があると思っている。

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

2011/08/21

チケット駆動開発におけるソフトウェア見積り

細谷さんの下記のつぶやきでいくつか考えたことをメモ。

【元ネタ】
Twitter / @yasuohosotani: @akipiiさんがbit.ly/9LRcnhで触れているようにXDDPとチケット駆動はとても相性がいいです。たぶん、USDM作成時に各階層の粒度がある程度そろった結果、1つの変更設計に対する作業量や深さも揃うからだと思っています。

ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(1) - アークウェブシステム開発SandBox

ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(2) - アークウェブシステム開発SandBox

ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(3) - アークウェブシステム開発SandBox

ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(4) - アークウェブシステム開発SandBox

www.sakuttoly.com - 読書記録#9 スティーブ・マコネル『ソフトウェア見積り 人月の暗黙知を解き明かす』

SEの読書回顧録 ソフトウェア見積り―人月の暗黙知を解き明かす

ソフトウェア見積りを読了

【1】RedmineのチケットをXPのタスクカードのように運用した場合、僕の経験上、チケットの平均工数は1.5人日程度になる。
最初は2~5人日程度の大きなチケットも作りがちだが、作業後に気付いたタスクや突然発生したバグ、突発的な仕様変更などが入り交じって、最終的には1人日以下のチケットが多くなる。
リリース後にチケットを集計してみると、計画当初に登録したチケット数とイテレーション実施中に登録したチケット数はほぼ同じぐらいの割合になる。

逆に言えば、実際のソフトウェア開発では、計画外の作業がかなり多く、計画当初の想定よりも2倍くらいの作業になることを意味している。
WF型開発でうまくいかない理由は多分この現象にあるのだろうと思う。
計画外の作業がとにかく多すぎて、計画当初の作業は追跡できても、計画外の作業をリリースまで追跡していくのはとても煩雑で難しい。
そこから作業漏れが発生し、リリース後に膨大な仕様変更と障害報告がチームに押し寄せる。

ソフトウェア開発では、要求は変更されやすいから、スコープ管理がとても重要。
コストと納期は固定なのだから、顧客のビジネス要件と開発チームの生産能力の観点で、スコープを削って定期的に安定してリリースさせるのが本来のSW開発のマネジメント。

そして、変更要求をきちんと管理して追跡していく仕組みがソフトウェア開発ではとても重要。
管理されない変更要求は、必ず作業漏れが発生し、仕様漏れという名前の大きなバグとしてリリース後に判明する。
駄目なマネージャは、変更要求を認識せず、顧客の言いなりになってどんどん開発作業を膨らませて、最後にプロジェクトを破綻させてしまう。

チケット駆動開発では、ロードマップ機能でリリース計画を担当するので、各イテレーションの計画時に必ずスコープをチェックする仕掛けがある。
直近のバージョンにリリースする機能はどれか、いつどの機能を順にリリースしていくか、というマネジメントを常に意識せざるを得ないからだ。

更に、突発的に発生した仕様変更やバグは、即座にチケットに登録すればいい。
登録されたチケットを吟味して、更に追加のタスクが発生すれば、子チケットで作ったり、関連するチケットを作ればいい。
あるいは、登録されたチケットのワークフローが現状に合わないのなら、トラッカーを変えて、本来のあるべきトラッカーへ修正すればいい。
あるいは、直近のイテレーションで実施しなくていいチケットならば、チケットの属性にある対象バージョンを変更して、イテレーション間を移動すればいい。
つまり、計画外の作業は即座にチケットに登録しておき、そのチケットを精査して詳細化する過程でチケットの属性を変更してFixすればいい。

【2】見積りという技術が計画プロセスで大きな重要性を占めることは下記で書いた。

ソフトウェア開発に特有な技術~ソフトウェア見積り: プログラマの思索

チケット駆動開発でも、リリース計画づくりで見積り技術は必須だろうと思う。
とはいえ、実際のチケット駆動開発では、チケットの粒度が小さいため、予定工数まで書かない運用は多い。

チケット駆動開発の特徴の一つは、チケットをタスクカードとして扱うため、既に見積りは終わっているという過程から始まる点がある。
実際、チケットの粒度は1人日以下が多いから、チケットの中身はかなり詳細化されているため、チケットの優先度や作業順序を決めやすい。
メンバーはチケットに書かれたタスクを順番にこなしていくだけでいい。

細谷さんが言う通り、清水吉男さんが提唱するXDDP(派生開発の開発プロセス)では、USDMという手法によって要件をかなり細かい部分まで仕様化していく。
だから、タスクの粒度も小さいレベルまで落とすことができて、その分、見積もりの精度も正確になるのだろう。

【3】チケットの属性には実績工数があるので、チケット完了後に実績工数を入力する運用があれば、リリース後に実績工数を簡単に集計できる。
僕は、毎週、登録・終了チケットの枚数と実績工数を必ずカウントして、Excel上で時系列に並べて分析している。
その目的は、バグ収束曲線とEVMを見たいから。
その時に気付いたことは下記に書いた。

アジャイルサムライで一番難しくて面白い概念~Velocity: プログラマの思索

安定したプロジェクトならば、未完了チケット数が一定になるようにプロジェクトがコントロールされているだろう。
つまり、登録チケット数-完了チケット数が一定なので、メンバーは忙しくもなく暇でもないように、常にタスクがある状況になっているだろう。

また、初期のイテレーションでは、Velocityが安定しないので、CPI(コストパフォーマンス)はあまり良くないが、イテレーションをこなしていくうちにVelocityのばらつきも減り、CPIも1.0へ近づいてくる。
これは、予定工数と実績工数の差が小さくなっていくこと、つまり、見積もりの精度が上がっていくことを意味している。

PMBOKのEVMの概念は、Agileのバーンダウンチャートとほぼ同じ概念だ。
EVMがPV・EVの右肩上がりのグラフなら、バーンダウンチャートは残PV・残EVの右肩下がりのグラフに過ぎない。
EVMの優れている点は、CPIを計測することで、リリース時のコスト(工数)を予測しやすくなること。
チケット駆動開発を通じて、この辺りの概念の特徴を理解しやすくなった。

【4】チケット駆動開発に弱点があるとすれば、規模見積りを含めた計画づくりをサポート出来ていない点だろう。
実案件の要件をチケットのレベルまで詳細化できれば、チケットの粒度は所詮1人日程度なのでかなり正確に見積もれる。
WBSを詳細化していく過程で、どんな作業が必要なのか、を考えるから、作業漏れがかなり減るはず。

しかし、肝心の要件そのものが漏れていたら意味がないし、スコープコントロールも作業レベルだ。
かなり大きめの仕様変更が来た場合、イテレーションに組み入れるのは難しいから、複数のイテレーションに分けるリリース計画を作る必要があり、そこには見積り技術が必要。
特に初期の概要見積りは、開発規模を見極めるのが重要で、顧客のビジネスの目的やコスト、納期を考慮して、どの機能が必要だから残し、どの機能が優先度が低いので削る、という判断がいる。
その部分はチケット駆動開発の範囲外。

チケットの親子関係によって、ストーリーカードとタスクカードを実現する手法もあり、多分ScrumのストーリーポイントやVelocityの概念をうまく使えばカバーできるだろうと思うが、まだよく分からない。

チケット駆動開発は実作業の管理にすごく向いているが、要件レベルの管理はまだ力不足かなと思っている。
見積りによって計画の精度を上げる、ないし、スコープを制御して計画をコントロールする手法はまだまだ研究の余地があるように思っている。

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

ソフトウェア開発に特有な技術~ソフトウェア見積り

ソフトウェア見積りを読んで考えたことをメモ。
ラフなメモ書き。

【元ネタ】
ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(1) - アークウェブシステム開発SandBox

ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(2) - アークウェブシステム開発SandBox

ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(3) - アークウェブシステム開発SandBox

ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(4) - アークウェブシステム開発SandBox

www.sakuttoly.com - 読書記録#9 スティーブ・マコネル『ソフトウェア見積り 人月の暗黙知を解き明かす』

SEの読書回顧録 ソフトウェア見積り―人月の暗黙知を解き明かす

ソフトウェア見積りを読了

【1】SW開発でプログラマからSEへ役割が変わる時に要求される技術の一つとして、見積もりがある。
このシステムの開発見積をしてくれ、この作業を見積もりしてくれ、その作業のスケジュールの概要を教えてくれ、と言われる。
この見積りはとても難しく、そして見積もられた数値は一人歩きする。

見積が必要な状況は2つあると思う。
一つはシステム提案時の初期見積り。

まだ営業活動中の時、お客さんのラフな要望からある程度の規模見積り・工数見積もりをして、おおまかな金額を知ること。
お客さんは安い方がよいが、SIとしては自分たちの能力以上に値切った見積りをして案件をとっても、赤字プロジェクトになるなら意味がない。
赤字プロジェクトが前提の案件は、よほどの戦略的プロジェクトでなければ、営業する価値もない。
その概要見積りの作業中に、概念モデルやシステムアーキテクチャをあれこれ推測するうちに、システムのリスクや特徴などを知ることもできる。

更に、見積りで顧客とSIで金額や納期が合わない場合、スコープを変化させることでコストや納期を妥協出来るか、という判断にも使いたい。
つまり、コスト・納期・スコープによるマネジメントの三角形で、どの機能(スコープ)を削除したらコストや納期で妥協できるか、顧客のビジネス要件に合致するか、という再見積の作業が更に発生する時も多い。

もう一つは、案件の受注確定後、開発の全作業を詳細見積りする場合だ。
WF型開発なら、設計・開発・テスト・リリースの各工程の作業や成果物をWBSで洗い出し、どれくらいの工数がかかるのか、一つずつ精査して見積もりしていく。
この詳細見積りがまさにプロジェクトの立上げ・計画プロセスで最も重要な作業になる。
何故なら、この時に洗い出したWBSと予定工数から、各工程の作業が確定して、担当者にアサインされていくから。
とはいえ、作業漏れやスコープ漏れも後になって判明するし、技術リスクを見落としてしまう時もあるから、マネジメント上の予備工数(コンティジェンシー予備)を故意に上積みしておく。
しかし、普通はこのバッファも食い潰してしまう時が多い。

「経営陣が欲しているのは、「見積もり」ではなく「計画」である。」という文章からは、「アジャイルな見積りと計画づくり」を連想させる。

【2】「アジャイルな見積りと計画づくり」では、不確実性コーンという図がいきなり最初に出てくる。
この図の意味が正直分かっていなかったけれど、ソフトウェア見積りを読んでようやく腑に落ちた。

不確実性コーンは、プロジェクトスコープ(規模・工数など)の見積りのばらつきを時系列(工程別)にグラフ化したもの。
当然、初期提案時は見積りの誤差は大きく、詳細設計の完了時には誤差はかなり小さくなり、ソフトウェア完了(リリース)ではゼロになる。

不確実性コーンが意味することは、プロジェクトの初期段階における見積りは誤差が大きいため、外れやすいこと。
初期見積りは概算見積りゆえに、システムが象さんレベルなのか、犬猫レベルなのか、ぐらいの判断しかできない。
見積りの正確性は、ソフトウェアの定義を詳細化していくレベルに依存する。
つまり、現在の見積もり作業が不確実性コーンのどの位置にいるのか、を常に意識しなければならないこと。

しかし、時間が立てば見積りの誤差が自然に収束するわけではない。
コーンが収束するには、ばらつきを取り除くための意思決定を経る必要がある。
つまり、スコープを確定するのが重要。

だが、Agile開発のように、スコープが常に揺れるのが普通のプロジェクトの場合、不確実性のコーンは時間が経っても勝手に収束することはない。
そして、変更された要求を追跡(トラッキング)する作業は大抵の場合おろそかにされやすく、再見積が必要なのに、再見積もりされない。
だから、初期のベースラインからどれくらいスコープやコストが変わったのか、をコントロールしにくい。
普通のデスマーチは、不安定な要求をスコープ管理できず、要求がどんどん肥大化してプロジェクトが破綻する時が多い。

ソフトウェア見積りでは、そんな場合は見積りの正確さを求めるよりも、先に混乱を収束させるべきと言っている。
つまり、要求が安定されないことを前提として、プロジェクトコントロールを重視して反復型・漸進型プロセスを採用するなどの手法を勧めている。

【3】「アジャイルな見積りと計画づくり」でまだ理解できておらず、実践出来ていない概念がストーリーポイント。
ソフトウェア見積りでは、ストーリーポイントをファジー見積りの一つとして詳細に説明してくれている。

ストーリーポイントによる見積りは規模見積りの一つだ。
スプリント前に見積もったストーリーポイントはただの代替指標に過ぎない。
初回の反復が完了後、実際の工数が得られると、ストーリーポイントから定量的な工数へ換算することができて、見積りの補正が可能になる。
例えば、ストーリーポイントから工数やカレンダー(納期)へ換算することで、チームのVelocity(開発速度)が得られる。
チームは、そのVelocityを参考にして、次の反復の見積りに生かす。
つまり、Velocity駆動でリリース計画、スプリント計画を作り、計画の精度を上げていく。

ストーリーポイントやVelocityなど、Scrumが従来のAgile開発に無かった概念や枠組みを提供した事実は考察に値する。
Scrumでは、規模見積り(ストーリーポイント)と工数見積もり(理想時間・理想日)を区別して見積もる点はとても重要だと思う。
ScrumはVelocityを経由して、規模見積りと工数見積もりを連携させている点が上手。

そして、Scrumでは、ユーザ(プロダクトオーナー)と開発者(開発チーム)のViewをバックログとタスクボードで意図的に分ける。
更にバックログ上でストーリーカードに対して規模見積り、タスクボード上でタスクカードに対して理想時間の工数見積もりを行い、それぞれの見積りをスプリント計画へ反映して、計画の正確さを上げる。
短い反復を繰り返すごとに、見積もりの精度は理論上上がっていく。

規模見積りの単位がストーリーポイントにするのは僕はまだ理解できてない。
ストーリーポイントは開発規模をフィボナッチ数列の尺度に合わせていることが重要なポイントの一つ。
しかし、ソフトウェア見積りでは、開発規模の見積りの相対関係がフィボナッチ数列の比率に合致してればうまく作用するが、尺度が現実と違えば誤差も大きくなる、と言っている。
実際のプロジェクトでどこまで見積もりの精度が上がるのか、試行錯誤が必要なのだろうと思う。

| | コメント (0)

2011/08/17

Agile開発に足りないもの~モデリング技術

@hatsanhatさん、@sugimoto_keiさんと議論していて、TiDD+DOAで開発できないか、と考えたことをメモ。
ラフなメモ書き。
下記はあくまでも僕の一意見。
間違っていたら後で直す。

【1】「DOAとRailsは相性が悪い」という意見はよく知られている。
でも、逆に、Railsだからこそ、DOAがより重要になってきた気がしている。
RailsでWebアプリを作っていると、どのようなテーブル設計が良いのか、という問題に結局ぶち当たる。
更新時異常が発生しないようなテーブルを設計するのは、そんなに簡単な技術ではない。
以前、Ruby関西の勉強会でも渡辺さんが講演した時もあったが、その講演の発端もその問題にあったのだろうと思う。

丁度それは、Agile開発がシステム開発をHowの問題に落とせれば高速・高品質に開発できるけれども、WhatやWhyの部分ではまだ手持ちの武器が少ない状態に似ていると思う。
最近は、XPのオンサイト顧客の概念を発展させて、Scrumがプロダクトオーナーと呼ばれる役割を提唱しているが、ユーザにいきなりプロダクトオーナーの役割を求めるのは非現実的な場合が多いと思う。

なぜなら、ユーザに自分たちの業務をモデリングできるレベルを要求しているから。
つまり、ユーザに、ビジネスをITの言葉で翻訳するアーキテクトの役割をいきなり求めているから。
ユーザは自分たちの業務は詳しいだろうが、それをソフトウェアという一つの論理モデルへ抽象化する技術は又別の技術だ。
それはモデリングの範疇だろうと思う。

【2】ユーザにプロダクトオーナーの役割を求めることやAgileな契約作りの前に、開発チームにはやるべき作業がまだたくさんあると思っている。
僕はSW技術者だから、まず技術にこだわりたい。
Agile開発しやすいビジネス環境があったとしても、肝心の技術力が低ければ無意味だ。
実際、WF型開発しか知らない開発チームがいきなりAgile開発を実践しようとしても、契約以前に技術上の課題がたくさんある。

そもそも、ユーザの業務をモデリングして、ストーリーを引き出すのが難しい。
そして、引き出したストーリーを1ヶ月単位で頻繁にリリースするのは、たとえAgile開発であってもそう簡単な技術ではない。

前者の問題に対しては、牛尾さんはAgileTourOsaka2010で、プロダクトオーナーに必要な技術として、ストーリー供給力とストーリー検証力という概念を提唱された。

Agile Tour 2010 Osakaで講演してきました - メソッド屋の日記

僕の解釈では、ストーリー供給力は文字通り、ストーリーをユーザから引き出す能力。
普通は、スプリント0ないしアーキテクチャスパイクの期間で、開発対象の8割ぐらいのストーリーを引き出さないといけない、と言われていたように思う。

ストーリー検証力は、ストーリー間の整合性をチェックしたり、ストーリーがユーザのビジネスの目的に合致しているか、という能力。
ストーリー間の整合性チェックは、リリースの優先順位に密接に関係する。それはチケットの優先度(開発チーム観点の作業の優先順位)で表現できるだろうと思う。
ストーリーとビジネスの目的の整合性チェックは、リリース後の売り上げや削減コストの計測のようなKPIやKGIで実際に評価できるだろうと思う。
それはチケットの重要度(ユーザ観点のビジネス上の優先順位)で表現できるだろうと思う。

後者の問題に対しては、頻繁にリリースできる開発環境が必要で、チケット駆動開発がその解決手段の一つになるだろうと思っている。
最終的には、月曜にストーリーをもらって金曜にはリリースできるように、1週間単位で本番リリースできる環境と技術がなければ、Agile開発をいくら実践したくても無理だろうと思う。

【3】モデリングそのものに関する問題は、オブジェクト指向分析では、ドメイン駆動に関する優れた本が出ていて、モデリング技術を補完してくれている。
特に、「エリック・エヴァンスのドメイン駆動設計」と「アナリシスパターン」の2冊の知識は、オブジェクト指向分析で要件定義しようとするときに必須だろうと思う。
だが、その2冊の本を読んでみると、DOAの技術から発展しているようにも読めるし、その概念モデルの背後には会計の概念が隠れていることに気づく。

@sugimoto_keiさんがTwitterで「エリック・エヴァンスのドメイン駆動設計」の感想を書かれていて、それを理解しようとしたら、オブジェクト指向分析(OOA)でもその概念モデルの背後に簿記のモデル(例:荷為替手形、経過勘定科目(前払保険料など))が出ているのに気づいた。

Twitter / @sugimoto_kei: (モデルと現実⑦)Eric Evans 氏が Domain-Driven Design 本で、「浅いモデル」と「深いモデル」を区別している(原著P190)。でも本当は彼が挙げた貨物配送の2つの違いは深さでは無くて、前者はビジネスの、後者は帳簿のモデルであるということだと思う。

Twitter / @akipii: @sugimoto_kei @hatsanhat とても勉強になります。DDD本では貨物輸送システムのモデルに出てくる貨物の移動オブジェクトは最終的に船荷証券オブジェクトに変わったとありますが荷為替手形の事ですね。219頁の発生主義会計は経過勘定科目を指すと考えられますね(続く)

エリック・エヴァンスのドメイン駆動設計では、貨物輸送システムのモデルを洗練させると、船荷証券(荷為替手形)というオブジェクトが主要な役割を果たすと書かれている。
荷為替手形とは「輸出代金決済のために輸出者(売主)が振り出す為替手形に船積書類が添付されたもの」であり、下記の解説が分かりやすい。

荷為替手形を徹底解説!【簿記検定ナビ】

荷為替手形は、誰が船に積まれた商品の保全に対して責務を持っているのか、誰が船に積まれた商品を受け取る権利を持っているのか、という概念を含んでいる。
権利や責務の概念が発生する場合、そこにはビジネス(お金)が必ず絡んでいて、それは複式簿記による仕訳(債権や債務)という概念で既に実現されている。
多分、横浜や神戸のような港町の銀行が荷為替手形を扱っている場合が多いだろうと思う。

また、発生主義とは会計の一原則で「現金の収入や支出に関係なく、収益や費用の事実が発生した時点で計上する」考え方。期中の取引が過去や来期の取引に影響を及ぼす場合、経過勘定科目を使って仕訳を起こす。
つまり、お金が発生した時点ではなく、役務(サービス)の提供又は受領が発生した時点で仕訳が発生する。
ここでも、権利と義務、債権と債務の概念がモデルに絡んでいる点が面白い。

グラス片手にデータベース設計 ~会計システム編」で会計の原則がSE向けに分かりやすく解説されている。
又、下記の解説が分かりやすかった。

経過勘定と未決済項目

業務システムのモデリング技法としては、OOAよりもDOAと簿記が一つの解決法を示唆していると思う。

そして、Agileな開発スタイルをビジネス化するよりも、優れたソフトウェア製品を作るという根本問題に立ち戻る方が重要だろうと思っている。

| | コメント (2)

2011/08/15

活動ログを解析するRedmine Graph Activitiesプラグイン

活動ログを解析するRedmine Graph Activitiesプラグインが公開されていたのでメモ。

【元ネタ】
Redmine Graph Activitiesプラグインのご紹介 - TitleNotFoundException

Redmine Graph Activitiesプラグインは、「Redmineのプラグインで「活動」の情報をもとに、どの時間帯に何回チケットが更新されたか、コミットされたかをグラフで表示します。」とのこと。
画面を見ると、曜日別・時間別・ユーザ別に集計表示してくれるので、便利そう。

雑記その1、その2に書かれている内容がとても面白い。
Ruby on Railsなので、CoC(コーディング規約)が徹底しているため、初心者でも書きやすいということを示唆されているのは興味深い。

下記を参考にすれば、たぶん誰でもRedmineプラグインを作れると思う。
Redmineに機能が足りないと思うならば、自作すればいいだけのことだ。

r-labs - プラグイン開発ガイド - Redmine

また、下記Blogが発端でRedmine Graph Activitiesプラグインを作ってみたとの事。

金曜にバグを発生させるコミットが多い: プログラマの思索

(引用開始)
僕の職場でもやはり夕方から夜にかけて、そして金曜日に駆け込みでチケットが更新されることが多いと感じていて、果たして本当にそうなのか?じゃあグラフにしてみよう!というのが開発のコンセプトです。
このプラグインを使えば、夕方から夜にかけて活動する「夜型人間」や、休日出勤して活動する「休出人間」を見つけ出すことができると思っています。僕のいる職場では、思ってたより夜型ではなかったようなので、それもまた一つの発見でした。
(引用終了)

メトリクスによる傾向分析の良い点は、リーダーの思い込みをメトリクスが修正してくれることだと思う。
僕も仮説を立ててはRedmineやTracにあるデータを分析してみると、自分が考えていたこととは違った結果が出たり、思わぬ傾向が見えたりする時がとても多い。
リーダーは裸の王様になりがちなので、メトリクス分析とプロジェクトファシリテーションを組み合わせてチーム運営すればいいだろうと思う。

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

2011/08/13

アジャイルサムライで一番難しくて面白い概念~Velocity

先週、アジャイルサムライ読書会に行ってきた。
スタッフ並びに勉強会の皆様、ありがとうございました。
考えたことをメモ書き。

【元ネタ】
アジャイルサムライ読書会(湯島道場) 第三回 火の巻に参加してきた #agilesamurai #湯島道場 - Shinya’s Dairy Report

ReadingAgileSamuraiInYushima - GitHub

Twitter / @ryuzee: 道場破り?の@akipiiさんがいますけどねw RT @haradakiro: 道場破りとかこないとヒマなのですね。RT @ryuzee: 用心棒だから黙ってるよ! #agilesamurai #湯島道場

Twitter / @kakutani: 読書会が盛り上っているなあという感じがよく伝わる / アジャイルサムライ読書会(湯島道場) 第三回 火の巻に参加してきた #agilesamurai #湯島道場 - Shinya’s Dairy Report http://htn.to/xXn8Nh

Velocity駆動のイテレーション計画の作り方とは: プログラマの思索

イテレーションの考え方は締め処理と同じ: プログラマの思索

TiDD初心者が陥りやすい罠~バージョンをCloseしないRedmineはVelocityが分からない: プログラマの思索

TiDDを実践して気づいたことpart9~Scrumのベロシティ #tidd: プログラマの思索

【1】VelocityはScrumが発見したもっとも重要な概念であり、Agile開発で一番難しくて一番面白い概念だと思う。

一番難しいとは、Velocityは実際のプロジェクトで簡単には計測しづらいメトリクスだから。
一番面白いとは、従来のソフトウェア工学にはなかった新たな概念であり、ソフトウェア開発の本質に迫る概念だと直感しているから。
とはいえ、PMBOKのEVMに出てくるCPI(コストパフォーマンス)、バーンダウンチャートで出てくる右肩下がりの残作業量の降下速度、でも表現できるだろうと思う。

今の僕は、RedmineやTracでVelocityを計測できないか、色々試行錯誤している。
Velocityらしきものとしては、2種類のメトリクスを計測している。

【2】一つは、EVMのCPI。
アイデアは下記に書いた。

RedmineからPMBOKのEVMを計測する方法: プログラマの思索

実際の計測方法としては、各イテレーション実施中のチケットに対して、PV=全チケットの予定工数、AC=全チケットの実績工数、EV=完了チケットの予定工数の総和、を1週間単位に計測し、CPI=EV/ACの変化をみている。

CPIは定義からして、顧客へ納品できた作業の出来高工数/実作業のコストだから、開発チームのコストパフォーマンスを表している。

例えば、「ソフトウェア見積り―人月の暗黙知を解き明かす」の188ページにある例がCPIの良い例だと思う。

www.sakuttoly.com - 読書記録#9 スティーブ・マコネル『ソフトウェア見積り 人月の暗黙知を解き明かす』

(引用開始)
例えば、6ヶ月のスケジュールがあったとしよう。あなたは、最初のマイルストーンを4週間で達成する計画を立てた。しかし、実際には6週間かかってしまった。この場合、あなたなら次のうちどれを選ぶだろうか。
(1)失った2週間は、スケジュールの後の方で埋め合わせられると考える。
(2)スケジュールの合計の2週間を追加する。
(3)誤差の大きさ(この場合は50%)をスケジュール全体に掛け合わせる。
もっともありがちなのは、1番目の選択肢だろう。通常は次のような論法になる。「要求にかける時間が予定より少し長かった。だが、もう要求は固まった。残りの時間を切り詰めよう。コーディングとテストの間で不足分を埋め合わせられるはずだ」。しかし、1991年に300以上のプロジェクトについて調査した結果によると、プロジェクトが一度失った時間を埋め合わせることは、まず不可能であることが分かっている。それどころか、遅れはさらに広がる傾向にある。したがって、この選択肢がベストチョイスなることは、ほとんどないと思ってよい。
(中略)
よほどの例外を除いて、実際の結果が見積もり通りにならない場合の正しい選択肢は、3番目ということになる。
(引用終了)

3番目の選択は、CPI=4週間/6週間=0.67という意味になり、顧客の要望から発生する作業の予定工数に対し、1.5倍の工数がかかって開発チームは作業していることを意味している。

実際にCPIを計測してみると、イテレーションの最初の1~2週間のCPIはとても低く、4週間目になると、ほぼCPIは1.0に近づくみたい。
つまり、最初はなかなかアウトプットを出せずコストオーバーになるが、慣れてくると予定通りのアウトプットを出せるようになってくることを意味している。

@ryuzeeさんの解説「直近2~3スプリントが、現時点での能力でありVelocity」「ベロシティは成長するものである。一定のままなのであれば逆に問題。」がとても分かりやすかった。

【3】もう一つは、未完了チケット数の推移。
運用保守のプロジェクトでは、単なる開発・修正だけでなく、顧客からの問合せ調査や本番障害など計画外のタスクが多い。
普通は、調査や本番障害のタスクはチケット化されてバックログに入れられて、優先度の高いチケットから順に直近のイテレーションへ混ぜ込んでいく。
当然、直近のイテレーションではなく、次回や次々回のイテレーションへ入れられるチケットもあるから、即座に対応しないチケットもある。

そこでバグ収束曲線のアイデアを活かして、チケットの累積登録数とチケットの累積完了数を時系列にグラフ化してみた。
すると、チケットは日々登録されるからチケットの累積登録数は右肩上がりに増える。
チケットもできるものからCloseさせていくから、チケットの累積完了数も累積登録数から若干遅れる形で右肩上がりに増えていく。
この時、未完了チケットの総数=チケットの累積登録数-チケットの累積完了数を時系列に見ると、最低値と最高値が平均値の2倍にならない範囲で収まるように計測できた。

未完了チケットの総数がほぼ一定の数値で前後しているという意味は、運用保守のプロジェクトで、仕掛り中のチケットがほぼ一定であることを意味していて、メンバーの作業負荷が高すぎることもなく、かと言って手持ち無沙汰で暇でもない実情を表していると思う。
つまり、仕事量が開発チームにとって溢れる程でもなく暇でもない状態であり、開発チームがプロジェクトをコントロールできているのを意味していると思っている。

@ryuzeeさんの指摘では「チケットの追加量、消化量が一定だから」とのことだが、確かに言われるとおりだと思う。
つまり、顧客の要望から発生した新規チケットがバックログへ貯められていく速度と、開発チームがバックログにあるチケットを消化していく速度がほぼ比例しているので、残作業量が一定になるのだろうと理解している。

【4】Velocityを計測したい理由は、Velocityを使ってリリース計画の精度を高めたいからだ。
普通のプロジェクトでは、納期と開発チームのVelocityを考慮すると、それ以上に顧客の要望がたまる場合が多く、うまくプロジェクトコントロールしないとすぐにデスマーチに陥る。
だから、「アジャイルな見積りと計画づくり」や「アジャイルサムライ−達人開発者への道−」で出てくるVelocity駆動で計画して、開発チームは顧客に対して、要望の制限をかけたい。
無制限な要望を全て実現するのは不可能だからだ。

特に、新しい技術を使った新規プロジェクトでは、次から次へと技術上の課題が噴出して、Velocityを計測したとしてもあまり有効でない可能性もある。
ソフトウェア見積り―人月の暗黙知を解き明かす」の47ページでは、要求が常に不安定の場合は、プロジェクトコントロールによる対象の方が見積による対処よりも強力に働くとあり、例として、ScrumやXP、タイムボックス開発などの手法があげられている。
これは、要求の変更が多くて不安定な場合、Velocity駆動よりもコミットメント駆動で計画した方がプロジェクトを制御しやすい、という主張だと理解している。

現場リーダーしてチケット駆動開発を実践してみると、プロジェクト管理をチケット管理に置き換えることによって、チケットの取捨選択とリリース計画のブラッシュアップという計画プロセスがとても面白い。
PMBOK、Scrum、XPが主張したいことはこういうことだったのかな、という納得感が非常に多いからだ。

Velocityはチケット駆動開発でも自然に現れた概念。
Velocityが意味することは、ソフトウェア開発において生産性の向上を開発チームに強いるよりも、開発チームが適切なペースで作業できる方が安定して開発できる経験則を示唆しているのだろうと思っている。

色々試してみる。

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

2011/08/11

レイヤの多い組織は無駄に複雑なシステムを作る~Conwayの法則

Conwayの法則とは「アーキテクチャは組織構造に従う」という経験則。
よく出る例は、4チームで作ったコンパイラは4パスのコンパイラになってしまい、複雑なアーキテクチャになってしまうというもの。
レイヤとConwayの法則について考えたことをメモ。

【元ネタ】
Togetter - 「RxTstudy Redmineでのタスク管理を考える勉強会@大阪」

Twitter / @cero_t: 「アーキテクチャは組織構造に従う」という経験則。 ソフトウェアのどの部分であれ、それを作った組織の構造を反映する。 ・・・いや、これは深いですね。なんか分かる気がする。今まで気づいてなかったけど、言われてみれば、確かにそうだ。 #RxTstudy

[#TiDD] アジャイル開発への壁 #RxTstudy: ソフトウェアさかば

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

10年前にJavaでWebアプリを作っていた頃の話。
まだStrutsのような汎用フレームワークもなく、各SI独自のWebフレームワークが乱立していた。

その頃のWebアプリのアーキテクチャは、DB層(EJBないしJDBC)・ビジネスロジック層(Servlet)・画面層(JSP)の3層構造でMVC2モデルと呼ばれていた。
開発チームのメンバーは、SQLを作る人、Servletを書く人、JSPを作る人のようにレイヤごとに分別されて作業していた。
レイヤごとに分ける理由は、各層で共通のロジックを作っておき、それを参照するようにしたかったからだ。
だから、WF型開発の設計工程で詳細な部分まで設計書を作る必要があり、オブジェクト指向設計が流行していたから、その影響を受けてかなり細かいクラス図やシーケンス図まで書いていた。

しかし、実際の開発では、結合テストで、各層のインターフェイスが合わなかったり、バグが多発したりして大変だった。
Conwayの法則に従えば、3層構造の開発チームだったので、3層構造のアーキテクチャになってしまい、バグ修正のパッチを当てるたびに複雑になっていくシステムだったのだろう。

最近では、Railsの開発が特徴的なように、一人の開発者がActiveRecordからrhtmlまで一気通貫で作る。
つまり、ユーザから見た機能単位で開発者が実装していくのが最近の開発スタイルだろう。
この開発スタイルが可能なのは、Railsのような優れたWebフレームワークがユーザインターフェイスから業務ロジック、DB層までのコーディング規約(CoC)が徹底しており、言語の高い生産性のおかげで以前よりも実装も楽になったからだ。
Conwayの法則に従えば、一人で開発するのだから無駄なレイヤがなく、機能単位で作るので、一つの機能の中でアーキテクチャも閉じている。

WF型開発では、元請のリーダーとたくさんの協力会社の開発者がチームを形成して、レイヤ単位で実装していくパターンが多い。
その理由は、技術上のアーキテクチャの観点もあろうが、開発チームが混成部隊ゆえに指揮命令系統が複雑になるという特徴もあるのだろうと思う。
特に受託開発では、元請けが要件定義の工程、下請けが設計や開発、単体テストまでの工程というふうに分けて開発するために、レイヤが発生する場所で必ず設計漏れやテスト漏れが発生する。
下請構造が深い階層になっているほど、レイヤが増えるのでその分コミュニケーションロスも大きくなる。
だから、無駄に複雑なアーキテクチャになってしまい、システムを保守しにくくなる。

Agile開発なら少数精鋭部隊で一気通貫でシステムを作るから、無駄なレイヤがない。
またリーダーはファシリテーターの役割なので、メンバーの意識も高く、チームは自己組織化されているだろう。
Conwayの法則の観点で見れば、Agile開発は理にかなっているように思える。

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

2011/08/09

Redmineのユーザインターフェイスは使いやすい

MantisやTestLinkなどのPHPアプリを触っていると、ユーザインターフェイスが古いなあ、と思う時がある。
Webアプリであっても、デスクトップアプリのようにマウスクリックする回数を減らすとか、オートコンプリートのような機能が欲しい。
チェックボックスをたくさんチェックしてボタンを押して初めて一括編集できるユーザインターフェイスは、やはり使いづらい。

Redmineは、Railsアプリなのでユーザインターフェイスが他のBTSに比べるとはるかに使いやすいことに改めて気づく。
僕が便利と思う機能をメモ。

【1】Redmineの気がつきにくい機能 | Redmine.JP Blog

チケット一覧画面で複数のチケットを選択後、右クリックするとコンテキストメニューが表示されて一括編集できるようになる。
この機能はとても便利。
最新バージョンでは、ブラウザに関係なく動作する。
#古いバージョンでは、IEで正常動作しない場合があるので注意。

【2】Redmine 1.1 新機能紹介: 「関連するチケット」設定時のオートコンプリート | Redmine.JP Blog

チケット画面で関連するチケット番号を入れると、チケットのタイトルをオートコンプリートしてくれる。
関連チケット番号を間違えて入力するミスもなくなるのでとても便利。

なお、関連チケット機能には「先行する」「後続する」「重複する」の機能があるがいつもややこしい。
英語表記ならば、主語+述語+目的語なので間違えないのだが。

チケット同士の関連づけ | Redmine.JP Blog

【3】ガントチャート画面でチケットの進捗バーにマウスカーソルを当てると、チケット情報をホバー表示(ポップアップで表示)してくれる。
逐一チケット画面へリンクしなくても即座に担当者などを確認できるから便利。

【4】チケット一覧画面で、チケットの優先度に従ってチケットを色分け表示するプラグインを@g_maedaさんが公開されている。
読みやすい日本語フォントへ設定してくれたりするので非常に便利。

日本語環境で読みやすいRedmine用テーマ「farend basic」公開 | Redmine.JP Blog

また、複数プロジェクトにわたって自分のチケットをみる機能はデフォルトではないけれど、下記のプラグインで自分担当のチケットが複数プロジェクトに散らばっていても、マイページ画面で確認できるようになる。
新規開発と運用保守の2つを掛け持ちしているメンバーなら、入れておきたいプラグインだ。

Redmineのマイページをより便利にする My Page Blocksプラグイン | Redmine.JP Blog

Railsは元々Prototype.jsのコミッタが混じっていたので、Ajaxと親和性が高かったおかげで、使いやすいユーザインターフェイスが実現された。
Rails3.0ではjQueryがデフォルト機能になると聞いているので、RedmineもRails3.0に対応するようになれば、もっと使いやすいユーザインターフェイスになるだろう。

今後もRedmineの動向に着目していく。

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

gitとRedmineを連携

gitとRedmineを連携する方法があちこちで公開されていたのでメモ。

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

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

「チケット無しのコミット不可」という運用ルールは、テスト工程の障害管理や本番運用中のソース修正から生まれた。
そしてこの運用ルールを徹底すると、全ての成果物を追跡可能というトレーサビリティにもつながるので、大変重要だ。

しかし、チケット駆動開発の運用ルールである「No Ticket, No Commit!」は面倒という声もよく聞く。
面倒な理由の一つは、コミットログを書く時に逐一、ブラウザを開いてチケットNoを探す手間がかかること。
でも、上記のコマンドを使えば、コミットする時にすぐにチケットNoを参照できるので便利。

特に、バグチケットに基づいてトピックブランチ上でパッチを作っている時に有効だろう。
何故なら、該当チケットを即座に参照しながらコミットしていくので、何のために修正しているのか、をいつも確認しながら修正できるからだ。
プログラミングに集中していると、肝心のチケットの内容も忘れてしまいがちだから。

個人的にはMercurialにも同様のコマンドがあるといいなと思っている。
TortoiseHgでもコミットログを書く時に、チケットNoがオートコンプリートしてくれると嬉しいけれど、誰か作っていないかな?

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

2011/08/07

Rxtstudyの感想

先日のRxStudy勉強会には、参加者の皆様、そしてスタッフの皆様ありがとうございました。
発表後、議論したりTwitterを読んで、考えたことをメモ。
下記はあくまでも一意見。

【元ネタ】
Togetter - 「RxTstudy Redmineでのタスク管理を考える勉強会@大阪」 by @buffering

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

【1】Twitter / @cero_t: TiDDで開発している人も半数以上? ほとんど? ぐらい。 すごい参加者 #RxTstudy

Twitter / @cero_t: 阪井さんもあまりRedmineを使ってなくて、Tracが多い。 TxTstudyで良いじゃないか。 #RxTstudy

チケット駆動開発という言葉の認知度が上がっている事実には正直驚きました。
そして聴衆の年齢層が比較的高めで、開発者よりも現場リーダーやマネージャの方が多い事実にも驚きました。

【2】Twitter / @yohhatu: 「気づき」ってトラッカーは面白いな。うちはその辺はyouRoomで出している。でタスクになれば、Redmineへ...という流れかな #RxtStudy

「気づき」「QA」というチケットは現場のチームから生み出された運用ルールです。
@yohhatuさんの言う通り、本来はチケット化せずに掲示板のような場で議論した方がいいのかもしれない。
もっと良い運用ルールはあると思います。

実際、以前はphpBB+Mantisで運用していた時もあった。
例えば、phpBBでコーディングルールやプログラミングの疑問点を質問して、Mantisチケットに書かれたバグを直すこともやっていた。
でも、情報があちこちに散在してしまったことと、phpBBが使われなくなってしまったので、あまりよい運用とは言えなかった。

【追記】
phpBBはPHPで作られた掲示板Webシステム。MantisはPHPで作られたバグ管理システム。
いずれもBitnamiでワンクリックでインストールできる。

BitNami :: phpBB
BitNami :: Mantis

僕がいたチームでは、僕がチケット駆動開発を推進していたので、Ticket FirstやNo Ticket, No Commitの運用ルールはチームに浸透していた。
だから、開発者は積極的にチケットを登録するし、チケットNoを必ず書いてコミットする運用には慣れていた。
そして、彼らは開発チケットで、設計書の不明点や設計漏れをQAの別チケットで登録して、設計者とやり取りする運用が自然に生まれた。
その中で、後でリファクタリングしたほうがいいかも、とか、JUnitをもっと追加したほうがいいかも、みたいな内容は、気づきのチケットでバックログに入れる運用も生まれた。

QAや気づきをチケット化する利点は、関連チケットや親子チケットでチケットを整理できること。
タスクのチケットで仕様の不明点を質問したい時、QAのチケットと関連リンクを張っておくと、後で見つけやすい。
Redmineでは、チケットやWiki、フォーラムでも、「#チケットNo」で簡単にチケットへリンクできるから、QAも気づきもチケット化した方が後で流用しやすい。
また、QAや気づきのチケットの内容が変わったら、トラッカーをタスクや課題に変更するのも簡単だ。最初はあいまいな内容でも、作業する時に正確な内容にすればいい。
タスクの進捗率が90%で停滞してしまう原因の殆どは、仕様の不明点や技術上の課題などが残ってしまうことなので、QAチケットで外に出すことで、何が問題なのかをはっきりさせやすかった。

QAのチケットが多くなれば、QAチケットを子チケット化して、一つのテーマ(改善要望・バグなど)にまとめる運用も自然に生まれた。
チケットの親子関係は、MS Projectに慣れたプロマネだけでなく、開発者も理解しやすいみたい。

逆にQAや気づきもチケット化する弱点は、チケットの量は莫大になり、放置されがちになりやすいこと。
だから、朝会や週次報告、ふりかえりなどあらゆる場で棚卸しを行うのは必須の運用ルールだった。
棚卸しでチケットの完了基準も明確になるし、開発者から管理者への報告・連絡・相談の場にもなる。

棚卸しは、チームの意思決定の履歴を残すという意味もある。
この運用は、特に大規模プロジェクトで、各チームリーダーが自分のチームで解決できない課題を持ち寄って、CCB(CAB、Scrum of Scrum)で方針を決定する運用にもつながるから、重要だと思っている。

とはいえ、Redmineにはフォーラム機能もあるので、フォーラムで仕様の質問をやり取りしたり、特定の課題について議論する運用も可能だ。
僕のチームでは、フォーラムに、Redmineの使い方に関するFAQをまとめている。
カスタムクエリの使い方、チケット一覧でのコンテキストメニューの出し方など、Redmine初心者から頻繁に聞かれる質問はFAQ化して公開しておくと、同一の質問が来たら、リンク先を教えるだけでいい。
つまり、フォーラムもナレッジを蓄積する場として使える。

情報は不足しているよりも過剰なほうがましだ。
アート・オブ・プロジェクトマネジメント」にも出てくるこの言葉の意味もチケット駆動開発を実践して理解できた。

【3】Twitter / @agilekawabata: たぶん、チケットは仕様書ですか?という人に、XPのタスクカードですって言っても理解されないと思う。#RxTstudy

Twitter / @agilekawabata: 空っぽのロードマックパターンは、先にアジャイル開発について研修すべきだと思う #RxTstudy

Twitter / @cointoss1973: #RxTstudy (工程としてバージョンを使うとその時点でハマりますね。バージョンはマイルストーンなので、過去の工程にこだわってもだめです。これからの作業予定に使うべき)

開発チームがRedmineをまともに運用できているかどうかの判断は、対象バージョンとロードマップの機能を使いこなしているか、という観点で僕は評価している。

Redmine初心者は、バージョンとマイルストーンの違いを知らなかったり、ロードマップがリリース計画である事実を知らないケースがとても多い。
ロードマップをまともに運用できていないチームは、せっかく登録したチケットが放置されやすく、棚卸しもうまくいかない場合が多い。

逆に、ロードマップを使いこなせば、バージョン単位のスコープ管理、小刻みなバージョンアップによる機能改善戦略、そこから生まれる開発のリズムや適切な開発ペース、Velocityの発見などが分かってくると思う。
アジャイルと言う言葉をメンバーは知らなくても、チームは自然にアジャイルの概念に慣れていく。

【4】Twitter / @cointoss1973: クローズしたバージョンのチケットは変更できないようにする。 #RxTstudy (これいいですね)

クローズしたバージョンのチケットが変更できないという意味は、リリース履歴を改ざんできない事実を意味している。
つまり、リリース済みバージョンは変更管理におけるベースライン(チェックポイント)なので、ベースラインが後で変わってしまうと、成果物の品質管理に疑問符がつく。
リリース済みの作業履歴を改ざんしたら、システム監査でNGになってしまうのではないだろうか?

【5】Twitter / @sousoumt: 今のところ全員が粒度と終了基準で一度は躓いているw #RxTstudy

チケットの粒度の問題は顧客と開発チームの観点のViewの違いから発生する。
チケットの終了基準の問題は作業の完了基準、リリース判定基準があいまいな点から発生する。
プロジェクトやチームで暗黙知として運用されていたルールが目の前に出てきたからこそ、噴出する問題だと思う。

【6】Twitter / @cero_t: アンチパターンとか、質問とか見てると、「Redmine」の使い方を知らないというよりも、「ソフトウェア開発」とか「物事のあり方」を理解してない人が多いっていう感じがしますねぇ。 その使い方はないだろ、という。 #RxTstudy

Twitter / @yktko: ITインフラ構築の現場を改善しようとしたら営業を改善する必要性にぶち当たりました。 RT @kuranuki: うまくいかない事例を聞いてると、ツールで解決出来る問題ではないところに問題があり過ぎるように思う。そんなのは現場の改善で解決出来るの? #RxTstudy

@kuranukiさんの立場は僕なりに理解しているけれど、現場リーダーの観点からすると、ツールを導入することで従来の開発プロセスの弱点があぶり出されたという簡単な事実を示しているだけだと思う。

従来は暗黙知としてプロセスが回っていたのだろうが、一度ツールを導入すると、従来のプロセスで隠されていた問題点が見える化しただけ。
丁度それは、ユーザ企業が従来の手運用の業務をシステム化するためにERPを導入したら、業務プロセスが変わるだけでなく、社員の役割も変わり、社員の配置も変わり、最終的には組織構造も変わってしまう症状と同じだ。

単にExcelによるプロジェクト管理をWeb化する発想だけでは不十分であり、最終的にはAgile開発の考え方を理解しなければ、Redmine本来の機能を100%フルに使うことはできないと思っている。

Redmineによるタスクマネジメント実践技法」の感想に、アジャイル開発の用語が出てきてよく分からないという意見はよく聞くけれども、その点に関しては曲げられないかな(笑)

でも、チケット駆動開発のアイデアはSW開発だけでなく、情報システム部門やインフラチームのタスク管理や課題管理、顧客からの問合せ管理などへも適用できるから、もっと発展させることができるだろうと思う。
多分、リーンソフトウェア開発にある概念(TPS)へつながるだろうと直感している。

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

2011/08/06

Redmineコード全文検索サービス

@g_maedaさんがRedmineコード全文検索サービスを提供されていたのでメモ。
素敵なサービスの提供ありがとうございます。

【元ネタ】
Redmineコード検索 提供開始 | Redmine.JP

(引用)
Redmineのソースコードの全文検索が行える「Redmineコード検索」の提供を開始しました。Redmineのプラグイン開発やカスタマイズを行うときなどにぜひご利用ください。

Twitter / @g_maeda: Redmineのソースコード検索ができるサイトを、Milkode使って作りました。

Milkode-codesearch.redmine

数万のソースコードから目的の一行を一瞬で見つけ出す、Milkode - おんがえしの日記

ダウンロード - Milkode

チュートリアル - Milkode

MilkodeはRubyで作られたソースコード検索Webシステム。
Redmineのソースコードで探し物がある時、とても便利。
感覚的にはGrepと同様。
Webからアクセスできるのが一番いい。

Redmineのプラグイン作成やパッチ作成、Redmine本家のチケットやフォーラムの議論を深堀する時に役立つだろう。

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

2011/08/05

対応完了予定日はイテレーションである

チケットに対応完了予定日を入れたい要望を受けたが、対応完了予定日はRedmineの対象バージョンで代用できます、と返答した。
その理由について考えたことをメモ。

【1】システムの運用保守では、既にシステムが稼動しており、本番障害や改善要望の対応で追いまくられる。
これらタスクをRedmineでチケット化すると、状況の変化をチケットで追跡できるので、見通しが良くなる利点がある。

だが、チケットに対応完了予定日(または対応期限)を入れたい要望を受けた。
その理由は、チケットの開始日・期日は作業実績であり、作業予定も別途入れたいから。
つまり、顧客の改善要望に対応する期限ないし対応完了予定日をチケットの属性として別途保持し、作業の優先順位付けに使いたいらしい。

【2】でも、僕は対応完了予定日はRedmineの対象バージョンで代用できると思っている。
なぜなら、対応完了予定日は、将来の本番リリース日だからだ。
つまり、それはイテレーションやリリースタグに同一視できる。

実際、チケットに対応開始予定日を入れたい要望はない。
なぜなら、作業の開始予定日はどうでもよく、作業の期限こそが重要で、その期限に遅れると、顧客の業務に支障が出るからだ。

【3】Redmineの対象バージョンには、期限日しか設定できないようになっている。
Redmineの使い方が分からない人は、なぜ対象バージョンに開始日が無いのか、不自然に感じるようだが、対象バージョンは本番リリース日そのものである性質からして、期限しか設定できないのはとても自然だ。

対応完了予定日を対象バージョン、つまりイテレーションに同一視すると、本番リリース日が同じチケットは全て、その日に一括リリースされる。
すなわち、対応完了予定日が同一のチケット群、つまり、そのチケットに基づいて修正されたソースや成果物は、リリース予定バージョンとしてタグ付けされる。
そして、構成管理の配下にある成果物を対応完了予定日ごとにスナップショット(構成管理ツールの特定のリビジョン)が残り、履歴が積み重なっていく。

チケット駆動開発では、ITSチケットとSCMリビジョンは必ず紐づいているので、成果物の変更履歴を追跡しやすくなる利点がある。
その利点のおかげで、過去のパッチの理由調査や、仕様変更における影響調査がやりやすくなる。
特に結合テストや受入テストのようなテスト工程でのバグ管理、本番システム稼働中の運用保守では、No Ticket, No Commitの運用ルールは重要な意味を持つ。
変更理由があいまいな修正ソースをコミットしてデグレしたり、正当な理由のない修正モジュールをリリースして障害を起こす危険があるからだ。

チケットの由来である障害管理票には、対応完了予定日の属性も含む時があるが、リリース予定バージョンに同一視すれば、多分その属性は不要だ。
実際、Mantisのチケットに対応完了予定日の属性はない。

チケットの他の属性として、解決状況や重要度、優先度などがあるが、それらについては下記で考察した。
チケットのそれら属性の歴史や必要性をたどると、チケットとはそもそも何なのか?ということが分かってくるような気がする。

BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索

障害管理における重要度と優先度の使い分け: プログラマの思索

【4】チケット駆動開発の発端である障害管理は、ソフトウェア開発の基本プロセス。
どの開発チームであれ、障害管理プロセスを観察すれば、そのチームの習熟度が分かる。
駄目なチームほど、バグ修正のスピードが遅く、どんどんバグを溜め込んでデスマーチに陥るパターンがとても多い。

障害記録票と問合せ管理簿の2重管理問題: プログラマの思索

障害管理の泥沼から脱出するには: プログラマの思索

障害管理には、ソフトウェア開発がなぜ難しいのか、という問題の本質が隠れているような気がしている。

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

2011/08/03

Enterprise ArchitectとRedmineを連携するアドオン

Enterprise ArchitectとRedmineを連携するアドオンが公開されていたのでメモ。

【元ネタ】
Twitter / @kaorun55: EAのRedmine連携もキタ / 日々精進 - スパークスシステムズ ジャパン代表のBlog:Redmineとの連携アドイン β版 - livedoor Blog(ブログ) http://htn.to/C7rnYA

Twitter / @akipii: Enterprise ArchitectとRedmineを連携するアドオンが公開された。設計工程の成果物と連携できるのはいい。Redmineとの連携アドイン β版 http://t.co/0SUnDya

日々精進 - スパークスシステムズ ジャパン代表のBlog:Redmineとの連携アドイン β版 - livedoor Blog(ブログ)

Enterprise Architect-Redmine連携アドイン

UMLモデリングツールは色々あり、僕はastah Professionalを使っているけれど、企業ユースならEnterprise Architectが多いだろう。
Enterprise ArchitectはUMLだけでなくDBモデリングもかなり細かい部分までサポートしているので、これさえあれば設計は何でもできる。

Redmineと連携した画面を見ると、EAで書いたモデル上でチケットを発行できるので、チケットとモデルをリンクさせることができるらしい。
これは、Redmineチケットから設計の成果物へ追跡できる機能を提供していることを意味するから、トレーサビリティの観点からしても重要だと思う。

興味深いのは「親チケットへのリンクを、Enterprise Architectの接続線に変換」という機能で、EAのモデルにある関連(派生関係?)をRedmineチケットの親子関係に変換できる、とのこと。
詳細は分からないけれど、システムやクラスを分割したモデルを作れば、即座にチケットの親子関係に変換できるから、システム単位でチケットの進捗率や工数を集計するのに役立つかもしれない。

過去の記事にも書いたが、EAはSVN連携やXDDPのプロセスフロー図(PFD)にも対応しているので、色々使える。
機会があれば試してみたい。

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

XDDPの資料リンク: プログラマの思索

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

2011/08/01

Pivotal Trackerとredmineの違い

Rxtstudyで@kuranukiさんが「RedmineからPivotal Trackerへ乗り換えた」話をしてくれた。
考えたことをラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
Pivotal Tracker - Simple, Effective Agile Project Management & Team Collaboration, from Pivotal Labs

Pivotal Tracker: はじめかた

Pivotal Trackerの「Getting Started」を翻訳しました - Ruby x Agile

Twitter / @minitau: ICEBOX -> BACKLOGに移動して、BACKLOGでステータスをいじる #RxTstudy

Twitter / @sousoumt: @@kuranuki さんに補足:Pivotal TrackerでのICEBOX : チケットの冷蔵庫。いつかやるよ、的なリストです。 #RxTstudy

Twitter / @kiyotune: チケットのゴミ箱化 #RxTstudy ゴミ箱だったら捨てればいいじゃない

Twitter / @sakaba37: @kuranukiさんのお話は1-2日のストーリーカードの管理だけで回せるというのがポイントかと RT: @yusuke_kokubo: 特にこだわりがなければ、Redmine+BacklogsよりもPivotal Trackerの方が自前の環境もいらないし簡単だし良いよね。

Twitter / @akipii: @kaorun55 @kuranukiさんのプレゼンを見た限りではIcebox(要望の貯蔵庫)→Backlog(ユーザが要望を順位付け)→Taskboards(メンバーが要望を取る。ユーザの受入チェックも含む)でチケットが流れます。#Rxtstudy #redmine

@kuranukiさんの話は、ソフトウェア開発をサービス業にするためのビジネスを自ら経営者で実践されているだけあって、とても説得力がある。
SKIPやYouroomのサービスのタスク管理では、RedmineからPivotal Trackerへ乗り換えたとのこと。

Pivotal Trackerのプレゼンを見て、Redmineよりも優れている点はいくつかある。
一つは、Icebox→Backlog→Taskboardsへチケットが流れることで、ユーザと開発者のビューをうまく切り替えていること。

Iceboxは冷蔵庫の比喩で、料理(システムのリリース)の前に、材料(要望)を冷蔵庫へ保管するように、要望(ストーリー)を入れておく貯蔵庫。
そして、ユーザはリリースしたい要望をIcebox(要望の貯蔵庫)から取り出して、Backlog(まな板)へ移し、上から順に優先順位を付ける。
開発者は、Backlogの要望を上から順に取り出してTaskboardsへ移動して実装していく。
Taskboardsでは、要望のステータスは完了・未完了のBooelanしかなく、実装が終われば完了ステータスに更新されて、ステージング環境(UAT:受入テスト環境)にリリースされる。
ステージング環境へリリースされた要望は、リリース確認前(?)という赤色のステータスになり、ユーザの受入テストの評価を待つ。
ユーザはステージング環境でリリースされた要望を確認して、OKなら、リリース済みの緑色のステータスに変わり、NGなら、フィードバックで赤色のステータスになり開発者へ差し戻す。
そして、受入OKとなった要望は本番環境へリリースされて終わる。

つまり、要望と言うチケットを作って初めてリリースの対象が分かり、リリースの順位が決まって、実装されてリリースされる。
@kuranukiさんはそれを「No Ticket, No Release! 」と呼んでいたのが印象的。

Pivotal TrackerがRedmineよりも優れているもう一つの点は、下記で言い尽くされている。

Twitter / @akipii: #RxtStudy Redmineの優先順位はカテゴリで、ソート順が出ない。進捗も%は不要で、Boolean(未完了・完了)のみで十分。

Redmineのチケットには優先度があるが、「緊急」「高」「中」「低」などのカテゴリであり、作業の優先順位でソートされていない。だから、開発者はチケット一覧でどのチケットから作業すればいいのか、逐一指示を仰がないといけない。
また、Agile開発ならDoneの基準はとても明確なので、Boolean(未完了・完了)で十分だ。
わざわざ進捗率や複雑なステータスは必要ない。

但し、Pivotal Trackerを運用するには、いくつかの前提(コンテキスト)も必要。
@sakaba37さんが言うように、Pivotal Trackerでは全てのチケットは要望(ストーリー)であり、1~2人日程度で粒度がとても小さい。
自社のパッケージ製品のようにシステムを知り尽くしているなら、ストーリーを細かく刻むこともできるだろうが、いつもそのパターンで開発できるとは限らない。
RedmineのBacklogsプラグインはScrumの技法をそのまま反映しているので、ストーリーカードを更にタスクカードに分割してスプリント単位にリリースしていくから、Pivotal Trackerの運用フローとは異なる。

Twitter / @yusuke_kokubo: http://t.co/6J3Tsp7 Redmine Backlogsプラグインを試してみたい人はこちらからどうぞ

また、Agile開発に特化しているので、バグチケットを後から障害分析するためにチケットにたくさんの属性項目を追加することもできない。
ワークフローもシンプルだから、Agileな開発なら威力を発揮するが、インフラチームの課題管理や顧客からのインシデント管理に使うのには不向きだろう。

そういう前提を考慮しても、使いやすそうなUIなので、使ってみると面白いかもしれない。

ただ、僕自身はSW開発に現れる全ての作業(開発だけでなく、運用保守や課題管理、問合せ管理など)をRedmineのチケット管理で実現できると思っているので、そのアイデアをもっと色々試してみたいと思っている。

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

« 2011年7月 | トップページ | 2011年9月 »