チケット駆動開発がWF型開発と相性が悪い理由 - プログラマの思索
「SIの現場で使えるチケット駆動開発｜セミナー｜Growth xPartners Corporate Site」セミナーをUStreamで聞いて、思ったことをメモ書き。 【元ネタ】 2013/08/24（土）「SIの現場で使えるチケット駆動開発」セミナー #gxptech - Togetter 【１】Excelによるプロジェクト管理は、計画作成時はまだしも、その後の実績管理の運用では、利点よりもたくさんの弊害の方が出てくると思う。 Twitter / akipii: #gxptech Excelの最大の弱点はコミュニケーションが閉じてしまうことかな。更新する人しか最新情報を知らない。メールにExcelを添付されても、その履歴を追跡するは面倒。Excel駆動とメール駆動の開発は表裏一体だと思う。 しかし、最近はRedmineを導入したものの、思ったような効果が出ていない事例をよく聞く。 話を
Redmineに対抗！Rails製のプロジェクト管理·Sprintapp MOONGIFT
SprintappはRuby/Ruby on Rails製のオープンソース・ソフトウェア（MIT License）です。 プロジェクト管理ソフトウェアは時代に合わせて幾つも開発されています。そしてプロジェクトや開発スタイル、人数によって最適なものを選択しなければなりません。今回はRails製の小型なプロジェクト管理Sprintappを紹介します。 ダッシュボードです。チケットやステータスが一覧で表示されます。 現在のスプリントのステータス。プロジェクトや締め切りなどでフィルタリングできます。 カレンダー表示です。 新規プロジェクトの作成。 プロジェクトの一覧です。こちらも条件に合わせてフィルタリングできます。 プロジェクト概要。 マイルストーンを定めます。 チケットの詳細。色で分かりやすく表現されています。 主な機能としてはカレンダービュー、スプリントビュー、課題トラッキング、タイムトラッ
TiDD初心者から必ず聞かれる質問～「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine - プログラマの思索
「チケットの粒度」と「チケットの完了条件」は、TiDD初心者から必ず聞かれる質問だ。 チケット駆動開発を実践している人なら、周囲からいつもこの質問に対して受け答えしていないだろうか？ 【参考】 第4回勉強会 - shinagawa.redmine 第4回shinagawa.redmine勉強会 : ATND チケット駆動開発のアンチパターンの事例: プログラマの思索 チケット駆動開発を上手に運用するためのポイント: プログラマの思索 プロジェクトマネージャが抱えるプロジェクト管理の問題: プログラマの思索 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索 【1】「チケットの粒度」は、チケットの作り方に悩んでいる人に多い。 チケットが大きすぎると、進捗状況を把握しにくいし開発のリズムも出ない。 現場リーダーがWBSからチケットへ作業を登録する時、1～2
Redmineを使ってみよう
自分なりにまとめてみたRedmineについてのスラ イド。 たぶん使ったことがない人向け。 あくまでも口頭での説明ありきでまとめているので、 ちょっと分かりにくい部分があるかもしれません。 資料のイラストや写真については、下記のサイトの素材 を使用させていただきました。 ※一部、自作の素材もあります。 フリーイラスト集【(株)タカミコーポレーション】 http://e-poket.com/ill... Materialand http://www.material-la... 素材のプチッチ http://putiya.com/ styraise（スタイライズ） http://www.styraise.com/ morgueFile free photos for creatives by creatives http://www.morguefile....Read less
Redmineでのタスクの進捗報告について - いぬおせろ
Redmine Advent Calendar jp 2011 : ATND の18日目です。 プラグインの開発や利用をほとんどしていないのですが、一応本体は1年半使い続けているので、今のプロジェクトでの利用方法について書きます。 背景 Shibuya.trac#13に滑り込んでみた - いぬおせろ でも書いたのですが、紙とRedmineでチケット(作業）を運用しています。紙はみんなが話し合うために、Redmineはやりたいこと（wiki/フォーラム/チケット）とやったこと（SCMへのコミット）の紐付けと、マネージャへの報告のために利用しています。 タスクに進捗率があっても、チケットに進捗率はない Redmineにはチケットに進捗率を入力する欄がありますが、みなさんはどのように利用していますか？ 進捗率といえば「永遠の90%」問題が有名ですね。担当者に話を聞くと、考慮することがどんどん出て
【資料公開】チケット管理システム大決戦 第二弾
みなさんこんにちは。@ryuzeeです。 2011年6月30日にShibuya.tracの第12回勉強会として、チケット管理システム大決戦第二弾を実施しました。 僕はモデレータ役として登壇させていただきました。普段講演者として発表する機会は多いのですが、モデレータは初体験でしたので段取りが悪かった点もあるかと思いますがご容赦ください。 以下に当日利用した資料を公開します。 手前味噌ですが、このレベルの内容が揃った資料はなかなか無いと思いますし、資料的価値もあると思いますので、参加された方もそうでない方も是非ご覧ください。 質問等がある場合は#shibutraタグをつけてつぶやいて頂ければと思います。(また各資料の左端に作成者のIDを記載しておきました) ご登壇頂いた池田さん、中村さん、山本さん、大貫さん、関さん、藤原さん、原田さん、かぬさん、ご参加頂いた皆さん、事前準備に奔走してくださった
RedmineからPMBOKのEVMを計測する方法 - プログラマの思索
RedmineからPMBOKのEVMを計測する方法についてアイデアをメモ。 【元ネタ】 チケット駆動開発にEVMの概念を導入してみる: プログラマの思索 RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索 チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索 【1】PMBOKのEVM(Earned Value Management)とは、工事進行基準による進捗管理と実質的に同義だ。 昨今のITプロジェクトでは、大規模案件ほど、成果物の進捗ベースで売上が計上される仕組みが多いだろう。 すると、メンバーに毎日の進捗報告を義務付けて、マネージャが週1回集計して、売上を計上して会社に報告する流れになるだろう。 以前は、工事終了基準だったから、システムの検収後に一括して売上を計上すれば良かったが、J-SOXがあるために実質的に不可能。 実際に工事進行基
チケット駆動開発は計画の変更を恐れない #tidd - プログラマの思索
チケット駆動開発でのリスケについての質問を見つけたのでメモ。 下記はあくまでも僕の一意見。 ラフなメモ書き。 【元ネタ】 チケット駆動開発でのリスケジュール方針について | OKWave 【1】チケット駆動開発をAgileに運用しているなら、チケットのDoneの条件はリリースする事。 すなわち「バージョンをCloseする＝リリースした」「バージョンをCloseできない＝リリースしていない」になる。 もし、遅れたチケットを無視してリリースしたなら、チケットは延期されたことを意味している。 つまり、遅れたチケットは次のバージョンへアサインされることと同義だ。 チケット駆動開発において、リスケのタイミングといつだろうか？ Agileに開発しているなら、朝会だ。 Scrumならデイリースクラム、XPならスタンドアップミーティングに相当する。 PLは課題解決マシーン。実作業はメンバーにお任せ。 課題
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
TiDD初心者が陥りやすい罠～マイルストーンの役割を誰も理解していない - プログラマの思索
ITS(Issue Tracking System：課題管理システム)の導入がうまくいっていない状況があったという記事があったのでメモ。 とても参考になります。 【元ネタ】 なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド Agile開発の肝はイテレーションにあり: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 (前略) 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんてITS使ってる人には常識
なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド
出張してもどってきたら社内Tracが残念なことになっていた 最近、もともと所属していたチームをはなれて外で開発をしていた。 久しぶりにもどってきてTracを覗いたところ、非常に残念な感じなっていて、有り体に言えばゴミタメになる寸前だった。 （今現在も解決していない） ほかのチームでRedmineを展開してそこそこ上手くいっていたので、 なんでこんなことになったのか？どうすれば防げたのかをいろいろ考えた。 個人的なメモ。 何がいけなかったのか 個人的に思うところは以下の３点 ・マイルストーンの役割を誰も理解していない ・バグ表を作る人（≒リーダー）がTracを使えない、使う気がない ・求められる機能とTracの機能に乖離があった マイルストーンの役割を誰も理解していない 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんて ITS使ってる人には常識
Kanon LAB: Kanon Allegro
Allegro(アレグロ)とは、イタリア語で「陽気に」、音楽用語では、「速く」を意味する言葉です。Kanon Allegroはスクラムをベースとしたアジャイル開発をサポートするチケットシステムで、アジャイル開発者は一般的に陽気で、素早くリリースするというイメージから名づけました。 また、ソナタ形式のクラッシックの第1楽章の多くはアレグロで構成されていますが、アジャイル開発を行う人のとっかかり(第1楽章)をサポートするという意味も込められています。 Kanon Allegroはバックログの管理、バーンダウンチャートの作成(全体、チーム個別)、Excelからのストーリー、タスクのインポートを行うことができます。 Kanon Allegroの使い方の詳細については、Shibuya.trac第11回で発表しましたをご覧ください。 バックログの管理 ストーリーとタスクで、プロダクトバックログとスプリ
【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン - プログラマの思索
工程単位のBTSプロジェクトやBTSバージョンが何故よくないのか、再考してみた。 ラフなメモ書き。 【元ネタ】 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 頻繁なVerUpがソフトウェア開発の本質: プログラマの思索 【1】WF型開発に染まっているPMやPGは、どうしても工程単位にBTSプロジェクトを作ったり、BTSバージョンにアサインしたりする。 自分たちの開発スタイルが、滝の流れのように成果物を下流工程の人へ渡して、最終成果物を作っていくからだ。 例えば、設計プロジェクト、結合テストプロジェクト、本番障害プロジェクト。 機能Aの設計バージョン、機能Aの開発
Redmineのロードマップにある進捗率の意味 - プログラマの思索
Redmineのロードマップの進捗率について良い説明があったのでメモ。 【元ネタ】 ロードマップ画面に表示される進捗率の算出方法 | Redmine.JP Blog Redmineのロードマップでは、進捗率が2種類表示される。 一つは終了チケットの進捗率で濃い緑色で表示される。 もう一つは仕掛り中も含めたチケットの進捗率で薄い緑色で表示される。 上記の機能が意味するのは、濃い緑色の進捗率こそが実質の進捗率であること。 顧客が使える機能は、実装する機能のチケットのステータスが終了でなければ、実装できたとしてもテストも終わっていないのだから、リリースできる品質が確保されていない。 Agile開発では、Done(終了)でない作業は全て未完了と見なすけれど、その意味は、顧客に取って価値あるソフトウェアはまさに動くソフトウェアであるからだ。 まともに動かないソフトウェアは価値あるソフトウェアとは言え
[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発 - ソフトウェアさかば
ウォーターフォール(WF)とアジャイルの議論はいつもかみ合いません。それは、モデルで考えるなら、1回だけか複数回かで複数回の方が変化に強いに決まっているものの、WFは決められた仕様どおりのものを作ることが目的で、アジャイルは変化に対応しながら顧客の要求に合ったものを作ることが目的だからです。目指すものが違うので、それを比較しても、どちらが良いということはありません(もちろん、あるプロジェクトにとって、どちらが向いているかはあります)。 ここでは、WFではなく「従来法」と呼ぶプロセスを考えてみます。具体的には、開発標準として、上流から下流までの段階的な工程に分かれ、各工程での作業、成果物、品質向上策のほか、メトリクスの基準が決められている。初めての技術に関しては、プロトタイピングが実施されて技術的な検証がされる。また、上流では少人数で、下流工程では増員されるようなプロセスを考えます。 このよ
![[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発 - ソフトウェアさかば](https://cdn-ak-scissors.b.st-hatena.com/image/square/cb3189f8cb55f68fc5c2b0270b2e8657e0d2eb43/height=288;version=1;width=512/http%3A%2F%2Fsakaba.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
Agile開発の肝はイテレーションにあり - プログラマの思索
Redmineでチケット駆動開発を運用するまで、Agile開発を体で理解できていなかった。 XPを実践したいと思っていても、本当のAgile開発は何か違うのでは？と思っていた。 何故、僕はTracではなくRedmineを使ってAgile開発を発見できたのだろうか？ RedmineがAgile開発と相性が良いのは、Redmineの「バージョン」の概念がAgile開発の「イテレーション」「スプリント」と自然に一致するからだ。 Redmineでは、バージョンに紐づくチケットが全て完了ステータスになって、進捗率が全て100％になれば、いつでもそのバージョンをリリースできる仕掛けが入っている。 つまり、バージョンをイテレーションと見なせば、各バージョンを次々にリリースしていけば、自然に小規模リリースを実現できる。 小規模リリースこそが漸進型開発、つまりインクリメンタル型開発の最大の特徴なのだ。 Ag
バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠 - プログラマの思索
TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ
チケットがプロジェクトを駆動する #tidd - プログラマの思索
さかばさんの記事を読んで、チケット駆動の意味を改めて考えさせられた。 以下メモ書き。 【元ネタ】 [#TiDD] チケット駆動開発がもたらすプロセス: ソフトウェアさかば [#TiDD] チケット駆動開発がもたらすプロセス その２: ソフトウェアさかば 僕の考えでは、アジャイル開発プロセスの基本は小規模リリースであり、その特徴が頻繁なリリースであり、そこにチケット駆動開発が当てはまると思っていた。 つまり、イテレーションありきでプロジェクトが開始すると思っていた。 その意味では、リリース計画駆動であり、本来のXPとは多分違ってくるのだろう。 さかばさんの指摘では、チケットでタスク管理を始めると、チケットに依存した開発スタイルから、チケットを中心とした開発スタイルに変わり、リアルタイムの見える化、スコープのコントロール、プロセス改善、頻繁なリリースが実現されるようになる、という流れ。 多分、
[TiDD] 速報！史上初の「チケット駆動開発」の本が出版に - ソフトウェアさかば
来月、いよいよチケット駆動開発の本が出版されます。そのタイトルは 「Redmineによるタスクマネジメント実践技法」 です。大人の事情でタイトルにこそ入っていませんが、表紙にはしっかりと「チケット駆動開発」の文字が入る予定です。まだ1ヶ月ほど先になりますが、すでにAmazonでは予約受付されています。 この本は、チケット駆動開発に関して精力的に活動されているあきぴーさんの多くの実践ノウハウを中心に、私(さかば)と共著で書きました。もちろん良書の条件を満たすべく、チケット駆動開発の歴史や背景も書いています。もちろん、Redmineのノウハウも詰まっていますし、TestLinkも説明しています。 中堅の技術者をイメージして書いていますので、近頃にない内容の濃い本になっています。目次は以下のようになっています。ご期待ください。 第1部 チケット駆動開発技法 ─BTSによる作業管理─ 第1章 障害
チケット駆動開発にPSPの概念を持ち込む - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
