« 2009年11月 | トップページ | 2010年1月 »

2009年12月

2009/12/30

ITの地殻変動はどこで起きているか?~Agile2.0をサポートするチケット駆動開発

2010年を迎えるに当たり、ITの地殻変動がどこに起こっているのか?を考えてみる。
#自分の理解した範囲内のラフなメモ書き。

【過去の記事】
第二期アジャイルムーブメント: プログラマの思索

「塹壕よりScrumとXP」

チケット駆動開発はアジャイル開発の実装である: プログラマの思索

ITの地殻変動はどこで起きているのか?~2009年: プログラマの思索

ITの地殻変動はどこで起きているのか?~SeasarとRuby、そしてPF~2008年: プログラマの思索

ITの地殻変動はどこで起きているのか?~2006年: プログラマの思索

【Agile1.0の登場と課題】

2000年頃出現したXPによって、初めてアジャイル開発が開発者へ認知されたように思う。
XPは従来のウォーターフォール型開発のアンチテーゼとして、特に開発者に熱狂的に受け入れられた。

XPの最大の特徴は、繰り返し開発の実践プラクティスを現場の開発者へ提示したことにある。
また、テスト駆動開発(TDD)、継続的インテグレーション(CI)のように、その後の開発スタイルを変える手法も編み出された。
これらは、今となっては普通のプラクティスの一つまで普及した。

今振り返ると、XPのプラクティスの中で最も重要な概念は、小規模リリースだと思う。
繰り返し開発というアイデアは従来から知られていたが、その思想を具現化すると、小さい機能単位に分割して順次リリースしていくというスタイルが最もリスクが少なく、確実だ。

小規模リリースの利点は、変化をイテレーションと言う単位に押し込めれば、変化を受け入れることが可能なこと。
突発的なタスクの変更、仕様の追加は、小規模リリースのおかげで「変化を抱擁する」ことも可能になる。

つまり、小規模リリースは漸進型開発の主要な思想であり、繰り返し開発の中でも漸進型開発が最も実現しやすいことを示唆していた。

その後の繰り返し開発の流派においても、小規模リリースの影響は色濃く見られる。
小規模リリースの開発スタイルは、特にオープンソースの世界ではとても当たり前になった。

しかし、XPはその熱狂さとは裏腹に運用のハードルは高かった。
よく言われる問題点は二つある。
一つは、大規模プロジェクト、大規模チームのようなスケールアップが難しいこと。
もう一つは、アーキテクチャ重視、品質重視のプロジェクトでは、小規模リリースが有効に作用しないこと。

前者は、サブチームごとにイテレーションを実施しても、複数のサブチームのモジュールを結合するイテレーション無しではうまいかないことを示唆している。
大規模になるほど、複数のサブチームのイテレーションの同期を取るのが難しい。

後者は、イテレーションというタイムボックス形式の開発では、アーキテクチャや品質を作りこむのは難しいことを示唆している。
RUPはアーキテクチャ重視の繰り返し開発なので、反復型開発というもう一つの繰り返し開発のプロセスを編み出したが、これはスコープの管理が非常に難しい。
実際は1回のイテレーションしか行わない場合が多いから、結局ウォーターフォール型開発と何ら変わらない。

上記のように、初期のアジャイル開発で試行錯誤した頃をAgile1.0と呼んでおく。

【Agile2.0の舞台要素】

アジャイル開発とは別に、PMBOK、ITIL、ソフトウェアプロダクトライン(SPL)という流れも2000年代に広く普及した。

PMBOKはプロジェクトマネジメントのフレームワークを知識体系化したもの。
PMBOKを読んで衝撃的だったのは、QCDを含めた全般的なマネジメントの知識体系よりも、スコープ管理を重視していること。
特に品質管理では、スコープを超えた品質重視は「金メッキ」と呼ばれ、無駄と言っている。
即ち、スコープ・コスト・納期・品質などのバランスの中で、品質を重視する。
品質重視のあまり、コストをかけすぎたり、納期に遅れるのは、ビジネス上無意味であると主張している。

ITILはIT運用保守のフレームワーク。
従来の運用保守と異なる点は、問題(障害)管理とインシデント管理を区別していることと、変更管理でプロセスを手続き化していること。
前者は、障害と単なる問合せを明確に分離し、実際の開発チームの業務に支障が出ないようにする。
後者は、変更要求(RFC)に対し、利害関係者が変更諮問委員会(CAB)を開き、優先順位や作業手順などを決めて、計画を立てるプロセスを明確化した。

このITILの考え方は、チケット駆動開発でも非常に参考にした。
BTSは本来バグ管理システムであるから、ITILの発想と非常に相性がよい。

SPLは特に複数の製品ファミリーを持つソフトウェア開発、例えば組み込み製品やパッケージ製品の開発で行われる開発手法。
共通部品や共通アーキテクチャであるコア資産と製品独自の部品であるアプリケーション資産に分離し、別々に管理することで制御する発想。
この発想も従来から知られていたが、体系化されて認知され始めたのが2000年代だと思う。

SPLの開発プロセスはウォーターフォール型開発や反復型開発に似ている部分がある。
特に、SPLは、ソフトウェア開発は本質的に、複数のコードラインを保守せざるを得ない並行開発である、と暗示した点が重要だと考える。

つまり、組み込み製品やパッケージ製品だけでなく、Webシステムや業務システムでも、並行開発はもはや当たり前の開発スタイル。
並行開発の最大の弱点は、複数のコードラインの品質を維持するのが非常に難しいこと。
普通は1つの変更が複数のコードラインへ影響するため、開発中の機能と衝突しないようにマージするのは非常に難しい。
おそらくGitやMercurialのような分散バージョン管理を導入しない限り、根本的な解決には至らないだろうと思っている。

そんな中、Scrumというアジャイル開発手法が広く普及し始める。
Scrumの最大の特徴は、繰り返し開発の中でも漸進型開発のプロセスフレームワークを提示した点にあると思う。
スプリント計画でスプリント(イテレーション)で実現する機能を決めて、そのスプリントでは他の変更は受け入れない。
そのScrumチームには明確な役割と厳格な規律があり、スプリント単位に小刻みにリリースしながら、システムを少しずつ作っていく。

Scrumはプロセスを重視しているから、特にマネージャ層に受け入れられた。
この点にアジャイル開発に対する大きな貢献があると思う。

ScrumがXPと異なる点は、「塹壕よりScrumとXP」にもあるように、スケールアップやアーキテクチャ・品質重視の課題に対する回答の一つを提示したことにある。

スケールアップのために、サブチーム単位のイテレーション同士で同期を合わせる。
リリース後の障害修正が発生した場合、暫定的なイテレーションを作り、品質改善の作業に取り組む。

Scrumでも上記2点の課題に完全に対応できているわけではないが、色んなノウハウを試そうとしているように思える。
そして、Scrumのおかげで、アジャイル開発の運用のハードルはかなり下がってきているように思える。

後もう一つは、平鍋さんが提唱したPF(プロジェクトファシリテーション)だ。
これは日本人がアジャイル開発から編み出した手法として重要だと思う。

PFは、従来のプロジェクト管理手法が見過ごしていたコミュニケーションや人間重視の発想をサポートする。
PFが普及し始めた理由は、チームビルディングがソフトウェア開発で重要だと認識されたからだろう。

昨今のソフトウェア開発では、3~12ヶ月で新規メンバーを集めてチームを形成して、リリースしていく。
この時、かき集めたメンバーをチームとして一体化させて有機的に活動させるのは至難の業だ。
PFはチームビルディングのプラクティスに優れているように思う。

【チケット駆動開発の役割】

上記のような流れをAgile2.0と呼ぶならば、チケット駆動開発(TiDD)もその流れに含まれる。
チケット駆動開発は、まちゅさんがTracのチケット管理から提唱した手法で、Tracのチケットでソフトウェア開発のタスク全般を管理しようと言うスタイル。
これは、BTSをITS(Issue Tracking System)として扱う点として画期的だと思う。

そして、僕はRedmineにチケット駆動開発を導入する時に下記をアレンジした。

1・BTSのチケットをXPのタスクカードのように扱う
2・BTSのチケット一覧をXPのタスクボードのように扱う
3・SVNコミットログにチケットNoを必ず書く
4・チケットをバージョンでグルーピングし、順次リリースしていく

1はIssueTrackingと呼ばれるもので、チケット(Issue)でタスクの状態や進捗を追跡する。
2はチケット集計機能を生かして、ガントチャートやカレンダー、ロードマップなどを生成して、進捗管理に使う。
1と2は、さかばさんからアドバイスを受けて、気付いた点がある。

3は、まちゅさんが「No Ticket, No Commit!」と呼んでいるプラクティスで、チケットとSCM配下の成果物をリンクすることで、成果物の変更をチケットで追跡できるようにする。

4はいわゆる小規模リリース。リリース予定バージョンをXPのイテレーション、Scrumのスプリントと見なして、小刻みにリリースしていく。

TiDDの最大の利点は、突発的なタスクの変更に対応できることと、タスクの最新化・集計を自動化できるので進捗管理や品質管理をサポートしていることだ。
上記を基本ルールとして運用していくうちに、チケット駆動開発がアジャイル開発のインフラになって入るのに気付いた。

そして、チケット駆動開発はPFのプラクティスとも相性がいい。
特に、朝会やふりかえりはTiDDの運用の中で自然に生かせるし、かんばんはステータスごとのチケット集計機能として簡単に得られる。
つまり、TiDDはPFをデジタル化してくれる。

また、Agile2.0で出てくる各種技法もTiDD上で実現できる。
ITILの各プロセス、PMBOKのEVM、SPLによる並行開発も、TiDD上で試してみると、結構うまくいく。
机上の知識に過ぎなかったものが、TiDD上では一機能として実現できるはずと確信している。

これらの要素を試しながら、TiDDの可能性を考えると色々ある。
TiDDは、Agile2.0において、それらの開発インフラとして黒子役を担うはず。

TiDDで今後最も面白いと思うのは、BTSを中心として各種ツールと連携すること。
分散バージョン管理Mercurial、Gitと連携して、トピックブランチをRedmineで管理。
CIツールHudsonと連携して、チケットからビルドモジュールまでの追跡を可能にする。
テスト管理ツールTestLinkと連携して、バグ修正をRedmineで管理。
コードレビューWebシステムReviewBoardと連携して、ワークフローはRedmineで管理。
StatSVNやStatCVSと連携して、SCMメトリクス出力を行う。

多分他にも色々考えられるし、それらのツールと連携することによって、ソフトウェア開発のプロジェクト管理支援を行う。
TiDDにSW工学の知識を導入して、従来のアジャイル開発を更に補強できるのではないか?

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

2009/12/28

Retrospectiva のAgilePMプラグイン

Redmineに似たRoRのプロジェクト管理ツールRetrospectiva に、Scrumの発想を取り入れたプラグインAgilePMの記事を見つけたのでメモ。
但し、使っていないので理解できた範囲でメモ。

【元ネタ】
Retrospectiva / Wiki: AgilePM

Retrospectivaを1年前に使った時、リモートSCMが使えないのでSVNと同じサーバーでしか動かせないし、BlogがあるぐらいでRedmineよりも機能が劣っているように思えた。
しかし、この1年で随分、機能改善されているようだ。

Retrospectiva のAgilePMプラグインでは、下記の特徴があるらしい。

1・Goal Backlog
 →Goalが一プロジェクト(複数のイテレーションの集まり)に相当するようだ。
  つまり、ビジネス要求を実現する単位がGoalで、そのGoal単位でプロジェクト管理する。

2・Sprint Backlog
 →Scrumのスプリントバックログに相当する。
  上記のGoalに対し、複数のストーリーがリンクされていて、スプリント単位で開発していく。
  バーンダウンチャートも生成できるようで、ストーリーごとに工数や進捗を測定できるようだ。

説明を読んでみると、マイルストーンをスプリントと見なして、インクリメンタルに開発していくようだ。
その意味では、小規模リリースを実現できるので、アジャイル開発しやすいだろう。

気になるのは、チケットにストーリーカードとタスクカードの違いが有るのかどうか、という点。
一つのストーリーの作業単位が大きい場合、進捗管理するのは難しくなるだろう。
ストーリーと言うチケットを複数のタスクカードに分割して、それらをまとめて進捗管理したい場合があると思うが、手作業でやるしかないのか、ツールでサポートしているのか、よく分からない。

とは言え、バーンダウンチャートがデフォルトで付属しているし、UIも使いやすさも改善されているようなので、試してみる価値はあるかもしれない。

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

Redmine on JRuby part2

Redmine本家に、Tomcat(又はGlassfish)上でRedmineを動かすインストール方法が紹介されていたのでメモ。

【元ネタ】
Redmine - HowTo install Redmine in Apache Tomcat - Redmine

Musings of a Programming Addict: Redmine on JRuby and Glassfish

下記の手順で、ビルド&デプロイすればTomcat上で動くらしい。

JRubyはインストールしておく

gem install warbler

redmineのdatabase.ymlへJDBCを設定

warble config
でwarble.rbを作成

★warble.rbで、
config.dirs = %w(app config lib log vendor tmp extra files lang)
へ修正

セッションクリア
rake config/initializers/session_store.rb

warble
でredmine.warを作成

Tomcatへデプロイ後、Tomcatを起動すれば、
http://your-tomcat-host.name:8080/redmine
で表示される

以前、warblerを使ってビルド&デプロイしたら、表示できるもののレイアウトが崩れてしまった。
上記の方法では、★でwarファイルの構造を設定しているので、これがミソだったのかなと思う。

JRuby+TomcatでRedmineが稼動できるのは、運用上とても重要だ。
理由は、RubyがインストールされていないUnixサーバーでも、JavaはPerlと同様に必ずインストールされているので、JRubyを使えばRuby無しでもRedmineを稼動させることができるからだ。
又、Tomcatで負荷分散させたり、スケールアップする運用方法はかなり枯れた技術だから、JavaアプリケーションサーバーでRailsアプリを動作できれば、従来の運用ノウハウも流用できる。

上記のコマンドも、AntやMavenでビルドスクリプトを書いておき、Hudsonと連携してワンクリックでビルド&デプロイできるようにしておけばいいだろう。

Railsがどんどんバージョンアップして、安定性も使いやすさもどんどん改善されているように、Redmineを取り巻く環境も1年前に比べるとかなり大きく改善されている。

今後もRedmineの動向を追いかけてみたい。

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

2009/12/27

Redmine0.9.xの新機能

もうすぐRedmine0.9RCが出そう。
新機能を読んで気付いたことをメモ。

【元ネタ】
Redmine - 0.9 feature freeze

新機能は下記3点がまず挙げられるだろう。
このうち、1番目と2番目の機能はとても重要だ。

1.Unlimited project nesting
2.Versions inheritance
3.User groups・User permissions

1は、プロジェクトの階層制限をなくす。
従来は2階層までしかプロジェクトの親子関係を作れなかった。
今後は、プロジェクトをツリー状に作ることができる。

この機能を使う状況は、特に大規模プロジェクトだろう。
例えば、第1階層のプロジェクトをブランチ単位、第2階層のプロジェクトをサブチーム単位、第3階層のプロジェクトをコンポーネント単位のようにツリー構造に割り当ててみるのも良いかもしれない。

特にブランチをたくさん作る状況では、ブランチ単位にプロジェクトを作るから、プロジェクトの階層を深くできるとグルーピングしやすくなると思う。

2は、親子関係のプロジェクトでバージョンを共有する。
従来はバージョンはプロジェクト固有だった。

この機能を使うと、子プロジェクトへ親プロジェクトのバージョンを継承できる。
故に、親プロジェクトをシステムのtrunk、子プロジェクトをサブシステム単位(例:jar, DLL)のように作った時、システムのバージョンをサブシステムのバージョンと共有すればいい。
この利点は、サブシステムでもシステムのバージョン、つまりシステム開発全体のイテレーションを意識できること。

階層構造を持つプロジェクトはrootのプロジェクトのバージョンを継承させることで、アジャイル開発しやすくなるかもしれない。

上記の2個の機能は、とても大きなポテンシャルがあると思う。
多分、もっと巧い運用方法を考えることができるはず。

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

2009/12/26

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化されていない部分は、実はプロジェクト管理ではないかと最近は強く思っている。
色々考えてみたい。

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

チケット駆動開発にEVMの概念を導入してみる

チケット駆動開発にEVMの概念を導入できるか考えた事をメモ。
#間違っているかもしれないので、あくまでもイメージを書く。

【元ネタ】
[ThinkIT] 第2回:EVMの基本値から導出される値の説明と練習問題 (1/4)

チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索

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

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

プロジェクト実績の測定とコントロール

【1】以前のように、システムの検収が終わった後に丼勘定で収支のつじつまを合わせる工事完成基準は、もはやできない。
2009/4から、SW開発も他業界と同様に工事進行基準で会計報告が必須になったため、四苦八苦しているプロジェクトは多いだろう。

EVMは、SW開発のプロジェクト管理における工事進行基準の仕組みと言ってもいい。
EVMで出てくる概念は、次の3つと言っていい。


・出来高計画値(PV)→該当期間の作業の総予定工数
・投入実績値(AC)→該当期間の実質の総実績工数
・出来高実績値(EV)→該当期間の完了した作業の総予定工数

PV(Planned Value)は計画価値であり、ベースラインに相当する。
AC(Actual Cost)は実コストであり、実績値そのもの。
EV(Earned Value)はいわゆる達成価値。

EVMの利点は、完了時総見積(EAC)を予測できること、そして、CPIやSPIから進捗やコストのリスク管理に使えることだ。

【2】この概念をチケット駆動開発では下記で置き換えられる。

・出来高計画値(PV)→該当バージョンのチケットの総予定工数
・投入実績値(AC)→該当バージョンのチケットの進捗率も加算した総実績工数(薄緑色の進捗)
・出来高実績値(EV)→該当バージョンの終了チケットの総予定工数(濃緑色の進捗)

即ち、Redmineのロードマップ画面では、ACは見かけ上の進捗、EVは実質の進捗に置き換えられる。

実際に下記のプロジェクトに当てはめた場合、チケット駆動開発で考えてみよう。

2-1.スケジュールも遅延し、コストもオーバーした場合
2-2.コストはオーバーしたが、納期までに納品できた場合
2-3.コストも予算内に収まり、納期までに納品できた場合

2-1.では、SV(スケジュール差異)<0、CV(コスト差異)<0になるので、EV<PV、EV<ACになる。
つまり、終了チケットの消化具合は予定よりも少ないため、EV(システムの実質の価値)は予定よりも低い。
又、終了チケットの総予定工数よりも総実績工数が多いため、コストオーバーでタスクを完了させたことになる。

Redmineのロードマップ画面では、該当バージョンの進捗バーは緑色が少なくて白色の部分が多く、殆ど進んでいない状況だろう。

即ち、タスクをこなす進捗速度は予定よりも遅いから、コストも増大しているのだ。
いわゆるデスマーチ、あるいは、要件定義から不穏な雰囲気のあるプロジェクトが相当するだろう。

原因としては、元々の見積もりが甘かった事もあるだろう。
だから、WBSを洗い出した時に、WBSをチケットに当てはめてBTS上で進捗のシミュレーションをあらかじめできれば、既に請け負った段階で、どうやっても納期はオーバーしたり、コストも予定よりもオーバーする事実を説明できるだろう。
つまり、チケット数と言うスコープを調整するしかありません、とユーザに言う事ができるだろう。

2-2.では、SV(スケジュール差異)≧0、CV(コスト差異)<0になるので、EV≧PV、EV<ACになる。
つまり、終了チケットの消化具合は予定通りに進んだものの、当初の予定工数よりも実績工数が大きいので、それぞれのチケットの工数を見れば、殆どが工数オーバーだったことになる。

Redmineのロードマップ画面では、該当バージョンの進捗バーは薄緑色の部分は多いものの、濃緑色が少ない状況だろう。
つまり、見かけ上の進捗は予定通り進んでいるが、実質の進捗(=終了チケット数)は遅延している状況だろう。
よくある状況は、設計や開発は進んでいるものの、色んな理由でレビュー待ちになっている場合。

即ち、タスクをこなす進捗速度は予定通りだが、コストは増大している。
このパターンがSW開発ではとても多いだろうと思う。
要件漏れ、仕様変更による手戻り作業、重大なバグをリリース間際に発見して何とか修正した、など、当初の予定になかったタスクが発生して、その分コストオーバーになった例が多いだろう。

SW開発では、当初の計画にない突発的なタスクの管理が重要になってくる。
チケット駆動開発をアジャイル開発として扱えば、変更を受け入れる余地があるため、突発的に生じたタスクをチケットに登録して管理できる。
しかも、そのチケットをどのイテレーションでこなすか、というイテレーション計画の発想によって、変化を吸収できる。
いわゆる小規模リリースによって、予期しない変化を取り込む余裕を作っているのだ。

2-3.では、SV(スケジュール差異)≧0、CV(コスト差異)≧0になるので、EV≧PV、EV≧ACになる。
つまり、終了チケットの消化具合は予定通りに進み、当初の予定工数よりも実績工数が少なかったので、コストもオーバーしなかったことになる。

Redmineのロードマップ画面では、該当バージョンの進捗バーは濃緑色の部分が多く、もう少しでリリースできる状況だろう。

即ち、チケットをこなす速度も予定よりも早く進み、そのおかげで納期も短くなったことになる。
このパターンは、プロジェクトの理想的な展開だといえるだろう。

実際は、アジャイル開発で小規模リリースを実施すると、初期のイテレーションは非常に苦労するが、後期のイテレーションではこのパターンに当てはまる。
最初は、要件や仕様の理解に苦しんだり、新しい技術の習得に時間がかかったり、メンバーの役割分担が不十分だったりして、何とかイテレーションをこなすのが精一杯。
しかし、イテレーションと言うリズムに慣れると、イテレーションに収まりきらないチケットは後回しにしたり、優先順位を付けてチケットを入れ替えるなどのマネジメントがスムーズになるので、結果的にバグが生じにくくなり、手戻り作業も減る。

SW開発では、学習速度と言う概念が重要だと思う。
3ヶ月経てば、新人であろうとも、仕様も技術も慣れてくる。
その分、タスクをこなす速度は上がってくる。
つまり、開発チームのベロシティ(進捗速度)はほぼ一定になるので、見積もりの精度が高くなり、手戻り作業などのリスク管理も上手に制御できるようになるだろう。

【3】つまり、Redmineでは、EVMの対象範囲をバージョンという複数のイテレーションに分割しており、各バージョンの進捗管理をロードマップ画面で一覧していることになる。

特に、Redmineのロードマップ画面がTracやMantisよりも優れているのは、上記3種類の進捗を表示している事だ。
TracやMantisでは、出来高計画値(PV)と出来高実績値(EV)しか表示しておらず、実質の実績工数から得られる進捗を表示しない為、現在の作業の遅延がどんな状況なのか、具体的に把握しづらい。

Redmineではサマリという画面で、チケットの作業状態をステータスごとに集計してくれるので、未完了の作業の内訳を見れば、レビュー待ちで遅れているのか、テスト中で遅れているのか、を探る事ができる。

TiDD(チケット駆動開発)は上記の関係によって、EVMが計算可能な点もある。
つまり、工事進行基準に対応可能だ。
この理由は、進捗情報・工数情報・WBS情報が全てDBにあるから、SQLやプログラムさえ作れば、いくらでも色んな観点で集計可能だからだ。

更に、TiDDの更なる利点は、WBSが頻繁に変わっても、TiDDならリアルタイムにEVM出力が可能なことだ。
実際のSW開発では仕様変更や手戻り作業が頻繁に発生し、その都度、最新状況を反映しなくてはならない。
TiDDでは、チケットを新たに登録すればいいから、スコープの変化に対応しやすい。

結局、現代のSW開発のプロジェクト管理は、高度な管理システムが必須だ。
現代のSW開発のビジネスは、プロジェクト管理がIT化されていなければやってゆけない。

工事進行基準に対応するには、Excelは到底無理なはず。
EVMを計算するには、マクロを駆使するしかない。
マクロを作ると言う事は、Excelが一つのシステムであること。
しかし、Excelは壊れやすく、保守しにくい。

更に、MSProjectも最終的には難しいだろう。
MSProjectには資源平準化の機能もあるし、EVMも計算できる。
しかし、WBSの変化や実績工数をの履歴を残せば、ファイルサイズがどんどん膨らむ。
結局、Excelのファイルバックアップのように、「XXシステムの進捗_yyMMdd.mpp」というファイル管理をせざるを得ない。

チケット駆動開発を単なるアジャイル開発のプロジェクト管理から、SW開発のプロジェクト管理ツールへ拡張できるか、模索してみたい。

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

情報システム部門がTiDDを運用する時の注意点

ユーザ企業の情報システム部門がチケット駆動開発を運用する場合の注意点を考えてみた。
以下メモ書き。

情報システム部門は、その企業の業務を遂行するために必要なシステムに関する仕事を担当している。
現代では、業務システムは企業のインフラ。
電気や水道が止まったら家で生活できないように、業務システムが止まったら会社で仕事できない。
だから、CIOはCEOに次ぐ重要な役割を担っているはず。
しかし、日々の雑務に追われている割には、他部署からコストセンターと思われて大変だと思う。

情報システム部門は、企業規模や担当範囲によって、その役割は大きく異なる。
想像すると、次の3つのパターンに分けられると思う。

1・業務システムの運用保守以外に、内製(自社開発)も行っている
2・業務システムの運用保守だけ。
3・運用保守すらアウトソーシングし、企画・発注のみ行っている

1は、自社に開発部隊があるので、かなりの技術力を持っている。
2は、サーバーやPCなどハードウェアの運用保守が中心。PCの資産管理や他部門からの問い合わせ対応が多い。
3は、システムの企画や発注だけ自分たちで行い、開発も運用保守もアウトソーシングしている。

チケット駆動開発を上記の3パターンのユーザ企業が運用する場合、どのように使うと効果的だろうか?

1の場合、我々開発者がTiDDを使っているパターンと同じだ。
BTSをバグ管理だけでなく、SW開発のタスク管理にも使う。
利点は、開発チームのタスク管理がスムーズになること、そして進捗報告が楽になることだ。
導入も簡単だし、BTSのサーバーの保守も自分たちでできるだろう。
チケット駆動開発の運用方法も、バグ管理に慣れているだろうから、スムーズに慣れるだろう。

2の場合、BTSをITILで言うインシデント管理や問題管理の場面で使うと良いだろう。
ユーザ企業の他部門から、ネットが接続できない、とか、セキュリティパッチはどうするの?とか、詰まらない問合せが結構多いはず。
それらの問合せは、インシデントとしてBTSに登録し、インシデント管理プロセスに当てはめる。
更に、インシデントの根本原因に対して対策を講じた方が良い場合、問題管理プロセスで是正対策を講じる。
例えば、問合せを減らすには既存システムに機能追加した方がいい、という判断ならば、他部署や上司へエスカレーションしたり、SIerへ発注したりする。

つまり、BTSをチケット駆動開発へ拡張して運用する方法が基本になる。
Webサーバー設置は慣れているだろうが、BTSの経験も少ないと思われるので、チケット駆動開発の運用ルールにまず慣れてもらう必要があるだろう。

3の場合、BTSの使い道として、発注するシステムの要件管理に使う場合と、発注したシステムを受入テストで確認する場合の2種類があると思われる。

前者の場合、高機能なBTSでなければ要件管理として扱いづらいし、チケット駆動開発でチケットをストーリーカードとして扱う方法は難度が高い。
後者の場合、受入テストのテストケースはTestLinkで運用し、納品モジュールのバージョン単位にBTSでバグ管理していく運用になるだろう。
この場合も、テスト管理ツールとBTSを連携する必要があるし、チケット駆動開発の使い方としては難度が高い。

つまり、チケット駆動開発でも高度な運用方法が必要な上に、Webサーバーにも慣れていないだろうから、チケット駆動開発の導入はかなり難しいだろうと思う。

しかし、いずれの3種類の情報システム部門であっても、チケット駆動開発によって、日々のタスク管理が可能になるし、リアルタイムに進捗情報や傾向分析を得ることができる。
上手に使いこなせれば、業務を分析した結果を元に、業務の改善も可能になるだろう。
しかもオープンソースのツールを駆使するので、サーバーの知識さえあれば、基本的に無料で運用できる。

色々な状況でチケット駆動開発の運用が耐えれるか、考察してみたい。

|

2009/12/24

TiDDはレコーディングダイエット

下記の意図についてラフなメモ書き。

【元ネタ】
PSPはレコーディングダイエット: ソフトウェアさかば

PSPは、CMMI提唱者ハンフリーが編み出した開発者個人用のソフトウェアプロセス。
自分で工数見積やバグ集計、メトリクス集計して、自分でプロセス改善していくから、規律が厳しいプロセスという印象がある。
でも、PDCAを回すという発想は、どの開発プロセスでも同じ。
特に、Checkプロセスで使うメトリクスを収集する理由は、「測定できなければ制御できない」から。

レコーディングダイエットも似た発想。
記録していくうちに、反省点が出てきて、色々試しながら、自己改善していく。

チケット駆動開発も同じだ。
チケットをタスクカードのように扱い、そのチケットをBTSというDBに格納しておけば、色んな観点でいくらでも集計できる。
開発チームがその集計結果を使って、リリース後にKPTでふりかえりを行えば、バグの傾向や開発速度(ベロシティ)が分かるだろう。
それによって、開発チームの特性に見合った改善ができる。

SW工学やSWテスト、品質管理、PMBOK、ITILを今まで色々勉強してきて、確かに知識は溜まったけれど、実際の開発現場では使えなかった。
その理由は、それらの知識で分析するための元ネタであるメトリクスが無かったから。

バグ収束曲線の見方、テストの傾向分析、リスク管理、コスト管理、クリティカルパスなどの知識は、チケット集計結果という元ネタがあって初めて分析できるのだ。

従来は、開発者にExcelで進捗報告を提出させて、プロマネが自分でExcelマクロを作って集計するしかなかった。
しかも、その精度も低いし、手間もかかった。
PMBOKを自分のものとしているリーダーは、果たしてその知識をどうやって活用していたのだろうか?と思う。
ExcelやMSProjectでは、もはや昨今のスピードの速いプロジェクトに追いつけないはずだ。

僕が今後やりたいのは、チケット駆動開発をプロジェクト管理のインフラとして扱いたいことだ。
EVM、リスク分析、要件管理、構成管理など色んな各種技法は、チケット駆動開発上で全て制御できるはず。

今は単に、RedmineサマリやTracレポートぐらいでしか集計できないが、もっと高度な統計処理ができる可能性はある。
最終的には、チケット駆動開発のインフラの上で、プロジェクトの進捗をシミュレーションしたいのだ。

開発案件を請け負った時、きちんとWBSさえ作れれば、Redmineに放り込むと、すぐにガントチャートが生成できるし、色んな観点で集計できる。
WBSを元ネタとしてシミュレーションすれば、請け負った段階でもはや工数(コスト)がオーバーしていたり、納期がオーバーしていたりする場合もあるだろう。
その場合、スコープで調整するしかないということを、シミュレーション結果を使って利害関係者に説明することもできるだろう。

つまり、XPの計画ゲーム、Scrumのスプリント計画を、プロジェクトのシミュレーション作業まで昇華できるはずだ。
今は想像に過ぎないけれど、チケット駆動開発にはかなりのポテンシャルがあると思う。

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

2009/12/21

MSやIBMのアジャイル開発事例

MSやIBMがアジャイル開発に取り組んでいる情報をググッてみた。
気づいた事をメモ。
#あくまでもメモ書き。

【元ネタ】
IBM Rational Software Conference 2009 - Japan

アジャイル開発の有効性を、経営トップが理解すべき - @IT

アジャイル開発支援 - 記事一覧 - IBM Rational Software Conference 2009 イベントレポート【マイクロソフト】 長沢 智治

セッション資料ダウンロード (PDF 形式)

レポート:アジャイルカンファレンスTOKYO 2009|gihyo.jp … 技術評論社

IBM Rational Software Conference 2009レポート - dshinaの日記

【1】MSやIBMはどこまでアジャイル開発のノウハウを取得できているか?

MSもIBMも、大規模プロジェクトで地理的に分散しているオフショア開発でアジャイル開発を実践している。
その意味では、難易度の高い領域で実験しているから、とても興味深い。

アジャイル開発の特徴である「プロジェクトの見える化」をツールでサポートしているのがすごく印象的。
ツールとしては、IBMは「IBM Rational Team Concert」、MSは「MS Visual Studio Team Foundation」はいずれも、イテレーション計画の管理・実行時の進捗管理・タスク集計出力というチケット駆動開発の3つの基本機能は全て満たしている。

興味深いと思ったのは、IBMでもMSでもイテレーション計画を階層化していること。
IBMは、テーマ>プランアイテム>ストーリー>タスク、MSは、Scenario>Value Proposition>Experience>Featureの観点で要件からタスクまでを階層化し、追跡可能な構造にしている。

更に、プロジェクトライフサイクルの観点であるリリース計画と開発者のタスクの観点であるイテレーション計画を上記の階層に結び付けて管理していること。
マネジメントの観点からすれば、要件からタスクまでのWBSがこの構造に一致するし、計画の変更はツールでサポートできるから、上記の階層化によって精度の高い計画を作ることができるし、進捗管理も容易のはず。
また、集計機能はツールが得意とする領域なので、問題なし。

アジャイル開発のプロセスをツールでうまくサポートしている印象を持った。

【2】アジャイル開発を運用する時のハードルはどこにあるか?

だが、上記の資料に書かれていない問題点や課題の方が気になる。
イテレーション計画に「漸進型開発」と「反復型開発」の使い分けが書かれていないのが気になるし、並行開発をサポートする構成管理手法も特に記載がないのも気になる。
また、アジャイル開発のスケールアップはまだまだノウハウがあるはずだ。

アジャイル開発はいくつかの部分的なプラクティスを導入すれば、実現できるわけではない。
アジャイル開発の一番の特徴である「小規模リリース」を実現するには、資料に書かれていないたくさんの暗黙知があるはずだ。

今の僕がまだ理解しきれていない部分は、要件管理。
上記の資料にもあるように「要求は劣化する」。
顧客の要望は、昨今のような好不況の激しい時代ではすぐに変わる。
頻繁に起こる要件の変更をきちんと管理し、追跡できるような仕掛けを作るのは、Excelでは至難の業だ。

また、顧客の要望をそのまま受け付けてよいわけではない。
要望を詳細化して、仕様の整合性を取るのが開発者の仕事だが、この作業がとても大変で、しかもバグを埋め込みやすい。

結局、要件管理とは、要件の変更管理・トレーサビリティ・整合性をきちんとできることが必須条件になる。
しかしながら、実際は要件を管理する良いツールがなく、要件の変化にSW開発が追い付けていない現状がある。

今の時代は「品質やコストよりもスピード重視」のSW開発スタイルでなければ、生き残れないのかもしれない。

【3】今後の方向性

XPが2000年頃に出現した頃がAgile1.0ならば、Scrumがアジャイル開発の普及を後押ししている2005年以降がAgile2.0と呼べるのではないか?

XPは、Agile開発のプラクティスを提示し、開発者へ実践手法を提供したが、マネージャ層への影響力は弱かった。
Scrumは、プロセスとしての管理手法を提示し、マネージャ層へマネジメントの実践手法を提供した点に意義がある。
そして、IBMやMSのようなツールベンダーが本腰を入れ始めていることから、今後、アジャイル開発の知見も増えてくるだろう。

鍵は、アジャイル開発をどこまでSW工学の観点でプロセスとしてきちんと理論化できるか、にかかっているような気がする。

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

2009/12/19

TiDDを実践して気付いたことpart7~繰り返し開発を制する者はSW開発を制す

先日、S-OpenでRUPで有名なクールシュテン博士によるアジャイル開発の講演があった。
Agile開発は大規模プロジェクトでは難しい、アーキテクチャを重視するプロジェクトでは難しい、などの話を聞いて、そんな話は昔から聞いていた、と正直聞き飽きた。

そんな違和感を感じながらも、チケット駆動開発を実践して、アジャイル開発の難しさが何となく分かってきた気がする。
考えたことをメモ。

【元ネタ】
TiDDを実践して気付いたことpart6~TiDDでAgile開発を実践して分かってきたこと: プログラマの思索

TiDDを実践して気づいたことpart4~TestLinkによるテスト戦略: プログラマの思索

以前書いたように、Agile開発が難しい理由は、その最大の特徴である「超短期間の繰り返し開発」を実現するハードルが高いことにある。
その内容は次の3つに言い換えられる。

1・繰り返し開発はイテレーション管理が難しい
2・繰り返し開発において、インクリメンタル型開発と反復型開発を混同してる
3・繰り返し開発は並行開発でもあるため、並行開発の制御が難しい

1は、変化を受け入れる技術、プロジェクト管理、開発環境がなければ、アジャイル開発は絵に描いた餅だ。
当初の計画になかったタスクの追加、イテレーション内におけるタスクの優先順位の変更は、頻繁に起こるが、確実に対応するのはやはり難しい。
タスクから成果物まで追跡できるインフラがなければ、ほんの少しの仕様変更の対応なのに、バグを混入させてしまい、品質を劣化させてしまう。

3は、実は、繰り返し開発には並行開発というプロセスが実は隠れているという指摘。
短期間にリリースしていくと、一度リリースしたシステムは生き続けるが、裏では次バージョンに向けて機能改善していく。
大規模プロジェクトになるほど、複数のサブチーム、サブシステム、製品ファミリーで同じような現象が起きるから、どんどん制御が難しくなる。

2で提起した「漸進型開発(インクリメンタル)」と「反復型開発(イテレーティブ)」の使い分け戦略こそが、違和感の根源だと思う。
「アジャイル開発では、アーキテクチャ重視や品質重視のプロジェクトでは有効でなかった」と講演で話していたが、それは漸進型開発のみで解決しようとして失敗するだけであって、2種類の繰り返し開発を切り替える発想がないだけだと思う。

一定の期間で機能拡張しながら小刻みにリリースしていく漸進型開発は、開発者にとってとても楽しい。
リリースするたびに作ったものが動くので、ユーザが確認できるだけでなく、開発者にとっても、開発のゴールはリリースなのだ、といつも再確認できる。
イテレーションのリズムで開発するのは、開発者のモチベーションアップにつながるし、楽しい。
試行錯誤しながらリリースしていくというスタイルには、漸進型開発がとてもやりやすい。

でも、アーキテクチャを作りこんでから機能追加していくスタイルや、とにかく稼動するシステムへ更に品質を作りこんでいくスタイルには、漸進型開発だけでは物足りない。
アーキテクチャや品質は1個のイテレーションだけで実現できるわけがない。

例えば、性能などの非機能要件は、全てのイテレーションで実現せねばならないが、解決方法は、試行錯誤しながら分かる時が多い。

また、作った機能の殆どは単体テストを通過しているから動くけれど品質に不安がある場合、システムテストや受入テスト、モンキーテストなどで、システム全体をテストして細かなバグを潰していく。

あるいは、ソフトウェアプロダクトラインのように、製品ファミリーの共通部品をコア資産として抽出し、各製品の特徴はアプリケーション資産で開発するスタイルの場合は、どうしてもアーキテクチャ重視になる。
そのアーキテクチャは試行錯誤しながら、決めていくことが多い。

品質もアーキテクチャも反復型開発で、システム全体を俯瞰して少しずつ作りこんでいく方がやりやすい。
でも、反復型開発の弱点は、スコープが発散しがちなこと。
実際の開発では、テストしながら仕様変更にも対応したり、割り込み作業が入ったり、変化が発生する。
更に、アーキテクチャや品質はいくらやっても、終わりがない作業だから、それらに対応するたびに、どんどん工数も作業の範囲も膨らむ。
だから、反復型開発はスコープを意識しなければ、とても難易度が高いと思う。

逆に、漸進型開発では、リリースと言うとても強い制約条件のおかげで、スコープがあまり広がることはない。
リリースというゴールがあるから、開発チームだけでなく、ユーザにも強い制約をかけることができる。

他に、大規模プロジェクトに繰り返し開発を適用する場合、サブチーム内部では漸進型開発で開発させて、複数のサブチームの結果を統合するイテレーションでは反復型開発に切り替える手法が最も現実的だと思う。
例えば、Webシステムの結合テストや、組み込み製品開発でSWチームとHWチームが連携する工程は、反復型開発に切り替えて、品質をまず確保する戦略を取る。
特に、チームのスケールアップには、反復型開発の方がやりやすいように思う。

チームのスケールアップでは、並行開発のインフラがあることも重要だ。
つまり、サブチーム単位にブランチがあるわけだから、そのブランチ間で最新機能を相互に確実にマージできるインフラがなければ、すぐに統制が取れなくなる。
多分、MercurialやGitのような分散バージョン管理がその解決方法になるだろう。

反復型開発をどの場面で使うべきか、漸進型開発をどの場面で使うべきか、戦略がはっきりしていないから、未だにアジャイル開発は難しい、と言っているだけなのだ。
それらの問題は、分散バージョン管理とチケット駆動開発を組み合わせれば、開発インフラに関してはほぼ解決できると思う。

今のSW開発は、常に新しい技術を取り込んで、定期的にバージョンアップする宿命を持つ。
変化を取り入れるのはSW開発の宿命。
繰り返し開発は「変化を受け入れる」ことができるのが最大の特徴。
繰り返し開発を制する者はSW開発を制するのだ。

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

2009/12/18

更にもう一つのAll In OneRedmine~RedmineLE

All In One Redmine たち - かおるんダイアリーから、もう一つのAll In OneRedmine~RedmineLEを見つけたのでメモ。

RedmineLE プロジェクト日本語トップページ - SourceForge.JP

Windows上でインストーラに従って、インストール場所やポート番号を設定すると、下記を一括インストールしてくれる。

Apache 2.2.13
Apache Ant 1.7.1
Hudson 1.334
imagemagick 6.5.3-10
OpenDS 2.0.0
Redmine trunk rev 3089 (0.9.x)
Ruby 1.8.7
Ruby on Rails 2.3.4
SQLite 3.6.17
Subversion 1.6.4

これってすごく便利ですね。
SVNとHudsonがあるので、新規プロジェクトを立ち上げる時はワンクリックでOK。
しかも、LDAP対応だから、Windowsのアクティブディレクトリにも対応できているから、社内で開発する時は重宝しそう。
できれば、TestLinkもあれば全く問題なし。

RedmineもTracLightningに劣らず、インストールが簡単になって来たのはとても嬉しい。

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

2009/12/17

もう一つのAll In One Redmine

Redmine本家にもう一つのAll In One Redmine情報があったのでメモ。

【元ネタ】
Redmine Appliance | TurnKey Linux Virtual Appliance Library

VMを置いているらしい。
内容は下記の通り。

redmine 0.8.4 (upstream tarball)
git-core 1:1.5.4.3-1ubuntu2.1
bzr 1.3.1-1ubuntu0.1
subversion 1.4.6dfsg1-2ubuntu1.1
mercurial 0.9.5-3
apache2 2.2.8-1ubuntu0.11
mysql-server 5.0.51a-3ubuntu5.4
ruby 4.1
rubygems 1.3.5
rails 2.3.4
rake 0.8.7
passenger 2.2.5

GitやMercurialがVMにデフォルトでインストール済みなのがいい。
bzrまで使えるし。
しかし、RedmineやRuby関連はVersionが新しいものの、SVNやMercurialのバージョンはかなり古い。

同様にTracのVMもある。

Trac Appliance | TurnKey Linux Virtual Appliance Library

trac 0.11.1-2.1
trac-bzr 0.2+bzr45-1
trac-git 0.0.20080710-3
trac-mercurial 0.11.0.5dev~svnr7354-2
git-core 1:1.5.4.3-1ubuntu2.1
bzr 1.3.1-1ubuntu0.1
subversion 1.4.6dfsg1-2ubuntu1.1
mercurial 0.9.5-3
apache2 2.2.8-1ubuntu0.11

Tracで、GitやMercurial、bzrが使えるのは面白そう。

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

astah*Professionalファーストインプレッション

ようやくastah*Professionalを購入した。
JudeCommunityを2004年に使い始めてから5年以上経ち、色んな機能を使ってみたくなった。

astah* professional6.0の新機能

EnterpriseArchitectやRationalRoseも使ってきたけれど、astah*ProfessionalのUIや操作感の簡便さにはかなわない。
EnterpriseArchitectは殆どのモデリングをカバーしていて機能も豊富でピカイチだけれど、僕は何かフィットしなかった。
自分のアイデアをUMLで色んなダイアグラムで書きながら分析していく時に、サクサク書けるスピードはastah*Professionalが一番かなと思う。

astah*Professionalで気付いたのは、UMLがVer2.0に対応している事。
UMLはVer2.0になってとても複雑になったように思うが、その理由はおそらく組込みシステム向けのモデリング記法を整備したかったからだろう。
業務系システムや普通の開発ならば、UMLのVer1.x台で十分と思う。

astah*Professionalで面白い機能と思うのは下記5つ。

1・ER図
2・マインドマップ
3・フローチャート、DFD
4・要求テーブル、テストケース
5・JudeAPI

ER図があるおかげで、astah*Professional上でデータモデリングも可能。

マインドマップは要求分析で要求の洗い出し、要件の定義に使える。
でも、FreeMindに慣れているので、FreeMindと互換性があると嬉しいのだが。

要求テーブルやテストケースは興味惹かれる機能。
SysMLに合わせた仕様らしく、まだ使い方が分からない。
TestLinkの要件やテストケースがそのまま使えるならば、「要求→モデル←テストケース」の形で追跡可能になる。
モデルのトレーサビリティが可能になるから、試してみたい。

また、JudeAPIはJavaやJRubyからastah*Professionalのモデル情報を取得できる。
下記のように、モデルからファンクションポイントを自動計算できれば、見積りの精度が上がる。

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

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

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

astah* Community Site - フォーラム

分析設計モデルをわがままに活用しよう JUDE API入門(1/5):CodeZine

他にも色々試してみたい。

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

第二期アジャイルムーブメント

第二期アジャイルムーブメントの記事があったのでメモ。

【元ネタ】
第二期アジャイルムーブメント ~ アジャイル開発の商業的取り組み と Agile2.0 ないし 「2週目の世界」 について - kawaguti の日記 (id:wayaguchi)

スクラムブートキャンプ ~ 今からスクラム/アジャイルをやってみようという人のための道しるべ - kawaguti の日記 (id:wayaguchi)

スクラムチェックリスト by Henrik Kniberg @ crisp.se - kawaguti の日記 (id:wayaguchi)

XPが2000年に出た頃が第1次アジャイルムーブメント。
アーリーアダプター層が中心。

Scrumが開発現場に適用され、数々の事例が紹介されて、注目を浴びている最近が第二期アジャイルムーブメント。
マーケット的には、アーリーマジョリティ層に広がりつつある。
上記の記事で面白いのは、アジャイルムーブメントの原因の一つに「WikiおよびWikiベースのプロジェクト管理ツール (Trac, Redmine)」があげられていること。

Redmineによるチケット駆動開発の経験を通じて、ツール無しでアジャイル開発を運用するのは難しいだろうと思う。
ホワイトボードやPostItによる牧歌的なアジャイル開発は、今のビジネスのスピードに付いていけないと思う。


スクラムチェックリスト by Henrik Kniberg @ crisp.se - kawaguti の日記 (id:wayaguchi)も面白い。
これは、[Agile]Agile Conference Tokyo 2009に行ってきた | Ryuzee.comであげられているIBMのAgileへの適合性のチェックリストの役割として扱えるかもしれない。
このチェックリストをあらかじめ収集できれば、アジャイル開発導入のリスクに未然に対処しやすくなる。

アジャイル開発の運用ノウハウはこの10年で色々溜まってきた。
後はどれだけ普及させて、運用事例を増やして、更に進化できるか、に鍵がかかっている。

そして最終的には、チケット駆動開発はAgile2.0を目指しているはずだ。

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

EclipseのMercurialプラグインHgEclipse

EclipseのMercurialプラグインHgEclipseをインストールしたのでメモ。
#まだ使い倒してないのであくまでもメモ。

【元ネタ】
Pleiades - Eclipse 日本語化

Welcome to HgEclipse

HgEclipseのScreenshots

インストールはすごく簡単。
MercurialプロジェクトはCloneして作るようなので、あらかじめTortoiseHgかMercurialで元プロジェクトを作っておく必要がある。

UIや操作感はSubclipseと同様で問題なし。
Eclipse上から使えるから、とても便利。

EclipseもJavaだけでなくRuby・PHP・Pythonにも対応しているから、Mercurialが使えれば、よりアジャイルに開発できるだろう。

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

2009/12/15

Mercurial以前と以後のチケット駆動開発

Mercurialのような分散バージョン管理を組み合わせたチケット駆動開発とそれ以前の開発スタイルの違いをまとめる。

【元ネタ】
Re:Re:mercurialでチケット駆動開発 - ろじぼ

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

ReviewBoardとMercurial+TiDDは相性が良い?: プログラマの思索

【Mercruial以前のTiDD】

「Mercurial以前のチケット駆動開発」シートにあるように、trunkと本番ブランチの2本でソース管理している。
基本は、trunkはリファクタリングや機能追加、本番ブランチは障害修正のみ行い、ソース修正の目的をコードライン単位に使い分ける。
理由は、コードラインの品質を維持したいからだ。
リファクタリングや障害修正、機能追加をtrunkの1本のみで行うと、突然の本番障害に対応できなくなるからだ。
そして、リリース予定のバージョンをtrunkからリリースするタイミングで、タグ付けして新しいバージョンの本番ブランチを作成していく。

これがメインラインモデルによる構成管理の原形。
つまり、本番ブランチはtrunkよりも品質が高く、硬いコードラインになる。
「硬い」という意味は、品質が安定しているだけでなく、ソースを触る作業も障害修正の目的以外は許されない意味も含んでいる。

すると、本番ブランチで障害修正を施した場合、trunkへマージする作業が発生する。
Subversion+Redmineでは、「障害修正」と「マージ作業」のチケットを別々に作り、相互に関連付けていた。
そして、マージ作業のタイミングは、trunkへガンガン機能追加中のチケットの進捗と調整して、優先度を付けていた。
当然、trunkのリリース予定バージョンにマージ作業も機能追加のチケットもアサインされる。

つまり、チケットのリリース順は、ロードマップのバージョン単位に分割するため、バージョンの順番になる。
そして、チケットの開発順は、バージョンの内部でチケットの優先順位を付ければいい。

チケット駆動開発では、チケットの関連やチケットの進捗が見えやすいので、マージ作業をTODO管理のイメージで運用していた。
但し、マージ作業は手作業のままであり、タグ付られたリビジョンを参考にマージ作業を慎重に行う必要はあった。

【Mercurial以前の大規模プロジェクトの構成管理】

大規模プロジェクトでは更にこの状況が複雑になる。
本番ブランチとtrunkの扱いは基本はほぼ同じだが、テスト環境ブランチを別途作る時が多い。

テスト環境ブランチは、サブの開発チーム単位に作られ、バグ修正や機能追加などを行う。
trunkと別ブランチにする理由は、複数のサブチームのソースがtrunkに混じると混乱しやすいからだ。
つまり、trunkを常時リリース可能なラインにするために、テスト環境ブランチをタスクブランチのように扱う。

テスト環境ブランチ上で、開発者は修正し、テスターは検証する。
検証完了になったら、タグ付けし、trunkへマージしてリリースする。

このリリース作業では、普通はライブラリアンがExcelのリリース作業一覧を作っており、このExcelの一覧に従って、タグを見ながら慎重にマージしていく。
理由は、開発順とリリース順が異なる場合は多いからだ。
リリース順序は、複数のサブチームを統括するプロマネがユーザと調整して決まるが、裏では開発を先取りしている時も多い。

だから、Excelのリリース作業一覧が常に最新化されているのが重要になってくる。
結局、複数人が手作業で厳重に管理するプロセスになり、機動性は低くなる。

【Mercruial+TiDD】

「Mercurialによるチケット駆動開発」は「Mercurial以前のチケット駆動開発や「Mercurial以前の大規模プロジェクトの構成管理」を更に洗練させた構造になる。
つまり、テスト環境ブランチをconfirmブランチとして扱い、Mercurialのpull&pushでtrunkやconfirmブランチのマージ作業を自動化して、trunkを機能が最新かつ常時リリース可能な品質に保てる。
更にチケット単位にトピックブランチを作り、トピックブランチをタスクブランチのように扱うことで、trunkやconfirmブランチに品質が不十分なソースをコミットする危険性を防いでいる。

このようにブランチをたくさん作っても安心できるのは、分散バージョン管理の優れたマージ機能(pull&push)があるおかげだ。

またこの開発スタイルは、オープンソースの開発プロセスに似ている。
つまり、トピックブランチがハッカーが作業するパッチ当てのコードラインに対応し、trunkへのリリースは、コミッタのレビューがOKの場合、trunkへパッチが反映される手順に相当するからだ。

分散バージョン管理のおかげで、SW構成管理の作業品質は確実に上がる。
チケット駆動開発と組み合わせれば、複雑なリリース作業を楽にしてくれるはずだ。

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

メトリクスでソフトウェア品質を見える化する

現場で使えるソフトウェアテスト Java編」を読んで内容がとても素晴らしいのでメモ。

【1】「現場で使えるソフトウェアテスト Java編」の対象読者は、Java開発者。
内容は、Eclipseの下記のテスト用プラグインで、Javaプログラムのテストや品質を解説している。

【本書で解説するEclipseプラグイン】
・Checkstyle → コーディング規約チェック
・FindBugs → バグパターン検出
・JUnit → 単体テストの作成/実行
・TPTP → プロファイリング(非機能テスト)
・djUnit → カバレッジ計測
・StepCounter → ソースコード行数測定

上記のプラグインのうち、全てを使いこなしている開発者はどれくらいいるのだろうか?
僕は、Checkstyle・FindBugs・JUnit・djUnitは使った事があるが、TPTPやStepCounterは知らなかった(^^;)

JUnitを使った単体テストで網羅的なテストを行う為に、境界値分析や同値分析をどのように使うか、静的解析とJUnitの使い分けも、分かりやすく説明されている。

【2】特に「現場で使えるソフトウェアテスト Java編」の第8章「ソフトウェアの品質評価~メトリクスで品質を「見える化」する」の内容がとても素晴らしい。

CHAPTER 08 ソフトウェアの品質評価~メトリクスで品質を「見える化」する
8-1 品質評価の進め方
  8-1-1 品質評価とは?
  8-1-2 品質評価の作業手順
8-2 品質評価の技法
  8-2-1 メトリクスを使った評価(定量評価)
  8-2-2 時系列データによる品質評価(バグ収束曲線)
  8-2-3 定性評価
8-3 例題による実習~プロセス/技法の実践方法
  8-3-1 メトリクスの測り方
  8-3-2 品質評価

メトリクスを利用した評価方法について詳しく説明されている。

日本の品質管理が生み出した手法「QC7つ道具」のうち「管理図」というものがある。
管理図は、品質の折れ線グラフが上限と下限の間の管理限界線内に含まれていれば、品質OKと評価する為の図。
例えば、メトリクスを管理図に応用して、上限と下限の範囲を品質の許容範囲と見なせばいい。

この時、メトリクスには色んな指標がある。
LOC、サイクロマチック数(複雑度)、凝集度、結合度。
テスト密度、コードカバレッジ、バグ密度、など。
これらの値は、SVNやRedmine、Hudsonにあるから自動集計できるだろう。

僕は、StatSVNStatCVSをcronで動かし、システムのLOCや開発者のコミット具合をメンバー全員が見れるようにしている。
StatSVNを見ていると、結構気づきが多い。

次は、Sonarを試してみようと思っている。

【3】また、テスト密度とバグ密度、テスト密度とコードカバレッジのマトリクスによる品質評価技法の解説も面白い。
例えば、テスト密度とバグ密度では、下記4ケースが考えられる。

3-1.テストが足りなくてバグが多い場合
→根本的にテスト計画をやり直した方がいい。

3-2.テストが足りないのにバグも少ない場合
→テストをもっと追加実施した方がいい。まだバグが出る可能性があるから。

3-3.テストを実施しすぎたためバグが多い場合
→本当にバグを出し切ったのか確認した方がいい。まだバグが出る可能性があるから。

3-4.テストを実施しすぎたのにバグは少ない場合
→品質に問題がある可能性は少ない。

テスト後に上記のように分析すれば、テストの傾向が見えるはず。
あらかじめテスト計画で上記の分析を考慮すれば、テスト時に意思決定に混乱する事もないはず。

TestLinkCnvMacroを使えば、TestLinkのテスト実績を簡単に集計できるので、代用できるはず。

【4】又、バグ収束曲線の解説も分かりやすい。
バグ収束曲線は、横軸に時間、縦軸に累積のバグ数を取った時系列の折れ線グラフ。
バグ収束曲線は普通、S字カーブでバグが増えるものの、テストが進むにつれてバグが検出されなくなる状態になる。

このバグ収束曲線の品質評価を下記3パターンで説明している。

4-1.バグの目標値に向かって収束している場合
→理想的なパターン。
 但し、バグの増え方の角度によって、品質評価が微妙に異なるので注意。
 「Γ」「S」字ならば品質をコントロールできているが、ギザギザ型ならば、収束するのか注意が必要。

4-2.バグの目標値を超えて増えている場合
→とても危険なパターン。
 バグの目標値を越える時点、あるいはそれ以前に早く異常を検知し、根本原因を分析すべき。
 実際のSW開発では、バグ修正しながら仕様追加にも対応するから、スコープを制御できなければ、このパターンに陥りやすいと思う。

4-3.バグの目標値を超えて高い値で収束している場合
→バグの目標値を超えた時点で品質は悪いけれど、収束に向かっているので、潜在バグは少ないと想定できる。
 実際のSW開発では、当初よりもコストが増えても、このパターンに落ち着く場合が多いように思う。

バグ収束曲線とテストケース消化曲線を重ねたグラフがあれば、テストの生産性や品質の測定が分析しやすくなる。
このグラフ生成も、TiDD上で自動生成できるはず。

【5】バグの傾向分析として、T型マトリクスというマトリクスがある。
T型マトリクスは、縦軸にバグ発見工程、左横軸がバグを作りこんだ行程、右横軸がバグを発見すべき行程で表を作る。

設計・開発における 品質保証・ミス防止活動のあり方

対角線上にあれば問題ないものの、対角線以外で発見されたバグは、潜在バグや同類バグが残っている可能性を示すから、更に分析が必要というもの。

JaSST関西2009のTEF関西コミュニティセッションでも紹介された手法で知っていたが、使いこなしてないので、やってみたいと思う。


品質管理は日本のお家芸とも言える分野。
特に製造業は品質管理が世界一だから、今まで世界を制覇してきた。
しかし、IT産業の品質管理は正直ボロボロと言ってもいいだろう。
ソフトウェアのメトリクスの知識はおそらく、テスターは知っていても、開発者は意識していないのではなかろうか?

この本は入門書としても実践書としても読みやすいので、まずこのやり方を真似ればいいと思う。
そして、できれば、品質評価もTiDD上に載せて、品質評価プロセスを自動化したい。
SVNやRedmine、Hudsonに品質評価で使われる元ネタは存在しているからだ。

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

2009/12/13

コードレビューは緩いペアプログラミング

記事は古いけど、気付いたことをメモ。

【元ネタ】
【ITpro Challenge!】「高い生産性を実現する『ハッカーのソフトウエアエンジニアリング』とは」---Google 鵜飼文敏氏:ITpro

(前略)
 開発もなるべく小さな単位で行う。「設計しつつ実装,こまめにマイルストーンを設定する。小さい単位で動くものを作る。作る順序は後で使うものから。テストしやすさ,デバッグしやすさのために重要」(鵜飼氏)。
 既にあるコードを利用して,新たに作らないことも重要だ。「何を作らなくていいか,利用できるか,把握する。持ち駒が多ければ多いほどいい」(鵜飼氏)。
 Googleに入って感じたのはコードレビューの有用性だという。「コードレビューはとてもいい。ゆるいペアプログラミングのようなものでお互いのコードをチェックできる。ペアプログラミングは時間が拘束されるが,コードレビューならいつでもどこでもできる」(鵜飼氏)。
 デバッグの際はバグが存在する範囲を狭めて絞り込んでいく。あるいは狭めるようなテクニックをあらかじめ仕込んでおく。
(後略)

生産性:知識ゼロから学ぶ ソフトウェアテスト:So-netブログ

(前略)
個人的にはなるべく優秀な人を優遇したgoogleなりmicrosoft方式が気にっている。ソフトウェアプロセスも重要だと思うけど、優秀な人はCMMIがなんだかんだ言う前に日々現実的な作業改善をしている。
なんかペアプロよりこコードレビューのほうがいいというのも共感する。
(後略)

XPのプラクティスの一つであるペアプロは、二人の目による品質チェックと設計情報や技術ノウハウの共有という二つの利点がある。
実際の現場では、ペアプロを意識して実施されることはないが、本番リリース作業やDBメンテ作業など失敗が絶対に許されない状況では、自然にペア作業を行っている。
また、要件定義プロセスで複数人の設計者がペアで設計したり、初めてのアーキテクチャを使ってプログラミングする時は自然にペアプロしている。

しかし、ペアプロは同じ場所に二人同時に在席する制約があるため、疲れやすい。
コードレビューならば、非同期にペアプロできるのでいつでも可能だし、緩やか。

チケット駆動開発では、ワークフローを徹底すると、自然にペア作業になる。
例えば、バグ修正(PG)とバグ検証(テスター)、作業(PG)と承認(PL)、質問(開発者)と回答(設計者)、のように。

このプロセスをチケット駆動開発やコードレビューWebシステムで補完できないか?

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

2009/12/11

TestLinkを受入テストで運用する方法

以前のhokorobiさんの記事にあったTestLinkの使い方の意味がようやく分かったのでメモ。
僕が勘違いしていた部分もあったので、再考してみる。

【元ネタ】
TestLink を使ってみた - hokorobiの日記

テスト手法の概念をTestLinkで説明する: プログラマの思索

第5回 脱Excel! TestLinkでアジャイルにテストをする - hokorobiの日記


TestLinkの運用方法は、開発チームがシステムテストで使う場合と発注者が納品モジュールを受入テストで使う場合で、観点が異なるようだ。

【1】開発チームがシステムテストで使う状況では、テスト計画をイテレーションと同一視して、Agileに開発するのがいいと思う。
理由は、スコープを狭めて徹底的にテストでバグを潰し、リリースできる範囲を少しずつ広げる手法の方が、システムの品質を確保しやすいからだ。
バグが残っているのに、新規機能をどんどん開発しても、開発チームはどんどん混乱するだけ。

この状況では、複数個のテスト計画をイテレーション単位を作り、テスト計画とビルド(テスト実施結果)は1対1の運用になる。
つまり、数百に絞ったテストケースをテスト計画にアサインし、ビルドは、テスト完了直後にビルドモジュールの最終バージョンでリネームする運用方法。
すると、バグ1個の発見と検証の作業履歴は、同一ビルドで運用する。

僕が運用している方法は、このやり方であり、まずは全てのテストケースを最低限1回はテストするのを最優先する。
そうでなければ、数千のテストケースを数ヶ月以内に終わらせることはできないし、バグが出るほどバグ修正と検証の連携作業が混乱してしまい、最悪の場合は、全テストケースすらテストできないだろう。

【2】しかし、発注者の観点では、SIが納品したモジュールを発注者が作った受入テストケースでテスト管理したい。
この状況では、テスト計画は受入テスト1個だけで、ビルドは納品モジュール単位に管理したいはず。
つまり、テスト計画とビルドは1対Nの関係になる。

状況としては、SIから届く納品モジュールでテストできるバグの履歴をビルドで別管理しておきたい。
理由は、どの納品モジュールで確実にバグが修正されたか、区別したいからだ。
すると、バグ1個の発見と検証の作業履歴は、異なるビルドで管理して運用するため、ビルドは納品モジュールのビルド番号でリネームしてテストを開始するだろう。

第5回 脱Excel! TestLinkでアジャイルにテストをする - hokorobiの日記で紹介されたhokorobiさんのテスト手法はこのやり方に相当する。

TestLinkのVer1.8のテスト実行画面では「以前のすべてのビルドにおける結果」というフィルターがあるので、過去のビルドで失敗したテストケースをフィルタリングして、そのテストケースだけテストに専念すればいい。
つまり、最新版の納品モジュールでは、過去直近の納品モジュールでバグが出たテストケースを最優先にテストすればいい。

しかし、hokorobiさんの指摘通り、上記のやり方では、我々が想定しているテストケースが「以前のすべてのビルドにおける結果」でフィルタリングできないバグ(?)っぽい現象がある。

本来ならば、TestLinkには、過去直近のビルドの情報を最新版のビルドへ複製する機能があるべきだ。
その機能があれば、最新版のビルドで、テスターは「成功」以外のテストケースを順次テストしていけばよい。

TestLinkはまだまだ使いづらいけれど、テスト管理を改善してくれるポテンシャルがある。

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

2009/12/09

ReviewBoardとMercurial+TiDDは相性が良い?

Mercurialによるチケット駆動開発の仕組みがコードレビューのプロセスに似ているアイデアをメモ。
#ラフなメモ書き。

【元ネタ】
ReviewBoard | Documentation | General Workflow

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

コードレビューWebシステムReviewBoardには、「pre-commit review」「post-commit review」の2種類のやり方がある。
ReviewBoardは「pre-commit review」の考え方で作られている。
つまり、改変したコードをtrunkにコミットする前にレビューを受けるプロセス。
多分、オープンソースの開発ではよく使われているコードレビュー手法だと思う。

開発者は、SVNなどでdiffを作り、ReviewBoardリクエストに登録し、レビューアのレビューを受ける。
つまり、trunkにすぐにコミットせず、自分のローカルに修正パッチを保持し、レビューアの指摘を反映して、OKが出たら、trunkへ初めてコミットできる。
このやり方は、trunkに中途半端なソースをコミットしないための運用ルール。

「post-commit review」は、改変したソースをtrunkとは別ブランチに作り、レビューを受けるプロセス。
「post-commit review」のレビュー方法は、Mercurial+TiDDでもっと簡単になるはず。
そのアイデアをまとめてみた。

つまり、チケット単位にMercurialのトピックブランチを作り、担当者はトピックブランチでガンガン開発する。
そして、ソース修正が終われば、チケットを解決ステータスにし、ReviewBoardリクエストへ登録してレビューを依頼する。
この時、ReviewBoardリクエストとRedmineチケットを相互リンクさせておく。

そして、レビューアの指摘を受けてMercurialのトピックブランチ上で修正し、レビューOKが出たら、初めてtrunkへpushする。
MercurialやGitならば、トピックブランチの管理が簡単で、trunkから最新機能を随時pullすればいい。
当然このやり方でも、trunkに中途半端なソースはマージされないので、trunkの品質は保たれる。

ReviewBoard上のコードレビューはRedmineチケットと紐づいているため、Redmineのワークフロー管理機能を使って、レビュー用プロセスを容易に管理できる。
もちろん、進捗管理も可能だ。

おそらく、コードレビューが重要と誰もが知っているのに実プロジェクトで運用できない原因は、分散バージョン管理のようなインフラがない為にソースの品質管理が難しく、ReviewBoard+TiDDのようなインフラがない為にコードレビューをワークフロー管理するプロセスが曖昧だからだろう。

Mercurial、TestLink、Hudsonなどのツールと連携したチケット駆動開発には色んな可能性を感じている。
ツールを駆使して、SW開発の生産性を上げてプロセス改善していくやり方は、もっと研究されていい気がする。

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

RedmineのMSProjectプラグインその他

Redmineのプラグインを見つけたのでメモ。

【元ネタ】
Redmine MS Project インポートプラグイン開発記録 (2) - すえひろがりっっっっ!

r-labs - Redmine関連ツール集 - Redmine


MSProjectプラグインは、MSProjectで作ったWBSをRedmineへインポートできる。
プロマネにはありがたい機能。
CSVインポートとMSProjectのXMLインポートを使い分けてもいいかもしれない。

r-labs - Redmine関連ツール集 - Redmineを見ると、r-labs - Redmine Toolbar - RedmineというFireFoxのAddOnやiPhoneアプリもあるみたい。

rRedmine Toolbarは、登録したURLを修正できなかったり、入力するプロジェクト名がRedmineのプロジェクト名と一致していないとエラーになるなど、使い勝手は悪いけど、FireFoxから簡単にアクセスできるのは嬉しい。

こう見てくると、RedmineはRailsなのでプラグインも作りやすいみたいだね。

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

Redmineで要件管理、リスク管理ができるプラグイン

Redmine - Plugin List - Redmineを見ていたら、面白そうなプラグインがあったのでメモ。
#試していないのでメモ書き。

【1】Estimer Redmine - Estimer - Redmineは、Function Point・ユースケースポイント・Cocomo II の見積もりを計算できるらしい。
チケットにこれらの見積もりをアサインするのかな?
Function Point・ユースケースポイント・Cocomo IIの見積もりで使うモデルとチケットに同期が取れれば、チケットからモデル、そして見積もりの根拠まで追跡できる。

【2】RequMNGT Redmine - RequMNGT Redmine Wiki - Redmineはソフトウェア要求の管理や追跡やベースライン管理ができるらしい。
おそらくチケットに要求や要件を登録し、ベースラインをバージョンのように扱うものと思われる。
このプラグインが本当に機能するならば、要件管理もタスク管理も全てRedmineチケット上で操作すればいい。

【3】RiskMNGT Redmine - Risk MGNT Wiki - Redmineは、リスク管理とそのリスクの影響度合い、リスクから発生したインシデントを管理するらしい。
そもそもインシデント管理で重要な事は、顧客から大量に寄せられるあまり重要でない問合せは実は、少数の原因に落ち着くから、真の根本原因まで探る事にある。

つまり、ハインリッヒの法則 - Wikipediaが実は背後にある可能性がある。
このハインリッヒの法則は、1:29:300の法則とも言われていて、300件の些細なインシデントにつき1件の重大な事故が起きるというもの。

リスク管理は、重大な事故を起こさないように、その事故を発生させる要因を予防して、あらかじめ潰す事にある。

他にも、下記のプラグインが気になる。
やっぱり、ScrumのアイデアやPFのかんばんなどを実現するツールに興味が惹かれる。

Redmine - Backlogs plugin 0.0.1 (scrum/agile) - Redmine
Redmine - Redmine Blog Plugin - Redmine
Redmine - PluginKanban - Redmine
Redmine - PluginSchedules - Redmine
Redmine - Redmine Scrumdashboard plugin - Redmine
Redmine - PluginStuffToDo - Redmine
Redmine - Feature #443: Subtasking - Redmine

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

2009/12/08

Mercurialによるチケット駆動開発は強力だ!

Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。
このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。

【元ネタ】
mercurialでチケット駆動開発 - ろじぼ

上記の記事を理解できた範囲でまとめてみた。

【仮定】
・SCMはMercurial。(Gitでも良い)
・BTSチケットでSW開発のタスクを管理する。

・trunk、confirmブランチは中央リポジトリ(サーバー)にある。
・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。
 常時同期されている。
・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。

【チケットAブランチ上の作業手順】
1・チケット担当時に、ブランチ作成。【チケットのステータス=担当】

2・チケットAブランチ上でガンガン開発する。【チケットのステータス=担当】
 →trunkの更新は随時マージ(pull)して、最新機能を取り入れる。

3・チケットA解決時、confirmブランチへpush。【チケットのステータス=解決】

4・チケットA検証はconfirmブランチで行う。【チケットのステータス=検証中】
 テスターはconfirmブランチで検証する。
 confirmブランチはたくさんのチケットを検証するコードラインなので、trunkよりも品質は劣る。
 confirmブランチはtrunkからpullされるが、pushはしない。

5・バグを検知したら、チケットAブランチで修正して、confirmブランチへpushする。【チケットのステータス=フィードバック】

6・confirmブランチでチケットA検証完了後、チケットAブランチからtrunkへpushする。【チケットのステータス=検証完了】
 →confirmブランチからtrunkへpushしない。
  confirmブランチには他チケット検証も混じっているから、trunkへマージすると中途半端な機能も取り込まれてしまうから。

上記のやり方が優れているのは、チケットブランチ(トピックブランチ)だけでなく、チケットの修正パッチをconfirmブランチで検証している点だ。

チケットをトピックブランチにして開発し、チケットの修正パッチをtrunkへマージする場合、チケットの修正パッチにバグがあれば、trunkの品質は落ちてしまい、リリースできなくなる。
だから、confirmブランチでテスターが別途検証できるコードラインを作っておく。
当然バグがあれば、テスターは担当者に差し戻し、バグ修正したソースをpushしてもらって更に検証する。

この時、confirmブランチでは、担当チケットの検証以外にも、複数の担当者、複数のチームが開発したソースを並行して検証中している状況は多い。
これが「リリース順≠開発順の状況」の意味。
つまり、confirmブランチはtrunkよりも更に最新の機能が実現されているが、品質はtrunkよりも劣る。
だから、trunkへマージするタイミングが非常に重要。
マージするソースの品質が安全でないのにtrunkへマージしてしまうと、デグレが起きてしまうから。

そして、チケットの修正が終わったら、チケットブランチからtrunkへpushする。
以前は、このconfirmブランチ上でチケットの作業を実施し、CVSやSVNのタグを付けて、チケット(バグ報告票)の番号と関連付けたExcelのリリース一覧で管理していた。
このExcelのリリース一覧を見て、ライブラリアンは、リリース順(≠開発順)にタグをtrunkへ手作業でマージしていた。
だから、この作業はとても煩雑で慎重に行う必要があった。

しかし、上記のやり方ならば、チケットブランチからturnkへのマージ作業を自動化できるので、ミスしにくくなるだろう。

普通は、trunkが本番ソース、開発サーバーのソースがconfirmブランチに相当するだろう。
開発者やテスターが意識するのは、confirmブランチであり、trunkを触れる人はライブラリアンだけにすれば、より厳重な品質管理ができた運用になる。
但し、trunkからtag付けして本番リリースする場合、本番リリースブランチをtrunkとは別に作る時もあるだろう。

このやり方は特に大規模プロジェクト・組込み製品・パッケージ製品のような並行開発が行われている環境で威力を発揮すると思う。
何故なら、似たようなコードラインがたくさんある状況では、バグ修正やマージ作業のミスが致命的になりやすいから。

分散バージョン管理とチケット駆動開発は非常に相性が良いと思っている。
そして、この2つの組合せに、ビルド管理ツールHudsonやテスト管理ツールTestLinkなどを連携できると、まさにワンクリックでいつでもリリースできるようになる。

つまり、この「いつでもリリースできるようになる」技術があるからこそ、アジャイル開発の運用が可能になる。
アジャイル開発が普及しない理由は改めて、殆どの開発チームは単純に技術力が無いだけだと思う。

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

2009/12/06

特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係

ユースケースとストーリーカードの関係、特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係についてメモ。

【1】「システム要求、システム要件をどのように書くか?」はどのSW開発手法でもバラバラ。
オブジェクト指向分析(OOA)なら、ユースケース記述書のフォーマットに従って、システム要件や要求、フローを書いて、そこからモデリングしていく。

ユースケース記述書の書き方で一番優れていると思うのは、コーバーン著の「ユースケース実践ガイド―効果的なユースケースの書き方」。
ユースケースの書き方、観点のノウハウが詰まっている。
特に、ユースケースの観点を、アイコン(雲・凧・海水面・魚・貝)で表示して区別するのを推奨しているのは要注意。

ユースケース記述書のサンプルは下記を参考。

ユースケースについて

システムユースケース記述 [C02あんしん電話(高齢者] ユースケース ...

ユースケース番号:
ユースケース名:動詞句で記述する
主アクター:
従アクター:
事前条件:
成功時保証:
トリガー:
主シナリオ(メインフロー):
拡張シナリオ(代替フロー):
備考:

とはいえ、ユースケース記述書を最初からきちんと書ききるのは非常に難しい。

例えば、非機能要件を明示的に書く欄がないため漏れやすい。
又、代替フローの定義から大きな要件漏れが発生しやすい。
あるいは、ユースケース記述をIF文できちんと書こうとして、どんどん複雑化し、要件ではなくフローチャートを描いているに過ぎない場合もよく見受けられる。

【2】XPならストーリーカードに要件を書いて、タスクカードに作業を書く。
重要なことは、ストーリーは顧客が分かる観点で書くこと。
ストーリーカードは顧客が優先順位付けしたり、操作する重要なカードだから。

ストーリーカードのフォーマットは、下記が分かりやすい。

Article 626 at 00/07/17 16:48:01 From: hiranabe Subject: [XP-jp:00626] Virtual XP ストーリカード (1)

顧客ストーリカード
────────────────────────────────
番号 : 1
────────────────────────────────
日付 : 2000/7/17
────────────────────────────────
アクティビティ種別 : ■新規 □ 修正 □ 拡張
────────────────────────────────
優先度 : ユーザ 技術
────────────────────────────────
リスク:
────────────────────────────────
技術見積り:
────────────────────────────────
記述:
メーリングリスト(以下ML)のユーザが,ML のアドレスにメールを
送信すると,ML に所属するメンバ全員に,そのメールが配信され
る.配信されるメールの Subject は,[ML名:23] のような文字が
先頭に付加される(XP-jp のような仕様).ただし,そのメールに返
信した場合,[ML名:xxx]という文字は重複しないような配慮がなさ
れる.ML に属するメンバは,members というファイルに1行1名で
記述されている.メンバ以外から来たメールは,エラーとして差出
人に返す.
────────────────────────────────
備考:
後のストーリにて,メンバの追加,削除をメールにて行う方法が記
述されることを考慮にいれよ.また,特定のML のみをサポートす
るのではなく,設定によって ML 名,ML アドレス等は変更できること.
────────────────────────────────
タスク記録:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
日付 状態 ToDo コメント
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

上記のフォーマットは分かりやすいとはいえ、ユースケース記述書に比べると曖昧な部分が多く、要件漏れが発生しやすくなるかもしれない。

【3】Scrumのプロダクトバックログについて、下記の優れた解説記事がある。

特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayangの日記(ピスト通勤他

[Agile]プロダクトバックログについて海外の例も踏まえ考えたこと | Ryuzee.com

以下、まとめてみる。

特徴(Feature)、粗筋(Story)、脚本(Scenario)を意識して区別することを推奨している。

特徴(Feature)は、顧客から見たシステムの特徴。
粗筋(Story)は、その特徴(Feature)を利用者が具体的に体験する過程を記述したもの。
脚本(Scenario)は、粗筋(Story)をより具体的に記述したもの。

Feature(特徴):カンファレンス運営原価管理

粗筋(Story):カンファレンス目標人数までの到達度を測定する
* (As a)カンファレンス主催者として
* (I want)カンファレンス申込状況の報告書を見たい
* (So that I can)これにより、申込目標人数までの到達度を知ることができる。

脚本(Scenario): 一人の登録が1%進捗と表示される場合
* (Given: 前提) 200人が目標人数の場合
* (When: 操作) 一人が申込登録すると
* (Then: 結果) 1%進捗と表示される

Feature(特徴)はシステムの機能。

粗筋(Story)は、XPならストーリーカード、Scrumならプロダクトバックログに相当し、これを見積もりや計画ゲームに使う。
上記の例の構造は下記と対応付ければ、非常に分かりやすい。
(As a)は主アクター。
(I want)は目的または要求。
(So that I can)はサービス、ユースケース名、又はユースケース概要。

脚本(Scenario)は、受入テストの根拠、つまり受入テストケース。
Given=受入テストケースの事前条件、When=受入テストケースのテスト手順、Then=受入テストケースの期待値のように対応付けることもできる。

上記をユースケース記述書の事前条件・ステップ・事後条件に該当できるように見えるが、そうするとユースケース数が受入テストケース数とほぼ同値になってしまって爆発してしまう。
脚本(Scenario)は受入テストケースとほぼ同値とみなし、ユースケース記述はもう一段抽象化した方が良いように思う。

上記がユースケース記述書やストーリーカードよりも優れていると思う点は、要求(変更理由)と要件(変更内容)を粗筋(Story)と脚本(Scenario)で区別していることだ。
特に、何故システムのこの機能が必要なのか、その目的や要求を表現する項目がある点に着目したい。
結局、目的や要求が曖昧な場合、何を実現すればいいのか、何度要件定義をやっても決まらないから。

【4】特徴(Feature)、粗筋(Story)、脚本(Scenario)をRedmineによるチケット駆動開発では、どのように表現できるか?

Feature(特徴)は、Redmineならチケットの属性である「カテゴリ」に相当するだろう。
カテゴリはシステムの機能であり、カテゴリ単位にチケットを分類しているからだ。

粗筋(Story)は、チケットのトラッカー(種類)を「ストーリーカード」で登録すればいい。
このストーリーカードを作業単位にチケットへ分割すれば、「タスクカード」になる。
ストーリーカードに見積もり工数・実績工数・作業期間も記入すれば、TiDD上で進捗管理できる。

脚本(Scenario)は、TestLinkの「受入テストケース」に相当するだろう。
この時、粗筋(Story)をTestLinkの「受入テストの要件」として登録すれば、要件管理ができるし、テストカバレッジや要件カバレッジをリアルタイムに出力できる。
つまり、ストーリーカード(粗筋(Story))を経由して、RedmineとTestLinkを紐付けることができるはず。

色々試してみたい。

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

TiDDを実践して気付いたことpart6~TiDDでAgile開発を実践して分かってきたこと

Redmineによるチケット駆動開発(TiDD)を実践して気付いたことをもう一度まとめてみる。

TiDDをAgile開発として運用するには、下記の運用ルールが最低限必要だと思う。

1・チケットをXPのタスクカードのように扱う
2・チケット集計結果をXPのタスクボードのように扱う
3・ロードマップをリリース計画のように扱い、小規模リリースを運用する

1によって、XPのタスクカードをTiDD上で実現できる。
更に、XPのストーリーカード、ScrumのバックログもBTSチケットで表現可能だから、Agile開発のタスクや要望は全て、TiDD上で実現できるはず。
また、チケットに構成管理情報を付与できるから、成果物の変更もチケットで追跡できる。

2によって、PFのかんばんをTiDD上で表現できる。
つまり、タスクの作業状態、イテレーションの進捗管理は全て、TiDD上でリアルタイムにモニタリングできる。
これを実現できるのも、チケットに進捗情報を付与できて、チケット集計を自動化できるおかげだ。

3によって、XPの小規模リリースを実現できる。
つまり、2~4週間のイテレーションで、小刻みに機能拡張してリリースを繰り返すことを制御できるようになる。
XPの計画ゲームは、どのバージョンにどの機能をリリースしていくか、というリリース計画の作業に落とし込める。
3の性質によって、TiDDはAgile開発プロセスを実装できるだけでなく、自然に繰り返し開発にもなる。

そして、Agile開発の最大の特徴である繰り返し開発の運用が難しい理由は、下記でまとめられると思う。

1・繰り返し開発はイテレーション管理が難しい
2・繰り返し開発において、インクリメンタル型開発と反復型開発を混同してる
3・繰り返し開発は並行開発でもあるため、並行開発の制御が難しい

1は、短いサイクルで頻繁にリリースを繰り返すために、各イテレーションのタスク管理が煩雑になるから。
本番リリースのタイミングはWF型開発よりも頻繁だから、たとえ小規模の改善であっても、開発チームに対するプレッシャーも大きい。
更に、リファクタリングや度重なる機能改善のため、ソース管理も難しくなる。

2は、繰り返し開発を使い分ける戦略を開発チームが持っていないことに尽きる。
Agile開発の基本は、リリースを最優先にするインクリメンタル型開発。
だからこそ、リリースする機能(スコープ)を制御することを重視する。

しかし、システム全体を少しずつ作り上げる反復型開発では、リリースのタイミングは随分後のため、度重なる仕様変更や手戻り作業を制御できず、スコープをどんどん膨らましてしまいがち。
むしろ、反復型開発は、テスト工程のように品質を作りこむ状況の方が扱いやすい。

3は、インクリメンタル型開発が実は並行開発でもあるという事実を理解していないことに尽きる。
一度リリースしたシステムはそれで終わりではなく、運用保守モードとして生き続ける。
更に、裏では次の新規開発を進めているから、2系統のコードラインを常時保守し続けている。
組込製品やパッケージ製品ファミリーの開発では、更にたくさんのコードラインを同時に保守し続けるため、品質管理が難しく、そのコストも大きい。

本番ブランチの障害修正は、裏で開発中のtrunkにも影響し、マージ作業が発生する。
そのタイミングを忘れずに管理していくのは、ツールによるサポートがなければ非常に煩雑になる。
それらを、TiDDはタスク管理でサポートするし、GitやMercurialはPullやPushでサポートする。

上記がTiDDでAgile開発を実践して分かってきたことだが、まだまだノウハウがあると思うので探っていきたい。

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

2009/12/04

TiDDを実践して気づいたことpart5~チケット管理システムとは

もう3年前の記事になるけど、参考になったのでメモ。

【元ネタ】
wikiとmantisを構築 業務をより効率的に - masahirorの気まま記録簿

Mantisは、BTSだけならばとても優秀なBTSだと思う。
しかし、Wikiが無く、SVNリポジトリと連携できない。
#但し、フックスクリプトを作ればSCMと連携可能だし、パッチを当てればWiki機能を追加できる。

RedmineやTracが従来のBTSと異なる特徴や利点は何なのか?
それを明確にできれば、チケット駆動開発(TiDD)が一体何をもたらしているのか、チケット駆動開発の何が画期的なのか、が分かるだろう。

BTSは単なるバグ追跡システムで、基本機能は、Web上でバグを障害報告票で追跡すること。
障害報告票をExcelからWeb化することによって、バグ修正と検証の作業がとてもスムーズになる。
更に、このワークフローがとてもスムーズな為、Mantisでも、障害報告票をSW開発のタスク管理に使うアイデアは従来から知られていた。
このやり方は、障害報告票をIssueと呼び変えて、Issue(課題・問題)でタスクを追跡することから、Issue Trackingとも言われる。

更に、BTS(Bug Tracking System)をSW開発のタスク管理へ拡張したシステムはITS(Issue Tracking System)と呼ばれている。
ITSの代表的な例は、Tracであり、RedmineやJiraだろう。

だが、Redmineの管理画面に「Ticket Tracking」「Time Tracking」という機能を知って、そもそもこれらの本質は何だろう?という疑問を持っている。

ITSを更に拡張したチケット駆動開発(TiDD)の代表的な機能を整理すると、下記と考えている。

1・チケットで全てのタスクを追跡できる
2・チケットで工数や作業期間を追跡できる
3・チケットでSCMリポジトリ配下の成果物の変更を追跡できる
4・Wikiで情報共有できる

1はいわゆるIssue Tracking。
チケットをバグだけでなく問合せも設計もリリース作業も何でも扱おうと言う発想で、チケットをタスク管理に使える。
チケットをXPのタスクカードのように扱えば、自然にアジャイル開発になる。

すると、チケットにトラッカー(チケットの種類)という概念が必然的に生まれて、トラッカー単位にワークフローが作られる。
Issue Trackingの概念を突き詰めると、ワークフローに行き着く。
バグ修正と問合せのワークフローは当然異なるからだ。
そして、このワークフローは自然にペアプロのように、2人以上の目を通して作業することになり、品質強化に役立つ。

2はいわゆるTime Tracking。
チケットの属性に、作業開始・終了日の予定と実績、見積もり工数と実績工数を付与すれば、進捗管理に使える。
Redmineが優れている点の一つは、Time Trackingを利用してガントチャートをデフォルト表示してくれることだ。
他に、カレンダー・ロードマップ・変更履歴・バーンダウンチャートなどいくらでも集計結果をカスタマイズして出力できる。

コストもチケットの属性に載せれば、EVMも可能だから、工事進行基準の発想を取り入れて、リアルタイムにコスト管理も可能になるだろう。
又、累積の実績工数と終了チケット数を時系列にカウントすれば、信頼度成長曲線を作成できるから、品質管理にも使える。

これらの結果を使って、管理者は意思決定の情報をいくらでも自動収集できる。

3はチケットに構成管理情報を付与すること。これがTicket Trackingだと考える。
チケットがExcelのバグ報告票やMSProjectのタスクとは異なる最大の特徴は、SCMリポジトリ配下の成果物と連携できるため、要件からソース、そしてビルドモジュールまでのトレーサビリティを保障する事だ。

この機能は、最終的には、チケットをナレッジデータベースにすること。
チケットにSW開発の全ての作業履歴、ノウハウ、試行錯誤の結果が残るから、全文検索できるようにすれば、運用保守でリバースエンジニアリングしやすくなる。
あるいは、テストでバグを発見した時、何故要件が漏れていたのか、を追跡できるインフラにもなりうる。
また、ソースに「障害管理NO.123でバグを直した」というコメントを書く必要が無く、チケットを参照すればよいから、ソースもより綺麗になる。

4は掲示板やフォーラムにも使える。
プログラミングのちょっとしたノウハウ、ふりかえりMTや会議の議事録などを共有するのにも使える。
但し、厳格にバージョン管理した方が良いもの、例えば、設計書などは、Wikiではなく、SCMで管理した方がよいだろうと思う。

ExcelやMSProjectによるプロジェクト管理がITSやチケット駆動開発に劣るのは、上記4個の機能全てを実現するには力不足だからだろう。
つまり、チケット駆動開発が必然的に生まれた理由は、昨今のSW開発が短納期・大規模化・複雑化しているため、手作業ではもはや管理できず、上記4個の機能をツールで補完する事を必要としているからだろう。

SW開発の作業は全て、チケットから始まるのだ。
まさにチケットファースト。
そろそろ、ITSと言うのではなく、チケット管理システム(Ticket Tracking System:TiTS)と呼びたいくらいだ。

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

TortoiseHgはPull、Pushをグラフィカルに表示する

TortoiseHg 0.9.1が出たので早速使ってみた。
Pull、Pushについて分かりやすい記事があったのでメモ。

【元ネタ】
TortoiseHG 0.9.0のincoming,pull/outgoing,push - 文殊堂

TortoiseHg マニュアルにようこそ! ― TortoiseHg v0.9.0 documentation

Pull、Pushがまさに、TortoiseHgのChangeLog上でマスタリポジトリとローカルリポジトリの間で特定のリビジョンをマージするやり取りをグラフィカルに表示してくれる。

メインラインモデルによる並行開発では、この機能は今後必須になってくるだろう。
そして、アジャイル開発でも当然のように必須になってくるだろう。

今後のVerUpに要注意だ。

| | コメント (0)

2009/12/02

チケット駆動開発のアンチパターンpart2

チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。

【元ネタ】
チケット駆動開発のアンチパターン: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

【1】メトリクスの罠

RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。
管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。
メトリクスは万能ではない。

メトリクスだけではプロジェクトの現状を把握できないのが現実だ。
メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。
いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。

メトリクスはバッドノウハウの塊。過信しない方がいい。

【2】問合せはバグ修正なり

顧客からの問合せや設計者への仕様の質問をチケットへ起票する時、そのチケットをバグ修正のワークフローで管理してしまいがち。
すると、問合せの作業状態を管理しにくいし、担当者がチケット更新方法をよく間違える。
「問合せ中」「回答済み」のステータスがバグ修正のどのステータスに相当するか、正直分かりにくい。

理由は、BTSのデフォルトの機能であるバグ修正のワークフローだけでは、SW開発の全ての作業をカバーできないから。
所詮、BTSはバグ管理にしか過ぎない面がある。

また、仕様の質問を問合せフローでチケットに起票しておけば、開発中やテスト中に、何故こんな仕様になったのか、要件を探す元ネタになりうるので役立つ。
あるいは、顧客の問合せなどのインシデント管理をチケットに残しておけば、どんな問合せが多いか分析できる。
例えば、「ログインのパスワード忘れた」という問合せが多いならば、パスワードリマインダーの機能を追加したら問合せ数が減りますね、という話に持っていける。

現場のメンバーと試行錯誤しながら、ワークフローを編み出した方がいい。

【3】チケットを決められない

特に大規模プロジェクトでは、担当タスクを他のサブチームに作業をお願いしたり、上級SEを通じて顧客へ問い合わせるなど、チーム外と連携する時が多い。
その時、チームから上がったチケットをどのように対処すればいいか、プロジェクトリーダーさえも対処しようが無い時がある。
こういう状況では、関係するステークホルダー全員で決めるしかない。

大規模プロジェクトでは、「進捗会議」「課題管理会議」と称して、サブチーム間で連携しなければ対処できないタスクを調整したり、溜まったタスクを関係者全員で棚卸しする会議がある。
いわゆる変更管理会議(CCB)、あるいは変更諮問会議(CAB)。

上記のようなチケットは、このような会議で一つの議題にしてもらい、ステークホルダー全員で、優先順位付け、対処方針を立てる、各チームの調整を行うのがよいと思う。
但し、会議で決めてもらう分、利害が対立しやすく、チケットの作業期間が長くなるので注意。

【4】足りないステータス

担当者の作業状態がチケットのステータスに紐づいていない状況。
例えば、レビュー中、テスト中、本番リリース前(開発環境にリリースして検証OKだが本番リリースしていない)などのステータスが無い場合が相当するだろう。

これらのステータスがなくてもプロジェクトが回るのならよいけれど、今誰がこのチケットを担当しているのか分からなくなるようなら、ステータスを増やした方がいい。
ステータスが無いために「このチケットは今どうなっている?」というやり取りが多いならば、無駄なコミュニケーションのコストがかかっている。

ステータスが不足していると思える状況は、BTS以外のツールと連携したり、ペア作業を行いたい時だ。
TestLinkとバグ検証を連携したり、Hudsonとデプロイ&リリース作業を連携するならば、ステータスを増やした方がやりやすい。
また、バグ修正&検証やコードレビューをペア作業する場合は、担当者ごとのステータスがあれば、作業状態や進捗情報を追跡しやすくなる。

リリース後のふりかえりMTで、開発者とKPTしながら改善すればいいだろう。

他にも気付いたら追加していく。

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

TracのscrumプラグインAgilo

TracのscrumプラグインAgiloの感想を見つけたのでメモ。

【元ネタ】
Agilo ファーストインプレッション - かおるんダイアリー

plugins/Agilo_ja - Shibuya.trac Wiki - Shibuya.trac - SourceForge.JP

「元がTracだったとは思えないほど大胆にTracをカスタマイズしてしまうAgiloの画面」という紹介もあるように、色鮮やかな画面とUIが特徴的。

解説を見る限り、下記の特徴があるように思われる。

・顧客の要望はプロダクトバックログに一旦貯蔵し、スプリント計画で各スプリントバックログへ移動する。
・バックログ(ストーリーカード)とタスク(タスクカード)に親子関係があるので、バックログにタスクを子供として追加する。タスクに作業期間や見積もり工数を記入し、メンバーをアサインする。
・スプリントに割り当てられたタスクから、ベロシティ(スプリントの開発速度)が得られる。
・バーンダウンチャートなどのチケット集計結果機能がある。

ソフトウェア開発のプロジェクト管理で最も難しい部分は、スプリント計画、つまりリリース計画を立てる部分だ。
顧客から届く大量の改善要望や障害報告から、優先順位をつけてリリース計画を立て、更にタスクへ分割して各イテレーションへアサインし、それらの作業状態をリリースまでずっと追跡していく作業はとても複雑になりがち。

どうしても手作業にならざるを得ないが、Excelでそれらの要望やタスクの状態を追跡するのは至難の業。
このいわゆる要件管理の部分は、大規模プロジェクトになるほど要件が爆発的に増える為、ツールでサポートしなければ手に負えなくなると思う。
というか、従来のプロマネはそもそもどうやって管理していたのか不思議なくらいだ。

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

« 2009年11月 | トップページ | 2010年1月 »