« 2011年8月 | トップページ | 2011年10月 »

2011年9月

2011/09/28

プロジェクト管理の理想の記事が素晴らしい #redmine

@yusuke_kokuboさんのBlogの記事をたまたま読んだら、とても良かったのでリンクしておく。

【元ネタ1】
プロジェクト管理の理想 - こくぼ@Everything is the experience.

チケット駆動開発の目的の一つは、プロジェクト管理を意識しなくても、プログラミングだけに専念すればいい環境を作ること。
プロジェクト管理を意識するタイミングは、チームによる開発が必要になった時が多いはず。

「「継続的に効率的なチームビルディング」のために管理する。というのがぼくにとっての理想です。」の言葉はしびれますね。
プロジェクトファシリテーションの思想そのものですね。

【元ネタ2】
Redmineでリマインダー - こくぼ@Everything is the experience.

Redmineチケットを定期的にメールで状況報告するためのRubyスクリプトを公開されている。
メール送信する対象のチケットの条件は下記の通り。

* 決まった時間(朝と夕方)にプロジェクトごとにチケット情報をまとめる
** 期限が過ぎているチケット
** 今日が期限のチケット
** 今日作成されたチケット
** 今日更新されたチケット
* プロジェクトメンバーへメール送信
* 1メール/1プロジェクト

「今日が期限のチケット」「期限が過ぎているチケット」は、PMBOKのEVMで言えば、SPI > 1に相当する。
つまり、チケットの開始予定日前がSPI=0、チケットの終了予定日後がSPI=1になる性質を利用すれば、開始予定日に作業が開始されていないチケット、あるいは、終了予定日になっても作業が終わっていないチケットの情報をメールに流して、遅延したチケットを全員で共有できる。

拙著「Redmineによるタスクマネジメント実践技法」の8.1節「PMBOKのEVM」の202頁にも、そのアイデアを書いてます。

RedmineのREST APIやメール送信機能を利用すれば、チーム全体で進捗や品質に関する情報を共有できます。
アイデアさえあれば、Rubyで色々やってみると面白いと思います。

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

2011/09/26

工数見積もりで陥りやすい罠

ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。
理解できたことをメモ。
間違っていたら後で直す。
※追記:一部修正した。
※追記:Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。

【元ネタ】
Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。

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

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

チームは加速するのか~Velocityの使い方 #agilesamurai: プログラマの思索

ソフトウェア開発の工数見積もりが混乱しやすい理由: プログラマの思索

以下、工数見積もりで陥りやすい罠を3つあげる。

【1】顧客へ提示した工数(規模)と開発チームの実績工数(コスト)は等価でない

RedmineやTracチケットには予定工数と実績工数を入力する欄がある。
実績工数は、チケットを完了させるまでにかかった時間ないし日数を書く。つまり、コスト(AC)に相当する。

予定工数は、チケットを完了させるまでにかかる最短の時間ないし日数を書く。つまり、Scrumなら理想時間・理想日に相当する。
予定工数はシステム規模を開発完了させる工数(PV)に相当するから、システム規模と見なしていい。

そして、予定工数は「ソフトウェア見積り」で言えば楽観的な見積りに相当する。
楽観的な見積りの意味は、前回の失敗の教訓を生かして今回のプロジェクトの方が生産性が高いだろう、とか、学習曲線を期待して前回のタスクの経験が今回のタスクの経験に生きるだろう、などのように、見積り時点では予測できないリスクや課題を排除して、最短で完成できる見積りをしてしまうこと。

実際、見積り時点では、開発者は管理者や顧客へ説明できない工数バッファを積むと、詳細まで突っ込まれたら説明責任を果たせないので、予測できないリスクやトラブルに対する予備工数(コンティジェンシー予備)は積まない。
マネジメント予備工数は、管理者がタスク全部の工数見積もり後、一括して積むのが普通だから。

すると、予定工数は最短で完成できる工数ゆえに、普通はコストオーバーになる。
ソフトウェア見積り」に書かれている即興の見積りで予定工数を見積もれば、見積りの誤差が大きくなるから、プロジェクト全体の実績工数は予定工数よりも大幅に超過する場合が多くなるだろう。

予定工数の1.0MDと実績工数の1.0MDは、単位は同じでも、システム規模とコストでは意味合いは全く異なる。

【2】私の見積り工数とあなたの見積り工数は等価でない

まず、理想日とは実際の工数のうち、打合せやメール問合せ、社内の雑務などを除いた純粋にタスクに専念できる時間を表す。
アジャイルな見積りと計画づくり」では、アメフトを例に持ち出し、理想時間は60分だが現実時間は2~3時間になると分かりやすく説明している。
ソフトウェア開発における理想日・理想時間は、次の三つが前提条件としてある。

・ストーリーに必要な作業だけに専念できる
・割込みタスクがない
・作業開始前に、作業に必要な情報や環境などは全て用意されている

理想日はまさに、タスクだけに集中できる時間を指すわけだ。

そして「アジャイルな見積りと計画づくり」では「僕の理想日と君の理想日は違う」という節で説明されている。
実際、経験者の工数1.0MDで出来上がるシステム規模と、新人プログラマの工数1.0MDで出来上がるシステム規模はかなり違う。
プログラマの生産性の比較は10倍以上にも達するから、見積った予定工数1.0MDはそもそも等価ではないのだ。

だから、理想日でシステム規模を工数見積もりする場合、各開発者の生産性が無視されがちなため、予定工数の純度は低い可能性がある。
特に昨今の受託開発は、3~6ヶ月間という短期間に新規の開発者をかき集めて開発チームを形成するから、実際のプロジェクトでは、開発者の過去の生産性があまり当てにならない。だから、見積りの誤差のリスクも大きい。

理想日が問題にならないようにするには例えば、常にペアプログラミングしていてチームメンバーのスキルが平均化されている状況があるだろう。

理想日による見積りは開発者同士の生産性を無視している。

【3】生産性が増えているのにVelocityが変わらない

アジャイルな見積りと計画づくり」では「ストーリーポイントによる見積りは長持ちする」という節で説明している。

例えば、プロジェクト初期の頃は、1.0MDという工数で開発できるシステム規模はかなり小さいだろうが、プロジェクト後半では、同じ1.0MDで以前よりもかなりのシステム規模を作れるだろう。
あるいは、CobolとRubyなどの開発言語の違い、業務システムやSNSなどのシステムの種類、新規開発と運用保守では、見積り工数1.0MDの中身は大きく異なるだろう。

また、Velocityを計測しても生産性の問題は解決しないと「アジャイルな見積りと計画づくり」では「ストーリーポイントによる見積りは長持ちする」という節で指摘している。
例えば、プロジェクト初期では、予定工数5.0MDで一つの機能を作れるとする。すると、1週間5日間のスプリント1のVelocityは1機能×5理想日=5.0MDになる。
次に、プロジェクト中盤では、一つの機能を予定工数1.0MDで作れるように生産性が上がったとしよう。すると、1週間5日間のスプリントでは、5.0MDかけて5つの機能を作ったにも関わらず、Velocityは5機能×1理想日=5.0MDになる。

このトリックは、開発者がアウトプットして作り出す出来高とコストの単位を混同していることから発生する。

生産性が上がってもVelocityが変化しないという指摘は、チームが新しい技術や未経験の業務分野に挑戦するプロジェクトでは、この問題が深刻な影響を与えることになる。
つまり、チームが経験を積んでも学習曲線の期待による生産性がVelocityに反映されないために、見積もり工数が狂ってしまうのだ。

開発の生産性に関する問題は、結局、開発者が作った出来高と実際のコストを混同しているために発生するのだ。

【4】上記の3つの問題の根本原因は、PMBOKのEVMで現れるPV(システム規模)・AC(実績工数)・EV(出来高)を混同していることから発生すると思う。
1.0MDという同じ単位で、システム規模・実績コスト・開発者が作る出来高を測定しているのだから、混乱しやすいのだ。

Scrumで、理想日よりもストーリーポイントによる見積りの優位性を強調しているのは、工数という単位が混同しやすいために、規模見積りと工数見積りを区別できるからだ。
つまり、システム規模や開発者が作る出来高はストーリーポイント、実際のコストは工数で使い分けることによって、どれだけの開発規模をつくっているのかを明確にしてくれる。

実際のストーリーポイント見積りは概算見積りゆえに、タスクカードによる詳細見積りではもっと工数が増えるリスクもあるが、初期の段階で開発規模をメンバー全員で共有できる利点は大きい。
そして、まず1スプリントをすぐに実施すれば、規模見積りを工数見積りへ変換できる利点がある。
WF型開発なら、1年後の本番リリースまで実際に納品出来るシステムを作れないから、規模見積りをいくら頑張っても、肝心の工数や期間がどれくらいかかるのか、1年後にならないと分からない。

初期のスプリントを実施した後、次のスプリントでVelocityを計算する方法は下記になる。

【追記】Velocityの計算方法は「塹壕よりScrumとXP」を参照して下さい。

まず、初期のスプリントを実施した場合、実績のVelocityは実際に納品できたストーリーポイントの合計値ゆえにすぐに計算できる。
初期スプリントの稼働人日を計算して、Focus Factorという係数を求めて、人日当たりのストーリーポイントを求める。

Focus Factor = 直近スプリントの実績Velocity/直近スプリントの実績の稼働人日

すると、次のスプリントで予測されるVelocityは下記で計算できる。

予測Velocity(次回) = 実施スプリントの稼働人日 * Focus Factor

Focus Factorをわざわざ乗算するのは、前回スプリントの見積もり工数と実績工数の差異を反映することによって、チームの直近の生産性を加味するからだ。
@daipresentsさんが説明してくれているFocus Factorは、本来はこういう意味があったのだろうとようやく理解できた。

計画プロセスそのものもAgile化することによって、計画の精度を上げていくことが可能になる。
つまり、Agileな計画プロセスとは、作った計画をすぐに直近のスプリントで実施して検証し、その結果を反映することで計画をどんどんブラッシュアップしていくプロセスなのだ。

上記のことを考えると、見積もりは計画作りでとても重要な要素であることが分かるし、見積もりの本質に迫っているScrumは非常によく考えられていると思う。

チケット駆動開発でVelocityや工数見積もりに関する考察ができるのも、RedmineやTracに元ネタとなるチケットの予定・実績工数があるから。
チケット駆動開発はもっと色んな可能性を秘めていると思う。

【追記1】@wkoichiさんの指摘を受けて【2】を修正した。
@wkoichiさん、ありがとうございます。

Twitter / @wkoichi: 理想日による見積もりだと生産性が上がった場合に、1理想日×5機能になるので、Velocityが相変わらず5になるということであって、Velocityの計算を25/5としているのは誤りではないかな? / “工数見積もりで陥りやすい罠: …” .

アジャイルな見積りと計画づくり」の「ストーリーポイントによる見積りは長持ちする」という節を読み直すと、下記のような意味で解釈できる。
最初は、1機能を5日かけて開発した場合、Velocityは1機能×5理想日=5MD。
生産性が上がって、1機能を1日で開発できるようになった場合、Velocityは5機能×1理想日=5MD。

【追記2】
規模・コスト・出来高の単位が一緒であることから発生する混乱の症状をまとめると下記になると思う。

【1】顧客へ提示した工数(規模)と開発チームの実績工数(コスト)は等価でない
→規模(顧客へ提示した予定工数)とコスト(開発チームの実績工数)を混同している。

【2】私の見積り工数とあなたの見積り工数は等価でない
→出来高(開発者が作ったアウトプットの規模)とコスト(開発者の実績工数)を混同している。

【3】生産性が増えているのにVelocityが変わらない
→出来高(開発チームが作ったアウトプットの規模)とコスト(開発チームの実績工数)を混同している。

【追記3】
@daipresentsさんから、「塹壕よりScrumとXP」にFocus Factorの定義があることを教えて頂きました。ありがとうございます。

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

作成途中のチケットを自動保存するDrafts plugin #redmine

作成途中のチケットを自動保存するDrafts pluginがとても便利なのでメモ。

【元ネタ】
Twitter / @miwa719: Redmineで下書き保存したいなあ。チケットを発行する前に、もう一度同じ手順で確認したり、影響ありそうな設定を変えて確認したり…テストエンジニアがやることってわりといろいろあるんだけど、ブラウザの操作を誤ってそれまで入力した内容がパーになったときのガッカリ感といったら…

r-labs - Drafts plugin - Redmine

Redmine - Drafts plugin v0.1.1 - Redmine

Redmineのユーザインターフェイスは使いやすい: プログラマの思索

上記のTwitterの気持ちはよく分かる。
Mantisで障害を起票している時、再現手順やバグの情報を詳しく書いたのに、登録時に必須チェックエラーに引っ掛かって、せっかく入力した情報が消えてしまうという悲しい場面はとても多かった。
Redmineでも実際、チケットを書きながら、色々考えて書き換えたり、チケットの属性をあれこれ入れ替えたりしている。

r-labsで@haru_iidaさんがDrafts pluginを導入してくれているので使ってみたら、作成途中のチケットを自動保存してくれるので便利。

デスクトップアプリで言えば一時保存や自動保存に相当する機能に過ぎないが、Webアプリは画面状態を保持する機能が貧弱なので、このような問題は何もRedmineに限らず以前からあった。
Firefoxにはブラウザの戻るボタンで入力履歴を保持してくれる機能もあるようだが、元に戻らない状況も多い。

チケット入力のUIを改善することは、Redmineのように変化の多いタスク管理ツールには最重要だ。
Redmineのユーザインターフェイスは使いやすい: プログラマの思索にも書いたけれども、RedmineはAjaxと親和性が高いので、チケット入力のユーザインターフェイスが他のBTS・ITSに比べてとても使いやすい利点がある。

Webアプリはデスクトップアプリのように自然に操作できるユーザインターフェイスになるように、もっと改善していくべきだと思う。

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

2011/09/24

Redmineに関する課題と展望

RxtStudyやshinagawa.redmineで見聞したことを思い出しながらメモ書き。
間違っていたら後で直す。

【1】プライベートチケットの使い方

プライベートチケットはVer1.2から追加された新機能。
プライベートチケットに設定すると、初期設定されたロール以外の人からチケットが見えなくなる。

Redmine 1.2.0 released!: プログラマの思索

Redmineの大規模化の壁: プログラマの思索

プライベートチケットの使い道が最初は分かっていなかったが、@g_maedaさんから、Redmine本体の運用から生まれた機能であると聞いた。
例えば、redmine.orgへRedmine自体のセキュリティに関するバグチケットが登録された場合、そのチケットの情報が公開されることでRedmine本体に悪影響を与える可能性があるため、サイト管理者がプライベートチケットで隠してしまい、開発チーム内部でパッチを当てているらしい、と聞いた。
そのような使い方ならば、プライベートチケットの有用性はよく分かる。

プライベートチケットの今後の使い方としては、単なるソフトウェア開発のタスク管理だけでなく、会社全体のタスク管理へ拡張した場合、登録されたチケットの内容を社員全員に公開したくない場合があるだろう。
例えば、情報セキュリティや会計情報に関するチケットは、あまり公にしたくないものだ。
つまり、サイト管理者がプライベートチケットにして一部の人以外は非公開にして、管理者がプライベートチケットを非公開で対応するという運用方法もありうる。

【2】Gitリポジトリの並び順

RedmineのSCMリポジトリ画面では、Gitのコミットログの順序が正しくない症状は以前から知られていた。
第1回shinagawa.redmineでコミッタの丸山さんは、随分前のパッチによって、rebase前のコミットログの更新日が反映されたため、と仰っていた。
下記チケットで色々対応されている。

Redmine - Defect #5357: Git: SCM revisions ordered by date/time (should be reverse commit order) - Redmine

また、下記チケットにあるように、Redmineデータベースの最新コミット日から7日前以上のコミットログが表示されないような仕様もあったらしい。

Redmine - Defect #7146: Git adapter lost commits before 7 days from database latest changeset - Redmine

これは妥協の産物だったらしい。下記のTwitterにもその理由が一部書かれている。

Twitter / @wankomagic: Gitのブランチはリビジョンへのポインタだから、リビジョン間に何があったか表示するのが大変(しかも遅い)。Gitの特徴のせいかな? #47redmine

Twitter / @munet9: Mercurialはリビジョン番号がある、リビジョン並び順が保証されているという2点でGitより断然有利、取り込みもとても楽、だとか。 #47redmine

Twitter / @naitoh: Git 7日間問題は、JPLの妥協案だったのね。 #47redmine

ITSがSCMリポジトリ参照機能を含むのは、No Ticket, No Commitの運用ルールが生まれた経緯もあって、とても重要な機能なのだが、SCMの種類によってはまだまだ問題があるようだ。
だが、丸山さんがコミッタになられてから、SCM関連機能がどんどん改善されているので、今後にとても期待しています。

【3】Ruby1.9とRails3対応

Redmineは2007年頃から開発が始まっていたために、下記チケットで随分前から改善要望はあがっているものの、Ruby1.9やRails3はまだサポートしていない。
Twitterを見ると、Ruby1.9やRails3をサポートして欲しいと思っているユーザは多いみたい。

Redmine - Feature #4050: Ruby 1.9 support - Redmine
Redmine - Feature #4796: Rails 3 support - Redmine

Redmine本家のリポジトリを見る限りでは、丸山さんが上記チケットに対応するように精力的に改善されている。
近い将来、対応されるだろうと楽観しています。

【4】Redmineコミッタへのパッチの送り方

Redmineへの貢献方法は下記HPに手順が書かれている。
その中で注目する文章は、「Do not send a pull request on github.」。

Redmine - Contribute - Redmine

第1回shinagawa.redmineで丸山さんは、Redmineはテストを厳格に行なっているため、単なるパッチだけでなく、テストソースも付属していないと受け入れられない、と言われていた。
全てのオープンソースプロジェクトを知っているわけではないが、丸山さんが言われている内容は普通だろうと思う。

入門Gitを書かれたGitコミッタの濱野さんは、入門Gitの10.9節「オープンな開発プロセス」で、オープンソースプロジェクトのコミュニティで新参者が発言する場合、メールの書き方や議論の仕方、レビューの受け止め方について丁寧に書いている。
その文章を最初読んだ時は、Gitと関係ない内容なのに何故あるのだろうと不審に思ったが、コミュニティという場でパッチをやり取りする時に重要なテクニックの一つなのだ、と思うようになった。

【5】主要ツールに日本人コミッタが存在する利点

Redmineコミッタは丸山さん、Jenkinsコミッタは川口さん、Gitコミッタは濱野さんのように、ITS・SCM・CIというソフトウェア開発の主要ツールに日本人コミッタの名前がちらほら見える。
最近思うことは下記に書いた。

Twitter / @akipii: 今日は大阪でJenkins勉強会があったらしい。最近思うのは3種の神器(例:Redmine・Git・Jenkins)のコミッタに日本人の方がかなりいること。日本人コミッタやコミュニティを通じて日本人開発者の勢いを反映しやすくなる環境ができつつあるのかもしれない。

@haru_iidaさんはITS・SCM・CIをソフトウェア開発の3種の神器と呼ばれたが、今後のソフトウェア開発で重要な役割を担うと思われるツール群に日本人コミッタがいるのは、日本人開発者にとって心強い。
そして、それに関連するように強力なコミュニティも生まれている。
Redmineコミュニティもようやく関西と関東に発足したし、JenkinsはHudsonの頃から関東でコミュニティが活発に活動されていた。先日は関西で初めてJenkins勉強会が開催されて盛り上がったみたい。

そのようなコミュニティに参加して思ったことは、コミッタもコミュニティを必要としていることだ。
ツールの機能改善の要望や運用事例をコミッタも知りたがっている。
コミュニティでユーザとコミッタの間で有意義な議論を行うことで、ユーザの要望をツールに取り込んで、ソフトウェア開発のベストプラクティスがツールの1機能になっていくことで、より強力に開発できるような仕組みが整いつつある。
コミュニティというオープンな場を通じて、ツールの導入や運用を通じて、アジャイル開発の敷居をどんどん下げていければと思っている。

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

2011/09/22

DevLove道場の感想 #agilesamurai #devlove

先日、DevLove関西でお会いした@papandaさんのご好意でアジャイルサムライDevLove道場に参加してきた。
アジャイルサムライ」と同じく、ユーザストーリー洗い出し→バックログ作成→プラニングポーカーによる見積り→受入基準作成までのレシピで、とあるチームに途中参加させて頂いた。
感想を思いついたまま書く。

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

ソフトウェア開発の工数見積もりが混乱しやすい理由: プログラマの思索

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

チームは加速するのか~Velocityの使い方 #agilesamurai: プログラマの思索

【1】途中参加したチームは、Androidで緩いタスク管理のツールを作るのが目的だったらしい。
ユーザストーリー洗い出しで、メンバーから案があまり出なかったので、PostItで画面を書きながら紙芝居のように模造紙に貼り付けてみた。
そして、こうした方がいい、などと色々議論して、ユーザストーリーを書いていった。

個人的には、ユーザストーリーはユースケースや要件みたいなものだと思っている。
ユーザストーリーのフォーマットは決まっているものの、それほど細かくはない。
ユーザストーリーの書き方が難しいと言う声も聞いたが、顧客観点でユースケースを作ればいい。
そう思うと、従来のWF型開発のテクニックはそのまま流用出来る。

他チームでは、プロダクトオーナーがいないからユーザストーリーが書けなかった、という話をよく聞いた。
その話を聞いて、よく見かける光景だよなあ、と思った。

と言うのも、受託開発の要件定義では、設計チームが一生懸命資料を作って、やる気満々で顧客の会社に乗り込んだものの、顧客は諸事情でいなかったり、あまり時間が取れずに思ったような成果を上げれなかったりする。
そういういきさつを何度か経ると、要件定義がズルズルと遅れて開発やテストの期間が短くなって、作ったシステムも顧客が本来望んでいた仕様とは違っている、と後で言われたりする。
つまり、プロダクトオーナーが本来の役割を発揮していないのだ。

だが、僕らのチームは、自分たちが欲するアプリを作るためにユーザストーリーを洗い出していたから、自分たちがプロダクトオーナーであり、開発者だった。
だから、とてもやりやすかったし、ユーザストーリーをアジャイルっぽくどんどんブラッシュアップできた。

最近、SNSやゲーム、SaaS系企業がAgile開発に積極的に関わっているのは、自分たち自身がプロダクトオーナーゆえに深く議論できて、ユーザストーリーを作ったら実際に早めに作ってフィードバックする仕組みがあるからだろう。
つまり、要件定義もアジャイルの良さを持っている利点があるのだろうと思う。

【2】そして、ユーザストーリーに優先順位をつける時、データのCRUDに着目して優先順位をつけていった。
普通は、データ登録やデータ更新、そしてデータ表示の順番。
何故なら、まず、データが登録されなければ、データを表示することもできないから。

個人的には、DOAの観点で、データのライフサイクルで考えればいいと思っている。
画面のUIをある程度作れば、渡辺さんの本「業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題」に従えば、テーブル設計はほぼ確定する。
そこで、テーブルのデータがどの機能でCRUDされるか、CRUDマトリクスを作ってもいい。
そうすれば、より明確になるから、優先順位が分かりやすくなる。

【3】一番やりたかったプラニングポーカーの見積りは興味深かった。
最初に@shirokappaさんから、基準となるユーザストーリーは1ptではなく2~3ptを基準にした方がいいよというアドバイスがあった。
実際に2Ptのユーザストーリーを見つけて、他のストーリーを見積もってみると、1ptにしたり、3ptや5ptになってくる。
つまり、相対的に開発規模を比較して見積もっている。

その利点は、三角測量ができるので、相対的に見積もりの精度が上がる点があるだろう。
1ptを基準にすると、全ての大きいストーリーが3倍、5倍のように見積もるしかないため、大きいストーリーほど見積りの誤差は大きくなる。
他のチームの話を聞くと、大・中・小のレベル感のような見積になってしまうみたい。

僕らのチームは最初はカードを出すものの、話しながらストーリーポイントを決めていた。
@shirokappaさんによれば、カードを故意に隠して、一斉に見せる方法もあるらしい。
つまり、最初に出した人のポイントに左右されず、議論が割れやすいので、議論がより深まる効果もあるらしい。
デルファイ法を自然にやっているような気がした。

プラニングポーカーによる見積りでは、過去のポイントを参考にして見積もっている時があった。
例えば、データのグラフ表示のストーリーが5Ptなので、かんばんによる表示のストーリーも5ptだろうと参考にして見積もった。
確かに、似たような機能のポイントはほぼ同等と見なせるから、ストーリーポイントのぶれは少なくなるだろう。

どうしても見積できないくらい大きいユーザストーリーは「Big」「?」というカードを皆で出した後、ストーリーを分割した。
実際にストーリーを三つに分割して、再見積もりしてみると、2pt + 5pt + 5ptになった。
この経験を考えると、例えば5ptを超える大きな見積もりは、ストーリーを更に分割して細かくした方が見積りの精度が上がるのではないか、という推測も成り立つ。

結局、僕らのチームは10個のユーザストーリーで合計30ptになった。
単純に1pt=1.0MDと見なせば、30MD=1.5MMとなり、3人で開発すれば2週間で終わる規模感になる。
実際そううまく進むか分からないが、皆そんなイメージを浮かべたみたい。

最後の受入基準は結局作れなかったが、ユーザストーリーの受入テストケースを書けばいいだろうと大体イメージは湧いている。

【3】プラニングポーカーによる見積りは実際に試してみて楽しかった。
トランプのカードを出し合うので、ゲーム感覚。
見積りは難しい、という心理的な硬さを解きほぐしてくれる。

実際のストーリーポイントによる見積りは、概算見積りに近い。
つまり、不確実性コーンの一番最初辺りに相当するから、ブレは大きい。
ユーザストーリーからタスクカードへ分割していけば、タスクカードが思ったよりも増えたりして、見積り工数は増える可能性はある。
だが、ユーザストーリーを作った時点で概算見積りして、開発規模を共有できる利点は大きい。
また、見積もったストーリーポイントを1~4週間のスプリントで工数に換算できるから、見積りの評価にも使える。

WF型開発では、FP法で時間をかけて規模見積りするが、かなり一苦労だ。
そして、規模見積りから工数見積もりへ換算できる時期は、1年後の本番リリースだったりするから、規模見積りがあまり役立たない。

プラニングポーカーをやっていると、XPの計画ゲームは本来こんな感覚だったのだろうな、という気がしている。

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

2011/09/19

No Ticket, No Commitの効果

No Ticket, No Commitの効果について考えたことをメモ。

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

明日からできる!バージョン管理システムへのコミット粒度を最適化するトレーニング方法 - 刺身☆ブーメランのはてなダイアリー

Twitter / @yusuke_kokubo:RedmineのリポジトリをウォッチしてるとJPLのコミットの粒度の適切さに感心する。Redmineの使い方はredmine.orgに学ぶことが多い。(それにくらべてBacklogsプラグインは…ゴニョゴニョ)

Twitter / @yusuke_kokubo: @akipii コミットの粒度とコミットメッセージあたりですね。

まちゅさんのスライドにもあるように、チケット駆動開発の最も基本的な運用ルールは「チケット無しのコミットは禁止」。
この運用ルールは、結合テストやシステムテスト、受入テスト、本番運用などでバグ修正した時に、必ず障害報告票とリンクづけて、修正理由を明確にするのが本来の目的だった。
何故なら、テスト工程では、どのバグ修正がどのバージョンのモジュールに含まれているか、きちんと管理しなければすぐにデグレが発生するし、せっかく直したバグが検証されなかったりするからだ。
また、ソース修正とバグの変更理由が紐づいていれば、コードレビューもやりやすい。
つまり、バグの変更管理が本来の目的だった。

チケット駆動開発では、No Ticket, No Commitをバグ修正の追跡だけでなく、プロジェクトで発生する成果物一般の追跡に使う。
つまり、SCMリポジトリに格納されているソースだけでなく、Excelの設計書、Wordの議事録、ビルドスクリプト、環境構築の初期データやDDL、共通ライブラリのコンポーネントなどの成果物を変更する場合は、チケットに紐付けるようにする。
この運用によって、何故こんな汚いパッチに変わったのか、とか、何故この要件がこんな複雑な仕様へ変わったのか、をチケット経由で追跡できる仕組みが出来上がる。

また、No Ticket, No Commitの副次的効果も幾つかある。
一つ目は、ソースに書かれた無駄なコメントはチケットに集約されるので、ソースがきれいになること。
CobolやVBなどの過去のソースは、「20yy/9/ddに障害管理No.XXで直した」などの無駄なコメントがとても多く、修正が入る度にガラクタのコメントアウトが増えて見苦しい。
修正履歴のようなコメントは、SCMやBTSの機能が貧弱だった時代には必要だったかもしれないが、今の時代は不要だと思う。

レガシープログラマかどうかを判断する基準: プログラマの思索

SVNのコミットログの書き方: プログラマの思索

No Ticket, No Commit! #tidd: プログラマの思索

二つ目は、コミットに明確な理由がつくので、コミットの粒度が分かりやすくなること。
新人プログラマのソースを見ると、Javaのmainメソッドに1000行も書いて、まともに動かないのにコミットしている場面を見た時がある。
バージョン管理は単なるソースのバックアップではない。
特にtrunkへcommitする時は、コンパイルエラーがないのはもちろん、TDDで単体テストもクリアして、コードレビューも完了しなければコミットできない。
そうでなければ、trunkは常時リリース可能なコードラインにならないからだ。

実際にプログラムを書いている時、チケットや仕様は頭の片隅に追いやって、ひたすらプログラムを綺麗に書いて動かすことに専念する。
そして、コミットログにチケット番号を付ける時に、今の自分はこの理由で修正したんだよな、と思い出す。
つまり、詳細な情報はチケットに書いておけば、それを忘れてプログラミングに専念できる環境がある。

また、XPJUG関西の山根英司さんは以前、駄目なプログラムはソース修正の意図が見えない、と言っておられた。
駄目なプログラマは、リファクタリングと機能追加を一緒に混ぜ込んでコミットするから、後で問題発覚した時にロールバックできない。
No Ticket, No Commitを意識すると、今はリファクタリング、次は機能の追加、次はバグの修正、などのように、意図を明確にしてcommitするようになる。
平鍋さんのプロペラ帽子のように、今はリファクタリングの帽子、次は機能追加の帽子のように、頭を切り替えて作業する単位でコミットしていけばいい。

三つ目は、新人プログラマに良い習慣を身に付けてもらえること。
プログラムを書くというのは、単にコンパイルエラーがないだけではない。
TDDのように仕様を満たすように書くことも大事だし、バグ管理やコードレビューで他人の指摘を反映していく作業も大事。
SVN・Git・Mercurialのようなバージョン管理ツールで修正履歴を残していくのも重要。

特に、バージョン管理で修正履歴を残す時、意味ある単位でコミットしていって欲しい。
その時に、No Ticket, No Commitでチケットにソース修正履歴を残しながら、自分が今書いているソースはどんな理由で書いているのか、を意識して欲しい。
単体テストしていないソース、ビルドが通らないソース、コードレビューしていないソースは、コンパイルエラーのソースと同レベルなのだと認識して欲しい。
実際、顧客に価値あるシステムを納品するというAgile開発の理念から考えれば、テストせずにまともに動かないソースは、顧客から見ればコンパイルエラーのソースと同じだ。

そうすれば、リファクタリングのテクニック、TDDのテクニックも自然に身に付くと思う。
下記でも書いた。

チケット駆動開発は仕事をさばく仕組み #agileto2010 #tidd: プログラマの思索

No Ticket, No CommitのようにBTSに由来した運用ルールは、ソフトウェア開発の作業を効率化するために長年蓄えられたノウハウ。
TiDDはBTSの機能をAgile開発に流用した経緯もあり、BTSのベストプラクティスもそのまま流用すればいい。

【追記】
No Ticket, No Commitの運用ルールを早とちりして、1コミット=1チケットと思う人がいますが、そんなことはない。
ITSチケットとSCMリビジョンの関係は多対多が普通だ。
実際、1個の仕様変更のチケットに対して、複数回のコミットはあるし、コミットの意図には機能追加もあればリファクタリングもあるだろう。
あるいは、2件のバグのチケットは同類バグでバグの原因が同じならば、1回又は複数回のコミットで一括修正してもいい。
よくある状況は、長年の運用保守でプログラムが複雑になって、新規機能の追加が難しい時だ。
仕様変更に対応するにはまずリファクタリングで綺麗にしないと対応すらできない場合、リファクタリングのチケットと仕様変更のチケットを分ける。
僕の経験では、リファクタリングが1人日もかかるならば別チケット化して、開発者が作業しやすい単位でチケットを分けている。

Redmineを使って気づいたことpart3~チケット分割のタイミング: プログラマの思索

つまり、状況(コンテキスト)に応じて、チケットとコミットの関係は異なる。

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

2011/09/18

3人集まれば文殊の知恵はIT業界にも当てはまる

たまたま見つけた記事やTwitterから考えたことをメモ。

【元ネタ】
プログラマの読書会と3年 - 千里霧中

Twitter / @quicy: 「向上心(意識の高さ?)」は後天的なものと思います。というのは、向上心が強いから技術が身につくというケースに比べて、技術が身についた結果として向上心が強くなるケースが、実際にところ多いように感じるのです。

IT 勉強会カレンダー検索

すさまじく充実してる IT 勉強会カレンダー - てっく煮ブログ

井芹さんが輪読会に参加して、たくさんの人達に出会い、切磋琢磨して、アウトプットを出すようになった経緯が書かれていて、とても参考になる。
今の時代は、社内に閉じこもっていてもスキルは上がらない。
OJTという名前の研修で社内で仕事するだけで、幅広いポジションで仕事したり、技術を深掘りしたりして経験を積む環境はそう多くはない。
会社よりもオープンソースのように、社外のコミュニティに技術革新の意気込みが移っているように思える。

以前、大学4回生で大学院に上がる時、研究室の先生から岩波基礎数学選書の一部コピーを渡されて、研究者の心構えの説明を受けた時がある。
その一節に、戦国時代に尾張三河で織田・豊臣・徳川の3人が切磋琢磨したから日本を統一できたという話があり、研究者の卵であっても自分たちの勉強会で切磋琢磨すれば、いつかは結果を出せるみたいな話があった。
僕の学生時代はインターネットが出る前だったので、自主ゼミという名前で、有志が集まって専門書の読書会をやっていた。そんな自主ゼミをもっとやった方がいいという趣旨だったと思う。

最初はそんなに技術も経験も持ってなくても、同じ志を持つ人達と切磋琢磨すれば、必ずいつかは成果が出せる。
技術が身に付いて行く過程で更に向上心も上がり、技術もついてくる成長のらせん構造が生まれる。

IT勉強会カレンダーを見れば、日本各地でIT勉強会が開かれている。
日本中の技術者が知的な議論に飢えていることを示しているのではないか?
このようなコミュニティは、日本のIT業界でそれほど影響力がないように見えるかもしれないが、時代は移っている気がする。

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

2011/09/17

【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ~BTSから始まる進化の歴史」 #devlove0917

今日開催されたDevLove関西2011の発表資料をCC Attributionライセンスで公開します。

9月17日 DevLOVE関西2011CONNECT(大阪府)

DevLove関西は2009年にも開催されていましたが僕は参加できませんでした。
ですが、下記のBlogからその情熱は感じ取りました。
だから、僕自身も無意識に熱くなっていたのかもしれません。

DevLOVE関西に心を込めて花束を - fkino diary(2009-09-26)

DevLoveは情熱的なコミュニティと知ってましたが、今日のDevLove関西も懇親会(渾身会と呼ぶらしい)も、高校生の文化祭や高校野球みたいなノリノリの雰囲気でした。
楽しかったです。

肝心の発表は50分枠だったので余裕で話せるだろうと思ったのですが、1時間近く話しても言い足りなかった。
よしうみさんから、今日のあきぴーさんは1.5倍速でしたよ、と言われてしまった(笑)

上記の資料では、チケット駆動開発はBTSの優れた機能をAgile開発に流用したこと、ツール連携による新しいプラクティスを発見できる可能性があること、そして、プロセス標準化・プロセス改善・自己組織化のインフラになりうるからこそAgile開発をもっと自然に普及できることを言いたかったのです。

内容を詰め込みすぎたので、どこかの機会で分割して話そうかなと思います。

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

クラウドの本質はインフラ管理のIT化

デブサミ関西2011の資料を読んで考えたことをメモ。

【元ネタ】
「デブサミ2011関西」でDozensの紹介をいたしました

クラウドと呼ぶにふさわしいサービスは事実上、AmazonEC2とGoogleAppsぐらいではないか?
クラウドの本質はインフラ管理のIT化による自動化だ。
単なるASPやプライベートクラウドではない。

Webサーバーがクラウド化されることによって、スモールスタートで始めて、アクセスが一時的に集中するなら自動的にスケールアウトしてくれる。
しかも、機器の老朽化もないから、頻繁に壊れるHDDの交換もいらない。
また、従量制だから、使った分だけ支払えばいい。
分割払いできるのも魅力。

日本でクラウドと呼ばれているサービスは、どれもクラウドと呼ぶに相応しくない。
AmazonEC2と比較すれば、どのサービスも幼稚すぎるし、逆に言えばAmazonEC2が数年先の技術を見越して作られている。
但し、上記資料のニフティクラウドは日本勢で唯一頑張っていると言えるのではないか?

継続的インテグレーションの進化形であるContinuous Deliveryの概念にも、クラウドは含まれてくると思う。
インフラ管理そのものもソフトウェアで自動化してしまい、本番環境の構築やサーバー保守の作業そのものをなくしてしまえばいい。
XPが提唱したTDDやCIという概念には、今後のソフトウェア開発に関する本質が含まれているように思う。

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

2011/09/16

ソフトウェア開発の工数見積もりが混乱しやすい理由

工数見積もりしていると、同じ人月で数えているのに、コストだったり、システム規模だったり、出来高だったり意味が違っているのに気付いた。
考えたことをメモ。
間違っていたら後で直す。

【1】運用保守では、顧客に毎月の実績工数を報告して保守料金をもらう。
マネージャの仕事の一つが、月次報告のための工数集計がある。
だが、この工数集計が結構面倒だ。

普通はメンバーに毎日の日報で、どのタスクにどれだけの時間をかけたのか、報告してもらう。
しかし、普通はタスクは顧客の改善要望をWBSレベルで詳細化したタスクのため、まず要望別に集計し直さないといけない。
更に、顧客からの改善要望のステータスが未着手なのか、進行中・完了なのか、逐一記録して、追跡しないといけない。
また、それら要望は、問合せ調査だったり、定常的な運用作業だったり、障害対応や改善対応などの種類に分けて、それぞれで集計し直したい。
特に、本番障害は原因報告とかかったコスト、更には抜本対策まで報告する必要がある時が多い。

メールで日報を収集して、集計作業をExcelでやっていると、管理作業だけでマネージャの作業が浪費されてしまう。

【2】マネージャは毎月集計した実績工数を元に、来月や次四半期の保守作業でどれだけの工数がかかるか見積もって、提案したい。
直近の実績は開発チームのペースを表しているから、見積もりの精度も高いと推定できる。
だが、見積もった工数を提案時にきちんと説明できなければ、顧客から保守金額の値下げ交渉をくらう。
実際は、見積もった工数の正当性を説明するのは、見積管理システムの仕様を説明するのと同じぐらいの煩雑さになるだろう。

月末に工数を締めて集計する場合、各タスクのステータスによって見積もる工数が変わってくる。
例えば、タスクがA~Cの3個あり、どのタスクの種類も改善対応とする。

タスクA:予定=0.9MD, 実績=0.0MD、ステータス=未着手
タスクB:予定=0.9MD, 実績=1.0MD、ステータス=担当中
タスクC:予定=0.9MD, 実績=1.0MD、ステータス=完了

これらデータから、単価(MD/件)を計算して、次月の件数がどれくらいか推定して、工数を見積もりたい。
その場合、改善対応のタスクの単価はどう計算されるか?
単純に考えると、3件のタスクで2.0MDかかったので、0.67MD/件という単価のように思える。
しかし、深く考えるとこの計算方法は正当性がない。

タスクAはそもそも未着手なので、アウトプットはゼロだ。
つまり、タスクBやCとは出来高が異なるから、同じ1件として件数にカウントするのはおかしい。
同様に、タスクBは未完了だから、完了タスクCの1件に対し、0.5件ぐらいの重みを与える方が正しいように思える。

また、タスクBとCは、予定されていた工数1.8MDの成果物を作るために、2.0MDのコストをかけて作った事実だから、実績はコストだ。
本来のタスクの規模は、タスクBとCの予定工数である1.8MDであるべきだ。

更に、タスクBのアウトプットは仕掛り中であり、予定工数0.9Mで作れる成果物を1.0MDをかけても未完成だから、出来高はタスクCの半分以下のようにも思える。

このように、本来の単価を計算するには、予定工数や実績工数、ステータスをパラメータとして計算せねばならず、Excel上ではひたすらマクロを使いまくる。
Excelで頑張って作り込むほど、それは見積り管理システムを作っているに等しい。

【3】上記のタスクA~Cにおける工数の考え方では、PMBOKのEVMの概念を入れると分かりやすい。
タスクをチケット化して、RedmineやTracに放り込んでおけば、SQLを叩くだけで工数集計できるだけでなく、近い将来のコストの予測や工数見積もりも可能だ。
アイデアは下記に書いた。

RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索

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

チケット駆動開発におけるソフトウェア見積り: プログラマの思索

すなわち、予定工数はPV、実績工数はAC、出来高工数はEVに相当する。
つまり、PVは顧客へ納品する本来の成果物の規模、ACはコスト、EVは開発者がコストをかけて作った成果物の規模に相当する。
そもそもシステム規模や成果物の規模、そしてかかったコストをひとつの単位で表現してしまっているため、同じ1.0MDでも意味合いが異なってくる。
同じ人月の単位を三つの意味で表現しようとしているので、混乱するわけだ。
しかも規模と時間を混同している。

EVMを導入すれば、下記のように整理できる。

タスクA:PV=0.9MD、AC=0.0MD、EV=0.0MD
タスクB:PV=0.9MD、AC=1.0MD、EV=?
タスクC:PV=0.9MD、AC=1.0MD、EV=0.9MD

ここで、WF型開発とAgile開発では、EVの定義の仕方が違う。
WF型開発ならば、タスクに進捗率を記載しておき、EV=PV×進捗率で導出する。
だから、メンバーに毎日の進捗率を記入させる運用を試みるが、90%で停滞する症状に陥りやすいため、進捗率はあまり当てにならない。
普通は、ステータス=作業中、レビュー中など細かく切って、ステータスに進捗率を対応付けて運用する方が正確さが増すだろう。

Agile開発ならば、未完了チケットはアウトプットがゼロと見なすため、完了ステータス以外はEV=0になる。
開発タスクでソースを修正中だったり、単体テストが未完了ならば、それは顧客から見れば、コンパイルエラーのソースと同じだ。
何故なら、顧客から見れば、まともに動くソースでないからだ。

【4】EVMを使って単価を求める場合、下記のような計算方法になると思う。
WF型で開発しているとして、進捗率から下記の値になると想定しよう。

タスクA:PV=0.9MD、AC=0.0MD、EV=0.0MD
タスクB:PV=0.9MD、AC=1.0MD、EV=0.7MD
タスクC:PV=0.9MD、AC=1.0MD、EV=0.9MD

まず、CPI(コストパフォーマンス)を求める。

CPI = EV/AC = (0.7 + 0.9)/(1.0 + 1.0)=0.8

次に、完了時の想定コストを求める。

ETC = AC + (BAC-EV)/CPI
= 2.0 + (3 * 0.9 - (0.9 + 0.7))/0.8
= 3.375 MD

従って、単価は、3.375MD/3件=1.125MD/件で導出される。
つまり、単純にPVやACを合計して件数で割り算するだけでは単価は出ないと思う。

ここでは、顧客が本来想定している成果物を作るのにかかる単価0.9MD/件に対し、1.125MD/件かかっているわけだから能率が悪い。
25%もコストオーバーで作っているのだから、赤字になりやすいし、メンバーの作業負荷も高くて大変だろうと思う。

Agile開発ならば、タスクBのEV=0なので、CPI=0.45となり、単価はもっと高くなる。
単価が高いと言う意味は、一つの成果物(アウトプット)を出すのにたくさんのコストが掛かっているわけだから、生産性はもっと悪い。

例えば、顧客に工数見積を提案する時は、顧客が本来想定している90MDかかるシステム規模を作るには、我々は112.5MDかかるので、提案工数は90MDとさせてください、という流れになるのだろうと思う。
もし、112.5MDで提案したとすれば、顧客は112.5MDかかるシステム規模を想定しているのに、実際は90MD相当のシステムしか作れない訳だから、多分もめると思う。

この人月単価の計算方法は、工業簿記の総合原価計算に似ている気がする。
総合原価計算では、生産データから完成品総合原価を求めるのだが、そのロジックが上記の考え方に近い。
特に、加工費の計算方法は、まさにEVで考えているのと同じような気がする。

とはいえ、工数見積もりをするのに、ここまで複雑な計算を考える必要があるのだろうか?
顧客に工数見積もりの正当性を説明しようとしたら、上記のような工数見積もり管理システムの仕様書で説明しようとするわけだから非現実的な気がする。

【5】Scrumの見積り技法が優れている点の一つは、規模見積りと工数見積りを区別していること。
Scrumではストーリーポイントで規模見積りして、スプリント実施後に工数を測定して、規模と工数の係数を求めることで、後どれくらいの時間をかければシステムが完成するのか、という見積りに使う。

この時の係数がVelocityという概念であり、1スプリントに対する開発規模を表す。
Velocityをスプリントごとに計測して、将来の予測とリリース計画の精度を上げるために使っている。
その時に使われるのがバーンダウンチャート。
バーンダウンチャートをEVMの言葉で変換すれば、右肩下がりの予定が残PV、右肩下がりの実績が残EVに相当する。
バーンダウンチャートは残作業量を表示することで、顧客や開発者に後どれくらいのタスクが残っているからどれくらいの時間がかかるのか、を説明しやすくしてくれる。

Scrumのストーリーポイントによる見積りは、EVMやCOCOMO2のような複雑な仕様による工数見積りをバッサリ切り捨てて、簡易な手法で見積もって素早いフィードバックを活かしながら、計画作りの精度を上げていく。
工数見積りそのものに工数がかかりすぎると、管理工数が増えすぎてアウトプットの量が減る。
そんなことを考えると、Agileな開発における工数見積もりの技法は色々考える余地があるように思う。

チケット駆動開発を実践してみて、PMBOKのEVMやScrumのVelocityの考え方がとても理解しやすくなった。
見積り、コストの予測、開発ペースに関する考察が可能なのも、Redmineに元ネタとなる工数データがあるから。
チケットに予定・実績工数を入力しておけば、いわゆるTimeTracking機能もRedmineは実装されているから、強力なチケット集計機能によって、工数の変化も追跡できる。

色々考えてみたい。

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

2011/09/14

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart14 #tidd

Redmineによるタスクマネジメント実践技法」の感想を見つけたのでメモ。

【元ネタ】
袋小路: Redmineによるタスクマネジメント実践技法

(引用開始)
アジャイル開発のメリットを活かし、難しいところをどうカバーするか。そんな観点で書かれたRedmine本。
Redmineそのものの説明もさることながら、現場の悩みをどう解決するかというところに深く切り込んでいて、ソフトのスクリーンショットより、チーム内で発生する仕事(チケット発行やら障害対応やら)のワークフロー図の方がむしろ多いくらい。
ツールの解説書によくあるような、「便利だから皆使おうぜ!」的バラ色話のノリは無い。クリーンな実験室のような、それ自体ありえないような環境でなく、現場の中でどう使ってきたという話が中心になっている。ホワイトボードと付箋の組み合わせから、Excelのガントチャート、Tracのような障害管理ツールなど、他のツールを経てRedmineにたどり着くまでの試行錯誤。既に他のツールでの管理が行われている中での部分的な利用など。実体験に即した話には「お前のところではそうだったんだろうけどよ~」的な感想を抱きがちな私だが、取り上げられている事例の豊富さと、適用の柔軟さには素直に感心した。
Redmine自体については、基本的な操作方法とか、見れば分る的なところはそこそこに、おすすめのプラグインの紹介があったり、あるいは個々の事例で、Redmineからどのような情報を引き出して報告書を作ったかといったプロジェクト管理をやった事がある人なら当然知りたいことに多くの紙面が割かれている。
(引用終了)

ありがとうございます。
Redmineを使って、アジャイル開発のタスク管理、更にはPMBOKやITILへ適用できるか、色々試したアイデアを書いています。
まだアイデアに過ぎない部分も多いですが、1年たった自分が振り返ってみると、そのアイデアは間違っておらず、プロセスに適用可能だと思っています。
CMMI、Agile、Scrum、XP、PMBOK、ITILなどの各種フレームワークで既にベストプラクティスは提唱されているのだから、その仕様をツールの1機能で実装して、実際にプロジェクト運営するだけの問題だと思います。
プロマネを顧客に見立てて、プロマネが欲しがる機能を開発して、プロマネからフィードバックを受けるというAgileな開発サイクルで作ればいいだけです。

(引用開始)
自分が一番うれしかったのはTestLinkとの連携について書かれていた第3部。「アジャイルやテスト駆動開発のテスト自動化って、単体テストだけなの?」という長年の疑問に対する答え(の一部)がここにあった。情報が溢れて泣きそうになるのは、むしろ結合テスト以降なんだよなぁ。(私だけかもしれんけど)
(引用終了)

Redmineの使い方だけでなく、紙面の1/3はTestLinkを説明しているので、注目してくれたのは嬉しいです。
テスト管理や品質管理の技法は、2000年代に入って数多くの書籍が出回るようになって、より注目されてきているのかなと思います。

他にもあったら探してみる。

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

2011/09/11

XPのトラッカーの役割はTiDDがサポートする

平鍋さんのBlogを読んでいたら、「XPのマネジメントの役割は2つに分けられる。コーチとトラッカー」という言葉に出会った。
考えたことをメモ。

【元ネタ】
XP 祭り X に参加して、XP白本読書会の前説やりました。:An Agile Way:ITmedia オルタナティブ・ブログ

アジャイル開発「エクストリーム・プログラミング(XP)」の価値を再認識する - プログラマ 福重 伸太朗 ~基本へ帰ろう~

XPが登場して10年たった今振り返ってみると、XPが生み出した直感的な概念をScrumが精緻に作り直して、新しい概念で補強しているように思える。
XPではプロジェクトリーダーの役割はコーチとトラッカーの二つだが、Scrumではスクラムマスターという概念で統一されている。

トラッカーの役割は、イテレーション計画と実際の結果の差異を追跡するためにメトリクスを収集することだ。
彼はメトリクスを収集するために朝会で進捗や課題を収集したり、メンバー一人一人に進捗や課題を聞いて回る。
僕はトラッカーの役割を持っているプロジェクトリーダーを「お巡りさん」「Police(警官)」と呼んでからかっていた。
つまり、進捗一覧や課題一覧を作るために情報収集しているのだ。

従来のアジャイル開発では、ホワイトボードにPostItを貼り付けて、タスクを見える化する運用をしていた。
僕もこの運用を試した時もあったけれど、うまくいかなかった。
PostItを更新していく作業に僕もメンバーも慣れていなかった。仕事が忙しくなると、PostItすら更新しなくなったり、PostItにないタスクを始めたりする。
また、作業完了したPostItを集めて進捗を集計しなおすのはとても手間がかかった。かと言って、進捗報告の義務は残っているから、作業完了したPostItを捨てるわけにもいかない。

チケット駆動開発なら、実績工数が発生するタスクや成果物を変更する場合は必ずチケットを起票する規律があるから、作業履歴を追跡しやすくする仕組みがある。
そして、トラッカーの役割はRedmineやTracのようなITSで自動化できる。
ITSにたまったチケットを進捗や課題、品質、コストなどの観点で集計し直せばいいだけだ。

トラッカーの役割がそもそも必要な理由は、マネジメントの基本が予定・実績の差異分析にあるからだ。
当初計画した予定と作業した実績に差異がなければ、思い通りに進んでいるが、普通のソフトウェア開発はそんな単純なものではない。
初めての顧客との距離やポーカーフェイス、初めての技術へチャレンジ、初めて一緒に仕事するメンバーのように、リスクを孕む要因はいくらでもある。
BTSがバグ追跡システム、ITSが課題追跡システムと日本語訳されるように、バグや課題の変更履歴を追跡していくのはソフトウェア開発の基本。
計画外の作業や計画外の変更を把握して、逐一追跡していくのが変更管理であり、ソフトウェア開発のプロジェクト管理の基本だ。

チケット駆動開発では、バグや課題や作業などプロジェクトで発生するすべての情報はチケットに一元化され、チケットで追跡していく。
チケットには成果物の変更履歴がリンクされているので、本来の要件がどんな改善要望や技術要件から変化してこんな複雑な実装に至ったのか、を探るインフラになりうる。
SEの基本作業は、変更履歴を追跡しながら、仕様の整合性を取って設計していくのが主な仕事だから。

チケット駆動開発では、進捗一覧や課題一覧を出力するのは簡単だ。
イテレーションごとにステータス単位でグループ化すればタスクボードになりうるし、トラッカー(チケットの種類)=課題で出力すれば課題一覧になる。
つまり、欲しいと思う情報はSQLの仕様さえきめればワンクリックでExcelやPDF出力できるはずだ。
Redmineでは@naitohさんが次々にPDF改善パッチを作られているが、マネージャへアピールするためにはとても重要な作業だと思う。

トラッカーの役割がITSで自動化されることによって、プロジェクトリーダーの役割は進捗管理ではなくコーチやファシリテーターへ変化する。
進捗報告や課題一覧がワンクリックで出力できる環境にあるので、そもそもメンバーを管理する必要もない。
メンバーは自発的に作業をチケットに登録して作業し始めるから、リーダーはそれらチケットの整合性をチェックするだけでいい。
むしろ、メンバーから自分では解決できない課題を拾い上げて、それら課題を顧客や社内部署へ調整したり、課題解決へ向けた方針を決定する役割へ変わる。
つまり、チームをどのような方向へ進めるべきか、というリードする立場へ役割が変化するのだ。

チケット駆動開発でアジャイル開発のプラクティスを理解できるようになって初めて、アナログのタスク管理の意味が分かってきた気もする。
アナログであれデジタルであれ、「No Ticket, No Commit」「Ticket First」「No Ticket, No Work」のプラクティスは同じであり重要だ。
計画された作業を追跡していくこと、更に計画外の作業も追跡していくことがマネジメントの基本。
変化を抱擁するには、変化を追跡していくインフラが大事なのだ。

ちなみに、僕は「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」(白本)よりも「XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)」の方が好きです。
一番好きな箇所は下記かな。

プログラマにとって人生で一番悲しい言葉、そしてプログラマの権利: プログラマの思索

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

継続的インテグレーションを再考

継続的インテグレーション入門」を読んでみて、もっと早く読んでおけば良かったと後悔した。
内容がとても素晴らしかったので、理解できたことをラフなメモ書き。

【元ネタ】
Togetter - 「SIerは自動化する対象が違っているのでは?」

Continuous Deliveryをポチッた - watawata日記

Continuous Delivery - haru01のめも

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

インフラやデータ移行の自動化~アジャイル開発の最後の問題: プログラマの思索

Continuous Delivery~TDDとCIの次に現れた自動化の概念: プログラマの思索

【1】「はじめに」に、キーボードに「Integrate」というボタンが貼られていて「こんなに簡単ならいいのに」という雑誌の広告から始まる。
この挿話は、ビルド&デプロイの作業はワンクリックで自動化すべきだ、という主張につながっている。

2011年にもなったソフトウェア業界でも未だに、Excelのリリース管理台帳を見ながらソースを1個ずつ取り出してはビルドするという手作業が残っている。

例えば、HudsonやJenkinsのような優れたビルド管理ツールがあるのに、Eclipseで手動でwarファイルを作っているチームすらもある。
特に、バージョン管理ツールがCVSやVSSのような古いツールを使っているチームは、構成管理やビルド管理に大きな問題点を孕んでいる時が多い。
そのアンチパターンは下記に書いた。

構成管理のアンチパターン~TiDD初心者が陥りやすい罠 #tidd: プログラマの思索

【2】「ソフトウェア資産を集中化する」節では、リポジトリパターンを説明している。
リポジトリパターンとは「パターンによるソフトウェア構成管理」で提唱された概念で、バージョン管理リポジトリをソフトウェア開発の作業に関する全てのファイルの置き場所にしてしまうこと。

ソフトウェア資産という概念は、ITILの構成管理プロセスにおけるCI(構成アイテム)につながるだろう。
例えば、ソースだけでなく設計書やビルドスクリプト、jar・DLLのようなコンポーネント、DDLや初期データなどがソフトウェア資産に相当する。

これらのファイルを全て構成管理の配下に置くことで、修正履歴が全て残り、環境依存のリスクが減る。
「魔法のマシン」というコラムがあるけれど、ビルド可能なマシンが古いPC1台しかないという悲劇は結構存在していないだろうか?

【3】継続的インテグレーション入門で面白いのは、自動化の対象がビルド作業だけでなくインスペクションやデプロイ、フィードバックにも広げていること。
「コードの複雑度を下げる」節では、サイクロマチック複雑度(CCN)とテストケース数に相関関係があるという指摘がある。
複雑度と単体テストケース数はほぼ同じという経験的事実は、下記で既に書いた。

複雑度と単体テストケース数の相関関係: プログラマの思索

「コード網羅率を評価する」節では、命令網羅率(C0)や分岐網羅率(C1)をレポート出力する件について書かれている。
上記の記事でも書いたが、複雑度と分岐網羅は密接な関係がある。

JUnitでテスト駆動開発を実践しているなら、命令網羅率の100%通過はもちろん、分岐網羅率の100%通過も課すべきだろう。
そうでなければ、IF文の分岐を全てテストした事にならず、未テストのロジックから必ずバグが出る。

実際にJUnitを書いてみれば分かるが、命令網羅率を100%にすることすら難しい。
特にExceptionのような例外処理に複雑な処理を入れていると、そう簡単にはテストしづらい。
また、1メソッドの行数が100行、1000行も書かれていれば、殆ど不可能に近い。

複雑度が30以上のプログラムは、リファクタリングするよりも書き直した方が修正コストも少ないし、バグが少なくなるという矛盾がある。
だから、継続的インテグレーション入門でも推奨しているように、複雑度を下げる最も効果的な方法は「メソッドの抽出」で複雑さを扱い易いメソッドへ分散させるリファクタリング作業があるだろう。

Eclipseリファクタリング・メモ: プログラマの思索

CobolやVBのコーディングルールに固執しているチームほど、メソッドの行数は長くなりがちで複雑度は大きくなりがち。
古い言語に固執していると、最新のベストプラクティスを反映しづらいので、開発の生産性も上がらない事実を示しているように思う。

【4】「継続的なデザインレビューの実施」の節では、求心性結合度、遠心性結合度、不安定性というメトリクスを使って、ライブラリの安定性を測定しようとしている。
これらの概念は、「プログラマのためのJava設計ベストプラクティス」や「アジャイルソフトウェア開発の奥義」で既に説明されている。

HudsonやJenkinsだけでなく、Sonarのようなメトリクス収集ツールを使えば、自動化できるだけでなく、いつでも誰にでも公開できるので、運用するとよいだろうと思う。
開発者は、StatSVNやSonarのようなツールで自分が書いたソースがどのように測定評価されているのか、結構気にしているし、もっと綺麗に書くというモチベーションアップにつながる。

メトリクスでソフトウェア品質を見える化する: プログラマの思索

Sonarでソースの品質をチェックする: プログラマの思索

品質管理ツールSonarの記事: プログラマの思索

【5】「継続的フィードバック」の章では、アンビエントオーブやX10機器のように、ビルドエラーの検知を通報する機器を紹介している。
このアイデアは、プロジェクトファシリテーションならば、ソフトウェアあんどんに相当する。

「見える化」でソフトウェア開発! ~オブジェクト指向実践者の集い(第 3 弾) 参加レポート~

ソフトウェアあんどんの意義は、開発チームに即座にビルドエラーの検知を通報することによって、製品化の遅れを即座に修正する点にある。
コードラインが常時リリース可能という意味は、いつでも顧客に最新機能のシステムを納品するというアジャイル開発の根本目的につながる。

駄目なチームは、ビルドエラーを放置したまま開発してしまうために、新たなバグが発覚したときに、そのバグの原因が以前のビルドエラーにあるのか、それとも新しい機能追加にあるのか、を判別しづらくなる。
バグ修正では、10回のうち2~3回は別のバグを埋め込んでしまうという経験則もあるので、下手に手を入れるほど、システムの品質はどんどん劣化していく。

ソフトウェアあんどんのアイデアは、ビルド管理システムのエラー監視の自動化というアイデアにつながる。
@haru_iidaさんはHudsonがビルドエラーを検知したら、即座にメールを発行してRedmineにチケット登録するという手法を公開されていた。

RedmineとHudsonやTestLinkを連携させるプラグイン: プログラマの思索

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

このアイデアは、業務システムやWebサーバーのエラー監視ツールが障害を検知したら、即座にメールを発行すると同時にRedmineへチケット登録して、ITILの運用保守のプロセスで管理していく発想につながる。
問合せや障害検知を含むインシデント管理におけるチケット登録の自動化は、もっと機能強化されるべきものだと思う。

【6】「継続的デプロイ」の節では、常時リリース可能にするために、リポジトリの資産にラベルづけするプラクティスを紹介している。
これはリリースタグを振ってリリースブランチを作る運用そのものだ。

リポジトリの資産にラベルづけすることは、規律を持ったソフトウェア開発で最も重要な作業だ。
その理由は2つある。
一つは、ラベル付けは単なるスナップショットではなく、ベースラインを設定することによって、顧客へ納品する基準にもなり、最悪のケースはロールバックする基準にもなりうる。
もう一つは、ラベル付け後、リリースブランチを派生させることによって、複数のブランチを併存させる並行開発が可能になること。

前者から、ラベルがリリースタグであり、ベースラインであることから、厳格な変更管理が可能になる。
後者から、複数のブランチを併存することによって、複数の製品ラインを常時保守する並行開発をサポートする。
これは、組込製品やパッケージ製品のように、似たような仕様だが細部は異なる製品群の開発、つまりソフトウェアプロダクトラインの開発をサポートする方向になるだろう。

そして、継続的デプロイのアイデアは、Continuous Deliveryのように、受入テストや本番環境構築、データ移行、リリース作業の自動化の方向へ進化している。

牛尾さんの記事「アジャイルなインフラのつくり方とデータマネジメント - メソッド屋の日記」では、Rubyのツールveewee やVagrantが紹介されている。
また、@agilekawabataさんはUltimate Agile Stories Iteration1にて、CucumberというRubyの受入テスト補完ツールを紹介されている。

これらContinuous Deliveryのアイデアを実現しようと試されているツールの殆どがRubyで作られている事実にも注目したい。
今の開発トレンドを見ると、技術革新が活発に行われているプログラミング言語は、JavaからRubyへ完全に移っているように思える。

継続的インテグレーションやContinuous Deliveryのアイデアは、もちろんチケット駆動開発にも適用できるし、相性も良い。
チケット駆動開発から発展したアイデアにはCIツールが含まれているし、CIツールとSCMやITSが密接に関連することで、ソフトウェアの開発インフラはもっと進化する余地があるように思う。

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

【告知】AgileTourOsaka2011が10月8日に開催されます

AgileTourOsaka2011

日時 2011年10月08日(10:45~16:40)
開催場所 大阪産業創造館
(大阪市中央区本町1-4-5)
参加費 無料
定員 100人(先着順)

Agile Tour 2011へようこそ!

Agile Tourは、2011年10月~11月にかけて世界中でアジャイルについてのイベントを行い、共有しようという趣旨の取り組みです。 AgileTourのサイトを見ていただけると判るように、世界中の沢山の都市でアジャイルをテーマにしたイベントが行われます。

■Agile Tour Osaka 2011

昨年に引き続き、今年も、AgileTourOsakaを開催します。今年は、関西で長年アジャイル開発の取り組みをされてきたオージス総研の藤井拓氏、関西、そしてアジャイルコミュニティとの縁が深い静岡大学の森崎修司氏、日本におけるアジャイルの第一人者、長瀬嘉秀氏、SCRUMを中心にアジャイル開発について価値の高い情報を発信し続けておられる吉羽龍太郎氏(@Ryuzee)のセッションに加え、書籍「アジャイルサムライ」の監訳者西村直人氏によるワークショップ(協力:スクラム道)という充実したプログラムとなりました。アジャイル開発を実践している方、今から実践したいと思っている方、アジャイル開発について知りたい方など皆さん是非、ご参加ください。

<セッション1> 11:00~12:00 メイン会場

アジャイル開発の普及を阻むものを受け止め、乗り越えよう
オージス総研 藤井 拓

日本でこれからアジャイル開発が広まるためには、アジャイル開発のビジネス上のメリットを理解するとともに、ユーザ企業とITベンダーに分かれた産業構造を乗り越えるための方策が必要になる。本講演では、いくつかの問いかけを通じてアジャイル開発のビジネス上のメリットを考え、さらにユーザ企業とITベンダーに分かれた産業構造を克服するためのフレームワークを紹介する。

<セッション2> 13:00~13:30 メイン会場
調整中
テクノロジックアート 長瀬 嘉秀
調整中

<セッション3> 13:45~14:45 メイン会場
調整中
静岡大学 森崎 修司
調整中

<セッション4> 15:00~16:00 メイン会場

アジャイル開発と組織
吉羽 龍太郎(@Ryuzee) 株式会社アイ・シー・アイ チーフテクニカルオフィサー/アジャイルコーチ/ 認定スクラムプロフェショナル/認定スクラムマスター/認定スクラムプロダクトオーナー

ビジネス環境が以前と比較にならない速度で変化している今、 企業にとって情報システムはオペレーションプロセスの効率化から 競争力の源泉へと役割を変えてきています。 このような状況化においてはシステムを開発する側はアジャイルな開発 プロセスを利用して変化に対応していかなければなりませんが、 アジャイルな開発の成功には組織のあり方が密接な関係を持っています。 本セッションではそれらの関係について失敗例や成功例を交えながら 解説いたします。

<ワークショップ> 13:00~15:00 サブ会場 定員25名

「Head First インセプションデッキ ~頭とからだで覚えるデッキ作りの基本~」
永和システムマネジメント 西村直人 featuring スクラム道

私が監訳者として携わった「アジャイルサムライ」という本で紹介されている「インセプションデッキ」を上手に作るコツをお伝えします。当日は、コミュニティ「スクラム道」の協力によりワークショップ形式で体験できます。数多くの現場でデッキを作った経験から得た事を多く伝えたいので、事前にデッキについて予習しといてくださいね。その方がより楽しめます!!

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

2011/09/09

【公開】第1回品川redmine勉強会の発表資料「障害管理からチケット駆動開発へ~ソフトウェア開発の3種の神器」 #47redmine

本日、第1回品川redmine勉強会が無事に終わりました。
多数のご参加ありがとうございました。
そしてスタッフの皆さん、会場を提供して頂いたIPA様、講演者の皆様、ありがとうざいます。

本日の私の資料をCC Attributionライセンスで公開します。
かなり話を省略しているので、詳細はDevLove関西2011で講演する予定です。

他の講演者の皆様の資料は、Twitterで探してみて下さい。

第1回品川Redmine勉強会 - Togetter

今日の勉強会は、RedmineコミッタによるRedmineの実装の中身と、Rxtstudyから来た講演者によるRedmineの運用方法、そして、プラグイン作成者による事例の3本立てでした。
実装方法と運用方法の2種類の講演がわずか2時間に詰め込んだので、質疑応答があったらもっと面白かったと思うので、次回に生かそうと思います。

僕がこのコミュニティを通じてやりたい事は、下記のつぶやきで書きました。

Twitter / @akipii: チケット駆動開発を過去4年やってきてようやくAgile開発・XP・Scrum・PMBOK・ITILなどの各種技法の意味がちょっとずつ分かってきた気がする。TiDDは実装方法の一つとして強力。実際にプロジェクトを回せなければ知識を持っていても意味がないから。

Twitter / @akipii: #47redmine プロジェクト管理の問題をソフトウェアでどのように解決するのか次回の品川勉強会で議論したい。関東にはプラグイン作成者が多いから実装と運用の二本で話して欲しいな。プラグインが作成者のプロジェクトで既存の問題をどのように解決するのか聞きたい。

「プロジェクト管理の問題をソフトウェアで解決していく」方法について、その実装方法(プログラミング)と運用方法(プロジェクトへの適用方法)の観点で分析してみたい。
RedmineないしTrac、GitやMercurial、HudsonやJenkinsというツールを自由自在に操ることによって、ソフトウェア開発のプロジェクト管理を本質的に変えるだけでなく、アジャイル開発へ流用することも可能だと確信しています。

【追記】
勉強会の資料やUstreamなどのリンクは下記にあります。
参加できなかった人はUstreamでお楽しみ下さい。

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

@haru_iidaさんが品川Redmineコミュニティの立上げに関する記事を書かれています。

Haru's blog: 品川Redmineのインフラ変遷

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

2011/09/05

Pivotal Trackerに似ているツールFulcrum

Moongiftさんの記事で、ストーリーベースのタスク管理ツールFulcrumが紹介されていたのでメモ。

【元ネタ】
ストーリーベースのアジャイル開発に。Railsのプロジェクト管理「Fulcrum」 - MOONGIFT|オープンソース・ソフトウェア紹介を軸としたITエンジニア、Webデザイナー向けブログ

Pivotal Trackerとredmineの違い: プログラマの思索

Fulcrumの画面キャプチャを見た感じは、倉貫さんがRxtstudyでデモしたPivotal Trackerにとてもよく似ている。
Fulcrumの作業領域は、Chilly Bin→IceBox、バックログ→Backlog、InProgress→TaskBoard、Done→本番環境へリリース済みと見なせば、Pivotal Trackerとほぼ同じだ。
後は、Fulcrumにおけるストーリーカードの作業状態やリリース状態がアジャイル開発の概念を反映しているなら、Pivotal Trackerのように、ストーリーカードの進捗はBooleanで、リリース状況は受入テスト中・済のいずれかになるだろう。

FulcrumやPivotal Trackerのように、ストーリーカードでタスク管理を行うツールは、「アジャイルサムライ」やリーンソフトウェア開発に出てくる「かんばん」をそのまま実装したように思える。
実際、ストーリーカードの作業状態をかんばんで表現しているし、かんばんの制約条件である作業中(Work In Progress)のカード数に上限を設けて、ストーリーカードをChilly Bin→Backlog→TaskBoard→Doneへ流れるようにすればいいだろう。

特に、Chilly Bin→Backlog→TaskBoard→Doneへストーリーカードが流れる様は、リーンソフトウェア開発に置けるPull方式の発想につながるのだろう。
例えば、TaskBoardにある作業がDoneに移って終われば、Backlogにある一番上(最優先)のカードを取り出してTaskBoardへ移動して作業を始めればいい。
すなわち、自分の手持ちの作業が無くなってから、次の作業に取り掛かるので、Pull方式のタスク管理になる。

かんばんがScrum界隈で最近注目されているのは、スプリント単位の反復開発よりももっとスピーディな開発スタイルとしてかんばんが取り上げられているのだろうと推測する。

但し、かんばんの運用はスプリント単位の反復開発以上に難しいと思う。
何故なら、Pivotal Trackerの倉貫さんのデモでも、ストーリーカードの粒度は1人日以下と非常に粒度が小さいように作られていた事実から、かんばんにのせるストーリーカードは事実上のタスクカードに近いレベルまで作業を落としこんでおく必要があるからだ。
普通のソフトウェア開発では、ストーリーカードから直接実装できるほど簡単ではない。
システムの仕様やアーキテクチャを知り尽くしているからこそ、ストーリーカードを細かく分割することができるからだ。
その前提条件(コンテキスト)は忘れがちなので要注意。

なお、かんばんの解説は@ryuzeeさんのBlogがとても詳しく参考になる。

[Agile]“塹壕よりScrumとXP”その後とテスト自動化順序の決め方 | Ryuzee.com

[Agile]Kanbanを導入する正しい理由5個 | Ryuzee.com

かんばんについてはまだまだ理解できていないので、チケット駆動開発上でどのように運用すればよいか、色々考えてみる。

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

2011/09/03

Redmineプラグインあれこれメモ

今度試してみたいRedmineプラグインをメモ。
今時間が取れないので、連休にゆっくり試してみたい。

【Watcher機能を拡張】
Twitter / @mkinside82: Redmineチケット一覧から右クリックでウォッチャー追加は、やはり地味に便利だ。いれてよかった。

Twitter / @mkinside82: @akipii こらのプラグインです。Watcher Sellection by Groupと合わせて使ってます。 Redmine - Context menu watchers - Plugins bit.ly/pOjUgr

Twitter / @akipii: @mkinside82 ありがとうございます。redmineチケットに複数の担当者をアサインしたい場合はwatcher機能を使う方が良いと僕も思います。

Redmine - Context menu watchers - Plugins - Redmine

Redmine - Watcher Sellection by Group - Plugins - Redmine

Redmine - Board Watchers - Plugins - Redmine

Redmineチケットには関係者に通知するWatcher機能がある。
チケットに複数の担当者をアサインしたいという要望を時々聞くが、Watcher機能を代わりに使えばいいだろうと思う。
担当者はやはり1人でよい。複数人を担当にすると、連帯責任になるので、責任者が曖昧になってしまう。

何故なら、チケットは本来、障害報告票から発生した概念であり、Excelや紙の障害報告票で作業ステータスを遷移させる時は、必ず判子を押す運用があったからだ。
判子を押すということは、私の作業は完了したと承認します、と署名するのと同じで、自分の担当作業から障害報告票が離れたことを意味するから。

もし、複数人のメンバーがチケットの作業に関係するならば、Watcher機能でチケット更新時に通知するように運用すればいいと思う。
とはいえ、Ver1.3ではユーザグループを担当者へアサインできる機能追加があるという話もあるので、今後のVerUpにも注意したい。

【ドキュメント作成】
Twitter / @kaorun55: [redmine][Sphinx]よさげ / Redmine Sphinx Pluginの概要 - nishio.densankenの日記

SphinxはPythonで作られたドキュメント生成のフレームワークみたい。
HTMLやPDF、epubへ出力できるだけでなく、クラス図やネットワーク図のようなダイアグラムもサポートしているらしいから、Excelの設計書の代わりに使える可能性がある。
SphinxがExcelよりも良い利点は、テキスト形式なので、ソース管理で差分履歴が分かりやすいこと。
設計書もソースと同じく、バージョン管理すべきだし、変更履歴を追跡できる環境をもっと使い易くしたい。

本来の要件や仕様が、どんな経緯で変更されて、現在の汚いパッチの実装に至るのか、を追跡する仕組みは、SEにとって重要なインフラだからだ。

【フォラームのメッセージからチケット登録】
Twitter / @haru_iida: フォーラムのメッセージからチケットを起こすプラグイン。フォーラムでの議論から課題が発生することはよくあるので良いかも。Redmine: Activity - Plugins: Issue from message plugin

チケット起票のタイミングは、タスク発生やバグ発生だけでなく、顧客からの問い合わせメールや開発者同士の掲示板の議論などもある。
以前なら、phpBBのような掲示板システムで議論した後、MantisやBugzillaなどのBTSへチケットを起票する運用が多かったのではないだろうか?
特に、新しい技術の実装方法のように、フォーラムや掲示板で開発者同士が議論した後にやるべきタスクが見つかる時はよくある。

Redmineは、Wikiだけでなくフォーラム機能もデフォルトなので、フォーラムから即座にチケットを起票できる機能があれば、チケット起票の入力の手間が省ける。

以前、ThunderBirdのメールからRedmineチケットを起票するプラグインがあったけれども、リンク切れでダウンロードできなくなった。
早く復活して欲しいと思う。

2016/3/5 ThunderBirdのメールからRedmineチケットを起票するアドオンは下記にあります。
Redmine連携 :: Add-ons for Thunderbird

Thunderbirdで受信したメールをRedmineのチケットとして登録できる「Quick Ticket to Redmine」 | Redmine.JP Blog

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

フォーラムやメールのように、インシデントからチケットを起票する機能はもっと機能改善の余地があると思う。
Redmineなら、RestAPIやメール送信でチケット起票のAPIがあるのだから、色んな実装方法があるはず。

【プラグイン開発】
Twitter / @yusuke_kokubo: Redmine code reviewプラグインはRedmineのプラグインをつくる上で参考になるノウハウがたくさんつまってる。

Twitter / @yusuke_kokubo: r-labsのコードレビュープラグインすげー!

@yusuke_kokuboさんがどこで感心されたのか、内容について聞いてみたい。
@haru_iidaさんに一度、コードレビュープラグインの中身や実装方法について、解説して欲しい(笑)

Redmineの利点の一つは、Railsなのでプラグインを開発しやすいこと。
現場リーダーは、プロジェクト運営である仮説を思いついたら、Redmineにたまったデータを解析してみて、自分の仮説が事実と合致しているか、検証してみるのもいいと思う。
プロジェクト管理も、仮説検証スタイルでどんどん結果を出して、自分なりのノウハウを貯めていけばいいと思う。
もしRedmineに機能が足りないならば、下記の方のように自分で作ってしまえばいいだけのことだ。

Redmine Graph Activitiesプラグインのご紹介 - TitleNotFoundException

活動ログを解析するRedmine Graph Activitiesプラグイン: プログラマの思索

下記のプラグイン解説がとても読みやすいので参考にしたらいいと思う。

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

Rails を知らない人のための Redmine プラグイン開発ガイド: プログラマの思索

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

2011/09/02

Continuous Delivery~TDDとCIの次に現れた自動化の概念

Continuous Delivery」という本が良いらしい。
下記のTogetterを読んでメモ。

【元ネタ】
Togetter - 「SIerは自動化する対象が違っているのでは?」

Continuous Deliveryをポチッた - watawata日記

Continuous Delivery - haru01のめも

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

インフラやデータ移行の自動化~アジャイル開発の最後の問題: プログラマの思索

アジャイル開発の面白さの一つは、技術の奥深さ。
テスト駆動開発(TDD)、継続的インテグレーション(CI)の技術は、アイデアはシンプルだけどその技術はとても面白い。
JUnitに初めて触れた時、スタブやリフレクションのプログラミングに驚いたことを覚えている。
境界値分析、同値分析というテスト管理技法も、テスト駆動開発で実践して初めて役立つと思う。
Hudsonを運用して、継続的インテグレーションは単なるビルド管理の自動化だけでなく、リリース作業全般のリアルタイムなバッチ処理化なのだと気付いた時があった。

OOAやDOAのように、上流工程の自動化に向かうと、要件定義書からプログラムを自動生成する方向へ走る。
その方向性は最終的にはモデル駆動開発(MDA)に落着くが、技術的には面白くない。
一度自動生成されたプログラムは手作業で直すと、二度とツールでサポートできなくなるから、逐一ツールで開いて修正する手間がかかる。

Continuous Deliveryは読んでないけれど、TDDやCIがテスト工程の自動化に注力しているのと同様、Continuous Deliveryが受入テストやリリース作業などの自動化へ進化しているのが興味深い。

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

2011/09/01

【告知】DevLOVE関西2011でチケット駆動開発の講演をします #devlove

9月17日 DevLOVE関西2011CONNECT(大阪府)

【開催概要】
日時 2011年09月17日(13時受付/13時30分本編開始) ※13時受付にご協力下さい。
開催場所 TIS大阪本社(パシフィックマークス江坂 19Fセミナールーム)(大阪府吹田市豊津町9-1)
参加費 1,000円(税込)
定員 50人(先着順)
主催 DevLOVE運営チーム
タグ #devlove

前回のDevLOVE関西から、2年。
2年。この2年だけとってみても、開発の現場を取り巻く世界は、大きく変わったように思います。
自分たちの現場のために、何をすることが出来るでしょうか。

今回のDevLOVE関西は、様々な方の発表、ワークショップからそれを考えるきっかけ、応用する手がかりをつかみ、「創り出す対話」を通じて、明日に向けたActionを産み出す場として開催します。

現場を創っていくのに、東京も、大阪も、会社も、コミュニティも、SIも、Serviceも、関係ありません。
ましてや。
現場のこれからを創っていくのは、どこか遠くにいるありがたい話をする、誰かではありません。
自分たちの現場を創っていくのは、私たち自身です。

◆DevLOVE関西から始まる繋がり◆
今回は、DevLOVEと関西のさまざまなコミュニティの力を集めて、この場を作ります。
その狙いは、関西コミュニティと関西に居る皆さんが繋がること関西コミュニティと関西コミュニティ同士が繋がることそして、関西コミュニティとDevLOVEが繋がることにあります。
システム開発は、未だ容易ではありません。
時に、惨状を呈する現場、プロジェクトもあります。
しかし、我々が繋がり、それぞれの経験と知恵から、互いに伝わるものを生み出せたら。変えられるかもしれません。
10人なら10人分の、100人なら100人分の経験と知恵が可能性を拡げるはずです。その繋がりは、東京大阪という物理的な距離も、超えていけるはずです。

そして、「自分たちの現場を創っていくのは、自分たち自身」この言葉に思いを込めて、それを実現する一助となる場を作るべく、我々は活動を始めました。DevLOVE VOYAGEです。
このDevLOVE関西の最後にも、帆を立てる時間があります。

【講演内容】
タイトル:「障害管理からチケット駆動開発へ~BTSから始まる進化の歴史」
講演者:あきぴー@RxTstudy

概要:
昨今、高機能化した課題管理システム(ITS)をソフトウェア開発のプロジェクト管理に適用してAgileに開発するチケット駆動開発(TiDD)が静かに広がっています。
チケット駆動開発は障害管理システム(BTS)から発展した手法であり、その歴史を辿ると従来のソフトウェア開発の問題点を障害管理の観点からどのように解決してきたのか、が見えてきます。
本講演では、障害管理からチケット駆動開発へ至る歴史を辿りながら、チケット駆動開発がそれら問題をどのように解決しようとして、どの方向へ進化させようとしているのか、についてお話します。

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

« 2011年8月 | トップページ | 2011年10月 »