チケット駆動開発は、BTS(障害管理ツール)の「チケット」と呼ばれる障害票に相当するしくみを使った開発の方法です。 チケット駆動開発は、チケットを中心にプロジェクトを運営することで、情報共有を進め、コミュニケーションやトレーサビリティの向上し、作業や手順の漏れを防止し、ツール連携によって自動化する、など多くの特徴があるほか、メンバーの協調性を高めて自律的な組織作りに役立ちます。チケット駆動開発には、多くのバリエーションがあり、様々なプロジェクトに適用可能です。 このチケット駆動開に興味を持ったのは、そのバリエーション豊富があったからでしょう。普通の上場論なら「こうなさい」というのがあって、それに従えばそれなりにできるのですが、チケット駆動開発はちょっとちがいます。 もちろん「No Ticket, No Commit!」といった基本的なルールあるのですが、それを教場的に守ったからといってうま

[#xpfes12] 先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 - ついにアジャイル開発は普及期に入りました。そんなことを、今年のXP祭り関西(リンク先はtogetter)で実感しました。 たぶん最初のXP祭り関西は、ワッハ髪型で行われたXP祭り2006です。私も赤いハッピを着て、スタッフをさせていただきました。リンク先を見ていただいても分かると思いますが、XPのプラクティスを試してみた人やXPを実践中の先駆者が、興味のある人やこれから始めようとする人に体験を踏まえて説明する集まりでした。 今回のXP祭り関西は、その内容も参加者もより実践的に感じました。私のつぶやきは上のリンクで見ていただくとして、変化を感じた3つの発表の感想を書きます。 【基調講演】「アジャイル開発の計画と管理」～アジャイルのプロジェクトマネジメント～ 梅田 弘之氏 /株式会社システ

まず、あきぴーさんの「チケット駆動開発の課題と展望」、次に中村さん「Redmineと守破離」で、最後に私が発表しました。 あきぴーさんがチケット駆動開発を展開する際の課題を話され、中村さんがRedmine導入の守破離を話されました。そして私が、最近はチケット駆動開発が難しいとか、うまくいかないというお話を聞くようになったので、成功のためにはビジョンが必要だというお話をしました。 3人で共通のポイントは「形骸化を恐れる」ということです。チケット駆動開発は広く普及しだしています。今回150名ほどの参加者のうち、半分近くの方がすでに実践されているようでした。 今回の発表内容も、ちょうどCMMが本格的に普及しだした頃に似ています。それまでの一般論から、組織に対する実践の議論に向かいました。どのように普及させるか、「守破離」などと言う言葉もそのころに出ていました。いかに現場に浸透させるか、以下に根付

Agile Japan 2012 では、発表準備もあってあまり発表を聞けなかったのですが、印象に残るセッションが“「アジャイルのあるとき、ないとき」 ～アジャイルは関西ビジネスをどう変えられたのか？そしてこれからどこに向かうのか？～”です。 関西ながらのコテコテのテーマですが、内容は充実していました。最も印象的だった議論は、「ある時と感じたのはいつですか？」というものでした。そこで出た言葉を並べると 「アジャイルには2つあり、アジャイル・プラクティスとアジャイル・マインドだ」 「やっぱり考えるようになった時、自主的に振り返りをするようになった。」 これがアジャイルなのでしょうね。プラクティスそのものよりも、マインドが大切で、メンバーが自律的に行動する組織になることが、アジャイルなのでしょう。そして驚いたのが、この発言です。 「プロジェクトファシリテーションのきっかけは、土屋さん！」 これは

小川さんとの共著「Redmineよるタスクマネジメント実践技法」には、個人タスクの管理方法として2つの話を載せています。 松下幸之助氏の仕事術：多忙な松下幸之助氏は1日の仕事を書きだしてから仕事を始めることで、収まりそうにないタスクを実践できていた(という伝聞)。 個人のタスク管理はメールを使え！：Redmineを個人のタスク管理に使ったが、楽しくなくてすぐにやめた話。 これらは、チケット駆動開発の特徴を示していると思います。まず、松下幸之助氏の話は、 仕事の可視化によって全貌が把握できる ゴールを明示することで、計画的に達成できる ということを示しています。これはチケット駆動開発と共通する特長です。 もう一方のメールには、以下のような特長があります。 メールに作業書くことで、作業の漏れを防止できる(未来の自分への作業指示) 未読、優先順位、フォルダ分けなどの属性を管理に用いることができる

[#devsumibook] 誰もが本を読んで学んできた「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」 インターネットの普及に伴い、本を読む機会が減っていないでしょうか？日々仕事に追われる中で問題の解決を優先し、休憩時間に雑誌を見る程度でじっくり本を読む機会が減っていないでしょうか？ 私の場合も例にもれず、かつては読書タイムだった通勤時間もスマートホンでTwitterやFacebook、たまにメルマガを読む程度で、なかなか本を読む時間がとれなくなりました。 去年のデブサミであきぴーさんとチケット駆動開発について発表して、二人で優秀スピーカー賞をいただきました。そのご縁から「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」にご協力させていただきました。 私の書いた内容はSEA関西プロセス分科会でTさんから教えていただいた「TSPガイドブック:リーダ

チケット駆動開発はプラクティスですか？プロセスですか？アジャイル開発ですか？ そういった疑問を抱かれる方もおられるでしょう。この答えは人によって違います。これをテスト駆動開発(TDD)の例を使って説明してみましょう。 テスト駆動開発はJUnitを用いて開発する方法(プラクティス)です。実行コードを書く前にテストコードを書くことで、テストが実行された実行可能なコードを徐々に増やしていく方法です。テスト駆動開発は従来型の開発においても有効で、多くの開発現場で利用されています。 ここで、JUnitがCIツールの機能が追加されたことをイメージしてください。JeninsのようなCIツールは、TDDの単体レベルのテストを常に実行できるほか、結合テストや静的解析、デプロイまでできます。もちろん、従来型の開発においても有効ですが、アジャイル開発の様に繰り返して開発やリリースを行うことで、より効果を実感する

プロセスモデリングの目的は、プロセスを他の人に示し、伝達し、教育することです。また、モデルを元に問題点を明らかにして改善することができます。また、シミュレーションによる予測も可能になります。チケット駆動開発におけるBTSのチケットは、タスクの計画であり、履歴です。この情報は非常に価値のあるものです。 近年、注目されている研究分野にリポジトリマイニングというものがあります。リポジトリとはソフトウェアの開発基盤のデータのことです。具体的には構成管理ツール、障害管理ツール(BTS)、メールサーバなどのデータを分析する研究です。ソースコードのメトリクスを元に障害の含まれていそうな(フォルトプローン)モジュールを探す。構成管理ツールのコミット履歴から、別の障害と関連(ロジカルカップリング)するモジュールを探す。あるいは障害履歴からプロジェクトの今後の予測を行う。など、多くの研究が行われています。 1

巷では「ソフトウェア開発では○○％のプロジェクトが失敗している」と言うことが語られることがあります。ありがちな成功の定義では、ＱＣＤ、つまり、品質が高く不具合の数が見積もり以下、予算内で収まる、納期までにリリースできる、といったところでしょうか。請負開発はもちろんのこと、準委託であっても、予め計画される場合ならば、発注元の観点からはこのような基準かもしれません。 一方、アジャイル開発では顧客の価値を生み出すことが目的ですから、より顧客のビジネスに利益をもたらせるソフトウェアをリリースできたか、信頼性ではなく広い意味の品質という意味のＱとして、より良いＱＣＤのバランスが取れたかどうかによって、成功を判定すべきでしょう。 しかし、これらの成功の基準はプロジェクトをブラックボックスとして見た場合のものです。実際のプロジェクト(開発の現場であるリーダーやメンバ)にとっての成功とは必ずしも一致しませ

Redmineとタスクマネジメントの勉強会であるRxTstudyの第3回勉強会に参加しました。 「Redmineプラグインの作り方(仮)」：@agilekawabataさん 残念ながら懇親会費の集計やお釣りの準備などで、川端さんプラグインのお話はあまり聞けませんでしたが、キチンとフックを使ってプラグインが完成したようです。あとでお勉強しようと思います。 webサイト「Redmine.JP」 4年4ヶ月： 前田 剛さん 2番目の前田さんは、私も色々とお世話になっているRedmine.jpというサイトのお話でした。アンオフィシャルではありますが、多くのRedmineユーザがお世話になっていると思います。 nanocというテキストベースのCMSで管理されているそうです。Redmineの普及とともにドンドン稼いでいただいて、今後もさらに良いサイトにしていただきたいと思います。 Backlog の開