« 2009年12月 | トップページ | 2010年2月 »

2010年1月

2010/01/31

業務システム設計に関する本

業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。
プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。

特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。
理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。
つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。

僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。

【1】グラス片手にデータベース設計編

グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)は、業務システムの中でも最も一般的な販売管理システムの業務をDBスペシャリストの観点から説明している。
著者の梅田弘之さんは、SI Objectブラウザの開発者らしいから、Oracleに強いのだろうと思う。
ER図はIDEF1なので正直読みづらいが、DFDや業務の説明は分かりやすい。


グラス片手にデータベース設計 ~会計システム編 (DBMagazine SELECTION)も同じ著者で、業務システムの中でも難しい部類である会計システムの業務をDBスペシャリストの観点で説明してくれている。
会計業務を説明している他の本は、会計士の観点だったり、簿記の知識がないと分かりにくかったりしてイマイチだった。
やはり、システム設計の観点、つまりデータモデリングの観点で書いてくれている方が読みやすいし、その方が実践で役立つ。
僕らの仕事は、お客様の業務を理解するよりも、いかにシステムへマッピングするか、という技術力が根底にあるから。

同じ著者で、グラス片手にデータベース設計 生産管理システム編 (DB Magazine SELECTION)があるけど、まだ読んでない。
今度読んでみたいと思う。


【2】渡辺さんシリーズ

業務別データベース設計のためのデータモデリング入門は、商品管理、販売管理、在庫管理など基本の業務に関するデータモデリングの本。
僕が初めてデータモデリングを勉強し始めた時に使った本。
ER図は渡辺さん独特の記法だが、具体的なデータも列挙してくれているので分かりやすい。

業務システムのための上流工程入門―要件定義から分析・設計までは、上流工程の要件定義やDB設計に重点を置いた本。
要件定義やDB設計ではまりやすいポイントを解説してくれている。

生産管理・原価管理システムのためのデータモデリングは、生産管理に関するデータモデリングの本。
MRPの仕組みについてとても詳しく書かれている。
生産管理は、データモデリングの中でも会計システムと並んで最も難解な分野。
製品や部品と言うマスタデータと、工程というプロセスに関するデータをいかにRDBに落としこんで、設計するか?

Oracleにある再帰SQLを使う場面があった時、この本を参考にした。
生産管理・原価管理システムのためのデータモデリングは全部理解できていないけど、時々読み返しては気付きがある。

業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題は、家計簿や医療システム、プロジェクト管理システムなどをデータモデリングの観点で解説してくれている。
実際の業務を分析しながら、ER図をどのように作っていくか、という観点がとても分かりやすい。

渡辺さんが作ったER図をRailsで実装すれば、Web上で簡単に動かせるので、業務システムのイメージを理解しやすくなるだろう。

【3】羽生さんシリーズ

楽々ERDレッスン (CodeZine BOOKS)は、DB正規化に関する説明と帳票(レシート)からER図を起こす実践例が非常に素晴らしい。

DB正規化で、コード体系とアイデンティファイアを区別しようと言う説明が出てくる。
コード体系は、ユーザが自分の業務の観点からユニークに作ったキー。
アイデンティファイアは、RDBのシーケンスであり、業務とは無関係なキー。

Railsでは複合キーと言う概念がない点は、DOA屋から非難される時があるが、昨今のWebシステムの現状を考えるとその方がいいと思う。
Railsで具現化されたRESTfulという設計思想とアイデンティファイアという発想はとても相性がいいからだ。
理由は、Web上で任意のデータにアクセスする時、リクエストパラメータはユニークなキーであるアイデンティファイア一つだけでいいからだ。
複合キーの場合、複数のキーをリクエストパラメータに渡さないといけないので、URLが醜くくなる。

そして、レシートからER図を起こす練習問題が素晴らしい。
コンビニのレシート、ファーストフードのレシート、病院のレシートから、業務を類推して、ER図を書き起こす。
この作業はプロならば3分で思いつかないといけないと羽生さんは言っている。
僕ももっと修行しなければならない。


データモデリングをマスターしたいならば、Railsで勉強した方が良いと思う。
ER図からマイグレーションのプログラムを書いて、DBスキーマを一発生成し、scafoldでCRUD画面を作る。
Web画面上でデータの遷移を見れば、データと業務の関係が見えてくるはずだ。

そんなことを思いながら、昨今の設計は実装にますます近くなっている気がする。
DB設計で悩むぐらいならば、RailsでプロトタイプのWebシステムを作り、実際にシミュレーションすればいい。
DOAとRailsはとても相性がいいはずだ。

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

2010/01/30

チケットの親子関係が持つ意味

さかばさんのBlogを読んで考えたことをメモ。

【元ネタ】
[TiDD] RedmineのWBS: ソフトウェアさかば

プロジェクトの初期にタスク洗い出しとして作られるWBSは普通、5階層までが良いと言われている。
WBSの階層が深いと管理しにくいが、階層化しなければ、タスクの見通しが悪い。

Ver0.8までのRedmineでは
「プロジェクト-サブプロジェクト-バージョン-チケット」
の構造を持つので、4階層になるようにWBSを作ればいい。
しかし、実際はもっと深く作りたい時もあるから、その場合は階層を省略するなど無理するしか無かった。

Ver0.9では、プロジェクトの階層が無制限へ機能改善されたので、
「プロジェクト-サブプロジェクト1-サブプロジェクト2-バージョン-チケット」
のように、5階層のWBSを簡単に作ることができる。

ここで、さかばさんの指摘のように、下記のように対応付ければ、小規模リリースを簡単に実現できる。

チケット←→モジュール(部品・機能)
バージョン←→コンポーネント(リリース可能な最小の稼動できるモジュール)

しかし、チケットをタスクカードに見立てることはRedmineで簡単に実現できるが、ストーリーカードを実現するのは難しい。
ストーリーカードを実現するには結局、チケットの親子関係、つまり、チケットの階層構造を作らなければならない。
そして、ストーリーカードとタスクカードには、Redmineの各機能から眺めたチケット駆動開発の課題:プログラマの思索のような制約が必要になる。

もし、この制約が実装できたならば、下記のイメージのようなRedmineで要件管理も可能になるだろう。

チケット管理の観点:プロジェクト-サブプロジェクト1-サブプロジェクト2-バージョン-チケット
要件とタスクの観点:ストーリーカード1-ストーリーカード2-ストーリーカード3-ストーリーカード4-タスクカード

つまり、要件をストーリーカード1~ストーリーカード4の単位で階層化・細分化し、タスクカードを最下層に配置する構造が対応するようにできる。
そして、要件の階層は、ステークホルダーの観点で進捗管理する単位にすればいいと思う。
例えば、第1~3階層までは顧客や管理者向け、第4~5階層は開発者やライブラリアンの観点で、要件や作業をチケットにすればいい。

上記のようなツリー構造をRedmine上で実現できれば、要件からモジュールまでのトレーサビリティが容易に可能になる。
例えば、モジュールでバグが発生した場合、バグが発生したストーリーカードを探せば、その階層構造から影響するストーリー(要件・機能)の範囲が分かるので、修正方法や修正工数の決定が楽になる。
あるいは、仕様変更が起きた場合、影響するストーリーカードの階層構造から、影響範囲が分かるので、対応工数を見積しやすくなるだろう。

即ち、チケットの親子関係という機能は要件管理と要件のトレーサビリティと密接に関係するからとても重要だ。
そして、要件管理が実現できれば、設計プロセスの品質改善に大きく役立つと思う。
何故なら、設計プロセスのバグである設計漏れの原因の大半が、要件漏れや要件の影響範囲の考慮漏れだからだ。

上記のアイデアは、既にRedmineのScrum系プラグインで実装されているが、Ver0.9で動くか確証がないし、Ver0.8でもそもそも不安定なプラグインもある。
早くRedmineのデフォルト機能として実現して欲しいと思う。

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

ついにRedmine 0.9.1が出た

待ちに待ったRedmine 0.9.1がようやくリリースされた。
0.9.1は0.9RC(ReleaseCandidate)がようやく安定されたことを意味している。

Redmine - Redmine 0.9.1 released - Redmine

リリース内容は下記が詳しい。

0.9 | Redmine.JP Blog

感想は下記に書いた。

Redmineの最新動向: プログラマの思索

Redmine0.9.xの新機能: プログラマの思索

Redmineの最後の課題~チケットの親子関係: プログラマの思索

後は、プラグインが動くかどうかが問題かな。
バーンダウンチャートを表示するChartsプラグインは、0.9で動かす場合、下記のパッチが必要らしい。

Redmine0.9.0でredmine_chartsプラグインを動かしてやるぜ - フジハラボ -- 目指せ!スーパーエンジニア

残る興味は、Subtasksのチケットの動向。
これは、Redmine最後の課題であるチケットの親子関係を実装する機能のチケットだ。

Redmine - Feature #443: Subtasking - Redmineを見ると、Eric Davisが担当者に決定しており、どこかのリポジトリでパッチを試すらしい。
興味ある人達は自らテスターを希望している。
URLが公開されているのを僕だけでなく、世界中の人達が待っている。

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

2010/01/27

Redmineの各機能から眺めたチケット駆動開発の課題

Redmineの各機能から眺めたチケット駆動開発の課題についてメモ。
ラフなメモ書き。

【プロジェクト】
「Redmineのプロジェクトはどんな単位で作るべきか?」という質問は良く出る。

僕がTiDDをアジャイルに運用した経験から言えば、二つある。
一つ目はブランチのライフサイクルに合わせる。
二つ目はITILの運用保守プロセスに合わせる。

前者は、RedmineのプロジェクトがSCMリポジトリと1対1に対応している思想から、自然に扱える。
例えば、本番リリースしたソースは本番ブランチとして作られて、trunkとは別のコードラインで保守される。そして、次のメジャーバージョンが出たら、古い本番ブランチは廃止されて、以後は保守されなくなる。
つまり、プロジェクトとブランチが1対1に対応する状態遷移になる。

プロジェクト:新規作成→使用中→非公開→終了
ブランチ:新規作成→使用中→廃止(以後保守しない)

本番ブランチとtrunkをRedmineプロジェクトで別管理する利点は、ソースのライフサイクルもタスクの内容も異なるからだ。
本番ブランチは障害修正のみで、機能追加は基本はしない。
trunkはガンガン機能追加していくが、本番ブランチの障害修正があればマージ作業が発生する。
この時、trunkへのマージ作業は、本番ブランチの障害修正のタスクと別にしておく方が管理は楽になる。
マージ作業のタイミングは、本番ブランチの障害修正のタイミングと異なる時があるからだ。

後者は、ITILの4つの運用保守プロセスの観点で、Redmineプロジェクトが分割される。
例えば、プロジェクトと要望にあがった機能改善チケットのライフサイクルは下記のフローになる。

プロジェクト:開始→インシデント管理→問題管理→変更管理→リリース管理→終了

チケット:
開始
→改善要望は、インシデント管理でチケットに起票
→チケットは、問題管理でバックログに入れられる
→チケットは、変更管理でイテレーション計画に組み込まれて、タスクに分割される
→チケットは、リリース管理でタスクを担当者が開発&テストして、リリースして反映される
→終了

本来、改善要望をリリースするプロセスは、いきなりタスクカードに落とすのではなく、そもそも開発すべき対象なのか、どのバージョンでリリースすべきなのか、等の観点で吟味すべきだ。
実際、他の機能で既に実現されているのにユーザが知らないだけだったり、次バージョンに向けて現在開発中のタスクに含まれているならば、そのチケットは対応不要だからだ。

【ワークフロー】
「BTSでは問合せ管理がやりにくい」という話は良く出る。
それは当たり前で、BTSの標準ワークフローであるバグ修正と問合せを混同しているからだ。

運用保守も含めたSW開発を考えると、ワークフローもITILの運用保守プロセスで制御できると思う。
例えば、Redmineプロジェクトとワークフローは下記のような対応が存在するのではないか?

プロジェクト:開始→インシデント管理→問題管理→変更管理→リリース管理→終了

インシデント管理のワークフロー:新規→問合せ中→回答済み→終了
問題管理のワークフロー:新規→担当→調査解決→終了
変更管理のワークフロー:新規→担当→方針決定→終了(承認済み)
リリース管理のワークフロー:新規→担当→解決→検証中→検証完了→終了(リリース完了)

※あくまでも思いつき。

つまり、インシデント管理はオペレータ、問題管理や変更管理は設計者、リリース管理は開発者やテスター等のように、それぞれのプロセスでは担当者のロールが異なるし、チケットのライフサイクルも異なるし、ワークフローも大きく異なる。
パッケージ製品開発のように、製品開発部隊と品質保証部門、問合せオペレータ部隊などでチームが分かれているならば、別プロジェクトで別ワークフローにして管理した方が楽かもしれない。

【チケット】
「チケットは仕様書ですか?」「チケットの粒度はどれくらいですか?」という質問は良く出る。
TiDDをアジャイルに運用するならば、チケットはXPのタスクカードのように扱う。
つまり、チケットを作業指示書として扱う。
この手法はIssue Trackingと呼ばれる。

チケットをタスク管理に使えば、ガントチャートなどを生成できるから進捗管理できる。
チケットは元々バグ管理の障害報告票だから、バグ収束曲線を生成すれば品質管理もできる。
つまり、ITSのチケットはとても柔軟な概念。

そして、チケットをXPのタスクカードのように扱えば、その粒度は自然に細かくなる。
この時、チケットをストーリーカードにも使いたいと思うのはとても自然。
ストーリーカードとタスクカードの関係の制約は下記で表現できる。

・ストーリーカードの開始・終了日は、タスクカードの開始・終了日のUnionである。
・ストーリーカードのステータスは、タスクカードのステータスの共通集合である。
・ストーリーカードの工数は、タスクカードの工数の合計である

しかし、現状のRedmineでも、チケットを要件管理に使うのは難しい。

【バージョン】
バージョンをイテレーションに見立てると、自然にアジャイル開発になる。
バージョンのライフサイクルは下記になる。

バージョン:開始→実施前→実施中→終了(リリース済)

実施前ステータスは、リリース計画に基づいてバージョンを作ったものの、バージョンにあるチケットを精査しておらず、未完成な状態。
実施中ステータスは、イテレーション計画を立てて、どんな機能をリリースするか決定済みで、リリースに向けて作業中の状態。
そして、全てのチケットが終了ステータスになったらリリースできる。リリースしたら、Redmineのロードマップ画面からバージョンは非表示になり、変更履歴にChangeLogとして残る。

この時、リリースしたバージョンは、以前はSVNのTagでリネームしていた。
理由は、リリースする直前に必ずSVNでTag付けした後、本番ブランチを作り、ビルドモジュールをデプロイするから。
ビルド管理ツールHudsonを使い始めてから、「SVNタグ.ビルド番号」のような形式でリネームするようになった。

しかし、設計やテストでは、バージョンをリリース単位に分割するのは難しい。
複数のバージョンをこなした後に初めてリリースできる時もある。
これは、漸進型開発ではなく、反復型開発になっている。

つまり、バージョンをイテレーションに見立てる時もあるし、マイルストーンとして運用する時もある。

【SCM連携】
SCMコミットログにチケットNoを書くと、成果物の変更をチケットで追跡できる。
チケットに構成管理情報を付与できる点が、従来のBTSにはない大きな利点。
Excelの仕様書も構成管理すれば、ソースのように成果物の変更を追跡できる。

最終的には下記のようなトレーサビリティを実現できるはず。

要件→タスク→チケット←SVNリビジョン←ビルドモジュール

つまり、ビルドモジュールから要件まで辿れるし、逆に要件からビルドモジュールまで辿ることもできる。
この性質をうまく使えば、仕様変更やバグの影響調査をサポートできるし、リバースエンジニアリングも可能になる。

Hudsonのプロモーション機能を使えば、ビルド番号にも「優良ビルド」「不良ビルド」を色付できる。
例えば、リリースできるがまだ不安定なモジュールなら「不良ビルド」、本番ブランチでバグ修正を施したモジュールなら「優良ビルド」になるだろう。
それらビルドモジュールからチケットを辿り、それらチケットを集計すれば、バグの傾向分析もできるのではないか?

【レポート出力】
「MSProjectのレポートとRedmineのレポートを連携しにくい」という質問はよく聞く。
それは当たり前で、MSProjectはストーリーカードの観点、Redmineはタスクカードの観点で進捗管理しているからだ。
顧客向けの進捗報告を作る場合、Redmineから生成する進捗報告は粒度が細かすぎて、似合わない。
つまり、Redmineでストーリーカード、すなわち要件管理を実現できなければ、この問題は解決できない。

Redmineのデフォルトのチケット集計機能は若干不足しているけれども、いくつかのプラグインを使えば、バーンダウンチャートやイテレーション単位の進捗情報を作ることができる。

プロジェクトファシリテーションでは3つの道具が頻出する。
かんばん、ダッシュボード、あんどん。

かんばんはイテレーションの状況を表すボードで、ステータス毎のチケット集計結果に置き換えられる。
ダッシュボードはイテレーションの進捗を表すボードで、例えば、バーンダウンチャートだから、RedmineのChartsプラグインで置き換えられる。
あんどんはシステムが危険な状況になった時に出る警告のようなものだが、ソフトウェアあんどんでなくとも、Hudsonでビルドに失敗した時にメール通知すればいいだけだと思う。
つまり、PFのアイテムはRedmine上で容易に実現できるはず。

最終的にやりたいのは、PMBOKのEVMをRedmine上で出力したい。
PVは予定工数、ACは実績工数、EVは終了チケットの予定工数で対応付ければ、Redmineのチケット集計機能で実現できるはず。
実現できれば、EVMの各種メトリクスによって、コストやスケジュールのシミュレーションが可能になる。


チケット駆動開発は元々RedmineやTracのチケット管理から生まれた。
Redmineは、プロジェクト・バージョン・チケットの機能が柔軟なので、うまく運用すれば、いろんな使い方を実現できる。
チケット駆動開発でアジャイルに運用する手法はまだ確定していないけれど、ものすごく可能性を感じている。

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

2010/01/24

プロジェクト管理ソフトウェア

プロジェクト管理ソフトウェアの解説があったのでメモ。
TracやRedmineも比較した結果が書かれている。

【元ネタ】
プロジェクト管理の選び方と使い方&プロジェクト管理×15 at Cool Coding

下記の内容が秀逸。

(前略)
とはいえプロジェクト管理の目的はプロジェクトを成功させるための道具であり、プロジェクト管理を運用することではありません。
意外とその点が理解されておらず、プロジェクト管理をメンテナンスするための工数が大きくかけられてしまっていたり、細かく管理することだけが目的化してしまっている現場もよく見かけます。
(後略)

ツールに踊らされて、マネジメント工数がかかりすぎて、開発チームの生産性が落ちるようならば無意味。
かと言って、ツール無しで、Excelや紙の障害報告票で進捗管理するのも現実的でない。

PMBOKには「プロジェクトマネジメント情報システム」(PMIS)という概念がある。
これは、プロジェクトマネジメント・プロセスのインプットとアウトプットを収集し、配布するためのツール。
上記のプロジェクト管理ソフトウェアもPMISの一部と見なしてもいいだろう。

開発者にいかにマネジメント工数を意識させずに、プロジェクト管理情報を収集して、プロジェクトの意思決定を支援できるようにするか?
チケット駆動開発では、開発者の実績報告や管理者向けの進捗報告を自動集計する機能があるから、それを上手く使えば、透過的に支援できるはず。

PMISを使って、いかにアジャイル開発の運用を楽にするか?
今はその問題を追いかけている。

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

繰り返し開発の罠

萩本さんがアジャイル開発と反復開発について記事を書かれていたのでメモ。
#以下はあくまでもメモ書きです。

【元ネタ】
アジャイル開発と反復開発の落とし穴 - @IT自分戦略研究所

「現状のソフトウェア開発は間違っていないか?」(プロセス編) - @IT自分戦略研究所

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

「塹壕よりScrumとXP」

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

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

「反復開発は、管理重視型開発」「アジャイル開発は、価値重視型開発」と書かれていて、なるほどと参考になったのと同時に違和感があった。
確かにその傾向はあるけれど、本質はそこだけでは無い気がする。

RUPのような反復開発は、アーキテクチャや品質を作り込むためにプロセスを反復する。
しかし、1回の反復だけではリリースできるレベルまで開発できないし、リリースは普通最後の1回だけだから、結局ウォーターフォール開発と何ら変わらない感覚がある。

アジャイル開発は漸進型開発であり、小規模リリースを基本とする。
1回のイテレーションでリリース出来る機能を実装しながら、小刻みにリリースしていく。
だから、アジャイル開発ではリリース計画やイテレーション計画を作るのが非常に重要になってくる。
その意味では、アジャイル開発はリリース計画駆動と言ってもいい。

でも、僕がチケット駆動開発を実践してみて、小規模リリースの戦略だけでは不足していると経験した。
やはり、品質を作り込むイテレーションが別途必要な状況が存在するのだ。
例えば、複数のサブチームが並行して、イテレーションを繰り返してモジュールをリリースしていき、最後にそれらを結合する場合、結合テストのようなイテレーションが必要だ。
この状況が発生するのは、組み込み製品でソフトウェア部隊とハードウェア部隊が連携する場合や、大規模プロジェクトで複数のモジュールを結合する場合が相当する。

この時、TestLinkを使って、結合テストやシステムテストを行い、品質を作り込む。
その手法は、反復開発に切り替えているのだ。
つまり、繰り返し開発は漸進型開発と反復開発を切り替える戦略が重要だと思う。

そして、繰り返し開発を使いこなすには、並行開発のインフラが必要になってくる。
つまり、「塹壕よりScrumとXP」にもあるように、ブランチを上手に使いこなす必要がある。

漸進型開発であれ、反復開発であれ、繰り返し開発を行うと、必ずブランチが発生する。
漸進型開発ならば、リリースしたソースは本番ブランチとして、次のメジャーバージョンまで生き続ける。
反復開発ならば、検証中のソースはタスクブランチとして、trunkへコミットされるまで生き続ける。

すると、ブランチとtrunk間のマージ作業が発生し、並行する複数のブランチをどのタイミングでマージするか、難しくなる。
デグレが起きないようにマージするのは、たとえチケット駆動開発であろうとも簡単ではない。

ブランチとtrunk間のマージ作業の問題に対する一つの解決方法として、MercurialやGitのような分散バージョン管理を上手に使いこなすのがあげられる。
そのやり方は、Mercurialによるチケット駆動開発は強力だ!: プログラマの思索に書いた。

つまり、繰り返し開発が難しい理由は、漸進型開発と反復開発を切り替える戦略が無いこと、そして、並行開発を制御する構成管理のインフラがないことにあるのだと思う。

繰り返し開発は試行錯誤しながら問題を解決する仕組みだとすれば、別にソフトウェア開発だけの代物ではないし、どんな人でもその利点は理解できる。
しかし、繰り返し開発に関するソフトウェア開発特有の問題を認識していないから難しいのではないか、と思ったりする。

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

2010/01/21

RedmineとTracの機能比較part2

RedmineとTracを比較した感想が書かれていたのでメモ。

【元ネタ】
これから使うならTracとRedmineどちらがよいか? - プチ技術メモ

Twitter / NeKo: [B!] たしかに最近Tracの動きは閉塞感が漂う。 ...

Redmineは年に1回大きなVerUpと、バグFixのマイナーVerUpが頻繁にある。
この1月中に大きな機能改善がリリースされるだろうver0.9を多くの人達が待っている。

しかし、Tracは前回のリリースから1年以上経つのに、ver 0.11のままでVer1.0にVerUpしていくロードマップすらはっきりしていない。

以前はTracの方が使い易かったし、プラグインも豊富だったけれど、Redmineはここ1年で急速に機能改善して、TracでできることはRedmineでもほぼできる。
Railsなので、Rails特有の思想さえ理解できれば、プラグインを作ってRedmineを機能拡張するのも容易だ。

RedmineもTracも、MSProjectによるプロジェクト管理を乗っ取るのが隠れた目的だと思う。
その中でもRedmineは、確かにMSProjectのリソース平準化やEVMの機能はまだ実現できてないが、チケットを有効活用することによって実現できる可能性がある。

そして、MSProjectにない機能として、構成管理ツールと連携したり、ワークフロー管理できる点がある。
何よりも、ロードマップ画面をリリース履歴になるように運用することによって、自然にアジャイル開発のプロジェクト管理にできる点が最大の利点だと思う。

今後の動向を見守りたい。

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

Railsの性能検証報告書

IPAなどがRuby on Railsに関する性能検証報告書を公開していたのでメモ。

【元ネタ】
自治体・企業等の情報システムへのRuby適用可能性に関する調査(「技術検証報告書」)PDFドキュメント || OSS iPedia

RailsとJavaのHibernateを性能比較した結果、「Rails+Passenger+memcached+(SQLのチューニング)でJavaと性能はほぼ同等か高速になる」とのこと。
「Railsは遅い」と言われる原因は、ActiveRecordがテーブルと密結合のため、SQLの発行回数が増えてしまっているからだと検証している。

この報告書を読むと、Railsは運用ノウハウさえ溜まれば、エンタープライズのシステム開発にも十分に使える感触を持った。
Javaに比べると、RailsとAjaxの相性の良さ、memcachedをKVSとしてDB周りを高速化、など最近の最新技術も使われていて、技術者としてはとても興味をそそる。
Railsの開発環境も、EclipseやAptanaがあれば、Javaと同じ感覚で開発できるようになっているから、問題ない。

個人的には、Rails+Oracleの開発ノウハウが欲しい。
実際の業務システム開発では、OracleをDBとして使っているケースが多いため、RailsとOracleの相性に問題なければ、すぐにリプレースすることもできるだろう。

そんな状況を見るにつけ、Railsでサクサク開発するイメージは下記を夢想している。

Excelのテーブル定義書から、Railsのマイグレーションプログラムを自動生成

Rails+Oracleでマイグレーションして、DBスキーマを一発生成

Railsのscafoldでマスタ保守画面はあっという間に実装完了

業務ロジックはRubyでサクサク書く。
リッチなUIはRailsと相性が良いAjaxで実装する。
デザインはCSS修正をデザイナーにお任せ。

DBチューニングは、memcachedでKVSっぽく実装して高速化する。

JRuby+warblerでビルド後、Tomcatへデプロイして終わり。

Railsを取り巻く開発状況は、この1年で急速に変化しているので、今後も注目していく。

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

ムードル・ムート函館2010年

オープンソースのeラーニングシステムMoodleのカンファレンスの情報があったのでメモ。

【元ネタ】
MoodleMoot Japan 2010 Hakodate ムードル・ムート函館2010年

Moodle.org: About

連載:eラーニングシステム Moodleの活用とカスタマイズ|gihyo.jp … 技術評論社

Moodle入門
Moodleを使って授業する!
遠隔教育

上記をみると、大学関係者が授業をeラーニングで行う手法に大きな可能性を持っていることが分かる。

また、下記のMoodleを使って授業する!なるほど簡単マニュアルのAmazonレビューが気になった。


(中略)
Moodleは使い慣れてくるとかなり便利で、
教材の配布、評価などは一度つかったらやめられないんですが、
いかんせん使い方が難しいというか分かりにくい。
(後略)

MoodleはLAMP(PHP)で作られているので、インストールしやすいが、日本語の情報も少なく、まだまだ運用ノウハウも少ない。

しかし、丁度、RedmineやTracがSW開発のプロジェクト管理を大幅に技術革新しているように、Moodleによって、今までにない発想で教育インフラを提供できる可能性がある。

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

hgbook 日本語版のHTML公開

分散バージョン管理Mercurialの「BOS本」がHTMLで公開されていたのでメモ。

【元ネタ】
hgbook 日本語版 HTML 公開 - 彷徨えるフジワラ

hgbook 日本語版

有志が日本語化+公開してくれたようです。
簡単に見れるのでとてもありがたい。

個人的には、バージョン管理ツールの歴史を整理している1 Introductionがとても興味深い。
今後のバージョン管理の方向性を考える上で参考になる。

12 Managing change with Mercurial Queuesは、MQの解説。
オープンソースで主流のパッチベースの開発スタイルと密接に関係していると思う。

TortoiseHgを使っている人は必見ですね。

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

2010/01/19

何故チケット駆動開発はタスクやイテレーションの変更に強いのか?

Redmine.JP | Redmine on Twitterを見ていて、下記の質問は、「何故、チケット駆動開発はアジャイル開発に使えるのか?」「何故、チケット駆動開発はタスクやイテレーションの変更に強いのか?」を示唆するヒントだと直感した。
考えた事をメモ。
#下記はあくまでも一つの参考意見。

【元ネタ】
Twitter / EG: Redmineとかtracとかで「ちょっと気になって ...

Redmineとかtracとかで「ちょっと気になってること→対応すべきこと」というレベルアップや「○○バグの修正」と「ソースの全般的な修正」のような規模の違うものをどう扱うのがいいのだろう


上記の質問に対する回答としては、二つあると思う。
一つ目は、タスクの内容に応じてワークフロー(トラッカー)を変えて管理する。

チケット駆動開発の基本ルールは「チケットファースト」。
プロジェクト内部の作業はチケットを受け取ってから始めるのが基本。
チケットがあれば作業履歴が残るし、作業状態や進捗情報をリアルタイムにモニタリングできる。

すると、チケットには、機能追加やバグ修正だけでなく、リファクタリングや設計作業、リリース作業、問合せなど各種の仕事がどんどん登録されてしまう。
だから、チケット駆動開発を使いこなすには、チケットを上手に使いこなすのが最優先だ。

Redmineでは、チケットの種類がトラッカーに相当し、ワークフローと1対1に対応している。
従って、作業の種類をトラッカーに対応付けて、作業特有のワークフローをチケットのワークフローで管理すれば、ソフトウェア開発の全ての作業をチケット駆動開発で制御できる。

つまり、ソフトウェア開発で発生する業務フローをきちんと設計ないしモデリングできていれば、トラッカーは自然に定まる。
この作業は、SIが各種業界の業務を設計してシステムを構築する作業と同一だ。
即ち、実は自分達のソフト開発業務をきちんと設計していない、つまり開発プロセスをきちんとモデリングできていない現場が多いから、混乱しているのだろう。

例えば、「ちょっと気になってること」は「ToDo」のチケット、「○○バグの修正」は「バグ修正」のチケット、「ソースの全般的な修正」は「リファクタリング」のチケットなどのようにワークフローを変えて登録しておけばいいと思う。

二つ目は、最初はチケットをToDoのように扱ってまずは登録しておき、そのチケットが必要になった時点で更に分割し、リリースするイテレーションにアサインしてから、作業を管理する。つまり「分割統治」の運用ルールを使う。

実際のソフトウェア開発では、WBSで洗い出したタスクをチケットへ一括インポートしてから作業するが、仕様変更や突発的なタスクの発生によって、当初登録したチケットの内容が変わり、更にチケット枚数は大幅に増える時が多い。
このタスク管理をExcelやMSProjectで行うと、度重なる変更に追いつかない時が多い。

RedmineやTracのようなチケット駆動開発をサポートするITSでは、チケットの登録や変更がすごく柔軟な利点がある。
本来BTSだったので、突然発生したバグ報告を登録しやすくする機能が付いているから、その機能を一般のタスク登録に拡張して運用すればいいからだ。
例えば、突然発生した仕様追加は、タスクの内容をチケットに登録して1枚作ればいい。

又、機能追加のチケットを担当しているのに、実はリファクタリング作業に工数がかかっているならば、リファクタリング用のチケットを別出しにして、そちらのチケットを最優先に作業すればいい。
そして、機能追加とリファクタリングのチケットを関連付けておけば、忘れる事もなくなる。

同様に、以前、ToDoのチケットを登録して、いざ作業を開始すると、作業の種類が変わったならば、トラッカーを変更して、その作業特有のワークフローへ切り替えればいい。
このパターンに当てはまる場合は、以前はToDoのチケットだったが、リファクタリングや機能追加のチケットに切り替えて作業を開始する時だろう。
当然、作業の開始日や期限日も現状に合わせて修正すればいい。

上記のようにチケットの内容だけでなく種類(トラッカー)も簡単に変更できるから、タスク変更がしやすいので、アジャイル開発しやすいのだ。

あるいは、Ver1.0のチケットは、ユーザと調整して後回しになった場合、そのチケットのリリース予定バージョンを新しく作ったVer1.1へ延期する時もあるだろう。
つまり、イテレーション計画やリリース計画を途中で変更しても、イテレーション間でチケットを移動すればいい。
そのイテレーションを2~4週間のサイクルで順次リリースしていけば、自然に「小規模リリース」を実現できる。

チケット駆動開発がアジャイル開発しやすいのは、上記のようなイテレーション管理もやりやすい利点があるからだろう。

以上のような運用が開発チームに馴染めば、システムのバージョンが自然にイテレーションとなり、自然にアジャイル開発になってくる。
イテレーションのリズムが生まれれば、プロセスがループする事によって、自然にプロセス改善できる。

チケット駆動開発が自然にアジャイル開発になる理由がそこにあるはずだ。

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

2010/01/18

2010年2月第1週はScrumとXP祭り関西の週です

2010年2月4日(木)から連続4日間で、ScrumとXPに関するイベントが行われるようだ。

【元ネタ】
Always All Ways: [IT] 冬のすくすく祭り?

1) 2月4日 第9回すくすくスクラム in 広島 ~Catch the Scrum~【広島】
  
2) 2月5日 第1回すくすくスクラム瀬戸内 ~ソフトウェア開発の3つの嘘~【岡山】
  
3) 2月6日 XP祭り関西2010 ~アジャイルマインドを育もう~【大阪】
  http://www.xpjug.jp/
  
4) 2月7日 第10回すくすくスクラム in 名古屋 ~朝会を極めろ~【名古屋】

広島→岡山→大阪→名古屋と西から東へ向かうらしい。
東京以外の人達は近場へ是非参加してみてはいかがだろうか?

別件だが、下記のHPを見ると、MSやIBMもアジャイル開発を支援する意思はあるようだ。
彼らが現場で通用するノウハウをどこまで持っているのか、追いかけてみたい。

マイクロソフトのアジャイル開発支援
IBM チーム開発の決め手はアジャイル - Japan
IBM Rational アジャイル開発 - Japan

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

2010/01/15

Redmineの最後の課題~チケットの親子関係

Redmine.JP BlogにあるRedmine0.9xの機能の解説が素晴らしい。

Redmine 0.9 新機能紹介(6): プロジェクトのコピー | Redmine.JP Blog

プロジェクトのコピー機能を使いたい場面は、以前のプロジェクト設定をテンプレート化しておきたい時だ。
例えば、Ph1のプロジェクトが終わって、Ph2のプロジェクトを開始する時、前回のプロジェクト設定をそのまま使えると楽になる。
特に大規模プロジェクトでは、サブチームのタスク管理の構造は殆ど同一だろうから、テンプレートを引継ぎできると、すぐにタスク管理を始められる。

Redmine 0.9 新機能紹介(7): チケット一覧画面の改善 | Redmine.JP Blog

チケットのグルーピングができるようになったのが良い。
これによって、ステータス単位でグルーピングすれば、PFのかんばんと同等の画面になる。
つまり、かんばんは、ステータスごとのチケット集計結果に過ぎないのだ。

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

チケットのステータスを変更すると、進捗率を自動で更新してくれる。
例えば、「新規」は0%、「担当」は50%、「解決」は80%、「終了」は100%のように決めておけば、メンバーがチケットのステータスを変更すると進捗率が自動で定まる。
進捗率とステータスの関係をプロジェクトの運用ルールにしてしまえば、進捗報告が楽になる。

小技(0.9): バージョンのロックと終了 | Redmine.JP Blog

Tracのマイルストーンの状態には「完了」ステータスがあるから、完了したマイルストーンはチケットから選択できない。
しかし、Redmineのバージョンは状態を持たないので、リリースして終了したバージョンもチケットのリリース予定バージョンに表示されてしまう。
Redmineをアジャイル開発で使う場合、イテレーションをバージョンと同一視する為、バージョンが膨大に増えるので、扱いづらかった。
この機能のおかげで、終了したバージョンはチケットに表示されなくなるので、より便利になった。

他は、Redmineの最新動向: プログラマの思索に書いた。

ただ、Redmine0.9xでは、
・プロジェクトは無制限に子階層を持てるので、大規模プロジェクトのタスク管理に適用しやすい
・親プロジェクトのバージョンを継承できるので、システム全体のイテレーションを意識させやすくなる
のような機能があるのに、チケットの親子関係は実装されていない。

下記のチケットで、Redmineチケットにサブタスクを持てるようにするかどうか、議論されている。
RedmineコミッタJean-Philippe Langと、開発者のEric Davisのやり取りが面白い。

Redmine - Feature #443: Subtasking - Redmine

Exciteで機械翻訳させてみる。

Jean-Philippe Lang:

(Eric Davisが投稿したパッチは)巨大なパッチです。 それは徹底的なレビューの必要があります、そして、残念ながら、1.0の一部でなくなるでしょう。

Eric Davis:

私はここで直接的になるでしょう: 1.0にSubtasksを含まないのは、巨大な誤りでしょう。 現在毎日、私は、だれかが子タスクを持たないことでRedmineの周りで尋ねるか、または不平を言っているのを聞きます。
再びとても多くの人々が、皆がした仕事のそれとすべてに働きを作成して欲しい後部がそれのために修理するこの特徴を押すのは、恥(私は137のアップデートを何人かの気が狂ったハッキングと共にそれを自分たちで実行しようとする、この要求、79人のウォッチャー、および少なくとも3つのプラグインまで数えている)でしょう。

私は、12月にパッチをコアで働かせるようにアレクセイ・グセフからプラグインを見直して、移植するために既に40時間以上を費やしました。 それは完全な実現ではありませんが、それは人々が現在使用できる解決策です、そして、私たちは1.0次の6カ月前の間それを改良できます。


実際、チケットに親子関係を入れるアイデアは従来から知られており、実に多くの人達が多数のパッチやいくつかのプラグインで対応しようとしていた。
例えば、Scrum系プラグインは特にそうだ。

チケットの親子関係を持ちたい理由は、チケットに階層構造とその制約条件を課す事で、ストーリーカードとタスクカードの関係を簡単に実現できるからだ。
あるいは、ストーリーカードそのものを階層化して、チケットを要件管理にも使えるだろう。
そのアイデアは下記に書いた。

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

Redmineプロジェクトやバージョンに階層構造があるのだから、チケットにも階層構造を入れて欲しい。
そうすれば、Redmineに足りない機能はもうない。

「チケットの親子関係」だけがRedmineの最後の課題になるだろう。

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

2010/01/14

アーキテクチャの変遷

下記の記事を読んでメモ。

スケールアウトからスケールアップへの回帰:江島健太郎 / Kenn’s Clairvoyance - CNET Japan

流れは、Webサーバーのスケールアップから、DBのスケールアップに向いている。
最近流行のクラウドの正体は、単なるASPの代替ではなく、MapReduceアルゴリズム+並列処理による高速化にあると思う。
だからこそ、NoSQLやkey-valueストア、Erlangなどの関数型言語やRuby・Pythonなどのスクリプト言語が流行しているのだと思う。

メディア不況がやってくる(ホームサーバの戦い・第46章):夢幻∞大のドリーミングメディア - CNET Japan

オープンソースと著作権に関わる知識を僕は完全に持っていないので、以下はあくまでもメモ。

Blogはグーテンベルクの印刷技術以来の革命と言われるように、巨大マスメディアから個人へ情報発信の流れが変わりつつある。

出版社からAmazon・GoogleのようなIT屋へ。
音楽レーベルからAppleへ。

コンテンツの主導権も変わりつつある。

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

2010/01/13

TortoiseHgでMercurial Queuesを使う

TortoiseHgでMercurial Queues(MQ)を使う方法についてメモ。

【元ネタ】
TortoiseHgでMQを使う | endflow.net blog

BOSBook | Inside ASCADE

Mercurial Queues Extension を使う - ursmの日記

(前略)
MQ は特定の変更をパッチとして扱うための Mercurial extension で、あるリポジトリに対して一部を変更しつつ同期を取ることを可能にします。
(後略)

mercurial.iniに下記を追加すると、MQが使えるようになる。

[extensions]
hgext.mq=

MQは、Mercurialコミットログを後から変更出来る黒魔術。
何故MQのような複雑な使い方が必要になるのか?
理由は、マスターリポジトリと同期しながら、ローカル環境で変更を加えていきたいからだ。
いわゆるパッチベースのソース修正。

分散バージョン管理を使いこなすならば、マスターリポジトリとPullで同期しながら、パッチを作ってはPushするというやり方が重要になってくる。
多分その時に必要になるのだろう。

とはいえ、「入門Mercurial Linux/Windows対応」にもMQを詳しく説明しているが、正直使い方が分からない。
TortoiseHgならばGUI上で操作できるので、試してみたいと思う。

|

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

RedmineのVer0.8.4、0.8.6に入れたプラグインのうち、使っているものを公開してみる。
1年前に比べると、プラグインが充実していて楽しい。
結局10個以上も入れていた(^^;)

【コードレビュー】
r-labs - Code Review - Redmine
Redmineのプラグインが充実している: プログラマの思索

リポジトリ画面からコードレビューのチケットを発行して、レビューをワークフロー管理できる。
お手軽にコードレビューできるのがいい。
レビューもチケットにするから、ワークフローのカスタマイズも可能。

【Hudson】
r-labs - Hudson - Redmine
Redmineのプラグインが充実している: プログラマの思索

Hudsonと連携して、ビルド管理する。
SimpleCIプラグインよりもはるかに機能が充実している。

【Wiki拡張】
r-labs - Wiki Extensions - Redmine

Wikiにリンクするサイドバーを作れる。

bitherder's redmine_markdown_formatter at master - GitHub

juno's redmine_markdown_extra_formatter at master - GitHub

いずれも、Wikiの書式にmarkdownを追加する。
但し、
gem install rdiscount
gem install rpeg-markdown
gem install bluefeather
が必要。
すると、設定画面の「テキストの書式」項目に「markdown」「markdown extra」が表示される。

RedmineのWikiはTracよりも使い勝手が悪い弱点がある。
しかし、上記のプラグインを使えば、普通のWiki記法が使えるようになる。
Wikiをバリバリ使う場合、このプラグインを使う方がいいだろう。

【バグ収束曲線】
Redmineのプラグイン (3) ゴンペルたん: これ本番ですか?
Redmineの集計プラグイン、statSVN諸々: プログラマの思索

チケットの累積数、残存数などを集計表示してくれる。
チケット数からプロジェクトの活発具合を見ることができる。
但し、チケットをCSV一括インポートした場合、急激にグラフが上がるので、分析の時は注意する。

Redmine - PluginCharts - Redmine
redmine_chartsプラグインでバーンダウンチャートは表示可能: プログラマの思索

バーンダウンチャートを表示してくれる重要なプラグイン。
また、下記のようにPMBOKのEVMの概念と密接に関係する。

・残り時間 → バーンダウンチャートに相当する。
・予測完了時間 (経過 + 記録) 時間 → 経過時間+残り時間。完了までに必要な工数(予測値)。
・経過時間 → 今日までの総実績工数。ACに相当する。
・見積時間 → 今日までの総予定工数。PVに相当する。

EV:今日までの終了チケットの総予定工数 も表示してくれれば、PMBOKのコスト管理で頻出するPV・AC・EVのグラフになる。
更に、CV・SV・CPI・SPIなどEVMの各種メトリクスを時系列で表示できれば、プロジェクト管理の精度がかなり上がる。
やりたいことは下記のようなこと。

[ThinkIT] 第2回:EVMの基本値から導出される値の説明と練習問題 (1/4)
プロジェクトマネジメント・コンサルティング・サービス会社 ピーエム・アラインメント PM Alignment
チケット駆動開発にEVMの概念を導入してみる: プログラマの思索

CV・SV・CPI・SPIを時系列に並べるだけで、スケジュールやコストが悪化しつつある状況を理論的に説明できるはず。

【ガントチャート】
2つめブログ バージョンガントチャートPlugin 0.1 完成

バージョン単位でガントチャートを表示する。
アジャイル開発でイテレーション単位の進捗を見たい場合、とても便利。

【改良ロードマップ】
Redmineプラグイン開発 - Roadmapsプラグインリリース - フジハラボ -- 目指せ!スーパーエンジニア

ロードマップを改良した画面。
バージョン単位の進捗や予定・実績工数を詳細に表示してくれる。

Roadmapsプラグインに出てくる項目がPMBOKのEVMと密接に絡んでいることは、下記に書いた。

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

アジャイル開発の場合、プロジェクト全体のEVMではなく、イテレーション単位でEVMを見たい。
理由は、現場リーダーも開発者もイテレーションの作業に集中しているから、作業中のイテレーションの状況を色んな角度で分析したいのだ。

【工数管理】
WorkTime - kusu - A redmine plugin to view and update TimeEntry by each user. - Project Hosting on Google Code

開発者毎に工数管理(日毎入力、月間集計)できるプラグイン。
自分が今日1日でどのチケットに何時間費やしたのか、を簡単に把握できる。
実績工数を時系列・チケット別に並べてくれるので、非常に使い易い。
このプラグインがあれば、工数管理は十分と言えるだろう。

estimate_timelog - へたれエンジニア日記 ver.2

Redmine標準の工数レポート機能を拡張した工数集計プラグイン。
チケット・カテゴリ・トラッカー・バージョンなどの単位で、予定・実績工数を並べて表示してくれる。
イテレーション単位、指定した期間で予定・実績工数を集計表示してくれるから、ざっくりとプロジェクトの進捗を見ることができる。

当然、検索条件で集計した総予定工数がPV、集計した総実績工数がACに相当する。
故に、PMBOKのEVMと密接に絡んでいる。

【CSVインポート】
Redmine_Importer: Redmine CSV Import Plugin | Martin Liu - Martin's Crazy World

チケットを一括インポートするなら、このプラグインでCSV一括インポートすればいい。
チケットのカスタムフィールドにも対応しているので便利。

但し、
gem install fastercsv
が必要。

インポート用CSVは、Redmineのチケット一覧画面からCSV出力したものをカスタマイズして作ればいい。
そのCSVを上記のプラグインでインポートすれば、簡単に取り込める。

但し日本語化されてないので、下記の日本語化されているプラグインを使えばいいだろう。
日本語化してくれた作者に感謝!

juno's redmine_importer at master - GitHub


Redmine - User CSV import plugin v0.0.1 - Redmine

RedmineのユーザをCSVで一括インポートするプラグイン。
メンバーを大量登録するなら、このプラグインを使えばいいだろう。

【メンバーの作業一覧】
Redmineプラグイン開発 - 史上最高のチームプラグインリリース - フジハラボ -- 目指せ!スーパーエンジニア
Redmineのプラグインが充実している: プログラマの思索

毎日の予定・実績工数から、成績表のように採点してくれる。
工数集計は管理者の観点ではすごく重要だが、管理者だけでなく、開発者も楽しんで欲しい。
チケット駆動開発はプロジェクトファシリテーションと相性がいいので、チームの雰囲気を和ませるのに使えるのではないだろうか?

こう見てくると、Redmineのプラグインはすごく充実している。
以前指摘した「工数集計が不十分」という弱点も十分にカバーされている。

又、日本人作者が作ってくれたプラグインが非常に使いやすい。
かゆいところに手が届く感じ。
改めて作者に感謝!

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

2010/01/12

RedmineプラグインRodmapsにEVMの機能を追加する

Redmineのロードマップス・プラグインにEVMの機能を追加するアイデアをメモ。
下記はあくまでもラフなメモ。

【元ネタ】
Redmineプラグイン開発 - Roadmapsプラグインリリース - フジハラボ -- 目指せ!スーパーエンジニア

Redmineのチケット集計機能を強化するプラグイン: プログラマの思索

Redmineの集計プラグイン、statSVN諸々: プログラマの思索

プロジェクトマネジメント・コンサルティング・サービス会社 ピーエム・アラインメント PM Alignment

PMBOKのEVMは「WBS/EVMによるITプロジェクトマネジメント」が一番分かりやすい。
公式とその具体例がグラフで掲載されているので、理解しやすい。

EVMがすごいのは、PV・AC・EVというたった三つの値で、今後のコストやスケジュールを予測できてシミュレーションできることだ。

EVMをRedmineに実装したいのは、PV・AC・EVという三つの値は既にDBに格納されているので、今後のコストやスケジュールを簡単にシミュレーションできるからだ。

PMBOKのEVMで定義されているPV・AC・EVは理解しづらいが、Redmineによるチケット駆動開発上では、下記のように簡単に定義できる。
特に、EV(達成価値)が「終了チケットの総予定工数」として表現できるのに注意せよ。

【RedmineにおけるEVMの定義】
・BAC:プロジェクト総予算 → 全チケットの総予定工数に相当する。

・PV:計画出来高 → 今日時点のチケットの総予定工数に相当する。
・AC:実績コスト → 今日時点のチケットの総実績工数に相当する。
・EV:実績出来高 → 今日時点の終了チケットの総予定工数に相当する。

・SAC:当初予定期間 →「プロジェクトの期限日-プロジェクトの開始日」に相当する。

【EVMの計算式】
・スケジュール差異。SV > 0なら予定よりも進捗が進んでいるので良い。
SV = EV - PV

・コスト差異。CV > 0なら予定よりもコストがかかっていないので良い。
CV = EV - AC

・スケジュール効率指数。SPI > 1なら予定よりも進捗が進んでいるので良い。
SPI = PV / EV

・コスト効率指数。CPI > 1なら予定よりもコストがかかっていないので良い。
CPI = AC / EV

・危険度指数。SPIとCPIが共に1.0未満の場合、CRはより小さくなる。スケジュールやコストを含めたプロジェクト全体の効率指標と言える。
CR = CPI * SPI

・出来高パーセント。プロジェクトの全体価値に対してどのくらい(何%分)達成しているかを表す。
PC = 100 * EV / BAC

・残作業効率指数。残作業を残予算で完了するために必要なコスト効率。例えば、TCPIが1.5ならば今よりも1.5倍働かないと、採算が合わなくなる。
TCPI = (BAC-EV) / (BAC-AC)

・完成時総コスト見積り。上司や顧客にとってすごく重要。CPI < 1ならば、予定よりもコストオーバーになる。
EAC = BAC / CPI

・完成時コスト差異。VAC<0ならば、コストオーバー。
VAC = BAC - EAC

・完了期間予測。上司や顧客にとってすごく重要。SPI < 1ならば、予定よりも納期が遅れる。
TEAC = TAC / SPI

・完了時期予測差異。TVAC<0ならば、納期が遅れる。
TVAC = SAC - TEAC

・完了予定日=プロジェクト開始日 + TEAC

【RedmineのRoadmapsプラグイン】
Redmineプラグイン開発 - Roadmapsプラグインリリース - フジハラボ -- 目指せ!スーパーエンジニア

Roadmapsプラグインはバージョン単位の進捗を集計表示してくれる。
実は、Roadmapsプラグインで出てくる値はEVMの概念とほぼ似ている。

・進捗(%) → 終了チケット数/総チケット数。チケットの工数の粒度が安定していれば、PCとほぼ一致するはず。
・バージョンの期限日-バージョンの開始日 → 当初予定期間。SACに相当する。
・予定工数 → バージョンに紐づく全チケットの総予定工数。BACに相当する。
・経過時間 → 今日時点のチケットの総実績工数。ACに相当する。

できれば、EVとPVの値を集計表示して欲しい。

・実績出来高:EV → 今日時点の終了チケットの総予定工数
・計画出来高:PV → 今日時点のチケットの総予定工数

そうすれば、バージョン単位で下記の値を計算できる。

・スケジュール差異:SV = EV - PV
・コスト差異:CV = EV - AC
・スケジュール効率指数:SPI = EV / PV
・コスト効率指数:CPI = EV / AC
・危険度指数:CR = CPI * SPI
・出来高パーセント:PC = 100 * EV / BAC
・残作業効率指数:TCPI = (BAC-EV) / (BAC-AC)
・完成時総コスト見積り:EAC = BAC / CPI
・完成時コスト差異:VAC = BAC - EAC
・完了期間予測:TEAC = TAC / SPI
・完了時期予測差異:TVAC = SAC - TEAC
・完了予定日=バージョン開始日 + TEAC

Rodmapsプラグインはサブプロジェクト単位でバージョンの進捗を集計してくれるから、最終的にはサブプロジェクトやプロジェクト全体のEVMを計算することができる。
つまり、チケットの入力ルールが徹底できれば、Redmine上でスケジュールだけでなくコストの管理も可能だ。

あるいは、プロジェクト開始前に、WBSをチケットにして、予定工数と実績工数をチケットの属性として登録して一括インポートすれば、プロジェクトの進捗やコストをシミュレーションできる。
そのシミュレーションでは、納期やコストが予算内に収まるSPIやCPIの下限値を計算できると良い。
そうすれば、その下限値よりSPIやCPIが低くなるならば、プロジェクトが危険な状況になった、というアラームを知らせることができるだろう。

WBS/EVMによるITプロジェクトマネジメント」では、SPIやCPIが0.9以下になると危険というアドバイスがある。
実際のプロジェクトで、実績を貯めていければ、予測しやすくなると思う。

EVMの公式にある概念は、パイロットが操縦している時の計測器に喩えられる。
パイロットの部屋は、計測器だらけ。
理由は、飛行機を操縦する時に現在の状況を確かめるには、実際の窓から見ることはできず、たくさんの計測器によって知るしかないからだ。
SW開発のプロジェクト管理も同様だ。
EVMのたくさんの概念を計測して、実際のプロジェクトの危険度を察知できれば、Redmineはかなり強力なツールになるだろう。

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

2010/01/11

Haskellの環境づくり

Haskellをちょっとやりたくて、Eclipseで開発環境を作ってみた。

【元ネタ】
EclipseでHaskellする方法 - 妄想宝箱

GHC又はWinHugsはインストール済みと仮定。

Pleiades - Eclipse プラグイン日本語化プラグインから、Eclipseをダウンロード

http://eclipsefp.sourceforge.net/updates/ からプラグインをインストール。

GHC、WinHugsをコンパイラに設定する。

Eclipseは、HaskellだけでなくScalaもErlangも動くから、とても便利だ。
とはいえ、コード補完もできないし、デバッグもできないし、リファクタリングもできないので不便だが、コードの色分けやコンパイラ実行、検索はできる。

Haskellの勉強は、「プログラミングHaskell」がお勧め。
ケンブリッジ大学の講義録らしく、序章では関数型言語のプログラムがどのように動くのか、易しく説明されている。
以前「ふつうのHaskellプログラミング ふつうのプログラマのための関数型言語入門」を読んで結局よく理解できなかったけれど、「プログラミングHaskell」なら関数型言語のアイデア、思想がよく分かると思う。


Haskellを書きたいなら、「Real World Haskell―実戦で学ぶ関数型言語プログラミング」がお勧め。
プログラミングは結局、たくさん書いて動かして、実際にデバッグしてみて、体で覚えなければ実践では使えない。

日本語の機械訳ぽいページが下記で公開されている。

Real World Haskell (jp)

やりたいのは、設計工程のモデリング作業の補完。
形式手法ではなくHaskellでモデルの整合性をチェックしたいのだ。
色々試したい。

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

2010/01/09

TestLink1.9beta1が出ている

TestLink1.9beta1が出ているのでメモ。

【元ネタ】
TestLink - open source Test management - TestLink 1.9 Beta1 available

TestLink - open source Test management - Roadmap

TestLinkもRedmineと同様に、1年おきにメジャーバージョンアップしているようだ。
今年は、ver1.9にバージョンアップするらしい。

ピンと来る機能はないけれど、「Requirements versions」には惹かれる。
この機能はおそらく、要件にバージョン付けできることだから、アジャイル開発のイテレーションに流用できるだろうと思う。

Ver1.9のロードマップで気になるのは下記の機能だ。

・Requirements: full compliance for n-depth structure
・Test Specification review process

前者は、要件に階層構造を入れること。
後者は、テスト仕様にレビュープロセスを入れること。

前者によって、テストケースにテストスイートのような階層構造があるように、要件も階層構造が入るので、要件を細かく分別して管理できるようになる。
以前は要件は1階層しか許されなかったので、工程・画面・機能などの単位で書くのが面倒だった。

後者はまだよく分からない。
でも、レビューは重要と従来から言われているにも関わらず、どのように運用すれば効果的なのか、誰も分かっていない気がする。
TestLinkでレビュープロセスが実現できるならば、是非試してみたいと思う。

RedmineだけでなくTestLinkのバージョンアップにも要注意だ。

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

2010/01/08

Redmineの最新動向

Redmine0.9.xの新機能の解説記事が素晴らしいのでメモ。

【元ネタ1】
Redmine 0.9 新機能紹介(4): ユーザーは複数のロールに所属可能 | Redmine.JP Blog

Redmine 0.9 新機能紹介(3): ユーザーグループ | Redmine.JP Blog

Redmine 0.9 新機能紹介(2): バージョンの継承 | Redmine.JP Blog

Redmine 0.9 新機能紹介(1): 無制限のプロジェクト階層 | Redmine.JP Blog

「プロジェクト階層は無制限」「子プロジェクトへ親プロジェクトのバージョンを継承させる」機能を使いこなせれば、大規模プロジェクトでも、サブチーム単位のタスク管理を制御しやすくなり、システム全体のイテレーションを意識させやすくなるだろう。

又、「ユーザーは複数のロールに所属可能」機能も、マトリクス型組織では非常に有効だ。
普通のSIでは、1人の開発者は複数のプロジェクトを兼任している時が多い。
例えば、運用保守プロジェクトでは開発者だが、プロジェクトBではヘルプでテスターをしている場合、同一ユーザをプロジェクトごとにロールを分ける事ができれば、管理しやすくなる。

【元ネタ2】
redmine 0.9の Wikiとプラグイン - あぁ そうだった

(中略)
「バージョンに状態(進行中、ロック中、終了)を設定出来て、チケットの編集画面に終了済みバージョンがドロップダウンに表示されない」機能が地味にうれしい。

この機能も非常に重要。
RedmineのバージョンをXPのイテレーションのように扱う場合、バージョンの数が爆発的に増える。
しかし、Tracマイルストーンは「停止」という状態を持つのに、Redmineバージョンは状態を持たない。
従って、チケット登録時に、過去のバージョンもプルダウンに表示されてしまい、Redmine運用が長くなるほど使いづらかった。
だから、この機能改善は地味であるが非常に重要だと思う。

【元ネタ3】
RedmineLE Wiki - SourceForge.JP

MOONGIFT: ? Redmine用iPhoneクライアント「iRedmine」:オープンソースを毎日紹介

RedmineLEは、TracLightningのように、SVNやHudsonも一体化したAll In One Package。
ワンクリックでインストールできて、すぐにSVNコミットしてビルドもできる。
自分一人だけのプロジェクトでもすごく有用だ。

iRedmineはRedmine用のiPhoneクライアント。
Redmineを営業マンのタスク管理として用いて、このツールをクライアントとして、出先の営業マンにiPhoneから作業状態を更新できるようにすればいい。
そうすれば、いつでもどこでもタスク管理が可能になる。

この1年でRedmineを巡る状況は急激に進化している。
Redmineは単なるバグ管理ではなく、IT以外のプロジェクト管理まで使えるのか、そしてAgile開発をサポートできるのか、更に考えてみたい。

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

2010/01/07

Sonarでソースの品質をチェックする

ソースコード品質管理WebシステムSonarについてメモ。

【元ネタ】
Sonar
Sonarでコードの品質をレビュー
Sonarのデモ
Sonar plugin - hudson - Hudson Wiki

Sonarは、Javaで作られたソースコード品質管理Webシステム。
ビルドすれば、warファイルが作られるので、Tomcatにデプロイすればすぐに起動できる。
但し、Mavenがないとプロジェクトを登録できないので、ちょっとハードルが高い。

でも、Sonarのデモを見れば分かるように、プログラムのLOC、複雑度だけでなく、テストカバレッジ、ビルド時間、各種メトリクスをWeb上にグラフィカルに表示してくれる。

Sonar plugin - hudson - Hudson Wikiにあるように、HudsonにSonarプラグインがあるので、Hudsonでビルドする時に、Sonarのレポートを出力するようにすればいい。

Sonarの目的は、StatSVNと同様に、開発者にソースの品質を意識させる事だ。
開発中は、作るのに熱中して、品質まで頭が回らない時が多い。
だから、Web上でいつでも、自分が書いたプログラムのメトリクスを簡単に確認できる環境があるのはすごく重要だ。

そして、SonarもRedmineを中心とするチケット駆動開発のインフラの一部に入れてしまいたい。
HudsonをTomcatで動かせるなら簡単にインストールできるから。

チケット駆動開発を実践して気付いたことは、良い環境(ツールだけでなくPFのような雰囲気も含めて)を用意すれば、開発者も開発チームもより良い方向へ自立的に動き出すこと。
手作業が多くてミスが多い、とか、品質が気になるのに現状がどうなのか分からない、という問題があった時、それらの解決を支援するツールがあれば、人は自然に問題を解決しようとする。
そういう環境になるように、現場リーダーもプロマネも、良い環境を作るのに力を注ぐべきなのだ。

とはいえ、Sonarはインストールはできたものの、まだ使いこなせてない。
色々試してみたい。

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

2010/01/06

【告知】XP祭り関西2010でチケット駆動開発セッションをやります

【告知ページ】
2010年2月6日 XP祭り関西2010(大阪府)

XP祭り関西2010 - XpjugWestWiki

◆XP祭り関西2010開催にあたって
今回のテーマ「アジャイルマインドを育もう」には、自分のアジャイルマインドを「育む(はぐくむ)」意味と、他の人のアジャイルマインドを「育てる」意味を込めています。私達は、アジャイルマインンドとは、「自分たちの周りを良くしたいという問題意識を持ち、色々な壁にぶつかっても、自分から周りを変えていこうという姿勢」であると考えています。このようなアジャイルマインドはどうやって育まれるのでしょうか?

今回のスピーカーの方々は、強いアジャイルマインドを持っている方々ばかりです。セッションを通じて、アジャイルマインドを育むためのキッカケやヒントを持って帰っていただければ幸いです。

アジャイル開発に興味を持つ方、そして、アジャイル開発は良く分からなくても従来のソフトウェア開発に何か疑問を持っている方は、周囲の方もお誘い合わせの上、是非ご参加下さい!!

◆開催概要
タイトル XP祭り関西2010
テーマ 「アジャイルマインドを育もう」
開催日時 2010年2月6日(土) 10:00~16:30
開催場所 大阪市立 会館 鶴見区民センター
定員 200名
参加費 無料です。カンパ(ワンコイン500円)受け付け中。※懇親会は有料。
懇親会 4500円前後(会場選定中です。詳細決まり次第ご案内致します。)

◆講演内容
【メイン会場】
10:00 - 10:30 開場
10:30 - 10:45 主催者挨拶
10:45 - 11:45 【1-1】基調講演
11:45 - 12:30 昼休み
12:30 - 13:10 【1-2】講演①
13:10 - 13:50 【1-3】講演②
13:50 - 14:30 【1-4】講演③
14:30 - 14:40 休憩
14:40 - 15:40 【1-5】パネルディスカッション①
15:40 - 15:45 休憩
15:45 - 16:15 LT大会
16:15 - 16:30 クロージング
16:30 終了

【チケット駆動開発セッション専用会場】
12:30 - 13:05 【2-1】セッション①
13:05 - 13:35 【2-2】セッション②
13:35 - 14:05 【2-3】セッション③
14:05 - 14:30 【2-4】パネルディスカッション②

◆メイン会場(2F小ホール)―200名

【1-1】 基調講演 「XPの10年を振り返る」

* 倉貫義人 /TIS株式会社 SonicGarden カンパニー長

eXtreme Programmingが世に出てから10年が経ちました。私自身、社会人としてこの業界で働いて10年です。
思い返してみると、私のこの業界での仕事は、XPをいかに実践するのか、に取り組み続けた10年だったと思います。
それは、単なる方法論の導入の話ではなく、何を為したかったのか、私にとっての物語があります。
私がXPに取り組んだきっかけから、経験した事例など、日本のXPコミュニティの歴史とともに振り返ります。
その振り返りを通じて、私のアジャイルマインドを伝えられたら、と思います。

【1-2】講演① 「アジャイル アンチパターン ~アジャイルの1周目で学んだこと~」

* 木下 史彦 /永和システムマネジメント

アジャイルが2周目に入ったと言われて久しい昨今、私が XP/アジャイルを現場で実践してきたこの5年のあいだに学んだことをアンチパターンという形にまとめて発表します。


【1-3】講演② 「スクラムはプロセスツールなのか。それとも・・・」
ebacky /すくすくスクラム、すくすくスクラム瀬戸内


【1-4】講演③ 「始まらなかったAgileの話をしよう」

* papanda /DevLOVE、XPJUG

われわれがAgileに辿り着くことは本当に可能なのか。
2009年、象徴的な滝開発を経て、決意新たにAgileの実現に挑みました。
そこから学んだ、SIerとAgileの関係について語ります。


【1-5】パネルディスカッション① 「アジャイルマインドの育て方」

* 細谷泰夫(モデレータ) /XPJUG関西代表
* 岡島幸男 /永和システムマネジメント
* papanda /DevLOVE、XPJUG
* てつ。 /すくすくスクラム瀬戸内、要求開発アライアンス西日本
* 太田憲治 /クリエイトシステム代表


◆チケット駆動型開発セッション専用会場(2F控え室1/2)―先着50名

【2-1】セッション① 「チケット駆動開発のプラクティス集」

* あきぴー /XPJUG関西

XPが登場して約10年経ちますが、アジャイル開発の運用のハードルはまだ高く、開発現場に普及しているとは言えません。
しかしながら昨今、高機能化したBTS(バグ管理システム)をITS(課題管理システム)へ拡張してSW開発のタスク管理に運用するプロセスが注目されています。
チケット駆動開発(TiDD:Ticket Driven Development)とは、このBTSを使ってアジャイル開発の一プロセスとしてフレームワーク化を試みたものです。
今回は、チケット駆動開発を過去2年実践した経験を元に運用ノウハウをプラクティスとして提案します。


【2-2】セッション② 「元気が出るチケット駆動開発」

* 阪井誠 /株式会社SRA

リリースが近づくにつれ、細かな作業が増えて困っていませんか?
チケット駆動開発はそんなプロジェクトを元気にしてくれました。


【2-3】セッション③ 「チケット駆動開発を用いたソフトウェア品質改善事例」

* 小枝徳晃 /シスメックス株式会社 科学計測事業部

ソフトウエアの品質を左右する原因には、コーディングミスといった実装段階の問題と仕様の誤解、伝達ミスといったプロジェクト管理の問題がある。
前者の問題は、各種の分析ツールが充実してきており確実に減ってきている。
しかしながら、後者は、人の問題に起因する部分が多く分析ツールだけでは解決しないものが多い。
当社では、この問題を解決するため、チケット駆動型開発を導入しこれらの問題を減らすことができた。
今回は、その事例を報告する。


【2-4】パネルディスカッション② 「チケット駆動開発の体験談」

* あきぴー(モデレータ) /XPJUG関西
* 小枝徳晃 /シスメックス株式会社 科学計測事業部
* 阪井誠 /株式会社SRA
* 倉貫義人 /TIS株式会社 SonicGarden カンパニー長

高機能化したBTS(バグ管理システム)をアジャイル開発のプロジェクト管理として扱うチケット駆動開発(TiDD:Ticket Driven Development)は、アジャイル開発を更に発展させる可能性を秘めています。
パネルディスカッションでは、講演者3人と共に、Rails製社内SNS「SKIP」の開発のタスク管理をRedmineで運用している倉貫さんもお呼びして、チケット駆動開発を運用した経験談を中心に、その利点や今後の課題について語ります。

主催
* 日本XPユーザグループ関西

後援
* アイネタジャパン
* オーム社
* オライリージャパン
* 株式会社技術評論社
* 翔泳社
* ピアソン・エデュケーション

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

Redmineの日本語マニュアル

Redmineの日本語マニュアルがとても分かりやすかったのでメモ。

【元ネタ】
Redmineの日本語ユーザマニュアル

ヘルプリンクは、上記のマニュアルにした方が使い勝手が良いはず。
理由は、「ヘルプを見ればRedmineの使い方が分かるはず」と普通の人は思うはずだから。

ヘルプリンクを下記に従って、「http://redmine.jp/manual/ja/」へ修正すればなお使いやすくなるだろう。

Redmine.JP | ヘルプを日本語化したい

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

2010/01/04

Rails検証報告書

日本OSS推進フォーラムという団体がRailsに関する調査結果を公開していたのでメモ。

【元ネタ】
日本OSS推進フォーラム

「RubyTF_Ruby_on_Rails検証報告書」 (PDF:975KB)

おそらくIPOの外郭団体のような立場で、日本の大手SIの技術者がRailsを調査したらしい。
その報告書を読むと、Railsは企業向けにそこそこ使えるが、スケールアップやセキュリティ、技術蓄積にやや難がある、とのこと。

報告書で興味を引いたのは、セキュリティに関する所。
リダイレクト、Web アプリケーション内リンクをSSLにする対応は特に問題なく非常に簡単。

Railsで特徴的なのは、CookieでHTTP セッションを管理できることだろう。
ここの仕組みが非常に分かりやすい。

Railsでは、HTTPセッションをシリアライズ化してCookieに書き込む。
この時、サーバーにもハッシュ値のキーが生成されてCookieのハッシュキーに埋め込まれる。
サーバーのハッシュ値のキーはOpenSSLで生成されるから、サーバーのキーが盗まれない限り、セキュリティは大丈夫だろうと予測できる。
但し、セッションに格納されたデータそのものは暗号化されていないので、個人情報をセッションオブジェクトに埋め込むのは危険。

この部分が重要と思ったのは、セッション管理はWebアプリの盲点だからだ。
Webアプリがデスクトップアプリのように使うには、セッション管理をデスクトップアプリのメモリ管理のように使わなければならないからだ。
セッションをクッキーに残せるならば、画面の状態をクッキーに保存しておけば、Webアプリの古くからの問題である「戻るボタン」「注文ボタンの2度押し」に対応するのは易しいだろう。

報告書にもあるように、この部分はJavaのセッション管理と大きく異なる。
Javaのセッション管理は逐一自分で作らないといけないから面倒だ。
Railsのセッション管理は非常にプログラミングしやすい。

他にはテスト。
JavaのDBUnitのように、テスト用データローダーはYaml・CSVなどに対応しているから、Modelの単体テストに使える。
又、複数のコントローラーを経由したテストもできるから、結合テストに近い操作も可能。
JavaのdjUnitのようなテストカバレッジも、RCovというツールで可能。
すなわち、Javaのテストユニットの機能はほぼ実現されている。

僕の感想は、Railsは丁度Strutsが出た頃に似ているなあ、ということ。
2000年代初頭、JavaによるWebシステム開発にどの技術者もSIも可能性を感じ、Webフレームワークが乱立していた。
そんな頃に、Javaで書かれたオープンソースのWebフレームワークStrutsが出現して、劇的に変化した。
Webフレームワークはこういう風に書けばいいのか、MVC2モデルはこういうことなのか、と感心した事がある。
Strutsも当初はバグ、スケールアップ、将来性など色々言われたけれど、今となってはJavaでは業界標準に近い。

Railsは頻繁にバージョンアップしていて、今も成長途中。
RedmineもRailsのキラーアプリとして非常に可能性がある。

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

Redmineが日本で急上昇している

Googleトレンドを見ると、日本ではRedmineがTracに追いついた状況になっているようだ。

【元ネタ】
Google トレンド: trac,redmine,mantis

更にもう一つのAll In OneRedmine~RedmineLE: プログラマの思索

RedmineもTracLightningのように、SVNやHudsonと一体化したRedmineLEも出てきて、使い勝手は非常に良くなった。

Redmineがアジャイル開発のプロジェクト管理に使えるという動機が、日本で流行している理由かもしれない。

脱Excel! Redmineでアジャイル開発を楽々管理 - @IT自分戦略研究所の記事が一役買っているならば、著者冥利に尽きる所。

補足ですが、RedmineLE Wiki - SourceForge.JPに説明されているRedmineによるタスク管理のイメージ図が分かりやすくて非常に素晴らしい。

チケット駆動開発は、上記のイメージの上で稼動する。
そして、そのプロセスは自然にアジャイル開発になると確信している。

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

2010/01/03

ファンクションポイント法による工数見積もりのリンク

ファンクションポイント法による工数見積もりをWeb上で検索した結果をリンクしておく。
後で自分で参考にしておきたいから。

【元ネタ】
デブサミ2009「私のコスト見積り20年史から~ファンクションポイントと共に~」講演メモ - アークウェブシステム開発SandBox

ファンクションポイント法入門

「やることリスト」に基づく見積もり手法

ファンクションポイント系見積りのメモ - asa nisi masa

ファンクションポイント法によるソフトウェア開発規模・工数見積の現状

ファンクションポイント法の利点は、ソース行数ではなくシステムの入出力に着目して工数見積する点にある。
このやり方ならば、ユーザも納得しやすく、プログラミング言語や開発者個人に依存せずに見積もりを提示できる。

しかし、ファンクションポイント法は昔から知られているにも関わらず、計算方法が複雑で、過去の蓄積データがないと精度が悪い弱点があった。
しかも、何十と言う流派があって、どれを選べばいいのか分からない。

ファンクションポイントに注目したいのは、工数よりも開発規模を見積もるように、アジャイル開発のストーリーポイントと発想が似ている点。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~でも、ストーリーのCRUDに着目してストーリーポイントを導くように、ファンクションポイントの発想はアジャイル開発でも使えるはず。

導入しやすいタイミングとしては、システム要求を洗い出す上流工程のモデリング時だと思う。
ユースケース図、概念モデル、業務フローによるDFDから、システムの入出力を洗い出し、ファンクションポイントの計算式に当てはめる。
そして、astahのモデルを書いておけば、JRubyを使ってファンクションポイントを自動計算できるはず。
つまり、モデルさえ書けば、自動計算できるインフラがある。

ストーリーカードをRedmineチケットというタスクだけでなく、モデルにも紐づけて、要件を工数見積りまで追跡できれば最高だ。

|

eラーニングシステム Moodle

eラーニングシステム Moodleの記事が技術評論社Webに掲載されていたのでメモ。

【元ネタ】
連載:eラーニングシステム Moodleの活用とカスタマイズ|gihyo.jp … 技術評論社

Moodle.org: open-source community-based tools for learning(デモサイト)

BitNami :: Moodleに既にワンクリックインストーラーがあるので、どんな形式でeラーニングができるのだろうか、と気になっていた。

記事によると、Moodleは下記の機能があるらしい。

・コース(教科)を作れる
・小テストの作成、実施、採点、集計ができる
・フォーラム、Wiki、投票などで教師と生徒がやり取りできる
・レポートの提出、管理ができる
・成績表の管理ができる

eラーニングシステム Moodleの活用とカスタマイズ:第1回 Moodle(ムードル)とは |gihyo.jp … 技術評論社

(前略)Moodleは元々、学校の授業で利用することを念頭に置いた設計になっています。
従来の講義室で一方的に先生から学生へ情報が伝達されるタイプの授業は,今の時代にはそぐわず,それだけで教育を行うのは,もう限界が来ているとも感じられます。学生が自律的に学ぶ,また,学生同士でみんなで一緒に学ぶタイプの活動をうまく取り入れていくことに Moodleは活用できます。
また,Moodleの用途は学校の授業だけに限らず,実際にはさまざまなことに便利に利用できます。会社などの研修に利用できるのはもちろん,教えあい,学びあう場であれば,多くの場面で活用する価値があると思います。(後略)

どうやら高校や大学の授業の管理に使えるみたい。
ソフトウェア開発のプロジェクト管理に使えるわけではないが、企業の新人研修に使えるかもしれない。
教育機関や研修企業に向けて、営業展開できるかもしれない。

面白いのは、Webを使って、単なる授業の管理だけでなく、教師と生徒の間のコミュニケーション促進に役立てていることだ。
SKIPのような社内SNSと発想が似ている感じがする。
多数の人達のやり取りを促進(ファシリテート)することによって、一人のアイデアが大衆の知恵のように進化して、更に組織が活性化する。
このノウハウはPFやファシリテーションの分野が特に優れている所。

Webは単に情報共有できるだけでなく、人と人を結びつけて、コミュニケーションを活性化させて、単なるアイデアをノウハウまで洗練させる仕掛けがある。
一人の天才の独創的アイデアに対して無数の大衆の知恵の方が勝る状況は、最近は特に多くなっているのかもしれない。

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

« 2009年12月 | トップページ | 2010年2月 »