2012年10月31日

[ツール]タスクマネジメントツール「Trello」

 今のところ、個人で一番使っているタスクマネジメントツール「Trello」です。

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

◆Trelloとは?
 「Fog Creek Software」が提供しているWebベースのタスクマネジメントツールです。

 Fog Creek SoftwareはWebサイト「Joel on Software」や「ジョエル・テスト」で知られているJoel Spolskyさんが設立した企業です。

◆Trelloの基本的な使い方

Trelloを業務で使ってみた@タチットにアカウント作成(Googleアカウントでログインできます)から基本的な使い方まで詳しく載っています。
#ありがとうございます。

 Trelloは割と頻繁に機能追加がされているため、上記エントリ当時(2011年9月頃)と違うかもしれませんが、シンプルな作りなので、すぐに使えます。

 Androindのクライアントもあり、Webの機能全てができるわけではありませんが、困らないレベルです。
iOS版もありますが、こちらは使ったことがないので。

◆Trelloの使いやすいところ

1:リアルタイムに更新される
 もちろんリロードする必要もありませんし、(複数人で)色々操作している時もそのタイムラグはありませんでした。

2:直感的な操作方法や機能
 D&Dでサクッと移動できますし、ショートカットも色々用意されていて、思考と(アプリの)操作が直結する感じです。

3:Trello自身の開発もTrelloを使ってそのアイデアや状況を開示しているところ
 Trelloというアプリの特性上当たり前なのかもしれませんが「ドッグフードを食べる」という点と「ユーザーへの透明性を確保している」という点がすごく好きです。

 そのボードを見てもらえると分かりますが、(自分はこの機能が欲しいというように)投票できます。

◆自分のTrelloの基本的な使い方
 レイアウトはタスクボード風にTodo/Doing/Doneという3レーンに分けて使っています。
トップ.png


 具体的な使い方で工夫している点(「誰かに依頼したタスクはどうしているの?」「Doneをいつ消すか?」)はまた別のエントリで書きます。

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

 タスクマネジメントツールは、ユーザーが「本来したいことに集中できる」ようにするのも目的の1つです。
 その点でTrelloはそのサクサク感や直感的に分かる点から優れていると思います。

 Trelloユーザーの方、「自分はこんな風に使っているよ〜」というフィードバックをくれたりすると嬉しいです。
posted by yohhatu at 08:47 | Comment(0) | TrackBack(0) | ツール | このブログの読者になる | 更新情報をチェックする

2012年10月23日

[雑多]第6回RxTstudyで発表しました

 「第6回RxTstudy」で(スタッフ/発表者として)参加してきました。
#「RxTstudy」のこれまでの内容はこちらのサイトをご覧ください。

 今回は[雑多]今度のRxTstudyはミニセッション大会ですで書いたようにメインセッション以外にミニセッション6本というコンテンツでした。

#参加していただいた、お話していただいた、準備/後片付けを手伝っていただいた皆さん、ありがとうございました!

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

◆ミニセッション
 今回のミニセッションでは「あまり発表などしたことがない人が話してくれると嬉しいなぁ」と思っていました。
 (直前まで)発表者がなかなか集まらず苦労しましたが、最終的にはあまり話していない(はず)の@mesodashさんや今回が初めての社外での発表という@komeshogunさんが話してくれました。

 @mesodashさんは、釣り気味のタイトル「もしExcelレガシー現場のマネージャーがRedmineを使ったら」(もしレガ)に負けず、リズム良く面白かったです。
 また@komeshogunさんの「モテ帳」も発表後、一目見ようと人だかりが出来ていました。

 LTほど勢いで終わってしまうわけでなく、また、メインセッションほど長くもなく、ちょうど良く長さでリズムよく話を聴くことができた・・・という声もいくつかありました。

◆自分の話


 前半はAgileJapan2012の再演でしたので、後半(半年後)の補足を少し書きます。
#参考:[雑多]「AgileJapan2012」に参加してきました

1:27ページのスライド
 複数チームのスクラムマスターをしていますが、プロダクトの特徴、チームの特性によって多少やり方や重視する点は変わっています。

 ただ、「次のリリースでどのような機能が出るのか?その中で目玉となるのはどれか?」など営業や上層部が気になることは(チーム間で)同じビュー、内容(粒度)で表現しています。

2:自然に集まる(32ページ)
 今は壁に貼っており、「常に」見えています。

 (前職でも)似たような文化があったのですが、常に見えているようにしているチームは少なかったようです。
 朝会や進捗MTGの時だけ持ち出してきて、普段は(隙間などの)「あえて見に行かないと見えない」所にしまっていたり。
#セキュリティ、オフィスの見映え、スペースがないなどの理由があるのかもしれませんが・・・。

 しかし、これでは共有ファイルサーバの奥底にしまっているのとそれほど変わらず、状況・情報の共有はなかなか難しいと思います。

 壁に貼っているとイヤでも目に入りますし、自然とタスクボードの前でディスカッションが始まることもあります。
 幸いタスクボードの横にはホワイトボードもあるので、そのままそこで仕様を書いたりすることもあります。

#この辺の話は第5回RxTstudyで@masahirotaguchiさんの「壁と私」から影響を受けてやってみました。ありがとうございました〜

3:やったった感(34ページ)
 そのまんまですが、スプリントが終わった時のDoneの付箋の量はそれなりにあります。

 ふりかえりで、それを見ながら改めて自分達がやってきたことを確認することで、ちょっとした自信にもなったりします(小さな成功体験)。

4:Tool(38ページ)
 (この手の話をする時に言っていることですが)アナログでもデジタルでも・・・
「何のためにこの方法をするのか?この方法でどういうことを実現したいのか?」
 ・・・を意識して、チーム(できればチーム以外の周囲も含める)が納得した上でやっていくというのが大事だったりします。

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

 ブログなどは#RxTstudyをつけてつぶやいてくれたりすると嬉しいのでよろしくお願いします!

@kamatamadaiさんが作ってくれた(ありがとうございます!)2012/10/20 第6回 RxTstudy まとめはこちらです。
posted by yohhatu at 08:07 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年10月19日

[ツール]「EveryThing」の検索結果を任意のファイラーで開く方法

 ファイル検索ツールで「EveryThing」というのを使っています。

 それを紹介したエントリ[ツール]高速かつ高機能なファイル検索ツール「EveryThing」で「フォルダ選択時に開くファイラーがWindows標準のそれになってしまうことです」が不満と書いていましたが、任意のファイラーで開く方法が公式サイトにあったのでメモです。

※「Everythingってなに?」という方は「K本的に無料サイト」に詳細な説明があります
***********************

◆設定方法
 Everything.iniに以下の2行を追加すればOKです。

open_folder_command=$exec("ExternalFileManager.exe" "%1")
open_folder_path_command=$exec("ExternalFileManager.exe" "$parent(%1)")
 "ExternalFileManager.exe"には使いたいファイラーのフルパスを記述します。
※参考:4.2 How can I set "Everything" to use an external file manager?

 後はEverythingを再起動すれば設定が反映されます。

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

 元からEverythingのお陰でフォルダやファイルを探すのがすごく楽でしたが、これでもっとサクサク(ストレスなく)作業ができます。

◆サイト:voidtools
posted by yohhatu at 08:12 | Comment(0) | TrackBack(0) | ツール | このブログの読者になる | 更新情報をチェックする

2012年10月10日

社内勉強会の難しさ

※この記事は新しいブログに移行しました。

移行先は【社内勉強会の難しさ – サウスポーなエンジニアの独り言】です。
タグ:勉強会
posted by yohhatu at 08:29 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年10月09日

えらくなっていきたいか?

 ずいぶん前に書いたまま放置していたのを(ちょっと書き足して)アップします。

 組織において「えらくなっていきたいか?」という話です。

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

◆えらくなりたいか?の問いに対して
 一時期「昇格/昇級したいか?」という問いにNoと答えていました。
#前職の話です。
 
 なぜなら「上の人が楽しそうに、やりがいを持って仕事をしているように思えなかった」からです。

 自分がやりたい仕事でないのか、責任やプレッシャーの割に(評価された結果の)給料が低いのか分かりません。
 が、目を輝かせて「今の自分の仕事が楽しい/やりがいがある!」と伝える(伝えなくても態度で示す)人が少なかったように思います。
#恵まれたことに(一番お世話になった)直属のボスは上記に当てはまらない人でした。

 (現場や若手から見て)管理職や上司が魅力的に見えない組織は、新しい力も出てこなく、新陳代謝も起きず、 新しい変化にも対応できず、結果として若く有望な方は出て行ってしまうし・・・で、良いことは何もありません。

◆最近の考え
 最近(※2011年の冬頃)は少し変わってきていて・・・
「その組織で自分がしたいことをやりやすく、横槍を入れられずにやる(=自分でハンドルを握る)には、えらくなって上に行くのが一番の近道」
 ・・・と思うようになっていました。
#この話の前提には「その組織で頑張るなら」がありますが。

 えらくなることを目的としてとらえると(魅力が無いように映っているので)イマイチ前向きになれませんが、「自分がやりたいことするため」の手段として見ると、そう悪い話では無いと感じたからです。

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

 それからしばらくして、ハンドルを握るまでの時間の長さに待ちきれずに移る※ことになったのですが。
[仕事]会社を移ることになりました
posted by yohhatu at 07:38 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年10月02日

自分の転職活動

 2012年7月に今の会社に入社しました。
 その活動や考え方などを軽く書いておきます。

#宣伝
 この話は機会があれば2012年11月10日(土)のDevLOVE関西〜Drive〜でも少しお話する予定です。
 他にも多くのスピーカーが登壇予定なので、ぜひお越しください!
#宣伝終わり


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

◆転職や市場価値に対する考え方
 「自分の市場価値」を知っておきたいという願望がありました。
 その方法の1つとしてキャリアの公開をLinkedInやリクナビなどの転職サイトで行っていました。

 2012年2月頃にプロジェクトの区切りがついたので、職務経歴書やスキルの棚卸しを行い、上記のサイトなどに公開しました。

 ここでの「市場価値」ですが、たいそうなことではなく「(文章や一部のアウトプットを見た上で)どのような人/組織から自分は声がかかるのか?」また「どのような見せ方にすれば自分が望む人/組織にささるのか?」というイメージで使っています。

◆企業のオファー
 しばらくして、それらのサイトを通じていくつかオファーが来ました。

 前職と同様のSIerや派遣会社からのオファー、「へぇこんなところからも来るんだぁ」という企業からもありました。
 (東京に拠点を置いていたWeb系やゲーム会社が)BCPなどの背景で大阪に拠点を作ろうとしていた時期と重なっていたようです(たぶん今も)。
 
◆転職エージェント
 転職エージェントについては、肯定、否定双方の意見がありますが、私は積極的に活用しました。
 理由は2つです。

1:これまでの成功体験(良かった経験)
 これまで接した転職エージェントの方々は良い人/結果が多く、「最初から毛嫌いすることはない」とこれまでの経験上、分かっていました。

 (時々言われているように)「何でもかんでも薦めてくる」エージェントの方もいましたが、そのような場合でも「自分の意見、軸を持った上で、優先順位を明確」にしていれば流されることはなく「No!」と言えます。
#実際、とあるエージェントさんとはそう言っているうちに音信不通になってしまいましたが。

2:情報が豊富だった。
 ソーシャル転職という話もありますが、エージェントしか(知り合えない)情報もまだまだあると思います。また多くの転職希望者やそういうシーンを見ており目が肥えていることも多いです。
#地域差や業界のなども関係あると思いますが。

 それと自分の年齢、キャリア、したいことが「ニッチ」と思っていたので、情報のチャネルは少ないよりは多い方が良いだろうと判断しました。

 繰り返しになりますが、エージェントは、それなりに多くの応募者、企業の採用担当者と接しており、真摯に良いアドバイスをもらえる良い方と巡り会うことができれば、力強い味方になります。

 力強い味方になるかどうかの1つに「○○というのはどうですかね?」と尋ねた時、そのエージェントが担当している企業だとしても・・・
「あなたには○○という点で合わないと思うので、お勧めはしません」
 ・・・と面と向かって言ってくれるというのがありました。

◆TwitterやFacebookなどのソーシャル転職について
 Twitterなどをきっかけに知り合った方から「うちを受けてみない?」と声をかけていただき「あぁ実際にこういう転職がポピュラーになってきたんだなぁ」とも実感しました。
#昔からあったと思いますが、もっと(リアルな人脈のみなどの)もう少し狭い範囲の出来事だったと思います。

 ソーシャルな関係の中で「この人と(組織で)働きたい」というのもありましたが、地理的な関係などで実現には至りませんでしたが、声をかけてもらったのは(お世辞だとしても)嬉しかったですし、勇気づけられました。
#ありがとうございました!

◆実際に動いてみて
 改めて「自分の強みや弱み」(と思っていること)が、それぞれのフィルターから見るとどのように見える/評価されるのかが分かって、面白く良い経験でした。

 在職中で時間が限られていたこと、自分なりに「こうしたい」という譲れない部分が明確でしたので、会う前に質問をしておき、返答が「もっと話を聴いてみたい」と思う人/企業と会うようにしました。

 ちなみに「一緒に働く人(チームとなる人)と話をしたい」と伝えて会わせてもらうこともしました。
#自分の中で下手したら上司よりも大事なことなのですが、なかなかそういうことをリクエストする人はいないようで驚かれることが多かったです

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

 転職をするかは別として「自分のキャリアをどうしたいのか?」という棚卸し、「したいことに対する自分の市場価値はどのようなものなのか?」などを定期的に観測してみると面白いですよ。
タグ:考察
posted by yohhatu at 08:20 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年09月18日

2012年09月15日

[雑多]「デブサミ関西2012」終わりました

 朝会から始まって、及川さんの基調講演、午後の3会場での各セッション、(自分が話した)自分戦略、懇親会までアッという間でした。
#スポンサー企業の皆様、参加されたみなさん始め、関係者のみなさん、楽しい時間をありがとうございました!

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

 それぞれのセッションの内容は誰かがまとめてくれると思うので、自分の感想を。

◆及川さんの基調講演
 内容、話し方も素晴らしかったのですが、その人柄やこれまでの実績(それでもより向上しようとしている姿勢)などから出てくるオーラに圧倒されました。
 目の前で及川さんが実際に話しているというシチュエーションに妙に感動してしまいました。

◆岩切さんとの話
 ちょっと時間があって、岩切(@kohsei)さんとも話すことができたのも自分にとって大きなお土産をもらうことができました。
 「デブサミを10年続けている中で感じたこと」や「次のデブサミ関西をもっと祭りにするにはどうしたらいいか?」などなど本当に色々とお話できました。
 岩切さんが「デブサミの母」と言われることに少しだけ触れることができたかな?と思いました。
※岩切さんのブログ:「[デブサミ]夏サミ2012と関西デブサミ2012終了の御礼と11回目のデブサミ「デブサミ2013」仕込み開始のお知らせ

◆自分の話
 「【A-5】あの人の自分戦略を聞きたい!-デブサミ関西編」でお話してきました。


 (当たり前ですが)30年強の人生をたかだか「10分で語る」なんてのは難しく大幅にカットしました。

 「どのような転機があったのか?またそこでどのように考えたのか?」とか「思いっきり頭を打って、ボキボキに心が折れた失敗談」や「やたら早く起きる生活リズム(呆れられますが)について」などなど。

 ただ、伝えたい根幹的な部分は言えたので、(時間的にはもっと話したかったですが)達成感はありました。
#良い/悪い・・・なんでもかまわないのでフィードバックをくれると嬉しいです。

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

 また来年のデブサミ関西でも「[雑多]「デブサミ関西2012」直前で・・・」のようなエントリを書けるのを楽しみにしています。
タグ:勉強会 日常
posted by yohhatu at 18:36 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年09月14日

[雑多]「デブサミ関西2012」直前で・・・

 「デブサミ関西2012」直前の朝早く、三宮駅のマクドにいるのですが、ふと。

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

 去年(2011年)のデブサミ関西(この時は正確にはScrumBCへの参加でしたが)の時も、ほぼ同じ時間に同じマクドの同じ席にいたような気がします(「塹壕より Scrum と XP」を読み直していました)。

 あの時は1参加者で@ryuzeeさんと初めてお会いしたり、(ワークショップで)紙飛行機を飛ばしてはしゃいでいました。

 あれから1年が経って、実行委員として少しでもお手伝いできて、10分とは言え、自分戦略をお話する・・・てのは、不思議なもんだなぁと思っています。

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

 そのうち本家デブサミでも・・・となれば幸せですが、まずは今日を思いっきり楽しみます。
 というわけで、デブサミ関西2012でお会いする皆さん、よろしくお願いします!
タグ:日常
posted by yohhatu at 06:58 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

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) | 雑多 | このブログの読者になる | 更新情報をチェックする

広告


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

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

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


×

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