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

2011年4月

2011/04/29

チケット駆動開発の3種の神器 #itsjp #tidd

チケット管理システム比較へチケット駆動開発とITS・SCM・CIの3種の神器の関連についてまとめてみた。

アジャイル開発のインフラを支える三種の神器: プログラマの思索

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかける: プログラマの思索

チケット管理システム比較Wiki #itsjp #devsumi: プログラマの思索

RedmineとSCMの機能の関連表~BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索

Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd: プログラマの思索

ITS・SCM・CIをソフトウェア開発の3種の神器と命名した人は、@haru_iidaさん。
この言葉にすごくインスピレーションが働いて、チケット駆動開発のどこにそれらツールの機能が関連しているのか、イメージをふくらませてみた。

フィードバックがあれば、上記のWikiへどんどん書き込んで下さい。

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

チケット駆動開発の使い道 #tidd

チケット駆動開発を運用した記事を見つけたのでメモ。

【元ネタ1】
チケットドリブン拡大中 - ついついネット

Redmineによるチケット駆動開発を社内のタスク管理、ToDo管理や営業の管理などに使っているようだ。
面白いと思ったのは2点ある。
一つは、チケットファースト(チケットがトリガーとなって仕事を行う)を徹底すると、部下は上司の横暴に対向できる口実が出来ること。
仕事を依頼される側でチケットがあふれれば、オーバーワークになり、進捗が滞り、ミスが増えてしまうのは当然だ。

(引用開始)
逆にチケットが無いと受けない。口頭で仕事をしない。これを徹底する(ちょっとコピーとって・・くらいは口頭で。量が「ちょっと」でないときはチケットを)。
これは非常に重要なポイントで、部下が上司に対して「チケットが無いと受けません」とは言いにくいのが普通だろう。これを最初に全員に理解してもらい、部下は「受けません」と言ってよく、言われた上司は言い訳無用で改めることを徹底してもらう。どうしても逼迫している仕事があったりしてチケットを発行できないケースもあるだろうから、杓子定規の話しではなく「代わりに部下がチケットを発行する」ことを許可する。ただし簡易な依頼のみに限定する。チケットの良いところは、「口頭依頼だと、忘れ/伝言ミス/解釈ミスが起こる」ことを排除する目的もあるからだ。
受ける側が切るチケットが多すぎるようであれば、依頼する側がオーバーワークになっているということなので、業務/体制を見直す必要がある。そのような状態では、ミスが多発することは自明の理だ。
(引用終了)

もう一つは、チケットを通じてコミュニケーションの品質が上がり、それによって仕事の調整がやりやすくなること。

(引用開始)
コミュニケーションが減るというデメリットがあるかも知れないが、それは逆だ。
コミュニケーションのために双方が同じ時間を空けなければならなかったり、力関係があるだろうから、弱い側が今どんなに忙しくても、強い側が手を止めさせて仕事を頼むといった、受ける側のストレスが減る。チケットで概要は互いに解っているので、コミュニケーションするにも要点のみに絞れて効率がよい(コミュニケーションが必要だった部分はチケットの発行の仕方に工夫の余地があることを示唆している)。
効率があがった分、建設的なコミュニケーションの時間を増やせばよい。というか時間の調整、言いまつがい、聞きまつがい(これは糸井重里さんの絶妙な言葉だ)による仕事のバックデートが減るので、必然的にそうなってゆく。
小さな会社ほど、口頭で作業が進んでいると思うので、ちょっとの労力をかけることで多大なメリットがある。
(引用終了)

バックデート(backdate)とは、スケジュールを後から変更する行為を指す。
駄目なプロジェクトでは、発行したタスクの見積もりが甘く、作業するほど漏れを見つけては手直しして、当初の期限をはるかにオーバーしてしまう。
チケット駆動ならば、最初にゴールを決めたものの、当初よりも工数が膨らむならば、チケットを分割して複数人で並行作業できるように調整すればいい。
PMBOKで言うファストトラッキング(Fast Tracking)やクラッシング(Crashing)をチケット管理で自然に行えるのがチケット駆動開発の強みだ。

【元ネタ2】
チケット管理ツールを比較 - 掘った穴に入るのはオイラか? - Yahoo!ブログ

開発案件にRedmine又はTracを導入して、チケット駆動開発を実践した感想が述べられている。
WF型開発の場合、設計→開発までは順調に進むが、結合テスト→総合テスト→受入テストで障害管理していく時にMS Projectではプロジェクト管理が力不足という点は、TiDDを実践している人なら当たり前だろう。

(引用開始)
2年前、Tracというツールを使おうと準備していたのだが、今一つ使い方がわからず、断念した。
折しもその頃は、社内でMSProjectで管理しましょう!という風潮であり、ガントチャートメインの開発管理スタイルを勧めていた。
MSProjectはどういうツールかというと、1つの仕事に人と期間が割り当てられ、仕事同士の時間的な関連を見やすくしたツールだ。
この特徴は。順次進める仕事A,B,Cがあり、Aが遅延した場合、自動的にB,Cの着手、終了日が変化するといったシステムだ。
年単位の長期間で詳細な計画を立てる場合、計画実行中の遅延を瞬時にガントチャートに反映できる点はとても有益だ。これをTracでやろうとした場合、管理工数が増えるばかりのため、採用を止めてしまった。
しかし、いつも悩むのが開発の後半。不具合対応がメインとなる後半戦を、ガントチャートで管理するのは無謀だ。結局、Accessで作成した不具合管理票と、Excelの課題進捗管理表での管理となる。
(引用終了)

興味深いのは、RedmineよりもTracの方が使いやすいという指摘。
特に、Tracの強力なチケット集計機能に魅力があるとのこと。
確かに、複雑なSQLを書くスキルがあれば、RedmineよりもTracの方が各種レポートを自分で簡単に作ることができる。
マネージャならば、チケットに貯められた情報を週1回は色んな観点で集計して、進捗や品質の改善対策に役立てたいものだ。

チケット駆動開発の事例についてもっと集めてみたい。

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

2011/04/28

チケット駆動開発にセル生産方式の概念を持ち込む

セル生産方式+アジャイルの記事を読んで、チケット駆動開発にその概念を持ち込めるように思えた。
考えたことをラフなメモ書き。

【元ネタ】
セル生産方式+アジャイルという枠組み - @IT情報マネジメント

チケット駆動開発の場合、ITSから発展した開発スタイルなので、突発的なタスク管理がやりやすい。
つまり、ITプロジェクトのように1回しか作らない製品開発や、ITILのような問合せ管理がやりやすい。
だから、ソフトウェアセル生産のように、多品種少量生産というルーチン化しにくい作業には向く。

チケット駆動開発なら、セル=チケット。
チケットがWBSの構造を持つので、システム(製品)を作るために必要な作業はチケットに全てマッピングできる。
もちろん、チケットには先行・後行の依存関係を付けれるので、製品の製造工程において、作業の順序を強く意識させることもできる。
突然の仕様変更依頼によって、作業日や担当者が変わったとしても、ITSのチケットの属性を簡単に変更できるので、即座に作業スケジュールに組み込むことができる。

あるいは、チケット駆動開発なら、セル=一つのコンポーネントを作る作業の集まり=ITSチケットの塊。
一人が一つのコンポーネントを作る責任を持ち、複数のコンポーネントが集まってひとつの製品が出来上がる場合、チケットの属性であるカテゴリをコンポーネントに対応付ければ、カテゴリ単位に人がチケットへアサインされる。
チケットには担当者がアサインされているので、各担当者が他メンバーや他のチケットに関係なく独立して作業できる。
つまり、チケット単位に開発=各人が独立して並行作業。
すべての作業が終われば、製品(システム)が完成されて出荷できる。

この考察を進めると、製品出荷=リリース予定バージョンで括られた全チケットが完了ステータスになること、と言い換えられる。
つまり、製品出荷に必要な作業は一つのリリース予定バージョンでグループ化される。
製品出荷の単位がリリース単位になる。
もちろん、製品出荷までにマイルストーンを細かく作って、ITSのバージョンにマッピングしてもいい。

チケット駆動開発を実践して気づくことは、チームのメンバーだけでなくチーム外の人も作業の現状を即座に把握できるので、風通しがよくなること。
ガントチャート、バーンダウンチャート、タスクボードを見れば、そのプロジェクトで誰のタスクが火を噴いているか、誰でも分かる。
だから、溢れたタスクを誰がカバーするのか、という対策を講じやすい。

チケット駆動開発で重要なポイントは、イテレーションという概念をタスク管理に自然に持ち込めること。
チケット駆動開発が回るようになれば、その対策の立案も実施も、リーダーが上から指示しなくても、メンバー自身が自発的に調整するようになる。
プロジェクトファシリテーションが提唱するアジャイル精神をベースとしたチームビルディングが自然に沸き上がってくるのだ。
そうすれば、プロジェクトの生産性も品質も向上してくるだろう。

チケット駆動開発には色んなメタファがある。

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

2011/04/27

ITSの黒魔術 private issue #tidd

Redmineの次期バージョン1.2.0にprivate issueの機能が実現される。
実際に使った記事があったのでメモ。

【元ネタ】
前略、private issue 使ってみました。あるいはITSの黒魔術とは何か - ハードコイルド・ワンダーランド

Twitter / @さかば: バレてないバグに使うと本当に黒魔術ですね。 RT: @fumito_ito: ブログ書いた。 [redmine][ITS]前略、private issue 使ってみました。あるいはITSの黒魔術とは何か http://htn.to/3ziRE9

Redmine - Feature #7414: Private issues - Redmine

Redmine - Feature #337: Private issues - Redmine

Redmine - Feature #7412: Add an issue visibility level to each role - Redmine

Twitter / @fumito_ito: private issue, コアメンバー全員にIssues visibillity権限を付与して、客とか発注先に見せられないタスクを共有する感じなのかな。オープンにできないタスクがあるって言うのはITSの使い方としてちょっと違和感あるけど、需要はあるんだろうな。

Twitter / @かぬ: @fumito_ito tracでも古くからプラグインとして存在してますが黒魔術扱いですw http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin

private issueは単にチケットの公開・非公開の機能を追加しただけと思ったがそうではないようだ。
同一プロジェクトでユーザのロールによって、チケットが出てこない。

結論を言うと、private issueの機能は不要だし、チケット駆動開発にとって害悪以外の何者でも無い。
private issueによって、チケット集計機能にも大きく影響をうけるので、潜在的バグになる。
バーンダウンチャートの表示方法も変わってしまう。

しかも、@sakaba37さんの言う通り、見つけたバグをprivate issueにしてしまえば、誰も気づかないから、故意に不正を起こすこともできる。

Agile開発の精神からすれば、メンバーが持っている成果物や作業や課題、バグはチーム全体の共有物であり、個人だけの問題ではない。
メンバー全員で課題を共有できるからこそ、チームは前進する。

private issueをあえて使う状況とすれば、同一プロジェクトを開発チームと外部の顧客で扱う場合、顧客には非公開の課題やバグはprivate issueを使う時が考えられる。
しかし、そのような運用がしたいならば、Redmineプロジェクトを別に新規登録して運用すればいいだけのことだ。
何故なら、そこまでしてチケットの公開状況を変えたいということは、そもそも課題のライフサイクルが開発チーム向けと顧客向けでは大きく異なるからだ。

Redmineも過去3年間でどんどん進化してきたけれども、余計な機能が追加されて潜在バグが増えたり、機能が複雑になって初心者に使いづらくなる危険性が高まったきたようだ。
僕個人としては、Redmineからprivate issueの機能は削除して欲しいと思う。

【追記】
プライベートチケットを使って、開発者個人のToDoチケットはプライベートチケットにして、工数集計から外すという運用も可能だ。
つまり、工数集計すべきチケットと工数集計から外すチケットをプライベートチケットによって分別するという新しい手法もある。
プライベートチケットの使い方については、実運用を色々試してみる必要があるように思う。

Redmineの大規模化の壁

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

2011/04/25

ITエンジニアのための【業務知識】がわかる本

ITエンジニアのための【業務知識】がわかる本」を偶然読んだら、ためになったのでリンクしておく。

【元ネタ】
ITエンジニアよりビジネスオタク向け?『ITエンジニアのための【業務知識】がわかる本』 - モジログ

for 退屈な人々:「ITエンジニアのための【業務知識】がわかる本 第2版」 三好康之 - livedoor Blog(ブログ)

「ITエンジニアのための【業務知識】がわかる本[第2版]」: 読む。忘れる。困る。

ITエンジニアのための【業務知識】がわかる本 第2版, 三好 康之 の感想 - ブクログ

【本】ITエンジニアのための【業務知識】がわかる本 - Assorted Biscuits - 楽天ブログ(Blog)

業務知識を知りたいと思う時に、浅く広く見通したり、辞書のように使える。
エンジニアがスキルアップするための役立つ資格、情報処理試験に出てくる用語のメモが役立つ。
この本で気になった言葉をキーワードにして探せばいいだろうと思う。

【追記】
もうすぐ第3版が出るらしい。

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

Xead Driverの感想

渡辺幸三さんがXEAD Driverを公開されたので、その講演を聞いてきた。
感想や考えたことをメモ。

【元ネタ】
関西IT勉強宴会のブログです: 2011-04-22(金)XEAD Driver公開記念企画の内容

渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - XEAD

仕様書でシステムが動く時代へ: 設計者の発言

Twitter / @seiya yazaki: XEAD Application Driver だかの記事( http://bit.ly/9UQcu0 )を見れば見るほど疲弊してきた。何かを見て「うさんくさい」という感覚を持つことが殆ど無いのだが、どうやら余りの「うさんくさい」感が辛いようだ。滅多にないので新鮮な感じである。

「帳簿組織の育成」としてのシステム開発: 設計者の発言

XEAD Driverの詳細は、記事を読んでもらえればいいが、僕はMDA(Model Driven Development:モデル駆動開発)の一種のように思っている。
僕の考えでは、アジャイル開発は動くプログラムが正であり、プログラミングが全てのIT技術の基本と思っているので、MDAとは真っ向から対立していると思っている。
自分の立場がアジャイル開発、あるいはプログラマであるだけに、モデルからプログラムを自動生成すればOKという話はとても好きになれなかった。
XEAD Driverを使える場面は、要件定義で画面プロトタイプ専用ツールとして使うぐらいしか連想できなかった。
(ごめんなさい)

でも、渡辺幸三さんがホワイトボードの前でまるで画家のようにモデリングしていく様はとても興味深かった。
渡辺さんが独自に編み出したDFDやER図の記法で、参加者の要望を吸い取り、システムのスコープを決めて詳細化しながら、「お客さんがなにか考え事をしていて場が止まっていても、モデラーはどんどん書いていくべきなんですよ」と言いながらドンドン書いていくのを見るのは面白かった。
そして、データモデリングでも、ビジネスルールを考慮しながらキー・非キーを配置していく様は、なるほどと思った。

個人的には、データモデリングは長い歴史を持ち、Railsが出てからはその重要性が高まっているにも関わらず、そのノウハウはパターンとして整理されていない印象を持っている。
OOAではアナリシスパターンのように業務モデルをパターン化してくれているのに、DOAではデータモデルパターンの本が日本語訳すらされていない。

実践的データモデリング入門の感想: プログラマの思索

データモデルパターンのリンク: プログラマの思索

Railsを使う開発者ならば、OOAよりもデータモデリングの手法を研究する方が実際に役立つし、その経験がドメイン駆動設計にも生きるだろうと思っている。
色々考えてみる。

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

ドメイン駆動設計よりもパターン本が好き

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」が出版されて、DDD(ドメイン駆動設計)が注目を浴びているらしい。
まだ手元にないので中身も知らないが、考えたことをメモ。

【元ネタ】
長年、邦訳されなかった「思慮深いソフトウェア開発者全員の必携書」(1/2):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

エリック・エヴァンスのドメイン駆動設計 - Eric Evans/牧野祐子/和智右桂/今関剛/株式会社翔泳社:SEShop.com

ドメイン駆動設計・俯瞰編 - Strategic Choice

実践DDD [Domain-Driven Design]:第1回:DDDを俯瞰する | 豆蔵ソフト工学ラボ

(一部引用開始)
同書は、一部のエンジニアには、マーチン・ファウラー氏の『エンタープライズアプリケーションアーキテクチャパターン』(以降PofEAA)と並び、システム設計におけるバイブルとされ、熱狂的に支持されています。
(引用終了)

アーキテクチャやモデリングに関する本は今まで色々読んできた。
だが、僕の中では正直ピンと来る物はなかった。

むしろ、GoFの「オブジェクト指向における再利用のためのデザインパターン」やファウラーの本「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」「エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)」の方がしっくり来る。
多分、僕は抽象的なアーキテクチャ解説の本よりもパターン系の本が好きだ。

パターンは、特定のコンテキストで問題の本質と解決方法、そのパターンを応用した時のリスクを明らかにしてくれる。
アーキテクチャ、モデリング、オブジェクト指向を突き進めると、いつも再利用の問題が顔を出すが、そのままの形で再利用できない。
パターンという形でしか再利用できていないのが現状だし、多分それが限界なのでは、と思う。

色々考えてみたい。

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

2011/04/24

理想ラインが加わったredmine_version_burndown_charts画面

@daipresentsさんがredmine_version_burndown_chartsプラグインをアップデートしたらしいので、インストール後の画面をアップしておく。
興味深いのは、理想ラインが追加されたこと。

【元ネタ】
Twitter / @Dai Fujihara:Redmineのバージョンバーンダウンチャートプラグインアップデート 予定線を追加 1.0.5での動作確認済 http://t.co/6RmdYZo

daipresents/redmine_version_burndown_charts - GitHub

Redmineに入れたプラグイン一覧part2: プログラマの思索

Burndownchart_20110424

redmine_version_burndown_charts画面は、バージョン(スプリント)単位でバーンダウンチャートを表示してくれる重要なプラグイン。

だが、従来は予想ラインと実績ラインしかなかった。
当然、予想ラインは予想工数、実績ラインは実績工数とステータスから集計されていると思われるが、理想ラインは何となくMSProjectの山崩しのように思える。
つまり、予想ラインは入力した予定工数や開始日・終了日からそのまま出力するのでリソースが偏っている可能性が高く、現実の進捗に程遠い可能性もある。

理想ラインに近い形でタスクが減っていけば、進捗は特に問題ないという判断を下せるし、逆に理想ラインよりも大きく実績ラインが離れると現状に合っていないという判断もできるだろう。
実際に運用してみると色々分かってくるかもしれないので試してみたい。

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

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

簿記に現れる権利と責務の概念

簿記を習っていると、簿記の中に権利と義務という概念が含まれているのが分かる。
考えたことをラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
当座借越(とうざかりこし) -わかりやすい 簿記

【1】当座預金の勘定は、当座勘定と当座預金・当座借越勘定の2パターンがある。
普通は、当座預金で小切手の振出など、当座借越で当座預金がマイナス値(貸方残高)になった場合などを記録する。
時々、当座という一つの勘定で記録する場合がある。
当座勘定の場合は、借方が当座預金の残高、貸方が当座借越の残高をセットする。

この当座勘定の説明を受けた時、当座勘定の借方は当座預金、つまりお金を受け取る権利を意味していて、貸方は当座借越、つまりお金が足りないので返す義務があるという意味と教わってなるほどと思った。
同様に、他の仕訳でも、資産はお金を受け取る権利、負債はお金を支払う、又は返却する義務という意味が込められている。

つまり、他人とのやり取りで権利や義務が発生する場合、それはお金になる。
権利を商品にして売る商売は、保険や証券、受取手形、売掛金、仮払金などがあるだろう。
義務を商品にした場合、社債や借金のように、お金を借りることで返却する義務が生まれる。

権利はペーパー資産になりやすい。
お金を将来返す場合は必ず利子が発生する、利子が発生すると金融取引になると教わった。
利子がつくから、お金がある人はお金を貸す。
最近は、金融取引がIT化されてペーパー資産を簡単に膨らますことができるので、IFRSのように、お金を企業に投資する投資家重視の会計基準が必要になってきたのだろう。

簿記3級で面白かったのは、「権利」と「義務」の話がよく出ること。
例えば、個人商店の従業員が給料を前払いしてもらった場合、個人商店側は一時的資産として立替金を借方に発生させて仕訳する。
つまり、個人商店は「従業員から給料日になれば立替金を返してもらう権利」がある。

あるいは、社員が出張旅費を会社から前払いしてもらった場合、会社は金額不明の資産として仮払金を借方に発生させて仕訳する。
つまり、会社は「社員が出張から帰ったら報告させる権利」がある。

この簡単な例から類推したのは、ビジネスとは「権利の売買」が基本ではないか、ということ。
身近な例では、野球やサッカーのスタジアムの命名権ビジネス。
名前を付ける権利を売っているのだ。
あるいは、コンサートや劇団四季、宝塚歌劇のチケットは、それらを鑑賞する権利を売っている。
小室哲哉は、自分の曲の著作権がないのに他人に売って、逮捕された。
IT技術者なら、ソフトウェアの著作権も相当するだろう。

とにかく、取引の中で、権利があれば、それはビジネスにできる。
ビジネスのどこに権利があるのか、それを探り、稀少性を高めれば売れる。

【2】権利が資産、義務が負債という概念は、複式簿記の発祥地であるイタリアの海上貿易から生まれた。
東方貿易の航海のための資金を、資産家が出資金を出して、航海から帰ったらその利益を分配する仕組みから生まれたと聞いている。

権利が資産、義務が負債という概念について興味ある事象はいくつかある。
一つは、民主主義と資本主義が密接に関係していること。
欧米の歴史をふりかえると、政治的自由は私有財産の保護と共に生まれた。
商業貿易から得られた私有財産を更に投資して回収するための仕組みの背後には、権利が資産、義務が負債という簿記の概念が隠れている。

お金の貸し借りを社会のルールの一つとして尊重する法体制や商業取引がなければ、経済は発達しない。
弾言 成功する人生とバランスシートの使い方」でも、モノがカネ化するということは、社会が安全で他人を信頼できるインフラがあるからできるのであり、盗みや詐欺の方が割が合わないように社会は発達してきたのだ、という文章がある。
つまり、他人(とそのお金のやり取り)を信頼できる社会ほど個人の利益を生みやすい仕組みを歴史を通じて発展してきたのだ。

お金の貸し借りからうまれた権利と義務の概念と政治へ拡張すれば、自然に民主主義へ発展する。
特にイギリスでは、自由と私有財産が密接に絡みながら民主主義が発達していった経緯を辿ると、簿記を基盤とした経済のルール化は民主主義に寄与しているように思える。

最近の歴史でも、韓国や台湾のように、当初は軍事政権による開発独裁体制であったとしても、経済が発展していくと、文民政権が選挙で選ばれる体制へ変化した経緯が見られた。この流れの背後にも、資本主義と民主主義が密接に関係している理由が隠されている気もする。

もう一つは、日本では江戸時代の頃から金融取引が発展していた歴史を持っていること。
大阪堂島の米相場の先物取引がまさにそうだ。
また、日本独特の手形という債権・債務も、金融取引の歴史を背負っている。
だから、明治になって外国から複式簿記が輸入された時も、すぐに理解して普及できる余地があったのではないか?

日本では福沢諭吉が簿記を作った人だ。
「簿記」という言葉はBook Keepingをそのまま音訳したものと言われている。
人事屋が書いた経理の本―MGから生まれた戦略会計マニュアル」によれば、福沢諭吉は日本最初の簿記の本「帳合之法」を書いたが、その内容は、彼の独創的著述であり、彼が簿記の本質を非常に良く理解していた、と言っている。
彼のおかげで、日本はすぐに近代化できて、今の製造業のように優れた産業を作れたのではないか?

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

2011/04/21

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

久しぶりに「Redmineによるタスクマネジメント実践技法」の感想を集めてみた。
皆さんの感想を読むと色んな読み方があることに気づいて参考になる。
感想ありがとうございます。

【参考ページ】
clmemo@aka: Redmine によるタスクマネジメント実践技法 (小川 明彦, 阪井 誠)

(引用開始)
今までになかった、チケット駆動開発に主眼を置いた解説書。同じ言い回しが何度か出てきて、疎ましく感じることもある。それを差し引いても、一読の価値はあると思う。
最後にチケット粒度について。本書とぼくはチケット粒度について立場を異にする。これはその道の人でもちゃんとした答えが出ていない問題のようなので、自分のプロジェクトに合わせて試行錯誤する必要がありそう。
(引用終了)

感想「Redmineによるタスクマネジメント実践技法」 - yujioramaの日記

(引用開始)
devsumi2011 のセッションには参加できなかったけど、TiDD (Ticket Driven Development) は面白いと思います。
まちゅさんの記事の公開も結構昔なので、
「もうやってる」という現場も多いんじゃないでしょうか。
この本はそういった知識の集大成+実例になっててなんかすごいですね。
(引用終了)

Redmineによるタスクマネジメント実践技法 - takeboruta’s Blog

(引用開始)
Redmineを単なるチケット管理システムとしてではなく、すべての開発活動の中心において、「チケット駆動開発」という事に取り組むのであれば、読んで損はない本だと思います。
これから導入を検討している人、既に使っている人でも読んで参考になる部分があると思います。
Redmineはここ数年案件では必須ツールとして使っています。そういう意味で、既にRedmineを使ったシステム開発にどっぷり浸かっているのですが、それでも毎案件ごとに、同じような使い方をした記憶はありません。PJは案件によって色々と仕事の仕方が違ってくるのと同様に、その時々のメンバーもまた色々改善、指向錯誤を繰り返しながら開発案件というのは進んで行きます。その改善、対策に柔軟に対応できるからこそのRedmineであるし、Redmineで使える機能があるからこその改善というのもあります。
様々な作業を抜けなく、スムーズに実施し、複雑なソフトウェア開発を効率的に行っていくのに、今はかかせない存在になっています。
初めて導入するのであれば、本書などを参考にまずは真似から、既に導入経験がある人は、本書を読んで、同じ課題があれば、対策方法などを参考にするなどの使い方が良いと思います。
諸々の細かい部分は本書を参考にすれば良いと思いますが、一番のメリットだと思っているのは、開発に関わるコミュニケーションと見える化です。作業の抜けを出来る限りなくし、端折ることがなければ、チケット、タスクを管理しているリーダだけではなく、開発メンバー全員が知る事ができます。
(引用終了)

Redmineによるタスクマネジメント実践技法/小川 明彦, 阪井 誠:特に意味のない日記:So-netブログ

(引用開始)
アジャイルでの開発に、どのようにチケットを利用して開発を進めていくか、ということが主に書かれている。また、筆者らが実際にソフトウェア開発の現場で行ってきた経験から書かれており、参考になることが多い。Redmineでなくとも参考になることが多いと思う。
(引用終了)

Redmineによるタスクマネジメント実践技法, 小川 明彦 の感想 - ブクログ

(引用開始)
Redmineをこれから使用しようと思っている人、今使っているけれどいまいち上手く使いきれていない人にとって、非常に参考になることが書かれていると思う。
著者が実際に使用した経験をもとに書かれているので、現場で使うためのノウハウがたくさん詰まっている。
もっと早くこういう本に出合いたかった。
本書に書かれていることを試してみることで、自分の環境にあったやり方が見つけられると思う。
Redmineを使いたいと思っている人は、まず本書を読んでRedmineについて理解すれば、格段に早く使いやすいRedmineの環境を構築することができるだろう。
(引用終了)

(引用開始)
道具の使い方、運用の仕方は参考になるなと思って読んでいるものの、「自然と取り組むようになる」といった表現が登場し、Redmineと運用ルールを持ち込んだら成功したかのようなやや安直な表現が目についてしまった.
プロジェクトメンバーの構成員の様子と、道具やルールとの相性を解釈した章があったらより良いなと感じた.
(引用終了)

厳しい批判もありますが、処女作なのでご容赦下さい。
執筆した後にふりかえると、自分が経験したこと、理解したこと以上の内容は書けない事実に改めて気付かされます。

Redmineによるタスクマネジメント実践技法」で紹介したアジャイル開発、PF、PMBOKやITIL、構成管理パターン、テスト管理などのノウハウはその界隈では既にプラクティスもアンチパターンも知られており、僕はそれら既に知られているプラクティスをチケット駆動開発に当てはめただけに過ぎないです。
でも、関係する情報をまとめて一つのコンテキストで翻訳しなおす作業は偉大な仕事の一つかもしれない、と最近思っています。

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

2011/04/19

RedmineのBacklogsプラグインを入れてみた

RedmineのBacklogsプラグインをインストールしてみたのでメモ。
@yusuke_kokuboさんがRedmine+Backlogsプラグインを使いこなして、Scrumを実践していると聞いていたので、興味を持った。

【元ネタ】
Redmine Backlogs :: Installation

Twitter / @Kakutani Shintaro: redmineのbacklogプラグインはすばらしいね

Twitter / @Lightning: RedmineのBackLogプラグインみたいなことがTracでもできないかという質問がありましたが、http://trac-hacks.org/wiki/WhiteboardPluginとかあります

【インストール方法】
下記のRubygemsを入れておく。

gem install rails -v= 2.3.5
gem install rubygems -v=1.3.7
gem install rack -v=1.0.1
gem install rmagick
gem install i18n -v=0.4.2
gem install icalendar
gem install prawn
gem install holidays

Redmineを新規に入れる。
Redmine本体とBacklogsプラグインを配置しておく。

Backlogsプラグインの日本語ファイルがないのでコピーしておく。
cd redmine\vendor\plugins\redmine_backlogs\config\locales
cp en.yml ja.yml

DBを作成
create database redmine character set utf8;

おまじないを実行
rake generate_session_store
rake config/initializers/session_store.rb

Redmineを新規作成
rake db:migrate RAILS_ENV=production
rake db:migrate_plugins RAILS_ENV=production
rake redmine:load_default_data RAILS_ENV="production"

Backlogsプラグインを新規作成
rake redmine:backlogs:install RAILS_ENV="production"
rake redmine:backlogs:generate_chart_data RAILS_ENV="production"

Redmineを起動してアクセスする。
ruby script/server -e production

http://localhost:3000/

【画面キャプチャ】
細かな使い方は分かってないけど、Scrumっぽい感じ。
画面キャプチャを貼っておく。
但し、AdvancedRoadmapプラグインも入れているので、ロードマップ画面にマイルストーンが設定されているなどカスタマイズされているので注意。

Advanced roadmap - Advanced roadmap plugin for Redmine - Redmine OCIO y TECnologi'a

【設定画面】
Redmine_setteings

【Scrum統計画面】
Redmine_scrum_statistics

【ロードマップ画面】
Redmine_roadmap

【バックログ画面】
Redmine_master_backlog

【タスクボード画面】
Redmine_task_boards

【バーンダウンチャート画面(マスターバックログ)】
Redmine_burndown_chart2

【バーンダウンチャート画面(リリースタブ)】
Redmine_burndown_chart

【チケット一覧画面】
Redmine_sprint_tasks

【ストーリーのチケット画面】
Redmine_story

【使用した感想】
使い方は多分こんな感じ。

Backlogsプラグイン設定画面で、ストーリーカードとタスクカードのトラッカーを定める。

プロジェクト設定画面で、
モジュール欄でBacklogsを選択。
バージョン欄でリリース予定のスプリントをいくつか登録する。

Release欄でリリース予定のスプリントのストーリーポイント、開始日・終了日を設定すると、バーンダウンチャートを生成してくれる。

Backlogs画面で、作成したスプリントに対して、ストーリーとタスクのチケットを新規作成する。

選択したスプリントのTaskBoards画面で、ストーリーとタスクのチケットを進捗管理する。

バックログ、タスクボード、バーンダウンチャート、ストーリーポイント、ベロシティなどの概念を実装してくれているので、Scrumをどのように運用すればいいのか、実験するのに丁度良い気がする。
チケットの親子関係をストーリーカードとタスクカードに当てはめて、Redmineバージョンをスプリントに見立てる考え方なので、Redmine本来の運用スタイルに合致していると思う。

但し、TaskBoards画面にある女の子のアイコンはオタクっぽいので気がひける(笑)

【追記】
@yusuke-kokuboさんから、タスクボード画面に女の子画像を出さないパッチを頂いたのでアップしておく。
これなら堂々と使えそう。

Twitter / @yusuke-kokubo: @akipii すみません。 うちの会社のものが勝手にpull requestしたものが取り込まれてしまったようです。 masterではとりあえず表示されないようになってるので、ここからダウンロードしなおしてください。 http://bit.ly/dXEnSw

Redmine_task_boards_2

【更に追記】
@kaorun55さんがja.ymlを日本語化してくれている。

RedmineのBacklogsプラグインを使ってみた - かおるんダイアリー

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

2011/04/18

Scrumの概念イメージ

AgileJapan2011の発表資料を追っていたら、Scrumの概念イメージの素晴らしい資料があったのでリンクしておく。
とても分かりやすい。

【元ネタ】
Twitter / @Tomoharu Nagasawa: ブログ書きま スクラムの拡張イメージと #QConTokyo, #aj11 ~ Be whats next: こんにちは。先週は、私を含む、IT エンジニアにとって非常によい流れをつくる契機... http://bit.ly/hnKhqJ

スクラムの拡張イメージと #QConTokyo, #aj11 ~ Be what’s next:ITとビジネスの可能性:ITmedia オルタナティブ・ブログ

スクラム Visual Studio 2010

Scrumのサイクル「プロジェクトの準備→プロジェクトの計画→スプリントの計画→スプリントの実行→プロジェクトの追跡」は、PMBOKのサイクル「立上げ→計画→実行→監視→終結」に似ている印象を持った。
Scrumでは、計画と実行、評価(追跡)というプロセスがループするようにうまくプロセス設計されている。

PMBOKでは計画プロセスが重視されるが、Scrumでも製品計画(リリース計画)・スプリント計画で計画プロセスが区別されて重視されている。
PMBOKのスコープ管理は、Scrumのスプリント計画やチームの速度(Velocity)によるスコープ管理に似ている。
当然、PMBOKとScrumは背景が全く異なるけれども、プロジェクトマネジメントという観点ではScrumはよく考えられていると思う。

AgileJapan東京では、SalesforceのScrum+XPによる事例ADMもあった。
RyuzeeさんのBlogにある資料がとても分かりやすいのでリンクしておく。
ADMはAdaptive Development Methodologyの略称らしい。

[Agile]Salesforceにおけるアジャイル開発 | Ryuzee.com

別の資料も上記と同じみたい。

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

2011/04/17

Conwayの法則~組織はアーキテクチャにしたがう

デブサミ2011で鈴木雄介さんの講演を聞いた後でTwitterを何気なく見ていたら、Conwayの法則を見つけたのでメモ。
AgileJapan2011北海道の資料でも、Conwayの法則が紹介されてますね。
ラフなメモ書き。

【元ネタ】
AgileJapan2011北海道サテライトに参加してきました - tricknotesのぼうけんのしょ

生成的開発プロセス・パターンランゲージ - lamuuの勿忘草日記

生成的開発プロセス・パターンランゲージ

Conwayの法則 
* Conwayの法則 
組織を製品のアーキテクチャに当てはまるようにしなさい。このパターンランゲージにおいて、ここでは、組織がアーキテクチャに影響をおよぼすべきであるというよりも、アーキテクチャが組織に影響をおよぼすべきであるといえるだろう。

コンウェイの法則 - Strategic Choice
(引用開始)
「ソフトウェアの構造(アーキテクチャ)」は、それを作った「組織」を反映したものになります。たとえば、コンパイラを4チーム編成で作れば、4パスのコンパイラが作成されます。
(中略)
「組織」と「ソフトウェアの構造(アーキテクチャ)」の相互依存関係も重要ですが、「組織」と「プロセス」の相性も重要です。
書籍「リーンソフトウェア開発と組織改革」では、役割で分割されたチーム、すなわちテクノロジラインで編成したチーム「組織」で、アジャイル「プロセス」を実践し、苦労している企業の例が紹介されています。
 データベースチーム、メインフレームチーム、Webサーバーチーム、テストチームのような具合にチーム分けを行います。このようにテクノロジ(あるいは役割)で分けたチームは、他のチームの作業に依存し、小さなフィーチャーセットですら、大量のコミュニケーションと協力が必要になってしまいます。コミュニケーションの手間がますます時間を食い、誤りの可能性もオーバーヘッドコストも増えていきます。こうなると、インクリメンタルに小さなリリースを重ねることは現実的でなくなってしまいます。
(引用終了)

鈍重な開発チームは鈍重なシステムを作る? - @IT情報マネジメント
(引用開始)
Melvin Conwayが1960年代後半に定義したConwayの法則は、「どのソフトウェアも、それを作り出した団体の組織構造を反映している」としている。このようなことが起きるのは、人は自分たちがどのように組織化されているかを反映した形で作業をするためだ。つまり、分散したグループは分散アーキテクチャのシステムを作り出す可能性が高い。プロジェクトチームの組織構造にある長所や短所は、いずれも彼らに生み出されるシステムに必然的に反映されることになり、それは効率的なITアーキテクチャが目標ならITの組織構造が効率的でなくてはならないことを暗示している。
(引用終了)

組織構造がアーキテクチャ、開発スタイルに影響する。
組織構造が開発の効率性に制約をかける。

では、WF型開発やAgile開発の組織はどんな影響を与えるのか?
さかばさんのBlogを読むと、答えが見えてくる。

[#TiDD] プロセスプログラミング2 - ウォーターフォールとアジャイル -: ソフトウェアさかば

WF型開発は構造化設計、Agile開発はオブジェクト指向設計に影響を受けているのが読んで取れる。
ソフトウェアプロダクトライン、派生開発も同様に、アーキテクチャと組織構造が密接に関係している。

Agileに開発したいなら、Agileなアーキテクチャ、Agileな組織構造が必要。
もう少し調べてみる。

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

影舞の感想~チケット駆動開発の起源を探る #tidd

今頃になって影舞をインストールしてみたのでメモ。

【元ネタ】
影舞への手引き

Windows で 影舞 > 導入方法 @みっちーわーるど

影舞を使ったサービスデスク (ITIL)

【環境】
Windows+Ruby+XAMPP

【インストール】
kagemai-0.8.4.tar.gz を解凍して
C:\xampplite\htdocs\kagemai
へ配置

httpd.conf へ下記を追加する。
<Directory "C:/xampplite/htdocs/kagemai/html">
Options ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>

影舞内の「html\admin.cgi」「html\guest.cgi」「html\user.cgi」の3つのファイルをテキストエディターで開き、先頭行の #!/usr/bin/ ruby を
#!C:/ruby-1.8/bin/ruby
へ修正する

Apacheを起動してアクセスする
http://localhost/kagemai/html/admin.cgi

全体管理画面で、色々設定する。
Unixの方がメール送信などが簡単に設定できるようだ。

【感想】
影舞は日本発のBTS。
設定の手軽さやメール送信機能、簡単なバグレポート機能があるので、小規模なプロジェクトの障害管理に使える。
僕は使ったことが無いので知らないが、知人が影舞を2005年頃に使っていて、更に影舞からMantisへBTSを移行してプロジェクト管理が随分楽になったという話は聞いた。
日本では結構使われていたのではないだろうか?

影舞を使ったサービスデスク (ITIL)などの資料を読むと、従来からBTSを問合せ管理に使おうという試みがなされていたりするのが分かる。
BTSが持つワークフロー機能、レポート機能を使って、障害管理票を問合せや課題へ拡張する手法(Issue Tracking)は同時に芽生えていたのだ。

チケット駆動開発の歴史を今になって振り返ると、TracがITSとして初めて成功したシステムであることが分かる。
Tracの画期的な特徴は、障害管理票をチケットという概念に洗練させたこと(Issue Tracking)とSubversionという構成管理ツールと連携したこと(No Ticket, No Commit)の2点にある。
それによって、ソフトウェア開発のタスク管理とソース管理が連携する機能が発見されて、ロードマップやタイムライン、多種類のレポート出力などの機能が生まれた。

そして、後発のRedmineがTracの良い点を取り込んで発展していった中で、世界中の開発者がアジャイル開発のプロジェクト管理に応用できることに気づいて、チケット駆動開発が生まれたと思っている。

この辺りもきちんとまとめてみたい。

|

2011/04/15

AgileJapan2011Osakaの感想~Agileのコンテキストが拡散している #aj11osaka #aj11

今日のAgileJapan2011Osakaの感想を書く。

【元ネタ】
AgileJapan2011Osaka

Twitter / 検索 - #aj11

【1】2011年現在、以前と違って「アジャイル」という言葉のコンテキスト(前提条件)は聴衆が既に知って経験もしている事実をよしうみさん、えと~さんと話していて、ハッと気づいた。
だから、「XPとは」「アジャイル開発とは」という初心者向けの説明をするセッションが無かった。
XPが日本に登場して10年経つと思うが、アジャイルのコンテキストは普及したのかなと思う。

その事実を痛感したのは、川端さんの講演を聞いてからだ。
一つは、JavaのプロジェクトではXPを説明する作業が最初にあるが、Rubyのプロジェクトではアジャイル開発の文化が既に当たり前であったということ。
だから、アジャイル開発が楽しかった、と言っていたのが印象的だった。

最近のプログラミング技術の動向を見ると、Javaは既に停滞しており、Rubyでは次々に技術革新が起きている印象を持っている。
実際、JavaのWebフレームワークはStrutsやSeasarの出現以来、殆ど進化していない。
それに対して、RubyはRailsはもちろん、自動テスト技術のcucumberなど次々に新しいフレームワークが出てきて、プログラミング技術の生産性を高める方向へどんどん進化している。
以前と違って、RubyとRailsさえマスターすれば、簡単にWebシステムを作れて、ソフトウェアで社会に対して影響力を発揮することが可能になっている。

もう一つは、東大の教養課程でRubyが第一プログラミング言語に選択されているということ。
実際、ネットで調べてみると、確かにそうみたい。
Rubyという生産性の高いプログラミング言語に慣れるという意味では、とても良いことだと思う。
そこから自然にアジャイル開発の習慣に慣れる可能性があるから。

Twitter / @Koichi Nakamura: 東大の教養課程でRubyを使っているのも批判とか結構あるみたいだけど、自分は教育用言語としてはすごく適切だと思う。あれはプログラミング技術の習得が目的ではなくて、情報を計算機でどう取り扱うかを学ぶ事が目的だから。

東京大学教養課程の第一プログラミング言語がRubyに - sumiiの日記

増原英彦『情報科学入門 Rubyを使って学ぶ』|無気力東大院生の不労生活

【2】AgileJapanではスーツ姿の人達が多かったので、その理由をスタッフや講演者に聞いてみたら、上司や友人を連れてくるためにスーツになっているのでしょう、という話を聞いた。
実際、AgileJapanでは、アジャイルという言葉・コンテキストが、プログラマ向けだけでなく、マネージャ向け、経営者向けでも通用していた。

その理由を考えると、日本のアジャイルの第1人者である平鍋さんの立ち位置の変遷と被っている気がする。
平鍋さんは10年前にXP行脚というイベントを日本各地で行い、プログラマ向けにXPを紹介してアジャイル開発を普及させようとした。
初期のアジャイルコミュニティのメンバー(特に日本XPユーザグループ)は、XPに影響を受けている人達が多いが、その発端はここにあると思う。

そして、2005年頃からプロジェクトファシリテーション(PF)という概念を提唱して、マネージャ向けにアジャイル精神をベースとしたチームビルディングの手法を普及させようとした。
PFP関西のようなコミュニティのメンバーは、平鍋さんが提唱したプロジェクトファシリテーションに影響を受けて行動をおこした人達が多いはずだ。

更に昨今は、リーンソフトウェア開発という概念を提唱して、経営者向けにトヨタ生産方式(TPS)をベースとしたアジャイルっぽい概念をITビジネスに注入して普及させようとしている。
経営者にアジャイルやファシリテーションを話してもあまり興味を引いてくれないが、トヨタ生産方式の話は経営者なら誰でも知っており、その有効性を一番気にしているので、マーケットとしてドンピシャりと当たっていると思う。

つまり、アジャイル開発というコンテキストをプログラマ向けを発端として、マネージャ向け、経営者向けへ拡張した方向を作ったのは平鍋さんだと思うし、そういう歴史を辿ると、平鍋さんの凄さを改めて痛感する。

でも、僕のアジャイル開発の立ち位置はやっぱりXPにあるのかなと思っている。
ScrumもPFもリーンからも重要な概念を教わったけれど、僕の立ち位置はまだプログラマであり、プログラミングを中心とする技術を追いかけるのが好きだ。
チケット駆動開発も現場リーダーの観点で概念をまとめようとしたし、今後も技術面を深く掘り下げたいと思っている。

AgileJapan2011Osakaで改めて自分の立ち位置を考えさせられた1日だった。

【追記】
下記の記事を読むと、AgileJapan2011で講演された牛尾さんも似たような感慨を持っているように思えた。
記事をリンクしておく。

アジャイルコミュニティのエネルギーを作り出した人々 ~ AgileJapan2011にて ~ - メソッド屋の日記

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

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

オープンソースのレコメンドエンジンMahoutについてリンクをメモ。

【元ネタ】
Apache Mahout の紹介

InfoQ: Mahout 0.3: オープンソースの機械学習プロジェクト

mahout/レコメンドシステムの作り方 - PukiWiki

レコメンドエンジンは、Amazonのオススメ商品機能が有名だろう。
AmazonがWeb業界でこれだけの影響力がある理由の一つは、レコメンドエンジンを最初にビジネスとして成功させたことがあるかもしれない。

レコメンドエンジンのアルゴリズムは協調フィルタリングが良く使われているだろうと思う。
OSSではApache Mahoutが有名らしい。

Mahoutの詳細は知らないけど、Hadoopと組み合わせて、レコメンドエンジンを高速化することは可能だ。
レコメンドエンジンは日々の大量のトランザクションデータをデータマイニングして、意味ある情報を取り出して、ユーザに価値ある情報を提供して、商品の購買を誘う。

データマイニングは以前はDWHのように特別なDB設計と高価なシステムが必要だったけれど、Hadoopで高速な分散並列処理を実装しやすくなったおかげで、データマイニングを普通のプログラマが実装できるようになってきている。
データマイニングはうまくビジネスに当てはめれば、プログラマにとって協力な武器になる。
マーケティングの知識がなくても、Hadoop+データマイニングで、今までに無かった新たな因果関係を見つけ出すことも可能。
郊外の業務スーパーでは紙おむつとビールが良く売れた、という都市伝説は、まさにデータマイニングなしでは分からなかった因果関係だ。

Web2.0の本質はデータマイニングにあり: プログラマの思索

データを収集して分析するというコンピュータの利用目的は未だに変わらないけれど、その実装方法は以前よりも高度にかつ簡単になりつつある。
その背景のキーワードは分散並列処理。
色々調べてみる。

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

抱腹絶倒「スパルタ達によるプログラマ職業紹介」 #aj11 #aj11osaka

今日のAgileJapan2011Osakaに行ってきました。
大阪ならではの事例やワークショップもあり面白かったです。

詳細な感想は後ほど書くことにして、懇親会で流れていたBGMがあまりにも面白かったのでリンクしておく。

Twitter / @えと~: #aj11 #aj11osaka ITスパルタ ワロスw

悲しいけど笑えた(笑)
僕も似たような状況に陥った時、思わず不満を上司にぶつけたら、「IT業界とはこんなもんなのだ!」と言われたのを思い出す。
デスマをいかに減らせるかどうか、がIT業界の健康度を表している気がする。

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

2011/04/14

【告知】4/29にAgile Charity Event in Osakaが開催されます #xpjugkansai

4/29にAgile Charity Event in Osakaが開催されます。
本イベントでは皆様の募金やチャリティグッズ代などを東日本震災の義援金とさせていただきます。

【リンク】
Technologic Arts Incorporated | アジャイルチャリティーイベントを開催します

【開催概要】
開催日 2011年4月29日(金/祝)
開催時間 11:00から16:30
会場 大阪市立会館 鶴見区民センター(住所:大阪市鶴見区横堤5-3-15)
地下鉄 長堀鶴見緑地線「横堤駅」3番出口より徒歩1分
定員 150名
参加費 無料/事前登録制

【プログラム】
10:30 受付開始
11:00~11:15 オープニング
11:15~12:00 リモートペアプロ by Kent Beck(現在調整中)
12:00~13:00 休憩
13:00~14:45 TWセッション by ThoughtWorks(オーストラリアから生中継)
14:45~15:00 休憩
15:00~16:15 パネルディスカッション by 日本XPユーザーグループ関西
16:15~16:30 クロージング

主催 ThoughtWorks
企画 株式会社テクノロジックアート
協力  日本XPユーザーグループ関西

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

2011/04/12

構成管理、変更管理、プロジェクト管理の密接な関係

2005年に書かれた@ITの記事を読んで、この記事に書かれている内容は全てRedmine+チケット駆動開発で実現できると直感したのでメモ。

【元ネタ】
@IT:意外と知らない構成管理の正体(1)第1回 ファイルバージョンの管理だけで十分ですか?

@IT:意外と知らない構成管理の正体(2)第2回 プロジェクトの構成要素を探す手順

@IT:意外と知らない構成管理の正体(3)変更管理、その正体と対策

@IT:意外と知らない構成管理の正体(4)構成管理とプロジェクトマネジメントの関係

構成管理は誰のためのものなのか?: プログラマの思索

(引用開始)
ただ、プロジェクトは、最後にきちんと納品さえすればよいというものではないのです。いつでも、指定された時点におけるプロジェクトの結果、状態を把握できなければいけないということなのです。そこには、タスクの依存関係、成果物の依存関係、それぞれに要したコスト、さらには検出された障害情報などが含まれていなければなりません。また、どのような経緯でそれらの成果物が出来上がったのかを示すことは、あなたがプロジェクトオーナーの立場なのか、開発者の立場なのかを問わず、あなたの身を守ることにもなります。
(中略)
このように考えると、ソースコードのバージョン管理だけではとてもこのような要望には応えられません。また、これらすべてを管理台帳のようなものとして作成し、人手で管理しなければならないとしたらどうでしょうか? 大変な労力を要しながら、ミスも続発するという事態になっても何ら不思議ではありません。
(引用終了)

成果物の管理は単なるバージョン管理だけではない。
成果物の作業履歴を残すだけでなく、変更管理プロセスそのものも必要だし、工数やコスト、障害一覧の情報も必要だ。
チケット駆動開発なら、成果物の修正履歴はSCMリポジトリ、成果物の作業履歴はITSチケットで使い分けて、更に相互リンクすることで、変更理由を追跡できるインフラもある。

(引用開始)
それは、構成管理を導入してもこんな状況は解決できないというものです。もちろん、構成管理では解決できないITプロジェクトの問題は山ほどあるわけですが、「構成管理を導入すれば、これは解決できる」という誤解を抱かれやすいケースがあるのです。それは、私が“インクリメンタルのドツボ”と呼んでいるものです。
(中略)
さて、1カ月を過ぎたころ、あなたはどのような状況に置かれているでしょうか? 予定では2回目のインクリメントに入っているはずです。あなたは、確かに2回目のインクリメントの開発をしているようです。しかし浮かない顔をしています。初めは調子が良かったのに、この1週間、深夜残業が続いているようです。なぜでしょう? お分かりですね? そうです、1回目のインクリメントのデバッグと、2回目のインクリメントの追加機能開発に追われているのです。しかも、構成管理プロセスに従って、1回目のインクリメントのコードと、2回目のインクリメントのコードは別管理されています。あなたは、修正と追加のコードをそれぞれ別のファイルに行い、2回目のインクリメントのデイリービルド用にマージ作業まで行っています……。
 つまり、プロジェクト計画に致命的な問題があるわけですが、構成管理の仕組みがあれば、別々のリビジョンとして並行開発のコード管理ができるので大丈夫(?)という、とんでもない問題点のすり替えが平気(かどうか分かりませんが)でまかり通っていたりするのです。
 確かに、あるソフトウェア製品の奇数バージョンと偶数バージョンを並行開発するとか、簡易版とプロフェッショナル版を並行開発するとか、そのような場合には、構成管理をきちんと行うことが重要ですし、そうすることによって混乱を防ぎながら短期間で次々とリリースすることにもなるでしょう。この場合には、もちろん、担当者がそれぞれで別であれば、という条件付きなわけですが。
(引用終了)

「インクリメンタルのドツボ」とは並行開発の罠のことだ。
繰り返し開発は実は並行開発である事実を知らずに実践しても、すぐに破綻する。
その考察については以前たくさん書いた。

裏プロセスは並行プロセス: プログラマの思索

アジャイル開発が並行開発になる理由: プログラマの思索

TiDDを実践して気付いたことpart7~繰り返し開発を制する者はSW開発を制す: プログラマの思索

TiDDを実践して気付いたことpart3~繰り返し開発の戦略: プログラマの思索

並行開発の問題は、ソフトウェアプロダクトラインや派生開発にもつながる。
繰り返し開発をスムーズに運用するには、メインラインモデルという構成管理が最低限必要であり、最終的にはGitやMercurialのような分散バージョン管理でブランチ管理しなければ解決できないだろうと思っている。

(引用開始)
これらを行ううえで、重要なものがあります。それは、ベースラインです。上記の3つの活動は、結局のところ構成要素に対する変更を管理、監視するというものです。そして、この活動を開始するきっかけが、ベースラインとなります。ベースラインとは、構成要素全体に対する、ある時点でのステークホルダー全員の合意といえます。変更管理、ステータス管理、監査とは、このベースラインに対する包括的な変更管理にほかなりません。ベースラインのない状態での変更管理はないということです。
(中略)
実際には、変更管理手順が、合意を確立する手順として効果的なものであるために、最初のベースラインを作成する前の段階から、変更管理手順を適用するケースも多く見かけます。しかし、変更管理の本質とは、ある合意に対する変更を管理し、新しい合意を適切に確立するための手順であるということを常に認識しておくことは重要です。明確な目的の達成のために管理する、ということが重要なわけですが、得てして管理すること自体が目的だという錯覚に陥りがちだからです。正しい目的のない状態での管理、ルールは、非常に簡単に崩壊してしまうのです。
(引用終了)

構成管理のベースラインは、SCMのタグ(tag)であり、リリース済バージョンに相当する。
つまり、ベースラインはユーザと開発チームの合意というマネジメント上の意思決定であるだけでなく、リリース物件に含まれる成果物のスナップショットでもあり、アジャイル開発のイテレーション(スプリント)にも対応付けられる。
ユーザに価値あるソフトウェアを届けるタイミングで、SCMリポジトリにタグが振られて、SCMリポジトリからビルドされたソフトウェアやドキュメント一式が作られる。
そのタイミングはイテレーションが終了した直後であり、リリース直後にもなる。
考察した詳細は既に書いた。

チケット駆動開発の本質はバージョン・ファースト: プログラマの思索

イテレーションはSW開発で何故重要なのか?: プログラマの思索

つまり、プロジェクトライフサイクルの管理とベースラインの管理、リリース管理は同値。
Redmine・SVN・HudsonというITS・SCM・CIツールとの関連については下記に書いた。
この関連を意識して運用すれば、成果物の追跡だけでなく要件から作業、成果物までの修正を追跡できるインフラが自然に整う。

RedmineとSCMの機能の関連表~BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索

Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd: プログラマの思索

(引用開始)
システム開発における変更管理とは、
変更要求を一意に識別し、
変更要求に対応することによる影響を正しく把握したうえで対応計画を立て、
対応作業の実施およびその結果を確認すること
によって、常にすべての成果物間の整合性を確保・維持すること、です。
 CMMIの構成管理に該当する説明には、詳細な記述がありますが、日常業務の範囲であれば、“最終的に”上記の認識で十分です。“最終的に”とは、「変更要求にはどんなものがあり、影響を把握するとはどういうことで、成果物間の整合性を確保・維持するためにはどうすればよいのか」といったことを理解したうえで、上記の認識を持てばよいという意味です。「なあんだ」と思うかもしれませんが、大事なのは、全体の構造を理解したうえで、上位概念を意識に留めておくということです。そうすれば、いつでも細部を思い出すことができます。
(引用終了)

上記の文章はITILの変更管理を連想させる。
変更要求はRFC、変更要求に対する意思決定は変更管理委員会(CAB)に相当する。
そして、ITILの変更管理で計画された対応内容は、ITILのリリース管理で実施されて評価される。
その場合、変更対象の成果物は構成アイテム(CI)として構成管理DB(CMDB)で修正内容も含めて一元管理される。

ITILとチケット駆動開発の密接な関係については下記に既に書いた。

ITILのプロセス関連図: プログラマの思索

TiDDにITILの概念を持ち込む: プログラマの思索

Redmine for ITIL: プログラマの思索

ITILの内容はRedmineやTracのようなITS上で管理しやすい。
その理由は、成果物に対する変更履歴がITSのチケットで一元管理されるからだ。

頻繁なVerUpがソフトウェア開発の本質: プログラマの思索

(引用開始)
このタスクの進捗率は、どのプロジェクトでも扱いに困っている代表選手です。各担当者に進捗率として聞くと、80%くらいまでは一気に進捗し、その後は急に進捗しなくなるということは皆さんご存じのとおりです。そこで、有効な手段の1つとして、各成果物のステータスを細かく定義し、それぞれのステータスごとに進捗率を割り当てておくことで、進捗を把握するというものです。各担当者は、成果物を構成管理システムにチェックインするときに、ステータスを登録するだけですから、こちらも余計な負担を強いることはありません。
(中略)
さて、ここまで書いておきながらこのようなことをいうのもどうかと思うのですが、私は、進捗率を細かく把握することの意義には疑問を持っています。というのは、経験的に、細かく進捗を把握した場合と、そうしなかった場合でのプロジェクトの目的達成における違いがほとんど感じられないからです。
 実際にはどのようなレベルで進捗を見ることが多いかというと、各成果物が完成したか、完成していないか、つまり、0%か100%のどちらかのみです。お気付きの方も多いと思いますが、SCRUMに似たやり方です。また、これもSCRUMと同様ですが、日々、各担当者に「後何日で成果物が完了するか?」を作業時間とともに教えてもらいます。これは、日々作業を行う中で担当者の作業見積もりの精度も上がるため、スケジュール調整の判断に非常に有効なデータとなります。
(引用終了)

駄目な進捗管理では、90%まで進捗が進んだのにそこから完了までとても時間がかかる場合がある。
その理由は、進捗の定義があいまいであり、作業の終了基準があいまいだからだ。
タスクの進捗率は、アジャイル開発なら極めて明確だ。
ToDo、Doing、Doneの三つのステータスだけであり、0%か100%のどちらかだ。
Redmineならステータスごとに進捗率を指定できるので、ぶれることもない。

小技(0.9): チケットのステータスで進捗率を更新する | Redmine.JP Blog

(引用開始)
構成管理の仕組みを工夫して使うことによって、テスト結果の集計や、障害情報のステータス追跡、成果物への変更手続き、変更履歴の確認のほとんどを自動化することが可能になります。
(引用終了)

構成管理の枠組みは最終的にはプロジェクト管理サーバーの概念につながる。
つまり、ソフトウェア開発で発生する作業履歴は全てITSに蓄積されて、そこから進捗や品質、コストなどのメトリクスをいつでも出力できる。
更に、ITSを中核としたプロジェクト管理サーバーは、プロジェクトマネージャがプロジェクト運営する時の意思決定支援のツールになりうる。
そのアイデアは下記に書いた。

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

プロジェクト管理サーバーのメトリクスは教科書みたいだ: プログラマの思索

チケット駆動開発が進むべき道 part3~BTSを中心に構成管理・テスト管理を含めたプロジェクト管理の枠組みを作る #tidd: プログラマの思索

構成管理を単なるバージョン管理と考えるのではなく、プロジェクトを丸ごと組織の資産として管理する。
仕組みとしてはITS・SCM・CIのインフラがプロセス資産になる。
つまり、開発チームは今までの開発や運用で得た経験をノウハウとして蓄積すれば、それは開発チームの資産になり、成長していくきっかけになる。
それがまさにプロセス改善になる。
そのアイデアは下記に書いた。

チケット駆動開発が進むべき道part2~プロジェクト管理サーバーは開発チームの資産: プログラマの思索

上記の記事は構成管理、変更管理、プロジェクト管理の密接な関係を抽象的に書いているが、チケット駆動開発ならその内容を全て具体的に実現できる。
その内容をもっときちんとまとめてみたい。

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

複数のRuby環境構築はrvmかpik

Ruby1.8.6と並列に、Ruby1.9やJRubyを使いたいと思う時がある。
複数のRuby環境構築の方法が分かったのでメモ。

【元ネタ】
pikで簡単、複数のRuby環境構築! ? 梨木を読む

Ruby/Windows7で1.8と1.9環境を同居させる - 俺の基地

RVMで複数のRubyを使いこなす - Capsule

RVMで複数のRubyを管理

Rubyの複数バージョンを共存させるgem。rvmとpikについて - holyppの日記

事の発端は、RedmineのXLS export pluginを入れたら、意味不明なエラーが出たこと。
gem install spreadsheet
も設定したのに何故だろうと思ったら、Ruby1.8.6からv1.8.7へアップグレードすると解決した。

Redmine - XLS export plugin - Redmine

とはいえ、Ruby本体を逐一アップグレードするのは面倒。
Unixの場合、rvmを使うと、複数のRuby環境を簡単に入れ替えれる。
Windowsなら、pikを使うといいらしい。

gem install pik
pik_install "C:\ruby\pik"

C:\ruby\pik\pik -v
** Adding: 187: ruby 1.8.7 (2010-08-16 patchlevel 302) [i386-mswin32]
Located at: C:\ruby\bin
pik 0.2.8

pik add でRuby1.9やJRubyを登録することも可能。
pik sw 191
pik sw jruby
pik sw 187

pik list -r でインストールできるRuby一覧をリストアップできる。
JRuby以外にも.NETで動くIronRubyもあって面白い。

DevKit:
3.4.5r3: http://rubyforge.org/frs/download.php/66888/devkit-3.4.5r3-20091110.7z
IronRuby:
0.3.0: http://rubyforge.org/frs/download.php/53552/ironruby-0.3.0.zip
0.5.0: http://rubyforge.org/frs/download.php/57126/ironruby-0.5.0.zip
0.6.0: http://rubyforge.org/frs/download.php/59717/ironruby-0.6.0.zip
0.9.0: http://rubyforge.org/frs/download.php/61382/ironruby-0.9.0.zip
0.9.1: http://rubyforge.org/frs/download.php/64504/ironruby-0.9.1.zip
0.9.2: http://rubyforge.org/frs/download.php/66606/ironruby-0.9.2.zip
"1.0": http://rubyforge.org/frs/download.php/70179/ironruby-1.0.zip
1.0-rc1: http://rubyforge.org/frs/download.php/67955/ironruby-1.0-rc1.zip
1.0-rc2: http://rubyforge.org/frs/download.php/69180/ironruby-1.0-rc2.zip
1.0.0rc: http://rubyforge.org/frs/download.php/69853/ironruby-1.0.0rc.zip
1.0rc3: http://rubyforge.org/frs/download.php/69665/ironruby-1.0rc3.zip
1.0v4: http://rubyforge.org/frs/download.php/70181/ironruby-1.0v4.zip
JRuby:
1.5.6: http://jruby.org.s3.amazonaws.com/downloads/1.5.6/jruby-bin-1.5.6.zip
1.6.0: http://jruby.org.s3.amazonaws.com/downloads/1.6.0/jruby-bin-1.6.0.zip
Ruby:
1.8.7-p302: http://rubyforge.org/frs/download.php/72087/ruby-1.8.7-p302-i386-mingw32.7z
1.8.7-p330: http://rubyforge.org/frs/download.php/73720/ruby-1.8.7-p330-i386-mingw32.7z
1.8.7-p334: http://rubyforge.org/frs/download.php/74296/ruby-1.8.7-p334-i386-mingw32.7z
1.9.1-p429: http://rubyforge.org/frs/download.php/71496/ruby-1.9.1-p429-i386-mingw32.7z
1.9.1-p430: http://rubyforge.org/frs/download.php/72076/ruby-1.9.1-p430-i386-mingw32.7z
1.9.2-p0: http://rubyforge.org/frs/download.php/72160/ruby-1.9.2-p0-i386-mingw32.7z
1.9.2-p136: http://rubyforge.org/frs/download.php/73723/ruby-1.9.2-p136-i386-mingw32.7z
1.9.2-p180: http://rubyforge.org/frs/download.php/74299/ruby-1.9.2-p180-i386-mingw32.7z
1.9.2-rc1: http://rubyforge.org/frs/download.php/71498/ruby-1.9.2-rc1-i386-mingw32.7z
1.9.2dev-preview3-1: http://rubyforge.org/frs/download.php/71175/ruby-1.9.2dev-preview3-i386-mingw32-1.7z

色々試してみる。

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

2011/04/11

アジャイル開発の契約スタイルに関するIPAの報告書

アジャイル開発の契約スタイルに関するIPAの報告書が公開されていたのでメモ。

【元ネタ】
Twitter / @Kenji Hiranabe: IPAのアジャイル推進活動の報告書( http://bit.ly/eRI6Om )と、島根県のRubyビジネスモデル研究発表( http://t.co/basmDdc )は、リンクしています。

情報処理推進機構:ソフトウェアエンジニアリング アジャイル型開発を推進するための活動成果を公開

・非ウォーターフォール型開発WG活動報告書(概要資料) (PDF形式)[858KB]

・非ウォーターフォール型開発WG活動報告書 (PDF形式)[5.05MB]

IPAが昨今のアジャイル開発ブームをどう見ているか、を知る上でとても良い資料。
羽生田さん、平鍋さん、川端さんの名前も上がっていて、アジャイル開発の契約というど真ん中のテーマに対して報告書を書き上げている。
具体的には下記10種類の契約のうち、アジャイル開発に適しているケースはどれか、詳細に記述している。
実際にアジャイル開発の契約をすると仮定して、契約書も添付しており、中身はとても良いと思う。

①スプリント契約(Sprint Contract)
②定額請負型(Fixed Price & Fixed Scope)
③実費精算契約(Time and Materials)
④固定仕様、シーリングありの準委任契約
(Time and Materials with Fixed Scope and Cost Ceiling )
⑤シーリングありの準委任契約
(Time and Materials with Variable Scope and Cost Ceiling)
⑥段階的開発契約(Phased Development)
⑦ボーナス/ペナルティ条項(Bonus/Penalty Clauses)
⑧固定利益(Fixed Profit)
⑨Money for Nothing, Changes for Free(早期中止、変更無料)
⑩ジョイントベンチャー(Joint Venture)

当然、スプリント契約などのようにスコープを変化させやすい契約の方がアジャイル開発に適している。
この話を読んで、PMBOKの調達管理(契約管理)の契約の種類を連想した。

【PMBOKの調達管理】
PMP 契約関連

ASCII.jp:第5回 契約を間違えば、プロジェクトはうまくいかない プロジェクトと契約の深い関係について学ぶ|公式ガイドブックだけでは不十分!? PMP資格試験対策

[ThinkIT] 第9回:調達管理(外注管理) (1/3)

調達マネジメント~契約管理|プロジェクトマネジメントの現場

PMBOKの契約管理では下記の種類があり、上から順に購入者側に有利(リスクが低い)に並んでいる。
当然、一括請負契約よりも実費償還契約の方がアジャイル開発に適している。

FFP:定額契約または一括請負契約
FP-EPA:インフレ率の変化などに応じて価格を調整することができる契約
FPIF:購入者は契約で決められた上限価格内で、実際にかかったコストを納入者に支払う契約。
CPAF:実費償還契約のうち、納入者にコストとフィーが支払われるが、フィーは購入者が主観的に決定する。
CPIF:実費償還契約のうち、見積りコストとかかったコストの差額がインセンティブとして支払われる。
CPFF:実費償還契約のうち、許容コストと固定額のフィーが支払われる。成績に関わらず固定額のフィーが支払われる。
CPPC:実費償還契約のうち、かかったコストのあるパーセンテージがフィーとして支払われる。

3ヶ月先の景気が見えない現在では、B2Cの業務システムやSaaS、パッケージ製品の開発ではスコープをビジネスの状況に合わせて変化できる方がリスクが少ない。
スコープを固定して数年かけて開発するスタイルは正直難しくなってきている現実はあると思う。

購入者(エンドユーザ)と納入者(SI)の間でバランスが釣り合う契約スタイルは何か、をもう一度探る必要がある。

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

2011/04/10

Hadoopのメモ

オライリーのHadoop本を買って読んでいる。
Web上でも良い記事が沢山あるようなのでリンクしておく。

【元ネタ】
NTTデータのHadoop報告書がすごかった - 科学と非科学の迷宮

高信頼クラウド実現用ソフトウェア開発(分散制御処理技術等に係るデータセンター高信頼化に向けた実証事業)(委託先:株式会社エヌ・ティ・ティ・データ) 報告書(PDF形式:9,606KB)

2010年まとめ:データと向き合った一年 - 科学と非科学の迷宮

Twitter / @Wataru Yukawa: これからは、学生アルバイトが Google あるいは Amazon 上の分散システムを駆使して大量のデータを操り、そこらの新卒社員が統計学やデータマイニング、機械学習を駆使して新たな視点を創りだす時代です。 http://bit.ly/eZFael

Twitter / @Wataru Yukawa: うーみゅ、結局のところ大規模データを解析して意味ある情報を引き出すには統計的知識を持っていなくてはダメで、その知識をもとにMap関数とReduce関数書くってことかな。そういう解析屋さんと基盤整えるインフラ屋さんはまた別なのかな。

基幹系バッチ処理をHadoopで高速化: プログラマの思索

Hadoopの本質は分散I/Oにあり~クラウド時代の非同期処理: プログラマの思索

第1回 分散処理を隠蔽し、大規模開発を可能に - Hadoop向け基幹バッチ分散処理ソフト「Asakusa」の全貌:ITpro

MapReduceのOSS版であるHadoopを大量データのデータマイングに使うのが最近のWeb技術の流れ。
でも、未だにレガシープログラムとして残っている大量のCobolプログラムをHadoopで置換できないだろうか?
業務バッチ処理をHadoopによる並列分散処理でより高速化できないのか?

昔から使っている、本番運用して安定しているから、と言う理由だけでCobolが今も生き続けている。
JavaはおろかRubyをやっていると、Cobolプログラムはあまりに古臭いコーディング規約やコーディング技術に縛られていて、書く気が失せる。
メインフレーム+CobolをUnix+Hadoopというオープン系システムで全て置き換えたい。

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

2011/04/09

クラウド時代のソフトウェア品質管理。それは健康管理と同じ

Googleのソフトウェア品質管理、テスト管理の記事があったのでリンクしておく。
感想をラフなメモ書き。

【元ネタ】
クラウド時代のソフトウェア品質管理。それは健康管理と同じだとグーグルのテスト担当者 - Publickey

開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか? - Publickey

グーグルが行っているビルドとテストの種類。続々、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか? - Publickey

グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか? - Publickey

(引用1)
かつてのようにソフトウェアは単に、開発してリリース、とはならない。ソフトウェアは成長するように構築されるものではなく、出荷されるものでもない…それは単に利用可能になるのだ、文字通り、スイッチを入れるように。

組込製品やパッケージ製品、公共インフラのような高信頼性を要求される製品の場合、WF型で開発してテストした後にリリースの儀式がある。
しかし、Web2.0のようなソフトウェア開発は永遠のベータ版と言われるように、頻繁なリリースは当たり前であり、リリースとは大げさなものではなくシステムが利用可能になるだけ、と主張している。

(引用2)
品質管理と品質保証について、父親の時代のソフトウェア、デミング博士のモデルでは、私たち(テスト担当)の役割は検査官(Inspector)にあたる。しかしそれとは対照的に、いまの私の仕事は内科医のようなものだ。
実際のところ、医療の例えはソフトウェアテストについて考えるとき興味深い類似点がある。内科医にとっての病院は、私たちにとってのデータセンターだ。つねに活動があり、多くのことが並行して起きている。
(中略)
さあ、テスターが診ることができるように、生体活動をモニタするための機器を取り付けよう。人間の患者のように、アプリケーションには脈拍があり、データは血液の流れのようにコードのあいだを流れていく。

品質管理や品質保証を内科医に例えているのが面白い。
ソフトウェアテストは健康診断みたいなもの。
その喩えから類推すれば、システムの品質を数多くのメトリクスで出力することが大切になるし、どのコンテキストでどんなメトリクスが有効なのか、という問題に発展するだろう。
特に最近はプログラミング言語がとても強力なので、コードの静的解析だけでなく、ソフトウェアの動的な構造やアーキテクチャを検証する技術をプログラムで自動化する方向へ発展しているように思える。

(引用3)
プロジェクトとレポートラインを分けることは1つのチャレンジだ。これまでは、テスターは(製品チームにとって)外部のリソースだった。製品チームにとってテストとはあまりに多くのリソースを必要とするため、それを適切に維持することができなかったのだ。
そう、グーグルではテストチームではなく、製品チームが自身で品質管理を負っている。各デベロッパは自身でテストすることを期待されている。テスターの仕事は、自動テストのインフラを確立することと、それによってデベロッパ自身がそれをプロセスの中で実行できるようにすること。テスターはデベロッパーがテストできるようにするのだ。

(引用4)
品質とはどのように実現するものなのか? という問いに対して、Whittaker氏は次のように書いています。
(中略)
この難問に対するシンプルな答えは、開発とテストを分けて考えるのを止めることだ。(略)品質を確保することとは、テストを行うことと同じではない。それは開発とテストをそれぞれの区別が付かなくなるまで融合させていくことなのだ。
そして、開発とテストの融合こそ、グーグルのゴールであると。
実際にコードを書いている人たち以上にうまくテストできる人がどこにいる? コードを書いている人以上にうまくバグを見つける人は? バグのないコードを書きたいと思っている人は? グーグルがわずかな専門テスターだけで済んでいる理由は、デベロッパーが品質に責任を持っているからなのだ。
品質とは開発の問題であって、テストの問題ではない。これを推し進めて、私たちは開発の中にテストを組み込んでいる。ハイパーインクリメンタルなプロセスを作り、だれかがバグを組み込んでしまったらそれ以前の状態にまでロールバックできるのだ。

品質保証部門やテスト部隊の必要性は分かっていても、その人達はコストセンターになりやすい。
テスト前の工程ではテスターは暇だからだ。
むしろ、プログラマが自身の成果物に関する品質の最終責任者であるし、テスト技術を持ってもいい。

(引用5)
ほかの多くの企業よりも少ない人数のテスターでグーグルはよい結果を得られているが、その鍵となっているのが、多くの機能をいちどに提供することをほとんどしない点にある。
もし実際の利用でバグが発見されたら、テスターはそれのためのテストを作り、それぞれのチャンネルのビルドに対して修正がちゃんと実装されたかどうか実行してみる。
(中略)
強調しておくと、グーグルではスクリプトによるもの、もしくは探索的なマニュアルテストのどちらも重要なものとして扱っている。
先進的なレコーディング技術によってマニュアルテストは自動テストへと変換され、ビルドの後再実行することでレグレッションを確認できるようになる。そしてこれが、マニュアルテスターがつねに新しい問題にフォーカスすることを可能にしてくれる。私たちはマニュアルテストの繰り返しとバグレポートの提出も自動化している。

ソフトウェアテストの技法で探索的テストは頻出されるが、実際の運用はとても難しい。
テストケースも関係なく、テスターの経験値を信頼して、自身で作業ログを取りながらバグを見つけて探っていく。
だから、新人のテスターやシステムの仕様が分からないテスターは探索的テストに向かない。
又、探索的テストはテスト工数を見積りにくいため、テストに際限がないリスクもある。
しかしながら、最近はPC上で操作ログを動画で記録したりできるので、バグの再現性を保証しやすくなってきた現実はある。

RedmineやTestLinkを使った経験から、テスト管理や品質管理の技法はかなり研究されているものの、タスク管理に比べると全くIT化されていないと思う。
ソフトウェアテストでは今でもExcelが幅を効かせていて、テスト結果の記録も手間がかかるし、集計するのは更に面倒だ。
だから、せっかくテストしても有効な知見が蓄積されないので、同じようなミスを何度も繰り返す時も多い。
アジャイル開発ではWF型開発よりも、はるかに高度な品質管理が要求されているのに、実際の現場ではIT化されてないためにボトルネックになっている時も多い。
色々試してみる。

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

2011/04/08

Redmineを使ってみよう~No Ticket, No Work #tidd

「Redmineを使ってみよう」資料が素晴らしいのでリンクしておく。

【元ネタ】
Redmineを使ってみよう on Scribd - hogehoge foobar Blog Style5

Redmineを使ってみよう

180ページもあるけど、プレゼンテーションzenのようなスライドなのでとても読みやすい。
Redmineの各機能をどうやって使っていくか、をプロジェクトの立ち上げ、遂行、評価、改善の順に説明してくれている。
「Iteration is version」「No Ticket, No Work」「No Ticket, No Commit」などのフレーズがとてもいい。
僕も使わせてもらおうと思う(笑)。

【追記】
Slideshareでも同じスライドが紹介されています。

Redmineを使ってみよう
View more presentations from mrgoofy33 .

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

2011/04/07

TiDD初心者によく聞かれる質問part2~チケットの粒度はどれくらいが妥当ですか?

チケット駆動開発を運用していると話すと、必ず「チケットの粒度はどれくらいが妥当ですか?」という質問が来る。
僕はまだその質問に完全な回答は持っていない。
その質問について考えていることをメモ。

【1】RedmineやTracで、全てのタスクからQAまでチケットを起票してから作業を始めるようにすると、チケットの粒度がかなり細かくなってしまう。
粒度が小さいと作業しやすいが、チケットの完了速度よりもチケットの登録速度が上回ってしまう時が多いため、どんどんタスクが増えていってしまうような感覚に陥ってしまう。
かと言って、チケットの工数が5人日以上になってしまうと、進捗がはかどっているのかどうかも分からない。

チケットの粒度が問題になる状況は、顧客へ進捗報告を出したい時だ。
RedmineやTracによるチケット管理はあくまでも開発者のためのタスク管理が目的だから、粒度が細かすぎて、顧客から見れば開発全体の進捗が分かりづらい。

実際のソフトウェア開発では、WBSで予想されたタスクよりもはるかに多いバグや仕様変更、突発的なタスクなどに忙殺される。
それらのタスクとWBSから作成されたタスクの粒度は元々合わない時が多い。

又、プロジェクトリーダーがプロジェクトの立ち上げでWBSを書きおこした時、チケットの粒度はどれくらいがいいのか悩む時がある。実際のWBSはユーザの観点から必要な作業を洗い出すから、実際にメンバーに作業を割り当てる場合、チケットよりも粒度が大きい。
粒度が大きすぎると、チケットをどんどんこなしていくリズムが生まれにくいので、チケット駆動開発の利点が薄れてしまう。

更に、バグを起票した時、バグのチケットはバグの原因や同類バグ調査結果など色んな項目を書く運用にしたいものだ。
何故なら、それらの入力項目は品質管理の観点で集計したいからだ。
つまり、集計された結果から、どの機能にバグが集中しているのか、どんな原因が多いのか、などの調査に使い、次の開発で改善する対策作りに当てたいからだ。
だが、チケットの入力項目が多いほど、チケットの登録がおっくうになり、1個のチケットを完了させるまでの期間が長くなってしまいがちだ。
そうすると、チケット駆動開発で自然に現れる開発のリズムが生まれにくくなり、進捗が停滞してしまう。

【2】チケットの粒度の問題は2つの原因があると思う。
一つは、ユーザやPMの観点と開発者の観点によるチケットの粒度の違い。
もう一つは、チケットの属性とチケット集計機能の関連。

前者は、フィーチャないしストーリーとタスクの違いだ。
この観点については既に下記に書いた。

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索
Redmineの最後の課題~チケットの親子関係: プログラマの思索

最終的には、ストーリーカードとタスクカードをRedmineのどの概念に当てはめるのか、という問題に落ち着く。
この問題は3つのプラグインの使い方によって解決方法は異なると考える。

【2-1】パーキングロットチャートを使う場合は、下記を使う。このプラグインは@daipresentsさんが作られており、とても使いやすい。

redmine_parking_lot_chart

redmine_parking_lot_chartを使う場合、
バージョン=フィーチャ、ストーリーカード
バージョン>タスクカード
と見なして、WBSからマッピングすればいい。
バージョンがサブシステム単位、大きな機能(フィーチャ)単位にリリースするならば管理しやすいだろうと思う。
@daipresentsさん作成のタスクボード、バーンダウンチャートと合わせて使うと有効だろう。

redmine_version_burndown_charts
redmine_task_board

【2-2】バックログを使う場合は、redmine_backlogsを使う。@yusuke_kokubo さんが使いこなしているプラグインであり、まさにScrumそのものの使い方だ。

relaxdiego/redmine_backlogs - GitHub

Redmine Backlogs :: Introduction

redmine_backlogsを使う場合、
バージョン=スプリント
親チケット=ストーリーカード
子チケット=タスクカード
と見なすので、Redmine本来の構造にとても近い。
おそらく、アジャイル開発本来の使い方だろうと思う。
プラグインの機能に若干癖があるが、使いこなせれば、Scrumのアイデアをそのまま取り入れて運用できるだろう。

【2-3】Advanced roadmapを使って、Redmineのデフォルト機能にはないマイルストーンを導入する方法もある。

Advanced roadmap - Advanced roadmap plugin for Redmine - Redmine OCIO y TECnologi'a

Advanced roadmapを使う場合、
マイルストーン>バージョン>タスクカード
マイルストーン=フィーチャ
バージョン=リリース単位
と見なせばいいだろう。
つまり、複数のバージョンが集まったら一つのフィーチャになる場合に使いやすい。
すなわち、複数回のリリースを経て一つのサブシステムが出来上がる場合、マイルストーンという階層を増やすと、より大きな観点で進捗度合いを簡単に表現できるように思う。

ただ、いずれにしてもRedmineのチケットの親子関係の機能をフルに使えてないと思う。
本当は、チケットに階層構造を導入して3階層以上のチケットの構造を表現できれば、WBSと完全にマッピング可能なのだ。
又、親チケットの集計機能があれば、簡単にストーリーカードの進捗度合いを表現できるはずだ。
Redmineが導入したチケットの親子関係による集計機能は、今後のRedmineプラグインの課題と言える。

【3】後者については、チケットの粒度とチケット集計ビューの間に密接な関係があると言う事実を指摘している。
チケットの粒度が細かいほどチケットの枚数は増えるので、プロジェクトの動向はチケット集計結果に敏感に反映される。
又、チケットの入力項目が多いほど、色んな観点でチケットを集計することは可能。
チケットの粒度が大きかったり、チケットの入力項目が少ないと、集計してもあまり役立つ情報は得られない。

Redmineのチケットの属性とチケット集計機能の関連については、下記でまとめている。

チケット管理システム比較Wiki

この比較Wikiを書きながら、新たな問題意識として、プロジェクト管理に必要なビューはどれだけの種類があって、どんな状況にどんなビューが有効なのか、というノウハウが実は整理されていないように思っている。

アジャイル開発では、InfoQ: かんばんボードによるプロジェクトの見える化のように、パーキングロットチャート・タスクボード・バーンダウンチャート・ニコニコカレンダーの4種類が最も有名なビューだが、これだけではないはずだ。
又、PMBOKでもガントチャートやPERT図、バグ収束曲線だけでなく、他にもあるはずだ。

今知られているプロジェクト管理のビューは、どんなコンテキストに対して有効なのか、という議論を整理してみたい。
そのようなノウハウがあれば、RedmineやTracという優れたプロジェクト管理ツールを使いこなすと、自然にプロジェクトマネジメントのスキルも身に付くようになるだろうと考えている。

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

Redmineに入れたプラグイン一覧part2

Redmineの最新版1.1.2にプラグインを入れてみた。
随分変わったので、インストールと注意点をメモ。

【参考】
Redmineに入れたプラグイン一覧: プログラマの思索

【Redmineのインストール】

Redmine(v1.1.2)を解凍して、DBも作っておく。

gem install rails -v=2.3.5
gem install rack -v=1.0.1
gem install i18n -v=0.4.2

rake generate_session_store
rake db:migrate RAILS_ENV=production

ruby script/server -e production

"http://localhost:3000/"へアクセスし、login : admin、password : adminでログインする

【@daipresentsさんのアジャイル開発プラグイン】
@daipresentsさん作成プラグインを一通り入れてみた。
大抵のプラグインも基本はテーブルをCreateしないので、Redmineを再起動するだけで正常動作する。
最新版でも問題無し。

daipresents's Profile - GitHub

redmine_parking_lot_chartは、バージョンの進捗や内容をボードに一覧化したもの。
redmine_parking_lot_chart

Parkinglotchart

元来、パーキングロットチャートはInfoQ: かんばんボードによるプロジェクトの見える化に紹介されているように、フィーチャの状況を一覧にしたものなので、@daipresentsさんはRedmineバージョンをフィーチャないしストーリーのように扱っていたようだ。
バージョンがサブシステム単位、大きな機能(フィーチャ)単位ならば管理しやすいだろう。

redmine_version_burndown_chartsは、バージョン単位のバーンダウンチャート。これがまさにScrumやPFのバーンダウンチャートそのものに相当する。
アジャイル開発を実践するなら必須のアイテムの一つだろう。
redmine_version_burndown_charts

Burndownchart

但し、redmine_version_burndown_charts は、open_flash_chart 2.1.1が必須なので注意する。
ruby script/plugin install http://svn.pullmonkey.com/plugins/trunk/open_flash_chart/
でインストールすると、パスが異なるのでエラーになった。
pullmonkey/open_flash_chart - GitHubからダウンロードするとよい。

redmine_task_boardはPFのかんばん、XPのタスクボードそのもの。選択したバージョンでステータス単位にチケットをグルーピングしてくれる。
これもアジャイル開発を実践するなら必須のアイテムの一つだろう。
redmine_task_board

Taskboard

史上最高のチームプラグインは、メンバーの進捗報告代わりになる。デザインも良いので予定・実績工数をきちんと入力すれば、メンバーのやる気も出るだろう。
redmine_all_time_team

redmine_roadmapsはロードマップの機能を拡張したもの。
redmine_roadmaps

Rodmaps

RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索にも書いたが、ロードマップスプラグインに現れる諸概念は最終的にはPMBOKのEVMに通じる。

【Redmineのテーマ】
日本語環境で読みやすいRedmine用テーマは下記を入れると良い。
日本語フォントが読みやすいし、MantisやTracのようにチケット一覧でチケットの優先順位ごとにカラフルに表示してくれる。
public/themes ディレクトリ直下にコピーするだけでいいので簡単。

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

Ticketview

【チケットの一括インポート】
以前のredmine_importerは、Redmineの最新版では動かなくなっている。
下記のプラグインを入れると良い。

akiko-pusu/redmine_importer - GitHub

Import

但し、en.ymlと同様に、
redmine\vendor\plugins\redmine_importer\config\locales\ja.yml
で、最後の2行の先頭に、スペースを2つ入れる必要がある。
これでやっと動いた。

RedmineでチケットをCSVで一括登録する - uedakoの日記

更にCSVは、Redmine CSV Import Pluginの使い方: プログラマの思索に書いてあるフォーマットに合わせる必要があるので注意。

WBSからチケットを一括インポートしたい時は多いので、プロジェクトリーダーならこのプラグインは必須だと思う。

【ニコニコカレンダー】
PFでもよく出てくるニコニコカレンダーは下記のプラグインを使うと良い。
Redmineの最新版でも問題なく動く。

YukiKita/redmine_niko_cale - GitHub
Redmineのニコニコカレンダー・プラグイン: プログラマの思索

Nikocalender

プロジェクトも開発チームもメンバーも生物(いきもの・なまもの)だから、常に最新の空気を入れるような工夫がいる。
ニコニコカレンダーを見て、メンバーのモチベーションが落ちているのに気づいたら、何らかの対策を早めに取る必要がある。

【CSV出力の強化】
チケットの履歴もCSV出力するプラグイン。
QAのやり取りやバグのやり取りもCSV出力すれば、ミーティングや報告資料を作る際に役立つ。

suer/redmine_export_with_journals - GitHub

他にもチケット一覧をExcelそのもので出力するプラグインやMS Project形式のXMLをインポートしてチケットを一括登録するプラグインもある。こういうプラグインを用意しておくと、プロジェクトリーダーの受けはよくなるだろう。

RedmineチケットをExcelにエクスポートするプラグインRedmine XLS Export: プログラマの思索

RedmineのMSProjectプラグインその他: プログラマの思索

【ロードマップの強化】
Advanced roadmapは、マイルストーンと言う概念をRedmineに導入する。
Redmineのオブジェクトの構造は、プロジェクト>サブプロジェクト>マイルストーン>バージョン>親チケット>子チケットのようになる。

Advanced roadmap - Advanced roadmap plugin for Redmine - Redmine OCIO y TECnologi'a

Advancedrodmap
Advanced Rodmapプラグインが拡張したロードマップ

Roadmap
デフォルトのRedmineロードマップ

インストールは手間取った。
まずRMagickをインストールする必要がある。
Windowsの場合、ImageMagickとRMagickを同じバージョンでインストールしなくてはならない。

RMagickをインストールしてみる(Windows) ? Katawara.*

Advanced roadmapは最新版0.4.0をインストールした。
rake db:migrate_plugins RAILS_ENV=production でテーブルをCreateする必要がある。

更に、管理画面のカスタムフィールド>バージョンで、「parallel_effort_custom_field」という名前でカスタムフィールドを作っておく。
このカスタムフィールドを作らないと、プロジェクト設定画面のマイルストーンタブで、マイルストーンを新規追加する時に落ちる。

Advanced roadmapでは、複数のバージョンをまとめたマイルストーンの単位で、進捗を集計してくれる。
だから、マイルストーンをフィーチャ、バージョンをストーリーのように扱えば、マイルストーンが顧客への進捗報告の資料の元ネタになるかもしれない。

まとめると、@daipresentsさん作成の
redmine_parking_lot_chart
redmine_version_burndown_charts
redmine_task_board
とニコニコカレンダー「redmine_niko_cale」はアジャイル開発を運用したいなら必須だ。
又、チケットの一括インポートredmine_importerと、履歴もCSV出力するredmine_export_with_journals、Excel出力するXLS Exportは入れた方が便利だ。
更に、r-labsのHudsonプラグインやコードレビュープラグインも入れると、ビルド管理やコードレビューのフローをサポートしてくれる。

RedmineもVer1.1になって、プラグインが以前よりも充実していて、色々試すのが楽しい。

| | コメント (0)

2011/04/06

TortoiseHg2.03でhgsubversionが動くようになった

TortoiseHg2.03でhgsubversionが動くようになった記事を見つけて、インストールしてみたのでメモ。

【元ネタ】
2011-04-03 - mnruの日記

TortoiseHg+hgsubversionの導入方法: プログラマの思索

TortoiseHgのダメ文字対応DLLとhgsubversionパッチ: プログラマの思索

TortoiseHgでSVNを使う方法: プログラマの思索

TortoiseHg2.0が公開されている: プログラマの思索

TortoiseHg Reviewboard extension: プログラマの思索

(引用開始)
tortoiseHgの2.0系が出てから結構、時間がたちましたが、2.03でhgsubversionがちゃんと動くようになったようです。
また,hg-gitとhgsubversionの干渉もなくなったのか、いちいち設定ファイルを書き換える必要もなくなりました。
これで、git,subversion,mercurialを統一的にtortoiseHgで扱うことができそうです。
(引用終了)

TortoiseHgは、hgsubversionやhg-gitでSVNやGitのクライアントとして扱えるはずなのに、どのバージョンからかmercurial.iniに設定するとエラーが出るようになった。
しかし、最新版2.03でhgsubversionが動くようになったみたい。

Ver2になってGUIも大きく変わり、Hgワークベンチでコードラインの成長がグラフィカルで分かりやすくなった。
コミット画面がムダに大きくなり、ボタンをなんども押すのは面倒だが、それが余りあるほど機能も改善されてきた。

TortoiseHgの設定画面では、課題管理メニューでITSのチケットにpost-commit-hookする設定があるので便利だ。
更に、コードレビューWebシステムReviewboardもメニューに設定されているようなので、post-commit-reviewもサポートしているのだろうか?
TortoiseHgとReviewboardが密接に関係しているのが面白い。

Tortoisehg_reviewboard


色々触ってみる。

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

Redmineの運用例 その3

@daipresentsさんのRedmineの記事が素晴らしいのでメモ。

【元ネタ】
3年使ったRedmineの使い方について共有したい10のこと | 世界 - daipresents!!

Twitter / @あきこ: 題名、説明はプログラムする気持ちで記述する、は心がけています。/ 3年使ったRedmineの使い方について共有したい10のこと | 世界 - daipresents!! http://t.co/rOcsJkL via @daipresents
http://twitter.com/#!/akiko_pusu/status/55514322046169088

InfoQ: かんばんボードによるプロジェクトの見える化

Redmineでアジャイルチームのスピードやパワーを見える化する

Redmineが1000人のエンジニアに使われるまでのこと

受託開発でTracを導入してよかったことや失敗したこと

大規模プロジェクトほどプロジェクト管理ツールの重要性は増す。
個人的には、20人月以上のプロジェクトでは、Excelによる進捗管理は事実上不可能だろうと思う。
ExcelやMS Projectによるガントチャート管理は、プロジェクト立上げでは有効だろうが、開発やテスト工程では、頻繁にタスクが変わってしまうので現状に追いつかない。
仕様変更やバグが入り乱れれば、ガントチャートの保守だけでプロジェクトリーダーの1日の仕事は終わってしまう。

更にWF型開発でも、サブシステム単位に順にリリースする段階リリースの戦略を取る場合、プロジェクト管理の難度は格段に上がる。
Agile開発のプロジェクト管理を実現するようなツールが、SW開発では最終的に必要になるのだろうと思う。

@daipresentsさんの記事で面白かった点が二つある。
一つ目は、パーキングロットチャートの使い方。
パーキングロットチャートは、最上層のプロジェクト状況を要約表示するものらしい。
Redmineのパーキングロットチャートプラグインは、全てのバージョンの進捗を表示する一覧である。
@daipresentsさんの記事によれば、パーキングロットチャートでバージョンをフィーチャーないしストーリーカードと見なすことで、フィーチャーストーリーカードの進捗を表すようにしているようだ。

個人的には、バージョンはイテレーションに対応付けたいので、親チケットをストーリーカード、それにぶらさがる子チケットをタスクカードの束と見なして、親チケット単位の進捗を見れるようなプラグインが欲しい。
そうすれば、イテレーションで実現すべきストーリーカードの進捗が一目で分かるので、どのストーリーカードが遅れているから対策を打つべきか、判断できる。
つまり、フィーチャーはパーキングロットチャート、ストーリーカードはストーリーカード用パーキングロットチャートで使い分けたいのだ。

二つ目は、ユーザ1000人が使うとRedmineが業務システムに変わってしまうという指摘。
プロジェクト管理ツールの運用も各プロジェクトでバラバラではなく、部門全体、社内全体に拡張していくと、プロジェクト管理を支える一つの業務システムになる。
Redmineが止まると業務(開発)が止まってしまうわけだ。
Redmineというツールをスケールアップする技術面も研究する余地がある。
RedmineをSaaS形式でクラウド化するのも一つの方法だろう。

色々調べてみたい。

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

2011/04/04

pre-commit-hookとpost-commit-hook #tidd

Subversionには、pre-commitとpost-commitの機能が元々付いている。
復習のためにメモ。

【元ネタ】
TortoiseSVN の設定

バグ追跡システム / 課題追跡システムとの統合

[Think IT] 第4回:チケットとソースコードを連携せよ! (1/3)

ソフト/Bug Tracking/trac/TortoiseSVNやSubclipseとチケットを連動 - discypus

TortoiseSVNとITS・BTSの連携 S.S.S. blog/ウェブリブログ

redMine で trac の trac-post-commit-hook のような事をやる

バージョン管理システムとの連携 | Redmine.JP

TortoiseSVNのようなSVNクライアントには、pre-commitとpost-commitの機能が元々付いている。
pre-commitは、コミット前にコミットログの中身を精査してコーディング規約に合致しているかどうかチェックする。もしエラーならコミットできない。
post-commitは、コミット後に付与された内容を実現する。よくある例は、コミットログにチケットNoが書かれていれば、BTSのチケット画面にSVNリビジョンとコミットログを表示する。

pre-commitの使い道は、コミットログにチケットNoが書かれていなければ、コミット不可にすること。
この運用ルールは「No Ticket, No Commit」と呼ばれる。
このルールによって、SVNリビジョンとチケットの相互リンクが実現されるので、最終的にはビルドモジュールからチケットに書かれた修正理由へ追跡できるし、逆に過去のチケットから修正されたソース一覧を洗い出せるので仕様変更の影響範囲や同類バグ調査に使える。

つまり、チケットと成果物を紐づけることによって、トレーサビリティを実現できる。
このトレーサビリティは従来の開発プロセスやAgile開発には現れなかった性質であり、とても重要なポイントだ。

post-commitの応用としては、コミットログにチケットNoだけでなく特定のキーワードによってチケットの状態を更新出来ること。
Redmineの場合、「refs #1」ならチケット#1とリンクするだけだが、「fixes #2」ならチケット#2の進捗率=100%にして更に解決済みステータスへ更新してくれる。
複数回のコミットはrefs、最終コミットはfixesと使い分ければ、開発者はチケットを逐一更新しなくてもコミット時に勝手にチケットの担当が終了したことになる。
この運用ルールに開発者が一度慣れると、コミットするのが楽しくなってくる。

SVNもCVSでも、pre-commit-hookやpost-commit-hookのスクリプトを書けば、ユーザはコミット時に意識する必要はない。
この手法はおそらくTracで普及し、RedmineではWeb画面から設定できるので便利になった。
今では、MercurialやGitでも、RedmineやTrac上で同様の操作が可能だ。

ITSが構成管理ツールと連携している利点は、単にITSの画面からSCMリポジトリを見れるだけでなく、pre-commit-hookとpost-commit-hookによって、チケットとSCMリビジョンがリンクされて、チケットに成果物の履歴が残り、トレースしやすくなることだ。

この特徴こそが従来のバグ管理システムには無かったものであり、チケット駆動開発へ発展していったきっかけになったのだと思う。
実際、チケット駆動開発では、ITSバージョンとリリース予定バージョンとイテレーションが対応づけられることによって、自然に小規模リリースを実現できる。
又、ITSプロジェクトとSCMコードラインとビルドモジュールが対応付けられることによって、メインラインモデルのタスク管理が楽になるので、派生開発や製品ファミリー開発を強力にサポートできる。

ITSと構成管理ツールとの連携については更に考察してみたい。

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

2011/04/03

オンサイト顧客が暗示したもの~プロダクトオーナーとアーキテクトの役割

最近のシステム開発のステークホルダーでは、ユーザと開発者、プロマネという役割だけでは足りない気がする。
キーワードは、XPのオンサイト顧客、Scrumのプロダクトオーナー、ソフトウェアプロダクトラインのアーキテクト。
考えたことをメモ書き。
間違っていたら後で直す。

【参考】
アジャイル実践者インタビュー(2) - @IT

【中級】反復開発 現場のノウハウ 第2回 - ITエンジニアのスキル向上ゼミナール:ITpro

マネジメントのスピードが開発のスピードに直結する: プログラマの思索

要件定義の疑問: プログラマの思索

アジャイルの基本原則と価値 (Jeff Sutherland 著)

【1】XPにはオンサイト顧客というプラクティスがある。
顧客も開発チームに巻き込んで、開発者がすぐに顧客に要件を確認したり、要件の取捨選択を即判断できるように、共に開発するスタイル。
この開発スタイルは特にパッケージ製品や組込製品のように、マーケット重視のソフトウェア開発ではより重要で、かつ威力を発揮するスタイルだと思う。

しかし、受託開発では、オンサイト顧客は実際はありえず、業務SEという名のメンバーが顧客と開発チームの間を取り持つ時が多い。
つまり、オンサイト顧客を開発チームのそばに置くことが出来ない場合、業務SEがユーザの要望をまとめてシステム要件に落として開発者に伝える役割を担う。
倉貫さんはこの手法を顧客プロキシと呼んでいた。
実際のプロジェクトでは、顧客プロキシと呼ばなくてもそのような役割を担うSEはブリッジSEとして、ユーザ企業へ頻繁に出張して、開発チームとのメッセンジャーになるため、とても負荷が高い。

ScrumがXPよりも優れている点の一つは、プロダクトオーナーと言う役割を明示化したことだと思う。
ユーザと開発チーム(プロマネ、開発者)の間でビジネス要件とシステム要件を結びつける前に、ビジネス要件をまとめて優先順位を付ける人がプロダクトオーナー。
プロダクトオーナーがまさに製品(システム)の機能を決定する権限を持つ。
プロダクトオーナーという役割をユーザ企業の担当者が意識していれば、システムのビジネス的価値を見極めてビジネス要件を作る。
ビジネス要件はまさに要求そのものであり、要求がはっきりしているからこそ、要件(システム要件)へ詳細化することが可能。
プロダクトオーナーがいなければ、ベンダーが作ったRFPをそのまま受け入れて、動かないシステムを作るだけに過ぎない。

多分、XPのオンサイト顧客という言葉で暗示した概念はプロダクトオーナーという言葉ではっきり具体化できると思う。

プロダクトオーナーという役割を認識した上で問題になるのは、プロダクトオーナーという役割を誰が担うのか、ということ。
本来ならばユーザ企業の情報システム部の人達がプロダクトオーナーになるべき。
しかし、開発チームとのやり取りを考えると、開発チームから業務SEを抽出して、その業務SEとユーザ企業の担当者がプロダクトオーナーのチームになるべきではないか、と思う。
そうでなければ、開発チームは要件の重要度や作業の優先度を身近にいるプロダクトオーナーに確認できない。
地理的な距離感が心理的な距離感になってしまうからだ。

【2】プロダクトオーナーとプロマネだけでなく、アーキテクトと言う役割の重要性を主張したのがSWプロダクトラインだと思う。
SWプロダクトラインでは、アーキテクトがユーザ・管理者・開発者の間でお互いの主張や意見を翻訳して調整する役割を担う。

デブサミ2011の鈴木雄介さんのなぜソフトウェアアーキテクトが必要なのか - デブサミ2011の講演でも、アーキテクトがプロマネとプロダクトオーナーの間を取り持つ、アーキテクトがいるからこそプロマネは仕事できる、と話されていた。

又、以前、SEA関西のSWプロダクトラインの講演でも、アーキテクトは設計する人ではなく調停者であると言う話を聞いて、なるほどを思った時がある。
だから鈴木雄介さんの講演内容はとてもストンと理解できた。

そのボタンを押したら何が起きるのですか?~アーキテクチャは利害関係者のコミュニケーション手段: プログラマの思索

実際のシステム開発における上流工程では、要求と要件の違い、要求から要件への詳細化がとても難しい。
結局WF型開発で設計を進めて、実際に作って動かしてみて、初めて要求を設計者が理解したり、要件とシステムのズレを開発チームが認識する時がとても多い。

だから、RUPのような上流工程を繰り返し開発するやり方では、業務SEがプロダクトオーナーかつアーキテクトの役割を持ってチームを組んで、システム全体を薄く設計しながら深堀していくやり方になるのだろうと思う。
そうしなければ、要件定義や外部設計という上流工程の作業を繰り返し開発するのは難しいだろう。

【3】特にクラウドを意識した最近のシステム開発では、アーキテクトの重要性が高まっているという事実もあると思う。
下記の記事を読むと分かりやすい。

新しい未来を見るその先のキャリアへ行く SEE,Go To シー、ゴー、トゥー コンサル記事

以前は、業務知識が強い業務SEがシステム開発のコアメンバーだった。
つまり、業務SEはプロダクトオーナーの役割を担っていたと言える。

しかし、開発経験が無い業務SEでは開発案件を回せなかったり、システムを作った後の運用保守が難しかったりする事例が多くなったという。
だから、業務知識だけでなく開発経験も持っていて、開発チームも回す能力のあるプロジェクトマネージャーのタイプがコアメンバーに代わった。
つまり、スクラムマスターという役割を持つ人が重要視されたと言える。

そして最近は、SNSなどのWebシステムのスケールアップがボトルネックになる時が多くなったので、DBサーバーやWebサーバーのスケールアップに強い人が要求されるようになったらしい。
つまり、この役割はアーキテクトそのものだ。

そういう時代の変遷を見ると、深い業務知識を持つプロダクトオーナー、実際に開発チームを回すことができるプロマネ、DBやサーバーのスケールアップなどのアーキテクチャ設計に強いアーキテクトという3つの役割をこなせる人が必要になってきたみたい。

しかし、実際の現場では、プロダクトオーナーとプロマネ、あるいはプロマネとアーキテクトの二つを兼任するぐらいしかできないだろうと思う。
小規模プロジェクトならまだしも、大規模プロジェクトで3つの役割を兼任していたら、負荷が高すぎてプロジェクトが回らない。
大規模プロジェクトになるほど、プロダクトオーナー・プロマネ・アーキテクトの役割を分化していくようになるのだろうと思う。

実際の開発現場で、プロダクトオーナー・プロマネ・アーキテクトの役割を誰が担っているのか?と言う観点でステークホルダー分析してみると面白かもしれない。
どれかの役割が欠落していたら、そのプロジェクトはどこかの時点でつまずいてしまう可能性が高いように思う。

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

2011/04/02

クラウドの定義

NISTによるクラウドの定義を再復習する。

【元ネタ】
クラウドの定義

とても重要な NIST のクラウド定義:対訳 ? Agile Cat ― in the cloud with openness

NISTによるクラウドコンピューティング定義の和訳|EL TIO

(引用開始)
「クラウドコンピューティングは、コンピューティング資源(ネットワーク・サーバー・ストレージ・アプリケーション・サービス)の共有プールへの、オンデマンドなネットワークアクセスを可能にするモデル。管理の手間やサービスプロバイダーの仲介作業を最小にしつつ、これらのリソースをすみやかにプロビジョンしリリースできる。」ということで、以下の、五つの特徴、三つのサービスモデル、四つのデプロイメントモデルが書いてあります。

五つの特徴(Essential Characteristics)
・On-demand self-service: 必要にあわせて自動的(=提供者側の人による仲介作業なし)にサーバーやストレージを利用できる。
・Broad network access: いろいろなプラットフォーム(携帯電話、ラップトップ、PDAなど)から、ネットワークを通じて使える。
・Resource pooling: マルチテナントモデルで提供され、一般的にはサーバーやストレージがどこにあるかはわからない。
・Rapid elasticity: すばやく(時には自動的に)、スケールアウト・スケールインできる。
・Measured Service: 適切な計測により、サービスの透明性が確保される。

三つのサービスモデル(Service Models)
・SaaS (Cloud Software as a Service): 利用者は、アプリケーションを使う(use)ことができる。
・PaaS(Cloud Platform as a Service): 利用者は、作ったりしたアプリケーションを、配備(deply)できる。
・IaaS(Cloud Infrastructure as a Service): 利用者は、基本的なコンピューティングリソース(演算能力・ストレージ・ネットワークなど)を、プロビジョン(provision)できて、いろいろなことができる。

四つのデプロイメントモデル(Deployment Models)
・プライベートクラウド(Private cloud):企業内でクラウドサービスを提供する
・コミュニティクラウド(Community cloud):いくつかの組織でプライベートクラウドを共用する
・パブリッククラウド(Public cloud):インターネットを介してクラウドサービスを顧客へ提供する
・ハイブリッドクラウド(Hybrid cloud):プライベートクラウドとパブリッククラウドの混合型
(引用終了)

今流行しているFacebookやTwitterはSaaSになるだろう。
GAEはPaaSかな。
企業が自社特有の業務システムを自社やその子会社だけでクラウド化したい場合、IaaSになるだろう。

業務システムをクラウド化したい場合、プライベートクラウドを狙っている会社は多い。
自社と子会社で業務システムを共用したいなら、コミュニティクラウドになるだろう。
SaaSはパブリッククラウドの一部。

BtoBはプライベートクラウド又はコミュニティクラウドあるいはIaaS、BtoCはパブリッククラウド又はSaaSが普通だろう。

今回の震災でBCP(事業継続計画)の観点からしても、業務システムのクラウド化が今後加速するだろう。
業務システムが国内のデータセンターだけでなく、世界各地に散らばっていれば、国内のデータセンターが震災でやられても、外国のデータセンターにある業務システムを稼働すればいい。

だが、プライベートクラウドは本当にクラウドなのか、という疑問もある。
社内に閉じた単なる業務システムに過ぎないのではないか?と。

自己矛盾を抱えたプライベート・クラウドに価値はあるか?(1/4):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

【Deep Dive】【解説】プライベート・クラウドへの険しい道のり : クラウド・コンピューティング - Computerworld.jp

色々調べてみる。

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

Hadoopの本質は分散I/Oにあり~クラウド時代の非同期処理

Hadoop向け基幹バッチ分散処理ソフト「Asakusa」の記事がとても素晴らしいのでメモ。

【元ネタ】
第1回 分散処理を隠蔽し、大規模開発を可能に - Hadoop向け基幹バッチ分散処理ソフト「Asakusa」の全貌:ITpro

第3回 業務の境界や並列性を見極め処理を分割 - Hadoop向け基幹バッチ分散処理ソフト「Asakusa」の全貌:ITpro

基幹バッチ再構築のニーズは大きい、Hadoopの課題をAsakusaで解決する - インタビュー:ITpro

Twitter / @akipii: Asakusaの本質は分散I/O。ディスクの入出力がバッチ処理のボトルネック。クラウド時代の非同期処理の設計技法は、ジョブフローからバッチ処理をDSLで自動生成することにあり。

CobolやPLSQLで書かれた古臭いバッチ処理は、全てHadoopで代用できないものか?
Cobolの生産性の低さは長年の問題だ、と思う。
結局、総合テストで動かさないと、まともに動く事を保障できない。
リリース間際までバグ修正ばかり追いまくられる。

Cobolの最大の欠点は、自動テストライブラリが無い事。
JavaはJUnit、Rubyはtest/unitのライブラリがある。
C++/CもCppUnit、CUnitすらある。
PLSQLならば、Javaからストアドをキックするツールを作る事で、DBUnitを使う事は可能だ。
しかし、Cobolにそのようなツールがあると聞いたことは無い。

基幹系業務システムの開発の最大のボトルネックはバッチ処理。
バッチ処理を制するものが業務システムを制する。
そのバッチ処理は50年以上前からCobolのまま何も進化していない。
だからこそ技術革新のブレークスルーが今起きてもおかしくない。

バッチ処理のボトルネックはディスクの入出力。
CPUがいくら早くても、ディスクの読み書きが遅いからトータルの処理時間は変わらない。

(引用開始)
Hadoopを使ってシステムの性能を高めるには、いかにディスクI/Oを分散させるかという観点が欠かせない。
ディスクI/Oを分散させるには、事前に処理の並列性を担保する必要がある。
Asakusaは基幹バッチ処理を高速化するために、設計段階から処理の並列性を確保し、そのままシームレスに開発につなげる仕組みである。
Asakusaでアプリケーションを開発する際は、この設計から実装までをシームレスにつなげるところが焦点になる。
本稿では、分散I/Oと表裏一体となる並列性の確保の考え方が、バロック音楽の通奏低音のように流れることに留意してほしい。
(引用終了)

つまり、Hadoopの本質は分散I/Oにある。
だからHadoopでディスクへ並列に読み書きすれば処理は早くなる。
そのためには、プログラムが並列処理になるように書いて、副作用をなくす。
関数型言語の発想が必要になってくる。

バッチ処理の設計書によく書かれているジョブフロー図は、リンクつきリスト(Linked List)に過ぎない。
だから、処理を分割したときに、並列に動くような設計をしておけば、Hadoopの威力が大きくなる。

AsakusaのソースはJavaで書かれているようだ。
ジョブフローからDSLでソースを自動生成する仕組みみたい。
浅海さんはSacalaでDSLを書くソースを公開されている。
関数型言語Scalaならば、並列処理をより簡単に書ける可能性がある。

asami/AsakusaScalaDslSample - GitHub

クラウド時代の技術は、KVSのような脱RDBの方向に走っているけれども、昔から何も変わっていないCobolを置き換える技術がそろそろ出てきてもいい気がする。
その鍵は非同期処理における並列プログラミングにある気がする。

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

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