2012年08月29日

[雑多]UltimateAgileStories【1】で書いた内容

 最近、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に遠征した際のもの)。
タグ:agile 日常
posted by yohhatu at 08:18 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年08月28日

[雑多]今度のRxTstudyはミニセッション大会です

 私がお手伝いしている「RxTstudy」の第6回が2012年10月20日(土)にあります。
#1:本編の申し込み
#2:懇親会の申し込み


***********************

◆基調講演
 最近出版されました以下の2冊の著者がお話してくれます。

1:入門Redmine 第3版 前田剛さん(@g_maeda )
2:チケット駆動開発 阪井誠さん(@sakaba37) とあきぴーさん(@akipii)



◆ミニセッション大会
 第6回の特徴はこのミニセッションです。
4,50分話すのはちょっと敷居が高いと感じる方も、
質疑応答含めて20分のミニセッションで
気軽にスピーカーデビューはいかがでしょうか?

 「20分きっかり」でなくてもOKです。例えば10分で話し終わって、後はQ&Aでも。

 そもそもQ&Aと言っても「聴き手」→「スピーカー」である必要ではなく、(スピーカーの話はそのきっかけにして)聴き手同士がディスカッションしても良いわけです。
#むしろそんな勉強会ならすごく良いものだと思います。

 ですので・・・
「こんなことでうまくいっていないんだけど、誰かアドバイスくださいな」
 ・・・というような内容でも大歓迎です。
例:「Redmineをこう使っているんだけど、うまく消化しきれない」「アナログのチェックリストを書いているんだけど、いつも破綻する」「こんな風に手帳を使っているんだけどみんなどうよ?」

 発表の場で色々話ができれば良いですし、さらに懇親会でも話が盛り上がって、うまくいくヒントが見つかれば・・・と思っています。

◆スタッフの1人としての想い
 RxTstudyはゆるい感じで、大御所的な人もいません。
 一方、あまり参加者が固定化して内輪感が強いわけでもない(と思います)。

 またお題もタスク管理(タスクマネジメント)なので幅広く、何かしら話すことがある・・・そして個人であれチームであれ、何か1つ位は困っていることがある・・・と思って、このミニセッションを企画しました。

***********************
 
 「発表なんて・・・」という方は、「[雑多]「勉強会で発表する」について」に書いているような気持ちで、気軽に手を挙げてもらえたら嬉しいです。
#もちろん他にもたくさんの方が「気軽に発表したら良いよ!」という主旨のことを書いていますので、そこで勇気づけられるのも良いと思います。

#↓は最近、社内向けの勉強会で(同じようなことを)話したスライドです。
posted by yohhatu at 08:15 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年08月25日

[雑多]UltimateAgileStories Iteration2が届きました

 寄稿させてもらったUltimateAgileStories Iteration2が届きました。
 細谷さん(@yasuohosotani)、ありがとうございました。
UAS2_20120817_165503.jpg

***********************

 これだけの著者のお名前が帯に並んでいるのは壮観です。
 前作もそうでしたが、今回はそれ以上にそれぞれの想いが詰まっていて、読破しまいました。

 特に気になって折り目を付けた箇所です。

やれば良いじゃないですか 倉貫義人さん
 ※「はじめの一歩を踏み出そう」より
チームへの期待を明らかにする 吉羽龍太郎(@ryuzee)さん
わかっているとは決して言わない(TOC(制約理論)のススメ 柴山 洋徳さん(@shibao800)
「上手になるまで待ってたらヨボヨボになっちまうぜ」 永瀬 美穂 (@miholovesq)さん
 ※“Just get out there and do it”より
「Project ≠Product」 @tetsu_m(てつ。)さん
 ※「エンタープライズ・アジリティについて本気出して考えてみたら…」より
"楽しいことやらなくてどうするんですか?" 藤原 大(@daipresents)さん
"自分が大事だと思うことは何度でも話せばいいんですよ"
 ※「The World Is Mine」より
「人を変えること」はできませんが、「人に変わってもらうこと」はできます。 長沢 智治 (@tomohn)さん
 ※「次の10年に向けた開発環境との向き合い方」より
自分のスピードを測っていますか? 原田 騎郎さん
 ※「アジャイルな開発をうまく続けるために」より
ふりかえりなんてつまらない やっとむ こと 安井 力さん
 ※「ぼくのかんがえたさいきょうのふりかえり」より
期待マネジメント 市谷 聡啓(@papanda)さん
 ※「Why Agile?」より
「何をするためにここにいるのか?」 懸田 剛さん
全員が「なぜ、我々はここにいるのか」という問いに答えることができますか?
その仕事の依頼者の意図を、全員が正しく理解していますか?
 ※「東北で気づいた大事なこと」より

***********************

 関西では(まだ募集サイトはオープンになっていませんが)2012年11月3日(土)にあるAgile Tour Osakaで頒布予定とのことです。


#増刷ができそうなら他の勉強会でも頒布されるかもしれませんが・・・
タグ:agile 日常
posted by yohhatu at 23:14 | Comment(0) | TrackBack(0) | 書籍 | このブログの読者になる | 更新情報をチェックする

2012年08月18日

[書籍]Inspired日本語版

 夏季休暇に読んでおきたいと思っていた「Inspired日本語版」の自分用メモです。
#途中までとはいえ、このような良い文章が翻訳されていて読めるというのは非常にありがたい話です。

***********************

 読みながらつぶやいたまとめ:「途中まで公開されている「Inspired日本語版」を読んだメモ書き

 ある程度、自分達でサービスやプロダクトを送り出そうとしているというコンテキストで「プロダクトマネジメント」「プロダクトマネージャー」(スクラムだと「プロダクトオーナー」かな?)の責務、考え方、振る舞いについて書かれています。

 ただ、受託開発や開発プロジェクト全般にも多くのことが適用できたりすると思います。
 そしてプロダクトマネージャーだけがこういう考えで良いか?というとそんなこともなく、エンジニア、デザイナーなどチーム全体がこういう考え、姿勢でプロジェクトを進めることが良い結果を生み出すことに繋がる・・・とも思いました。

 なので「自分は製品開発じゃないから関係ないや」と思わずに関係ありそうな章だけでも、つまみ食いするだけでも面白いと思います。

***********************

 自分が一番気に入った言葉は(あまり本編の内容とは関係ないですが)↓でした。

posted by yohhatu at 04:51 | Comment(0) | TrackBack(0) | 書籍 | このブログの読者になる | 更新情報をチェックする

2012年08月12日

[雑多]デブサミ関西2012で少しだけ話します

 2012年9月14日(金)にある「デブサミ関西」で、実行委員として少しだけお手伝いしています。

***********************

 本家デブサミはこの前10周年を迎えましたが、「デブサミ関西」は2回目でまだまだこれからです。

タイムテーブル
 Googleの及川さんによる「【S-1】Chromeのプロジェクトに学ぶAgileでScaleするソフトウェア開発手法」がまず午前中にあります。
 さらに午後からも[System/Agile]、[Web Tech]、[Mobile Tech]と3つに別れて様々なセッションが開催されます。どのセッションも特徴があって正直どれを選ぶか迷います。

 平日ですが、有給休暇を使って、話を聴く/質問しにいく価値はあると思います。
#余談:こういうイベントに、組織が「業務」として認め、大手を振って参加できればもっと素晴らしいことだと思います。

 私も少しだけ「【A-5】あの人の自分戦略を聞きたい!-デブサミ関西編」でお話させてもらうことになりました。
#発表者は投票でした。投票していただいた皆さん、ありがとうございました。
 
 このセッションでは、前川 直也(@nao_maru)さん、野ア 啓史(@irof)さんと、コンテキストが大きく違う方々の自分戦略を聞けます。

 「何を話さそうかな?聴きに来てくれる方は何を期待しているんだろう?」と内容に頭を悩ませています。

懇親会にはスピーカーの方々も割と参加されるようです。是非お申し込みください。

***********************

 実行委員としてもちろん良いイベントにしていきたいです。
 それに1参加者として色々な方の話を聴いたり、またお話できるのが楽しみです。

#前職からも数人来るようで楽しみです
posted by yohhatu at 09:33 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年08月11日

2012年08月01日

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。