Shibuya.trac第11回勉強会で発表してきました

このエントリーをはてなブックマークに追加このエントリのはてなブックマーク数

こんにちは、Oかもとです。

※ 当サイトのメンテナンスをしているのはOかもとだけではないので、明示的に誰が書いたか分かるようにする必要がある場合は、今後挨拶を入れることにします。

「チケットシステムによる初めてのアジャイル開発」というタイトルで、4/13に行われたShibuya.trac第11回勉強会「管理から可視化へ」というタイトルで発表してきました。(不肖ながら司会もさせて頂きました)


(編集可能なOpenOffice文書)
※上記資料は発表資料から公開NGの部分を削除し誰でも再利用できるマニュアル風に編集しています。

内容は、Kanon(TracLightning)を利用したアジャイル(スクラム)開発について、アジャイル開発のエッセンスを紹介しつつ、Kanonを利用してアジャイル開発におけるどの部分が効率的に運用できるかについて紹介しました。

Kanonをアジャイル開発で利用する際のポイントは、

  1. バックログ(ストーリー、タスク)の管理がチケットで行えるようになる
  2. バーンダウンと稼動時間の集計を簡単に行うことができる
  3. Excelで雛形を作ってインポートして使える

です。1のバックログの管理については、サブチケットが利用できる他のチケットシステムでも同等のことができますが、例えば、「ストーリー」のサブチケットを作成すると自動的に「タスク」と設定されるなど、スクラムで利用したときに簡単に使えるように最適化したり、バックログ閲覧用のビュー(レポート)や、担当者割り当て用のビューなど、用途別にビューを用意しています。

2.の管理面については、バーンダウンチャートはチーム単独の消化予想線(と呼ぶのでしょうか..)と実績を見れる他、複数のチームで開発する場合は、チーム毎の残時間を重ねて表示する機能も提供しています。チーム数が増えても対応できるようになっています。また、残時間の管理だけなく、稼動時間も管理できるように工夫しており、どのタスクに時間が掛かったか後で振り返ることができます。何よりも、自分のタスクの稼動時間・残時間を簡単に入力できるビューを用意しているので、めんどくさがり屋の人でも使い易くなっています。

3.のExcelからのインポートについては、個人的にExcelが好きであるというのと、最初のバックログの洗い出しの部分は色々な関係者(PO)との刷り合わせが必要であり、Excelベースでの管理の方がやり易いと思っているからです。もちろん直接チケットを入力していくことも可能です。

他のツールとの優位性

最近は、スクラム専用のツール・サービスが色々出てきていますが、正直言えば、商用のツールやサービスに比べると、TracLightning/Kanonは、タスク管理の部分に元々汎用的なチケットシステムであるTracにプラグインを追加したりカスタマイズして工夫して運用できるようにしているので、必ずしも優れている訳ではないと思います。ただ、

  1. Subversion、Mercruail、Gitなどのバージョン管理システムとの連携
  2. 継続的インテグレーションとの統合
  3. ウォータフォール的管理手法との統合(問題・課題管理、バグ管理など)
  4. アジャイル開発のインフラが無料でカスタマイズ可能なオープンソースとして利用できること

という点では、優れていると思っています。幾つかの点では、Redmineと被る部分はあると思います。あまりRedmineと比較するのは好きではありませんが、現在はTracの利点を主張する人が皆無になってきてたので(笑、敢えて紹介すれば、

  1. レポーティング機能によりSQLさえ書ければ様々なビューでチケットの分析を分りやすく行える
  2. 細かい使い勝手が良い。例えば、WYSIWYGプラグインにより初心者でも簡単に視覚的にWikiを利用できたり、OSのフォルダ(エクスプローラ)からファイルをドラッグ&ドロップするだけでファイルを添付できたりする。
  3. プロジェクト毎の切れが良いので、バラバラのサーバで運用しているプロジェクトを1つのサーバに集約したり、組織編制による引越しなどで特定のプロジェクトだけを別の場所(サーバ)に移動が簡単にできる
  4. (Trac/Subversionの話で)大手の会社で社内標準やソリューションとして利用され実績がある。TracLightning自身も小中企業で標準として採用されている

特に社内標準などのウォータフォール的な手法を一部利用せざるを得ないときは、SQLのレポートによるチケットの分析機能が役に立ちます。やはりRuby、Pythonと言った言語ができる人は一般的な現場には少ないです(私の主観ですが)。

SQLならJava、.NET、PHPなどの開発言語を問わず必要となるので、有識者も多いと思います。また、チケットをカスタマイズするために作成したSQLの知識は業務でも役に立つ可能性があるので、配属仕立ての新人に勉強でSQLをカスタマイズさせるのは良いかもしれません。

Tracは大企業でもそれなりに使われていますが、残念ながらあまり表に出ることはありません。TracLightningも幾つかの大手で使われていますが、会社名を出すことはNGだと先方に言われているので、大代的な利用方法や標準化が表に出てくることはないような気がします。Redmineは、社内のプロジェクト管理ツールを整備している方が発表していることが多いのは羨ましいところです。

さいごに

TracLightning、Kanonの紹介として書きましたが、ぶっちゃけて言えばツールは重要ではありません。どういうプロセスで開発をするか、したいか、また、開発における様々な制約条件(ウォータフォールにどっぷりな親父や社内標準的なプロセス管理手法、CMMI、ISOなど…)をどのようにクリアしていくかが重要だと思います。まずは、開発において何を管理しなければいけないかを考えてツールを選択するのが良いと思います。また、プロセスも固定ではなくプロジェクトを運用しながら改善されていくべきですが、プロセスの改善にあわせてツールもカスタマイズされ進化すればより一層効率的な運用ができることでしょう。ツールを選択する際に、プロセスを選択でき、また、プロセスに合わせてレポートを簡単にカスタマイズできるTracLightning/Kanonをご利用いただけると幸いです。

Leave a Reply

*