Redmine」カテゴリーアーカイブ

UltimateAgileStories1で書いた内容

最近、UltimateAgileStories Iteration2(UAS2)のエントリ([雑多]UltimateAgileStories Iteration2が届きました)を書きましたが、その1冊目・・・「UltimateAgileStories Iteration1(UAS1)」で書いた内容を原文のまま公開します(少し長めです)。
これをきっかけにRxTstudyなどを始め、お話する機会を多く得ることができました。またコミュニティ活動にも積極的に関わっていったのもこれがきっかけの1つでした。

最後にベースにお話したスライドへのリンクがあります。

題名:Redmineと私

自己紹介

題名が中学生の作文みたいですが…良いのが思いつかなかったのでこのまま行きます。
初めまして(またはそうでない方、こんにちは)、@yohhatuという者です。
大阪在住でとあるSIer所属です。

「お客様も自分達もハッピーにして、かつ、より良い価値を届けるか?」を日々考えています。
チームビルディングやファシリテーションに重きを置いていて、「自分は”スクラムマスター”的なことをしたいんだ」と最近気づきました。

こんな者です。
しばらくお付き合いください。

なぜこのお題にしたか?

今のプロジェクトでは「開発の三種の神器」と言われるITS/CI/SCMを使って開発しています。
ITSはRedmine、CIはJenkins、SCMはSVNです。

その中でもRedmineは(いくつかのPJで)4年近く使っており、その使い方、成果や課題を伝えたいと思ったためです。
構成は、主なプロジェクト(3つ)毎に「特徴」「使い方」「成果」「課題」として書いています。

最初のプロジェクト:X

【特徴】
メンバーは約6人。
お客様内のWebシステム新規構築というものでした。
このPJで初めてRedmineを使いました。

開発プロセスは(弊社のほとんどのPJで採用されているウォーターフォールでなく)、いくつかの機能群でグルーピングし、それらの完成を1つのイテレーションとする反復形式のプロセスでした。

このPJでは割と弊社標準を使わないでやってみよう…という雰囲気があったのか、課題管理、不具合管理も(弊社標準のExcelではなく)、Redmineを利用することにしました。
これがきっかけです。
ただ当時のRedmineは諸事情があり、カスタマイズやプラグインを自由に入れることができませんでした。

【使い方】
1:WBSの1つを1チケットとし、進捗管理をチケットレベルで行いました。
ただし、お客様やマネージャーとの共有のため、大/中日程レベルの進捗管理はExcelのガントチャートとして存在していました。

2:(WBSレベルの)タスク、不具合、仕様検討項目、課題等は全て同じレベルのチケットで管理し「トラッカー」で区別しました。

3:カスタムクエリで『前営業日に作成されたチケット』『未対応バグ』『課題一覧』などを使い「(こういう時には)このクエリを見ればOK」という工夫をしました。

4:「バージョン」をイテレーションの単位としました。

【成果】
1:(Excelと比較して)タスクや課題が『チームで管理する』ものになったため、リーダーに(不要な)負荷がかからず、本来のタスクに集中することができました。

2:進捗管理にガントチャートを使った際に、陥りがちなマイクロマネジメントにならず、イテレーション単位での大枠の進捗管理ができ、大きな問題になりませんでした。結果、これもリーダー(管理者)の負担軽減に役立ちました。

3:そのイテレーションで得た知見などを次のイテレーションにすぐに反映することができ、見積精度や品質が上がりました。

【課題】
1:チケット1つがWBS1つだったため、粒度が大きすぎたチケットがありました。
結果、そのチケットのアクティブな期間が長くなり「いつ終わる」「どうなっている?」ということが、チケット上で見えにくいことが何度かありました。
改善として、「チケットの予定工数は長くても1日、通常2.5時間程度に区切ってみる」と変えてみることにしました。

2:チケットと(弊社でよく使う)『付箋にタスクを書き出して見える化する』方法を共存したため、その棲み分けが難しかったことがありました。
改善として、(自分が関係して、Redmineをガッツリ使ったPJでは)開発タスクに関しては付箋に書き出さないことにしました。

【全般】
BTSとしては十分機能していましたが、チケット駆動開発としてはまだまだ使いこなせておらず、工夫が必要な感じでした。
ただ、メンバーがRedmine(とそれを中心にしたPJの進め方)に慣れて経験したことは、次のPJで大きく役立ちました。

改善を試みたプロジェクト:Y

【特徴】
Xプロジェクトと同じお客様、技術要素、ほぼ同じメンバー(4人)で、これまたお客様内のWebシステム新規構築というものでした。
開発プロセスは(ほぼ)Agile開発で、RedmineをITSとして全面的に利用することにしました。

【使い方】
Xプロジェクトでの運用をベースにし、課題などを改善して、使っていきました。
1:チケットは(WBSレベルより)細かく、最大でも2.5時間程度に分割して作成しました。
ガントチャートはマイルストーンのみを表記したレベルで簡略化しお客様と共有しました。

2:イテレーション毎にお客様に動く機能を見てもらい、フィードバックを得て、次のイテレーションのチケットとして登録するようにしました。

3:お客様には(Scrumにおける)プロダクトオーナー(PO)の役割を説明し、優先順位の検討、チケットの取捨選択、お客様内の調整などを積極的に動いてもらうようにしました。
Redmineそのものは共有していませんでしたが、エクスポートすることでほぼリアルにチケット一覧を見ている状態にしていました。

【成果】
1:「着手する前に、とにかくチケットを登録しましょう。結果、しなくなってもかまわないので」という考えが浸透したため、タスク漏れ等がほとんどなかった
※前回のXプロジェクトとメンバーがほぼ同じだったため、浸透しやすかったです。

2:チケットの登録はメンバー全員ができ、また、やりたいチケットを(自分で)アサインする方式にしたので、(ある程度は)「自律的なチーム」になりました。
ここでは言い出しっぺが損をしない工夫をしました。

3:イテレーション毎にお客様に見てもらっていたので、WFの開発プロセスにありがちなシステムテスト、ユーザテストなどで(仕様齟齬などによる)「仕様追加/変更」がほぼありませんでした。
この点は「こんなにスムーズに行ったのは初めて」と評価されました。

4:お客様が(弊社へ)丸投げでなく、その役割を果たしてくれました。そのため、PJを通じて「問題vs私達(弊社+お客様」という動きができました。
そこには「押し付け合い」や「お客様対自分達」「誰かが言うだろう」という雰囲気はありませんでした。

この土台には、チームメンバー間、弊社とお客様間の信頼関係があってこそで、Xプロジェクトでの経験が大きく役立ちました。

【課題】
1:(細かなガントチャートを作っていなかったため)細かな進捗を好むマネージャから「何が進んでいて、遅れているか分かりづらい」との声がありました。
これに対しては「イテレーション単位で確認している」「細かな進捗はチームで管理するので、それよりも別のことにリソースを使って欲しい」などを話し合い、役割分担することで解決しました。
※当時は標準のガントチャート以外にそのような進捗を表現する機能がなかったためです。

2:お客様POが(別の職務で)多忙時に、進捗のボトルネックになったこともありました。
対策として、マイルストーンに「Best」と「Better」の2つのポイントを作り、バッファを持たせ、「待ち」が発生しても別のチケットをやるなどリソースを効率良く使うことを工夫しました。

現在のプロジェクト:Z

【特徴】
社内向けにフレームワークやそれに関するツール群の開発、またそれらの導入支援などを行っています。
メンバー10人ほど…東京、大阪に分かれて…で、何度かのリリースを行っており、現在も進行中です。

開発プロセスはAgile開発のScrumの要素を多く取り入れています。
RedmineをITSとして、さらにチケット駆動開発を意識して、全面的に利用しています。

【使い方】
1:(これまでの2つのPJと異なり)Redmine自体の管理者権限を持っているため、Redmine本体のカスタマイズやプラグインの導入を積極的に行っています。
その運用方針も、柔軟に改善していくサイクルになっています。

2:主に使っているプラグインですが、その1つは「見える化を強化する」類のものです。 ロードマップの強化やバーンダウンチャート、ベロシティ、ニコニコカレンダーなどです。
もう1つは生産性の向上で、「開発の三種の神器」を相互連携させるプラグイン…ソースコードレビューやJenkinsとの連携…を入れています。

3:(基本的に)1ヶ月をイテレーションとし、終了時にフリカエリと次のイテレーションのタスクばらしを行っています。
この時点で大まかにしか分からない機能は親チケットとして登録し、詳細が分かる、調査する時期に来たら、その段階で子チケットとして登録する形式にしています。

4:チケットには「Doneの定義」を記述し、またその作業ログが残すように運用しています。
まだ全てのチケットで、できているわけではありません。

5:「ステータス」遷移は「未着手→着手→レビュー待ち→完了」というようなシンプルな形にしています。
「進捗率」はチームとしては利用していません。

6:朝会では「活動」「バーンダウンチャート」「ニコニコカレンダー」を使いながら行っています。

【成果】
1:Redmineを中心にした「開発の三種の神器」とその土台となるプロセス、マインドがチーム全体に行き渡っているため、生産性と品質が高い状態を維持できています。
また、チームの雰囲気も(最初から良かったのですが)良い状態を保っています。

2:チケットにDoneの定義、仕様検討の結果などがまとめられて、情報の集約が進みました。

3:(まだ改善の余地はありますが)このPJ以外で使っている時間が明確になり、ベロシティが安定してくるようになりました。

【課題】
1:RedmineやAgile開発プロセスに慣れていないメンバーの増減が何度かあり、またそういうプロセスの導入を(一気にすると負荷になると思ったため)徐々に行ったため、その定着と効果の発揮まで数イテレーションくらいはかかりました。

【参考】
このPJでは開発系以外のツールとして「Googleカレンダー」でのスケジュール共有、「youRoom」でのアイデア出しやディスカッション、「社内SNS(」での週次進捗ミーティングなどを行い、極力、無駄な会議の時間を減らしているという特徴もあります。

最後:私がRedmineを4年間ほど使っていて思ったこと

始めに…Redmineはあくまで「ツール」です。

「ツールを入れて終わり」でなく、そのプロセスやマインド(振る舞い)を変えていくことが大事です(もちろん、最終的には「お客様により良い価値を提供すること」です)。
「今日から変えましょう!」と言って変わるわけでなく、日常の中で継続的に運用、改善を行っていくことが大事です。

そしてそれがどういう形になるか…はPJの特性やチームの成熟度、規模などによって毎回変わってきます。
アンチパターンはあるでしょうが、必ず正解するパターンはないと思っています。

その点から、(今回挙げたどのPJでも)運用方針の枠を最初に作りましたが、イテレーション終了時などのフィードバックから、より使いやすいように改善しました。
その際には、(管理者よりも)開発者にとって「自然に負荷なくできるプロセスはどういうものだろうか?」という視点を重点にしました。

次に、メンバーにRedmineの使い方やマインドを理解してもらう時の心構えです。

トップダウンで「やらせる」感じではなく、母性的や世話役的な感覚で接して、メンバーが「やれば楽になるんだ」と理解した上で浸透していくのを、じっくりと待つ辛抱強さが必要です。
トップダウンでやっても「Redmineを使うこと」自体が定着しても、そこから引き出すことができるチーム力の向上にはなかなか至らないと思います。

Zプロジェクトでのフリカエリでも、何度目かのイテレーションが終わった後くらいにやっと「こういうやり方も良いよね」という言葉、雰囲気が出るようになりました。

一方、リーダーの心構え的なものです。

このスタイルがチームに浸透し、理解してくると、【リーダーがタスクを作る/割り当てる/確認する】スタイルから、【自分達がタスクを洗い出し/割り当て(自分から手を挙げる)/進捗を管理する】スタイルに変わります。
(メンバーもそうですが)リーダーが自分の役割の変化…管理から違う価値の提供へ…を受け入れる必要があるとも思います。

繰り返しになりますが、「入れて終わり」でなく、プロセスやマインドが少しずつ変わって行って「当たり前」になる…のが、1つのゴールだと思います。
ですので、即効性のある/大きな効果を期待するよりも、まずは自分達のチームで使い始めて「お、ちょっとこれは良いかも」という点を1つでも見つけ出していくことから始めれば良いと思います。

最後までお付き合いいただき、ありがとうございました。

この記事をベースにお話したスライドが↓です(ShinagawaRedmineに遠征した際のもの)。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

チームへのRedmineの効果

Redmine Advent Calendar jp 2011の25日目になります。

#余談。本場のAdvent Calendarは「24日まで」を窓を開けていくことでクリスマスを祝うそうです。一方、【技術系】Advent Calendarは「25日」まで書くことが多いようです。

というわけでトリなわけですが、相応しい壮大な話ではなく「チームへのRedmineの効果」について書いてみます。

普段よく言っている「Redmineの効果」

先日、社内で「Redmineを活用したタスク管理改善セミナー」というのをしました。

Redmineの簡単な紹介から始まり、事例紹介を交えてそこから得た自分なりのメリットやTips、考え方をお話しました。
後半は参加者の方と「こんなことで困っていませんか?」などのディスカッションをしました。

その中で「Redmineを使った効果はどういうものがありますか?」と質問がありました。
私はたいがい「Redmineは【見える化】【トレーサビリティ】【開発リズム】を強化してくれるツールです」と「ツールを入れることが大事ではなく、そのプロセスやマインドを変えていくことが大事」の2つを合わせて答えています。

最近はそこに「教育に伴うチーム力向上の効果もあるかも?」と思い始めました。

教育効果があると思ったシーン

あるチームは、割とエンジニアとしての経験年数が少ない人が多かったのですが以下のような変化が出てきていました。

  • 1:チケットの書き方が(良いレベルで)揃ってきた
  • 2:(チケットに書く)設計やそれまでの経緯を共有することができて、設計の技術が上がってきた
  • 3:コードレビューの結果を共有することができて、実装のレベルが上がってきた

1:チケットの書き方が揃ってきた

親チケットに要求をプロダクトオーナーが中心となって書いています。
その要求に対し「どう作るか?」と言った子チケットは担当するメンバーがそれぞれ自分で考えるような開発プロセスで回っています。

最初の頃はそのチケットの粒度が大きすぎたり、内容が抽象的過ぎることもありました。
また、粒度が大きすぎることも原因の1つとなって見積もり(予定工数)の精度が低いこともありました。

そんな状況からイテレーションを繰り返していくうちに、他のチケットの良い粒度を参考にしたり、自分が書いた粒度が大きいチケットを苦労しながら片付け、それをふりかえることで、分かりやすいチケットの書き方がチームの中で浸透していったように思います。
ここで言う「分かりやすい」とは自分以外にも「チームが見ても分かりやすい」ということです。
「チームが見ても分かりやすい」ということはチケットの引き渡しをやりやすいということにもなります。

2:設計の技術が上がってきた

1はチケットの書き方の粒度のお話ですが、こちらはチケットに書く内容の話です。

チケットに「この設計はどういう考えで、この結論、仕様に至ったか」を書くことがあります。
特に複雑な要求や仕様の場合「A案、B案、C案と考えたけど○○な理由でB案で行く」という風に議論の過程も書くこともあります。

ちなみに「設計書」と呼ばれるドキュメントには「どういう設計になっているか?」は書かれていますが、「なぜこれになったか?」はあまり書かれていないと思います。
それ故に次にその機能を修正する際に余計なリソースがかかっているように思います。

そういうチケットを担当することで、設計の仕方や思考の経緯を学ぶことで設計の技術を上がってきたように思います。

3:実装のレベルが上がってきた

コードレビューはRedmine Code Review プラグインを使っています。

それまでのやり方(コードをプリントアウトして行ったり、レビュー指摘内容はExcelに書く)に比べると、効率が良くなっていますし、指摘内容の共有をしやすくなっています。
もちろんレビュー指摘もそのままチケットに登録されるので「どのように対応したか?」まで共有しやすくなっています。
そのため若手や新しく入った方が、過去にどのようなレビュー指摘があったかを見ることでそのようなコードは書かないようになってきました。

またそうなることで、コードレビューアの負担も軽くなり、より有効に時間を使うことができます。

チーム構成やその入れ替わりの頻度などによっては、Redmine(ITS全般でも同じことが言えますが)のこういう側面に着目してみても、使うことによるメリットは大きいと思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Redmineのチームでの使い方を紹介

Redmine Advent Calendar jp 2011の10日目になります。

私は(プラグインをガリガリ作ったりしてないので)「自分達のチームでの使い方」をいくつか紹介します。

コンテキスト

・チーム:東京と大阪で別れて10人ちょっと
・作っているモノ:社内向けのFWや色々なツール群
・Redmine以外に使っている主なツール:Jenkins、SVN、youRoom

親子チケットの使い方

※これは「RxTstudy第2回でお話した内容」が元になっています。
「親チケット」を「機能(feature)」、「子チケット」を(そのfeatureを実現する)「タスク」として使っています。
親チケットは以下のテンプレートで書いています。

【背景】
※その機能の背景やなぜ作るようになったかの経緯などで要件定義の一部。
【ユーザーメリット】
【機能スペック】
【影響範囲】
【テスト時確認内容】

これくらい書いていると、設計や実装の方針に迷った時などに「そもそもこれが誰にとってどんな風に嬉しいのか?」がぶれることなく開発に集中できます。

またチームの進捗を見る場合、バーンダウンチャートと併用して親チケットの状態で見ています。
具体的には「親チケットのみを表示する」カスタムクエリを作っています。

親チケットの進捗率は、子チケットのステータスと進捗率に連動しているので、メンバーが親チケットを更新する手間なく確認できます。

レビューアの話

2つ目も第2回のRxTstudyでお話した内容ですが「レビュー」の話です。

「ステータス」にデフォルトでは“レビュー中である”ことを知らせるステータスがなく、これの表現方法を考えていました。

今のところ、チームでは以下のように運用しています。

【準備】

1:カスタムフィールド「レビューア」を(リスト形式で)設定
リスト内容はチームメンバー
2:ステータスに”レビュー待ち”を追加
3:カスタムクエリで「レビュー待ち一覧」(ステータスが”レビュー待ち”)を用意

【運用】

チケットの担当者が(コードレビューが可能になれば)ステータスを”レビュー待ち”にします。
「レビューア」にレビューして欲しいメンバーを選択します。

「担当者」を(レビューする際に)レビューアに変更して、レビューが終わったらまた元に戻す運用も考えました。
それでは自分のチケットの行き先が分からなくなり、「自分のチケット」へのコミット感が失われてしまうと考え、このような運用にしました。

「担当者」を変えないことで、担当者が自分のチケットを楽に追うことができ、レビューアに対して「滞留してるので、早くレビューしてくださいよ」を声をかけやすくなります。
※そんなことしなくてもレビューが消化できるのが良いのですが。

レビューアにとっても「自分のチケット」と混ざることはなく、分かりやすくなります。

プライベートチケットの話

3つ目は「プライベートチケット」に関した感想です。

「前略、private issue 使ってみました。あるいはITSの黒魔術とは何か」(@ハードコイルド・ワンダーランド)を読んで、(黒魔術的な面では同意の上で)「こういう時、プライベートチケットは有効かも?」と思いました。

それは親チケットなどで機能仕様などを書いている途中、何らかの理由で作業を中断する時にプライベートチケットとすることです。

途中かどうかメンバーには一見して分からないので、そのまま公開されているとそれを見たメンバーから意見やツッコミが入ったりします。それをプライベートチケットとして見せないことで、このムダな時間を防ぐことができると思いました。

RxTstudy

最後に宣伝です。「RxTstudy」というRedmineやタスク管理を考える勉強会が大阪にあります。
スタッフの1人としてお手伝いしています。
※過去2回の内容などはこちらで。

その第3回が2012年2月4日(土)にあります(ATND)。

充実した内容になるかと思いますので、この時期に関西に来る方は参加してみてはいかがでしょうか?

次のエントリは

次は@suerさんです。よろしくお願いします。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

チケットの粒度が難しい

過去のメモを整理していたところ、2年程前のプロジェクトで悩んでいた時に書いたメモが出てきたので備忘録としてアップしておきます。

悩んでいたこと

RedmineやTracなどのITS(Issue Tracking System=問題追跡システム…こういう呼び名だと今、初めて知りました)に登録するチケットの粒度、単位です。

背景

Railsを採用したWebシステムを4,5人で構築するというものでした。
で、そのPJで、本格的にITSを使って「チケット駆動開発」(的)なことをしてみようとなったわけです。

まずはこうやってみた

MVCモデルで分割していたので、機能毎のモデル/コントローラ/ビューをそれぞれ1つのチケットとして登録してみました。

その結果

なかなか「チケット駆動開発」のリズムになりませんでした。

なぜだろう?(推測)

1:チケットの粒度が大きすぎた。
(設計の善し悪しもありますが)当時はコントローラにそれなりの量の業務ロジックが実装されていました。
なので、下手すると1日以上かかる実装量を1枚のチケットにしてしまったのが原因ではと思います。

2:Railsの開発スタイルとチケットの単位が合っていなかった。
Railsでは頻繁にMVC間を行き来して、分業したりせず開発するスタイルが合っていました。
ところが前述したようにチケットはMVC単位だったため、MVCともちょくちょく進んではいるものの…という感じで、チケットの完了による進捗が見えませんでした。

次やるとしたらどうするだろう?

これの解は出ていません。

が、今のPJ(SAStruts+S2JDBCで3,4人)では(粒度もまちまちですが)少なくともタスク漏れがあるよりはマシ…という考え方から、「まずは登録!」のスタイルで運用しています。
感覚的には、数分程度で終わる、かつ、チームメンバーの確認(レビューや仕様確認)が不要なタスクはチケット登録しないようにしています。

で、朝会などの中で、チケット間の親子関係を作るなりして、「進捗が見える」単位に調整しているという感じです。

なんかこの辺の運用方法は、メンバーの人数、スキル、マインドにもよるので、絶対的な正解はないと思いますが、議論したりして深掘りしたい内容です。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by tony.eckersley on Visual hunt / CC BY