Rxtstudyの感想

先日のRxStudy勉強会には、参加者の皆様、そしてスタッフの皆様ありがとうございました。
発表後、議論したりTwitterを読んで、考えたことをメモ。
下記はあくまでも一意見。

【元ネタ】
Togetter - 「RxTstudy Redmineでのタスク管理を考える勉強会＠大阪」 by @buffering

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

【1】Twitter / @cero_t: TiDDで開発している人も半数以上？ ほとんど？ ぐらい。 すごい参加者 #RxTstudy

Twitter / @cero_t: 阪井さんもあまりRedmineを使ってなくて、Tracが多い。 TxTstudyで良いじゃないか。 #RxTstudy

チケット駆動開発という言葉の認知度が上がっている事実には正直驚きました。
そして聴衆の年齢層が比較的高めで、開発者よりも現場リーダーやマネージャの方が多い事実にも驚きました。

【2】Twitter / @yohhatu: 「気づき」ってトラッカーは面白いな。うちはその辺はyouRoomで出している。でタスクになれば、Redmineへ...という流れかな #RxtStudy

「気づき」「QA」というチケットは現場のチームから生み出された運用ルールです。
@yohhatuさんの言う通り、本来はチケット化せずに掲示板のような場で議論した方がいいのかもしれない。
もっと良い運用ルールはあると思います。

実際、以前はphpBB＋Mantisで運用していた時もあった。
例えば、phpBBでコーディングルールやプログラミングの疑問点を質問して、Mantisチケットに書かれたバグを直すこともやっていた。
でも、情報があちこちに散在してしまったことと、phpBBが使われなくなってしまったので、あまりよい運用とは言えなかった。

【追記】
phpBBはPHPで作られた掲示板Webシステム。MantisはPHPで作られたバグ管理システム。
いずれもBitnamiでワンクリックでインストールできる。

BitNami :: phpBB
BitNami :: Mantis

僕がいたチームでは、僕がチケット駆動開発を推進していたので、Ticket FirstやNo Ticket, No Commitの運用ルールはチームに浸透していた。
だから、開発者は積極的にチケットを登録するし、チケットNoを必ず書いてコミットする運用には慣れていた。
そして、彼らは開発チケットで、設計書の不明点や設計漏れをQAの別チケットで登録して、設計者とやり取りする運用が自然に生まれた。
その中で、後でリファクタリングしたほうがいいかも、とか、JUnitをもっと追加したほうがいいかも、みたいな内容は、気づきのチケットでバックログに入れる運用も生まれた。

QAや気づきをチケット化する利点は、関連チケットや親子チケットでチケットを整理できること。
タスクのチケットで仕様の不明点を質問したい時、QAのチケットと関連リンクを張っておくと、後で見つけやすい。
Redmineでは、チケットやWiki、フォーラムでも、「#チケットNo」で簡単にチケットへリンクできるから、QAも気づきもチケット化した方が後で流用しやすい。
また、QAや気づきのチケットの内容が変わったら、トラッカーをタスクや課題に変更するのも簡単だ。最初はあいまいな内容でも、作業する時に正確な内容にすればいい。
タスクの進捗率が90％で停滞してしまう原因の殆どは、仕様の不明点や技術上の課題などが残ってしまうことなので、QAチケットで外に出すことで、何が問題なのかをはっきりさせやすかった。

QAのチケットが多くなれば、QAチケットを子チケット化して、一つのテーマ(改善要望・バグなど)にまとめる運用も自然に生まれた。
チケットの親子関係は、MS Projectに慣れたプロマネだけでなく、開発者も理解しやすいみたい。

逆にQAや気づきもチケット化する弱点は、チケットの量は莫大になり、放置されがちになりやすいこと。
だから、朝会や週次報告、ふりかえりなどあらゆる場で棚卸しを行うのは必須の運用ルールだった。
棚卸しでチケットの完了基準も明確になるし、開発者から管理者への報告・連絡・相談の場にもなる。

棚卸しは、チームの意思決定の履歴を残すという意味もある。
この運用は、特に大規模プロジェクトで、各チームリーダーが自分のチームで解決できない課題を持ち寄って、CCB(CAB、Scrum of Scrum)で方針を決定する運用にもつながるから、重要だと思っている。

とはいえ、Redmineにはフォーラム機能もあるので、フォーラムで仕様の質問をやり取りしたり、特定の課題について議論する運用も可能だ。
僕のチームでは、フォーラムに、Redmineの使い方に関するFAQをまとめている。
カスタムクエリの使い方、チケット一覧でのコンテキストメニューの出し方など、Redmine初心者から頻繁に聞かれる質問はFAQ化して公開しておくと、同一の質問が来たら、リンク先を教えるだけでいい。
つまり、フォーラムもナレッジを蓄積する場として使える。

情報は不足しているよりも過剰なほうがましだ。
「アート・オブ・プロジェクトマネジメント」にも出てくるこの言葉の意味もチケット駆動開発を実践して理解できた。

【3】Twitter / @agilekawabata: たぶん、チケットは仕様書ですか？という人に、XPのタスクカードですって言っても理解されないと思う。#RxTstudy

Twitter / @agilekawabata: 空っぽのロードマックパターンは、先にアジャイル開発について研修すべきだと思う #RxTstudy

Twitter / @cointoss1973: #RxTstudy (工程としてバージョンを使うとその時点でハマりますね。バージョンはマイルストーンなので、過去の工程にこだわってもだめです。これからの作業予定に使うべき）

開発チームがRedmineをまともに運用できているかどうかの判断は、対象バージョンとロードマップの機能を使いこなしているか、という観点で僕は評価している。

Redmine初心者は、バージョンとマイルストーンの違いを知らなかったり、ロードマップがリリース計画である事実を知らないケースがとても多い。
ロードマップをまともに運用できていないチームは、せっかく登録したチケットが放置されやすく、棚卸しもうまくいかない場合が多い。

逆に、ロードマップを使いこなせば、バージョン単位のスコープ管理、小刻みなバージョンアップによる機能改善戦略、そこから生まれる開発のリズムや適切な開発ペース、Velocityの発見などが分かってくると思う。
アジャイルと言う言葉をメンバーは知らなくても、チームは自然にアジャイルの概念に慣れていく。

【4】Twitter / @cointoss1973: クローズしたバージョンのチケットは変更できないようにする。 #RxTstudy （これいいですね）

クローズしたバージョンのチケットが変更できないという意味は、リリース履歴を改ざんできない事実を意味している。
つまり、リリース済みバージョンは変更管理におけるベースライン(チェックポイント)なので、ベースラインが後で変わってしまうと、成果物の品質管理に疑問符がつく。
リリース済みの作業履歴を改ざんしたら、システム監査でNGになってしまうのではないだろうか？

【5】Twitter / @sousoumt: 今のところ全員が粒度と終了基準で一度は躓いているｗ　#RxTstudy

チケットの粒度の問題は顧客と開発チームの観点のViewの違いから発生する。
チケットの終了基準の問題は作業の完了基準、リリース判定基準があいまいな点から発生する。
プロジェクトやチームで暗黙知として運用されていたルールが目の前に出てきたからこそ、噴出する問題だと思う。

【6】Twitter / @cero_t: アンチパターンとか、質問とか見てると、「Redmine」の使い方を知らないというよりも、「ソフトウェア開発」とか「物事のあり方」を理解してない人が多いっていう感じがしますねぇ。 その使い方はないだろ、という。 #RxTstudy

Twitter / @yktko: ITインフラ構築の現場を改善しようとしたら営業を改善する必要性にぶち当たりました。 RT @kuranuki: うまくいかない事例を聞いてると、ツールで解決出来る問題ではないところに問題があり過ぎるように思う。そんなのは現場の改善で解決出来るの？ #RxTstudy

@kuranukiさんの立場は僕なりに理解しているけれど、現場リーダーの観点からすると、ツールを導入することで従来の開発プロセスの弱点があぶり出されたという簡単な事実を示しているだけだと思う。

従来は暗黙知としてプロセスが回っていたのだろうが、一度ツールを導入すると、従来のプロセスで隠されていた問題点が見える化しただけ。
丁度それは、ユーザ企業が従来の手運用の業務をシステム化するためにERPを導入したら、業務プロセスが変わるだけでなく、社員の役割も変わり、社員の配置も変わり、最終的には組織構造も変わってしまう症状と同じだ。

単にExcelによるプロジェクト管理をWeb化する発想だけでは不十分であり、最終的にはAgile開発の考え方を理解しなければ、Redmine本来の機能を100％フルに使うことはできないと思っている。

「Redmineによるタスクマネジメント実践技法」の感想に、アジャイル開発の用語が出てきてよく分からないという意見はよく聞くけれども、その点に関しては曲げられないかな(笑)

でも、チケット駆動開発のアイデアはSW開発だけでなく、情報システム部門やインフラチームのタスク管理や課題管理、顧客からの問合せ管理などへも適用できるから、もっと発展させることができるだろうと思う。
多分、リーンソフトウェア開発にある概念(TPS)へつながるだろうと直感している。