TiDDをRubyで補強するアイデア

RubyとRailsを触り始めた。
とても書きやすい。
Rubyに色んな可能性を感じている。

TiDDをRubyでサポートするアイデアをメモ。

【1】BTSチケットのFS関係から、ネットワーク図を作成し、クリティカルパスを自動計算する

チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索に書いた。
やりたいのは、開発中にクリティカルパス上にあるチケットを調べたい。
それらのチケットを管理するのが、プロジェクトマネージャの最重要な仕事だから。

できれば、バージョン毎にクリティカルパスを計算したい。
1個のバージョンに含まれるチケット数はせいぜい10個ぐらいなので、すぐに計算できるはず。

多分バックトラックのアルゴリズムを使えば、計算できるだろうと想像している。
Redmineのプラグインとして作れるはず。

【2】チケットの予定・実績工数から、プロジェクトのEVMを計算する

チケット駆動開発にEVMの概念を導入してみる: プログラマの思索に書いた。
やりたいのは、プロジェクト開始前に、WBSをチケットに登録し、プロジェクトをシミュレーションしたい。
シミュレーションした結果、どうやっても納期に間に合わない、とか、どうやってもコストオーバーになる、という事実が判明することがある。
つまり、デスマーチがプロジェクト開始前に決定という状況。

その結果を早めにエスカレーションして、そもそも開発を請け負うべきなのか、という判断を上司へ仰がせたい。
取らない方がよいプロジェクトもあるはずだ。

Redmineのプラグインとして作れるはず。

【3】BTSチケットとSCMリビジョンが紐づく関係を使って、ソース修正履歴の傾向を統計処理する

Redmineにお勧めソース機能が欲しい: プログラマの思索に書いた。
やりたいのは、そのソースに技術的負債があってリファクタリング工数が別途必要になる、というリスクを未然に調べたいこと。

どのシステムも何年も運用するうちに、たくさんの開発者の手が入ってどんどん劣化していく。
そして、機能追加したい時に、実は機能追加の工数よりもリファクタリング工数の方が多いという状況は多々ある。
そして、その工数を事前に確保していないから、納期までに終わらないという状況が発生しやすくなるからだ。

SVNの全コミットログは、下記でXML形式で取得できる。

svn log -v --xml > logfile.log

上記をパースして集計するRedmineのプラグインとして作れるはず。

【4】astahのモデルからファンクションポイントを計算して、見積もりに使う

おかじまさんが下記で色々試されている。
astahのAPIはJRubyでも使えるから、モデルさえ作ればすぐにRubyで書けるはず。

astah*Professionalファーストインプレッション: プログラマの思索

JUDE改めastah*、ファーストインプレッション - TECH-moratorium ： テクモラトリアム

JRubyでJUDE CRUD-APIを試す - TECH-moratorium ： テクモラトリアム

JUDE APIでFPを算出するアプリ - TECH-moratorium ： テクモラトリアム

【5】astahの要求テーブルとテストケースをTestLinkへインポートできる形式へ変換する

astahには、要件管理やテストケースの機能が不十分だが付属している。
要件やテストケースをastahのモデルと紐づけて、TestLinkの要件やテストケースと関連付けたい。
そうすれば、要件カバレッジや、モデルからテストケースへの追跡が可能になるだろう。
すると、テストケースの品質が上がるだけでなく、バグが出た場合、バグの影響範囲を調査する時に役立つだろう。

astah* professional 概要

[pro] 要求テーブル

【6】astahのステートマシン図から出力した状態遷移表をデシジョンテーブルへ変換し、TestLinkCnvMacroと連携してTestLinkのテストケースへ変換する

astah* Community Site - フォーラム

astahのステートマシン図から状態遷移表を出力するツールは上記で配布されている。
やりたいのは、ステートマシン図からTestLinkのテストケースを自動生成したい。

システム上の制約条件は結局、ステートマシン図で見た方が早い。
しかも仕様を理解しやすいし、レビューでも指摘しやすい。

上記のようにRubyでTiDDを補強したい理由は、プロジェクト管理をもっと楽にしたいからだ。
従来のプロジェクトマネージャは、ExcelやMSProjectを駆使して、進捗管理したりプロジェクトのシミュレーションを行っていた。
Excelマクロを駆使して、そのプロジェクトに特化したツールをたくさん作っていただろう。

開発メンバーにExcelで進捗報告を提出させて、PMは残業してそれらのExcelを集計する。
1日の最後に、テスターへExcelのテスト仕様書にテスト実施結果を書かせて、PMは残業してテスト結果を集計する。
そんなやり方では、昨今のビジネスのスピードに、プロジェクト管理が追いついていない現状がある。

現代では、プロジェクトマネージャでも強力なスクリプト言語を使って、自分のマネジメント業務を改善すべきだ。
Rubyという強力なツールを使えば、ルーチン作業は全て自動化できる。

SW開発で最もIT化されていない部分は、実はプロジェクト管理ではないかと最近は強く思っている。
色々考えてみたい。