XP祭り2011でLTしました。発表させていただいた内容は、「6ヶ月のプロジェクトのリリースまでをタスクボードとふりかえる」ものです。チームは10名ぐらい。私のチームとプロジェクト側のチームの合同プロジェクトになります。 @tk0miyaさん、@zuisenerさん、@kohseiさんなどからいろいろご感想をいただいたので、今回は、このLTのコンテキストをちょっぴり補足させていただきます。 チームをつくるということ 合同チームでのプロジェクトということもあり、当初は一体感がありませんでした。そのため、まずは以下のような変化をチームに求めました。 合コンのようにメンバーをごちゃごちゃに席替え 週一の進捗報告でなく、毎日の朝礼を実施 誰が何を今やっているかわかるようにタスクボード（かんばん）を作成 プロジェクトで僕が目指したかった開発チームの姿を「誠」という旗として見える化 プロジェクトのシン

Agile2011のスポンサーブースで見かけたコチラの方。初日からがんばって「Road to AGILITY」の図をホワイトボードいっぱいに描き上げておりました。この人の絵は、YouTubeで見たことがあるので、たぶん有名な方なのでしょう。Agile Manifest作成からどのような道を歩いてきたのか？完成図はこちら。 一つ一つの絵に関しては、スポンサーのRallyがflickrで公開しているみたいです。それにしてもすごいなこの人。

Linkedinは、ビジネスロールごとのディスカッションが面白いのでおすすめです。今回見つけたのが「What software do you use to track user stories and tasks? To manage a product backlog and build sprint backlogs?」というディスカッション。「アジャイル開発に登場するユーザーストーリーやバックログをどんなツールで管理しているか？」が共有されています。 すでに３００を越える共有や議論が行われており、世界のスクラムマスターはどんなツールを使っているのか、気になったので調べてみました。 優勝したツールは・・・ 今回の優勝ツールは「Jira」でした。 Jira+Greenhopper 46票 TFS 28票 Rally Software 27票 Excel 26票 VersionOne 16

Agile 2011 Conferenceに行ってきました。 たくさんのセッションに参加してきたのですが、その中でもカンファレンス二日目に参加した、Chet Hendrickson氏とRon Jeffries氏の「What We Have Learned So Far: what we got right & what we got wrong」が面白かったので、ここでまとめたいと思います。 内容はタイトルにあるように、「この10年で何を学び何を得たのか？そして何が正しくて、何が間違っていたのか？」というもの。アジャイルに関するたくさんのプラクティスやアイデアを共有してきた、Chet氏とRon氏が提起するアジャイルの注意点を確認してみましょう。 アジャイルはしばしば独断主義としてとらえられてしまいます。常に改善を求められる雰囲気や、現実的なマネジメントの影響で「隠し事」が難しくなり、恐怖を

via chelmsfordpubliclibrary 後輩から質問されたので、上手にチーム運営する上で必要となってくるミーティング設計について考えてみた。 ミーティングを侮るなかれ。ミーティングは、プロジェクトにとって諸刃の剣といえる、時間をかければいいわけでもなく、短ければいいわけでもない。ミーティング設計するときは、 なんのためにミーティングを開くか？ どの周期でミーティングを開くか？ どれぐらいの時間をかけるか？ どういった内容にするか？ だれを参加者とするか？ どうファシリテーションするか？ などなど、考えることがたくさんあり、組み合わせもいろいろあることに気がつくはず。 「チームで情報共有」ができて、「チームの状況確認」ができて、「ゴールの共通認識」を確認出来れば自分は満足。しかし、それだけのことがとても難しい。今回は、チーム内や横のラインでつなぐ「ミーティング」を考えた。 伝

Scrum Process via Lakeworks in the Wikipedia 前回はプロダクトオーナとしての使い方を調べてみた。今回は、スクラムマスターの使い方をRedmine Backlogs :: Usage Scrum Masterを元に調べてみる。 スプリントバックログは、プロダクトバックログの上からチームのベロシティ分選択していくだけでよく、選び出されたストーリーにポイントを付け、スプリント内でストーリーが消化されるようにチームを支援するのがスクラムマスターの仕事になる。上の図だと全体にかかわるお仕事なのだが、Redmine Backlogsではスプリントバックログやスプリントが、舞台の中心になるのだと思う。 スクラムマスターとして使う ストーリーの調整はプロダクトオーナーともチームとも相談する必要がある。Backlogsではスプリントごとのベロシティも簡単に確認する

前回、インストールまで終わったので、使い方を考えながら調べてみる。僕は認定スクラムマスターではないので、間違った認識があれば教えてくれるとうれしいです。 その前に、最近日本語化ファイルを作ってくださったかおるんさんのロケールファイルをRedmineのBacklogsプラグインを使ってみた via かおるんダイアリーからGet！ まずは、Redmine Backlogs :: Usage Product Ownerを参考に、プロダクトオーナーとしてのRedmine Backlogsプラグインの使い方を調べてみる。プロダクトプロダクトオーナーの役割についてはこちらを参照のこと。下の図でいうとプロダクトバックログの整備がメインの運用となる。 Scrum Process via Lakeworks in the Wikipedia プロジェクトメニューのBacklogsをクリックするとMaster

Redmineのプラグインを作りながらRailsのテスト方法を学ぼうと思ったら、プラグインの作り方すら完全に忘れていたので、備忘録としてredmine.orgのPlugin Tutorialを訳してみる。これを読めばRedmineプラグイン作成が簡単にできるはず。 注意：チュートリアルを活用するにはRedmineのr1786以上が必要とのこと。 プラグインを作成する プラグインを作るときは、様々なコマンドを利用する必要があるので、パスを通しておくとよい。 https://gist.github.com/daipresents/cd8c75cbe343487bfa7968ee231b6589.js?file=gistfile1.txt Redmineのプラグインはプラグインジェネレータがあるので、ジェネレータを使って雛形を作成する。コマンドの構文は以下。 https://gist.githu

cambiodefractal via Frickr アジャイルムーブメントの影響もあり、アジャイル開発を最近はじめた。またははじめようとしている方も多いと思います。私は2003年に社会人になり、第一次アジャイルブーム？か何かでXPを知り、少しだけ学んだ世代なのですが、去年の1月からアジャイル開発を勉強・実践するようになりました。 そんな中、アジャイルコーチを仕事としている方を間近で見たり、新人研修にアジャイル開発の手法を取り入れたり、実際に自分のチームで実践したりする経験を得ることができました。今年は、まったく自分に関係ないチームのプロジェクトリーダー/マネージャをしながら、アジャイルコーチのような役割を果たしているところなのですが、そこでのコーチング時にふと疑問が浮かびました。 「自分の成果はなんなのだろう？」 その疑問について、Twitterでいろいろと教えてくださった方からのアドバ

LinkedinのCertified ScrumMastersグループで「How do you measure team performance?」というディスカッションが活発に行われています。Linkedinだと職業などに特化した議題が多くてなかなか面白いですね。このディスカッションの始まりは以下の質問です。 Simply, how does you measure output, that team generates, its performance or what metrics do you use? どのようにしてチームが生み出すアウトプットを測定していますか？パフォーマンスや基準として使っているものはなんですか？ 前回書いた「XXXX」という記事にも繋がる部分があるので、投稿されているコメントをまとめてみました。 世界のスクラムマスターのコメントまとめ 南アフリカのスクラムマ

Scrum Boot Camp 横浜に参加しました。たくさんのコーチ陣に囲まれてのワークショップは楽しかったです。また、いろんなつながりによって「はじめましてな人」「ひさしぶりな人」にもお会いすることができました。こういった場を提供してくださった@ryuzeeさんはじめ、皆様ありがとうございます。 今回のブートキャンプでは、アジャイル開発の基礎からスクラムの概要。そして、スクラムで登場するツールやプロセスをワークショップで体験し、理解を深めていく内容でした。私は、書籍を読んで現場でTry and Errorを試していた「野良スクラムマスター」なので、こういう場でコーチの説明を聞くことにより、「自分との差分」「理論の裏付け」など、いろいろと発見することができました。本からは読み取れない部分を学べるのがワークショップの醍醐味ですね。

デブサミ2011の後に、Shibuya.tracの第10回勉強会で初LTをしました。テーマは「EnterpriseレベルのRedmine導入結果について」です。外の勉強会は緊張しますが、@yusuke_kokuboさんや@akipiiさん、アジャイルなゆかいな仲間たちにお会いすることができ、とても楽しい勉強会でした。また学びに行かせていただこうと思います。 はじめに 上の資料はそのときのものです（Slideshareはこちら）。5分間のLTだったため、あまり詳細をお話しすることができませんでしたが、勉強会の時に知り合った方と、今度、Redmine導入＆運用の情報交換会を企画しており、そこで共有するネタとして、まずは、Redmine導入時の経験をここにまとめようとおもいます。まずはその前に、私の仕事内容を少しだけ説明させてください。 標準化とか全社共通とかいう仕事 私は入社以来、サービス開発

burndown chart via kakutani アジャイルなチームを目指す。私がチーム運営を始めたときのポリシーでした。どうやって作業をこなすだけから、アウトプットへの価値へとシフトしていくか？チームの方向を示すためにも、様々なメトリクスやKPIを見える化する必要がありました。 通常のプロジェクト管理方法だと、ガントチャートでロードマップを設定、進捗の状態を管理。WBSなどを作ってそれぞれのタスクを管理・・・といった形が一般的なのでしょうか。しかし、それではワクワクしない。そんな中、常に改善を心がけ、私が試して行き着いた方法を紹介させていただこうとおもいます。 唯一生き残ったプラグイン バーンダウンやタスクボードなど、Redmineのプラグインで様々な見える化をしましたが、ずっとそれを使うことはしませんでした。その中で、最終的に生き残ったのがパーキングロットチャートです。なぜ、これ

前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考

Agile2010のリサーチセッションで、アジャイルソフトウェア開発におけるレビューをテーマに発表をしている方がいらっしゃいました（資料はこちら）。発表者はMario Bernhartさんだったと思うのですが、彼は発表の中で、Continuous Changeset-Based Review（CCBR）という言葉を使っており、開発の最後でレビューに時間をかけるのではなく、コミットごと（Changesetベース）のレビューという戦略を考え、CCBRを実践するためのツールとしてReviewClipseを紹介していました。 開発におけるレビューのコストは大きいと思います。アジャイル開発だけでなく、通常の開発もサポートする効率的なレビューツールを探してみました。 Mylyn Reviews (ReviewClipse) BernhartさんおすすめのReviewClipseはMylyn Revie

アジャイル開発の本質とスケールアップ読書会というのを、会社の先輩が開催しておりまして、 この本は、@ryuzeeさん翻訳のアジャイル関連書籍ベスト100にもランキングされています。（が、翻訳があまりよくない気がする） 2012/08/15追記 – Big PictureはWebで詳細が確認できるようになっていました。詳しくはこちら。 そこで、以下のようなエンタープライズアジリティの面白い図を教えていただきました。 以下、適当な翻訳 このブログのリーダーたちは、エンタープライズレベルで効果的なソフトウェアアジリティの実施には、たくさんの巧みな技が必要だと気づいている。 十分にコミットできている部門や企業であっても、アジャイルの紹介や、たくさんの基本的なアジャイルプラクティスの習得に6ヶ月から1年かかってしまう。そして、生産性を勝ち取ったり、それほどの重要なエンタープライズレベルのアジャイルへ

もし、ソフトウェア業界におけるソリューション開発の現在の能力よりも、市場がより早い変化を必要としている、という前提を認めるなら、「そのために何ができるだろうか？」という問いを持つことになるだろう。私にしてみればその答えは、アジャイルだ アジャイルは使える – そして、スケールアップ可能であるという結論までを語る本。原書はScaling Software Agility: Best Practices for Large Enterprises (Agile Software Development Series) 社内の先輩が「面白い本を見つけたので読書会をしようと思う」という話をしてくれた。 その方はマネージャになるのだけれど、データ分析とかが得意なアーキテクトでもあり、 「この人が開催する勉強会は面白い」と思って、「絶対面白いからやりましょう」と伝えた。 それから、数か月がたち、今月で

XP祭り2010で講演しました。にXP祭り2010の平鍋さんの資料がアップされています。 最近、本当に思うのですが、日本でこういう活動をされ、翻訳や講演やAn Agile Way、InfoQなどで情報発信されている平鍋さんには、いつも学ばせていただいています。 以下、気になったところをピックアップで。 発注と納品の関係だと綱引きが怒ってしまう アジャイル開発の機能分割だと、ホールケーキからショートケーキを作るのではなく、いきなりショートケーキを作る 共通部品を先に作る・・・とかではなく、画面からデータまでまとめて作る 経営者にはリーン、マネージャにはスクラム、開発者にはXPの本を渡すとすっきりする デミングさんはすごい アジャイル≒スクラムなのか？ 逆にアジャイルからスクラムを引くと何がのこるか？ 一つはエンジニアプラクティスが残るはず もうひとつはクラフトマンシップ（職人魂）が残るのでは

Agile Japan 2010に行ってきました。 ・Agile Japan 2010（Twitterのハッシュタグは#aj10） いきなり寝坊です。自社の技術理事からの電話で起きるという贅沢な朝でした。 来年からは自分のお金で行こう。 IBM本社には紀伊国屋がある！すげー！というテンションもいいのですが、ついたら昼ごはんの時間でした。 よって、午後からのセッションしか見ていません。 * 会場の雰囲気 実践知のリーダーシップ ?スクラムと知の場づくり? 野中郁次郎氏 （キーノートセッション1） 以下、響いた言葉。 ナレッジソサエティ ナレッジは唯一の意義ある資源 企業はユニークな未来を創る存在 主観から客観を創る（まず自分から） 暗黙知と形式知 氷山というメタファー スパイラルアップで向上 リーダーシップ 実践知リーダーシップへ 経験＞共感（共同）＞凝縮＞体系化＞価値化 アリストテレスの知

QAからのレポートは大抵似たレポートとなります。 バグ収束曲線とか、発生件数、消化率・・・。 これらをRedmineでレポート化して、オンラインで状況確認出来るようにプラグインを作ります。 テストレポートプラグイン(Test Report Plugin) 開発中です。 よ り詳細はgithubを ご確認ください。(You would like to get more information, please check github.) Download github (Recent version is here.) Product Backlog バグ収束曲線を折れ線グラフで表示する バグの発生件数を 折れ線グラフで表示する バグの修正件数を折れ線グラフで表示する Reference 特に日本電気株式会社の川村さんの資料はとても面白かったです。ありがとうございます。 どこでテストをやめる