Redmine×Gitのハーモニーは涙のチケット駆動開発!?：かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）（1/3 ページ） 本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。 これまでのお話 本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。 ひょんなきっかけから電子目安箱（カウンセラー）を開発することになった「ぷりん」と「まいん」の姉妹。第1回の『高校生になって初めてスクラムを始めました～「ストーリー」で何を作るかまとめよう』、第2回の『スプリントと“かんばん”でチームのビートを刻め!! ～スクラム開発で使う手

ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム（BTS）や課題管理システム（ITS）を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま

背景 「コーディング作業に入ったお仕事」のリーダーになった時の経験。正確には「リーダー」という役職ではなかったけれども、役割的には指導的な立場だった。メンターというのかな? 新人部下と書いたけれども、正しくはプログラミングの基本を一応勉強した同期と一年下の後輩だった。その開発プロジェクトは、その後一か月位いでキャンセルされてしまったので、メンターを務めた期間もほんの僅かだった。 とはいえ、メンターとして指導をする機会に恵まれたことは確かで、その中で頭を悩ませた。自分なりに教育方法にも工夫した。その話を、記事にしてみる。 基本は PDCA とコミュニケーション PDCAサイクルは、Plan (計画)・Do (実行)・Check (評価)・Act (改善) の頭文字を取ったもの。会社の研修では、報連相 (ほうれんそう) (報告・連絡・相談) と共に教えられることが多い。 PDCA は仕事をする

[#TiDD] アダプタブル・ウォーターフォール開発の事例 ～想定外の作業はチケットで補完せよ!～ #RxTstudy 第2回 RxTstudy(Redmineやタスク管理を考える勉強会＠大阪)で講演をしてきました。 これまで、補完型チケット駆動開発と呼んでいたもののうち、従来型の開発に提要したものをアダプタブル・ウォーターフォール開発と呼んでいます。今回はその事例を紹介します。 講演で少ししかお話しできなかったコーチングのお話は、別の記事に書きました。

Agile Tour Osaka 2011でライトニイングトークをさせていただきました。当日になって修正したり、説明を追加してしまい。３分の２ほどしかお話しできませんでした。せっかくスライドを作りましたので公開します。 「チケット駆動開発によるアダプタブル・ウォータフォール開発」というタイトルで、ウォータフォール開発には難しいことがあるけど、チケット駆動開発を導入するとアジャイルの良さを取り入れることができるというお話です。アダプタブルというのは、アジャイル開発の名称の候補であった(参考アジャイルマニフェスト10周年 - アジャイルマニフェストはどう生まれたのか＜kawaguti の日記＞)アダプティブを参考に、これまで従来型開発における補完型チケット駆動開発と呼んでいたものに命名しましたです。当初、アダプティブにしようかとも思ったのですが、あらかじめ変更のための仕組みを入れておくのではな

【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ～BTSから始まる進化の歴史」　#devlove0917 DevLove関西は2009年にも開催されていましたが僕は参加できませんでした。 ですが、下記のBlogからその情熱は感じ取りました。 だから、僕自身も無意識に熱くなっていたのかもしれません。 DevLOVE関西に心を込めて花束を - fkino diary(2009-09-26) DevLoveは情熱的なコミュニティと知ってましたが、今日のDevLove関西も懇親会(渾身会と呼ぶらしい)も、高校生の文化祭や高校野球みたいなノリノリの雰囲気でした。 楽しかったです。 肝心の発表は50分枠だったので余裕で話せるだろうと思ったのですが、1時間近く話しても言い足りなかった。 よしうみさんから、今日のあきぴーさんは1.5倍速でしたよ、と言われてしまった(笑) 上記の資

Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。 「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」 確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。 でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、本質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

自分が今いるチームは、3か月半ぐらい前にTracを導入して、チケット駆動開発に移行しました。 今では、チケットを中心に作業を進め、進捗の報告もチケット上で行っています。 そんなチケットですが、より作業がスムーズに進むよう3タイプの人を意識して書くように工夫しています。 同僚、先輩 → 詳細に書く 同僚や先輩に向けてチケットを書くときには、できるだけ詳細に書くように注意しています*1。 バグ報告のチケットなら、 発生手順（どういう前提条件で、どう操作をすれば発生するのか） 根本原因（ただの単純ミスなのか、設計上の問題なのか） 修正方法（どのクラスを直すか、水平展開のポイントはどこか） といった点を詳細に書いています。 Trac導入前だと、これらを口頭で説明したり、手書きのメモで箇条書きにして渡したりしていました。 でも、これだと相手に意志がうまく伝わらず、直したと言われてもチェックしたら直っ

【緩募】BTSでバグや要求を管理している皆様。ある程度の期間、管理していると「優先度が低い」チケットが溜まってくると思います。多くなり過ぎた場合クローズする必要がありますが、「誰が」「いつ」「どういう基準」でクローズすると判断していますか？

10/30に行われたAgileTourOsakaのライトニングトークスで、@kami_teruさんのLTがとても興味深かったのでメモ。 下記のUstreamで見れます。 【元ネタ】 AgileTourOsaka2010 LT, Recorded on 10/10/30 tetsu_m on USTREAM. 会議 Atsuteru Kamiya (kami_teru) on Twitter 「チケット駆動開発をやってみて」というタイトルで、@kami_teruさんのチケット駆動開発の導入経験談。 率直な感想は、とても面白いし、とても興味深かった。 @kami_teruさんによれば、XP祭り関西2010のチケット駆動開発セッションを聞いたのが、Redmineによるチケット駆動開発をやるきっかけだったとのこと。 詳細は上記のUstreamを見て頂きたい。僕が興味を惹いたのは2つ。 一つは、いき

TracやRedmineを障害管理に使うことに慣れてくると、会議のアクションアイテムや各自の作業項目をチケットに入れて管理するようになってくる。いわゆるチケット駆動開発により、作業の見える化、効率化を進め、管理負荷の軽減を図るわけだ。何でもチケットに入れて整理しつつ片付けていくと、日々の業務がスムーズに進むようになるメリットは大きいと思う（ゲーム感覚と言う人もいたけど）。 このような形でチケットを使う時に大切なのは、チケットの終了（クローズ）基準だろう。障害管理ならソフトのバグを直してソースコードをコミットし、修正箇所が確認出来れば完了という極めて明確で普遍的なワークフローが存在するけれど、WBSの作業項目をチケットに放り込んで「概要仕様を検討する」なんて言う曖昧な項目を入れてしまうと、各自の認識が実は異なっていて開発途中にその違いが露呈して混乱することが珍しくない。 例えば、仕様を決めた

さかばさんの記事とyusuke-kokuboさんのつぶやきを読んで思ったことをメモ。 【元ネタ】 [#TiDD] チケット駆動開発はプロジェクト成功の3C(Commitment、Communication、Collaboration)を実現する: ソフトウェアさかば Twitter / yusuke-kokubo: 社内Redmineのチケットに「後で振り返る？:Boolean」というカスタムフィールドを追加した。 僕もRedmine導入前は、Excelで課題管理、タスク管理をやっていたし、Excelのテスト仕様書でテストして、Excelで障害管理もやっていた。 プロジェクトをどう進めればよいか、は自分では見えていたけれど、制御するのは非常に難しかった。 Redmineでチケット駆動開発を運用し始めて、色んな事に気づいた。 単にAgile開発を初めて実際に運用できただけでない。 従来からや

TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ

来月、いよいよチケット駆動開発の本が出版されます。そのタイトルは 「Redmineによるタスクマネジメント実践技法」 です。大人の事情でタイトルにこそ入っていませんが、表紙にはしっかりと「チケット駆動開発」の文字が入る予定です。まだ1ヶ月ほど先になりますが、すでにAmazonでは予約受付されています。 この本は、チケット駆動開発に関して精力的に活動されているあきぴーさんの多くの実践ノウハウを中心に、私(さかば)と共著で書きました。もちろん良書の条件を満たすべく、チケット駆動開発の歴史や背景も書いています。もちろん、Redmineのノウハウも詰まっていますし、TestLinkも説明しています。 中堅の技術者をイメージして書いていますので、近頃にない内容の濃い本になっています。目次は以下のようになっています。ご期待ください。 第1部　チケット駆動開発技法 ─BTSによる作業管理─ 第1章　障害

チケット駆動開発におけるExcelの役割についてメモ。 ＃あくまでもメモ書き。 受託開発では顧客の業務のうちExcelで手運用している業務をIT化、Web化することで狙い撃ちにしているのに、自分たちのSW開発ではExcelが幅を利かせている。 つまり、SW開発の業務そのもののIT化は遅れているのが現状だろう。 なぜ、Excelによるプロジェクト管理は良くないのか？ その理由は下記で書いた。 Excelのプロジェクト管理は何故良くないのか: プログラマの思索 一言で言えば、ExcelのドキュメントはSVN・Mercurialなどでバージョン管理すべきか、RedmineのチケットやTestLinkのテストケースなどで代用できるか、使い分けることが肝心。 では、チケット駆動開発は何をもたらしているのか？ その理由は下記で書いた。 Excelのプロジェクト管理から脱却せよ～SW構成管理を見直そう:

「アート・オブ・プロジェクトマネジメント」を読み直して、チケット駆動開発を運用した経験から、そうだよ！と何度も頷くところがあった。 ラフなメモ書き。 【元ネタ】 「 アート・オブ・プロジェクトマネジメント」の検索結果1 - 脱・下流エンジニア (仮) 「 アート・オブ・プロジェクトマネジメント」の検索結果2 - 脱・下流エンジニア (仮) 【12章 リーダーシップが信頼に基づく理由】 「表明」とはコミットメント、約束を意味する。 メンバーが表明することによって、小さな約束が積み重ねられて、一つのシステムが完成する。 チケット駆動開発では、チケットファーストの原則に表明の概念が組み込まれている。 プロジェクトで発生する全ての作業は、チケットに起票してから開始する。 WBSから起こされたタスクも、突発的な事件によって発生したタスクも、まずチケットに起票する。 そのチケットには、開始日と終了日、

「派生開発カンファレンス2010」の講演資料が公開されたのでメモ。 ラフなメモ書き。 【元ネタ】 「派生開発カンファレンス2010」開催案内 XDDPとUSDMでプロジェクトの課題解決 ソフトウェアの改造で悩んでいませんか？　～派生開発の品質と効率の向上を目指して～ 派生開発は、既に運用されているソフトウェア製品に対し、保守したり、機能追加したり、それを移植して別製品を作ったりするアプローチ。 日本の携帯電話が、カメラ、着うた、オサイフケータイ、Edyなど次々に機能追加していく様は、まさに保守ではなく派生開発だ。 派生開発は組込製品やパッケージ製品でよく発生し、その難しさは以前から知られていた。 特に大規模プロジェクトほど、再利用可能な部品を作る設計にしておかないと、似たような部品を作っているのに、別チームで開発してしまって、工数やコストをかけすぎてしまいがち。 更に、似たような機能やソー

興味深いTwitterがあったのでメモ。 【元ネタ】 Twitter / kashisan: 最近行った #Redmine を使いこなせてチームに対するアドバイス。「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」、「各トラッカーのステータスがどういう状況を表すか定義する」「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」 Redmineを有効に運用出来ていないチームに対するポイントは3点ある。 １・「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」 ２・「各トラッカーのステータスがどういう状況を表すか定義する」 ３・「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」 ポイント1は、チケットファーストの原則。 プロジェクトにある全ての作業はチケットから始まる。 そのためには、チケットは成果物単位、つまりWB