月別アーカイブ: 2011年12月

チームへの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さんです。よろしくお願いします。

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

Jenkinsさんと気軽に友達になってみませんか?

今のチームではこちらのエントリにも書いたように「Jenkinsさん」はチームの一員・・・と言うほど、色々なことをしてもらっています。

使い始めるのは簡単だけど…

一方、社内でJenkinsのセミナーなどの出た声を聞いてみると「現場で入れてその後、継続して使うのが難しい」という声がチラホラ聞こえてきます。
どうやら「導入すること」は(上司などが「そんな訳の分からないもの入れるな!」と言わない限り難しくないのですが)「mavenなどの設定、Jobのメンテナンスが大変そう」と思っているようです。

そういうチームではリソース(できる人がいないし、仮にいてもそういう余裕がない)も無く「継続して使うのは難しい」という判断が多いようです。

まずは軽く使い始める

そんな時に思うのが「フルスペックでなくても【段階的に】使い始めてもでも良いのでは?」ということです。
100点(フルスペック)であればBestですが、何もやっていない0点よりも少しでもやっている方が良いという精神です。

「構成管理からチェックアウトしてコンパイルエラーが出ないか?」だけでもチェックします。
これで(別の誰かが)チェックアウトしたら壊れている…ということを早めに見つけることができます。

次にcheckStyle、PMDなどの静的チェックをやってみます。ルールのファイルさえあればすぐに導入できます。デフォルトでも良い感じにチェックできます。

これらが安定して実行されるJobがあるだけで「よろしくない」コードが混入するのを防ぐことができます。
少なくともコードレビューで「インデントが・・・」なんて指摘はしなくて済みます。

静的チェックの次は…

JUnitやSeleniumのテストはテストコードをいるので、ちょっと置いておくとして、次はデプロイに取り組みます。
本当はこの時点でテストコードを書き始めてくれると嬉しいのですが…。

これで常にチーム全員(チーム外の人も)が、動くアプリケーションを常に見ることが自動化できます。
時々ある「オレの所では見えるんだけど・・・」という状況も少なくなります。

そして、並行して「見える化」を進めるため(checkStyleなどの)レポートを表示します。
コードの出来高などもレポートするようにすると「やる気」も出てきます。
またcheckStyleの結果などがブルーだったりすると「うまく行っている」感が出て、チームのモチベーションアップにもなります。

そして自動テストへ…

ここまで来ると「テストの結果も見えると良いよね?」となって、テストコードやSeleniumのシナリオを書きやすくなります。
この時も「カバレッジ100%じゃないと意味がない」わけでなく、まずは重要なクラスや変更が入りやすいクラスからコードを用意すれば良いと思います。
今のチームでも、Jenkinsさんに色々やってもらっていますが、最初からいくつものJobやレポートがあったわけではありません。

使いながら「こんなことが自動化できると嬉しいね」「この情報がレポートで見えると嬉しい」という話が出る度に運用を追加していきました。

簡単なJobでも最初は思いの外、なかなかブルーにならないと思います。
でもそれまで「成功/失敗が分からなかった」ことが「分かる」ようになったことが変化の一歩(改善)です。

ですので、「大変そうだから」と尻込みせずに、気軽にJenkinsさんと友だちになってみてはいかがでしょうか?

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