JIRA+Github+Jenkinsによるチケット駆動開発 | 工房「伽藍の堂」
JIRAとGithubとJenkinsを組み合わせてチケット駆動開発をするには、どういう流れで、どういう連携が必要なのか、考えてみました。 流れを図式化したものが以下になります。 手順 図の流れに合わせて手順を説明します。 ①チケットを作成する ソースコードを書き始める理由が何であれ、すべての始まりはチケットになります。あらゆる理由がチケットになり得ます。バグもそうですし、機能改善や機能追加もチケットとして一元的に扱います。 チケットという管理方式を用いることの最大の利点は、あらゆる事象をチケットという単一の概念で扱うで扱う事にあると思います。 何らかの理由でソースコードを書く時は、チケットを作成します。作成されたチケットはOpenという状態になります。 ②チケット名でブランチを作成する チケットに着手するには、チケット名でブランチを作成します。これをトリガーに、JIRA側のステータスを
[#TiDD] yaXPでXPのハードルを下げ、自律的な組織を実現する - ソフトウェアさかば
先日の説明では、詳細をXP祭り関西のライトニングトークスのスライドに振っていましたが、やはりネタはネタなので、yaXPについてまとめておこうと思います。XP(eXtreme Programming)にTiDDを適用した事例は、小川さんと共著で書いたSQiPの論文(PDF)にあり、今度のデブサミ2011でも小川さんが語られる予定です。ここでは、私の経験からyaXPの可能性について語ってみたいと思います。 1. yaXPとは yaXPはBTSを用いたXP(eXtreme Programming)です。XP版のチケット駆動開発と言ってもよいでしょう。 タスクカードをBTSのチケットにする タスクボードをBTSのチケット一覧(レポート)にする イテレーションのタイムボックスをマイルストーン(バージョン)で管理する スタンドアップミーティングではなく座ってBTSを使って朝会をする というものです。そ
![[#TiDD] yaXPでXPのハードルを下げ、自律的な組織を実現する - ソフトウェアさかば](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)
[#TiDD] 第43回 SEA関西プロセス分科会「チケット駆動開発による�現場力の向上」 - ソフトウェアさかば
第43回 SEA関西プロセス分科会で講演しました。ご参加いただいた皆様、ありがとうございました。 あきぴーさんのTestLinkのお話やてふかんの皆さんの「ふりかえり」のお話もあり、充実した内容で楽しめました。 下記のスライドには、45分間でお話しできなかったおまけスライドも入れておきました。いつか、きちんとまとめてお話ししてみたいと思います。
【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン - プログラマの思索
工程単位のBTSプロジェクトやBTSバージョンが何故よくないのか、再考してみた。 ラフなメモ書き。 【元ネタ】 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 頻繁なVerUpがソフトウェア開発の本質: プログラマの思索 【1】WF型開発に染まっているPMやPGは、どうしても工程単位にBTSプロジェクトを作ったり、BTSバージョンにアサインしたりする。 自分たちの開発スタイルが、滝の流れのように成果物を下流工程の人へ渡して、最終成果物を作っていくからだ。 例えば、設計プロジェクト、結合テストプロジェクト、本番障害プロジェクト。 機能Aの設計バージョン、機能Aの開発
TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン - プログラマの思索
TiDD初心者が陥りやすいアンチパターンを更に見つけたのでメモ。 【参考】 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 【1】WF型開発のプロマネとしてバリバリ腕を鳴らしている人がRedmineでタスク管理を運用していると、共通した特徴がある。 それは、工程単位にRedmineプロジェクトやRedmineバージョンを割り当てていること。 例えば、プロマネが1個のプロジェクトだけを抱えているなら、Redmineプロジェクトは1個だけだが、Redmineバージョンを設計、開発、テスト障害、本番障害のように工程単位にアサインしている。 大規模プロジェクトで、プロマネが複数チームをマネジメントしているなら、Redmineプロジェクトを課題、設計、開発、テスト障害、本番障害のように工程単位
[#TiDD] チケット駆動開発がもたらすプロセス その２ - ソフトウェアさかば
続きです。 では、チケット駆動開発でどのようにプロセスが変わるかというと チケットへの依存から、チケット中心の開発 2階層プロセスが明確になる リアルタイムに見える化される スコープの変更(計画ゲーム)が実施される 改善が始まる リリース回数が増える という点です。 チケットへの依存から、チケット中心の管理へ 手作業による管理が難しい状況では、チケットによる管理は効果的です。チケットを使うことで、細かな作業、仕様変更、不具合が容易に管理できます。チケットを使い出すと、チケット以外のメディアとの2重管理は無駄です。すぐにチケットを中心とした開発に移行していきます。 チケットが中心になると、常にチケットを見ながら次の作業を考えるようになります。そして、1日の作業が、チケットの確認から始まり、目標設定、作業、進捗の登録といったリズムを持つようになります。 2階層プロセスが明確になる チケットを中
チケットがプロジェクトを駆動する #tidd - プログラマの思索
さかばさんの記事を読んで、チケット駆動の意味を改めて考えさせられた。 以下メモ書き。 【元ネタ】 [#TiDD] チケット駆動開発がもたらすプロセス: ソフトウェアさかば [#TiDD] チケット駆動開発がもたらすプロセス その２: ソフトウェアさかば 僕の考えでは、アジャイル開発プロセスの基本は小規模リリースであり、その特徴が頻繁なリリースであり、そこにチケット駆動開発が当てはまると思っていた。 つまり、イテレーションありきでプロジェクトが開始すると思っていた。 その意味では、リリース計画駆動であり、本来のXPとは多分違ってくるのだろう。 さかばさんの指摘では、チケットでタスク管理を始めると、チケットに依存した開発スタイルから、チケットを中心とした開発スタイルに変わり、リアルタイムの見える化、スコープのコントロール、プロセス改善、頻繁なリリースが実現されるようになる、という流れ。 多分、
TiDD に scrum 混ぜると幸せになれるんじゃない？ - Natural Software
あきぴーさんの記事を読んで、そもそも scrum が組めていればそもそも起こらないんじゃないの？と思ったのでつらつら書いてみる（あきぴーさんも書いているけど） チケット駆動開発のアンチパターン: プログラマの思索 1-1,乱発されたチケット スプリントプランニングでタスク分割をメンバー全員で行う。 よって、チケットはメンバー全員で合意の上で作成されるので、乱発されることはない。 テスト時の不具合にしても、１イテレーション中での数はそれほど多くないと予想できるので、制御できないほどのチケットは作成されないと思われる。 1-2,有効期限切れのチケット・放置されたチケット スプリントプランニングで登録されたチケットは１スプリントですべてクローズされるはず。 残ったチケットはバックログ未完了になるので、振り返りで完了できない理由を明確にしたのち、再度振り分け（登録）される。 よって、放置されるのは
チケット駆動開発のアンチパターン - プログラマの思索
チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過
【公開】SQIP2009の論文資料 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
gitだからこそできるチケット駆動開発のやり方 - kunitの日記
ここ数ヶ月の成果。やっぱり中心にはgitがある。 チケット駆動開発の良さはわかっていたが、なかなかうまくいかないなぁと思っていたが、gitをちゃんと使うようになってそれができるようになってきた。 チケット駆動開発を実践するにはまずはチケットをきらないといけない。けど、それができない。やっぱりいきなり手をつけちゃうんだよね。それってなんでそうなっちゃんだろうと常々思っていた。 それをある意味抑制するやり方。今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 会員管理を拡張したいなぁ じゃRedmineでチケットを切るぞ チケット番号が振られた(たとえば #567 だとする) さぁ、ブランチ切るか(members_567) そのブランチで作業開始！ 濱野さんがWEB+DB
【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」 - プログラマの思索
第4.5回Shibuya.trac に参加して発表してきた。 スタッフの皆さん、ありがとうございました。 その発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」をCC Attribution ライセンスで公開します。 今回の発表は、昨年のKOFで発表したRedmine＋TiDDから続く一連のチケット駆動開発のまとめになります。 SQIP2009では、大手SIの経営者や管理職が多いせいか、チケット駆動開発の発表はプロセス改善というよりもツールに依存した運用改善と捉えられがちで、あまり反響がなかった。 でも、第4.5回Shibuya.tracはまるでホームのような雰囲気で、聴衆はTrac使用者がRedmine使用者よりもやや多かったけれど、チケット駆動開発に興味のある人達ばかりだったので、熱く語ることができた。 関西から八朔さんや小枝さんも来てくれて心強かった。 最後のパ
チケット駆動開発を日本発のアジャイル開発へ発展させるには？ - プログラマの思索
さかばさんの記事を読んで考えたことをメモ。 【元ネタ】 [TiDD] 小規模開発の難しさを考える: ソフトウェアさかば チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) アジャイル開発は元来、小規模で変化の激しいプロジェクトが向いていると言われてきた。 しかし、XPが出現して10年も経つというのに、現場の実践例は非常に少ない。 ネット上でアジャイル開発の情報がこれだけ溢れていて、開発者も興味を持っているのに、事例になかなかお目にかからない。 情報処理試験の勉強でも、プロセス改善のセミナーでも、繰り返し型開発の重要性が叫ばれているのに、事例は非常に少ない。 その原因は、単純にアジャイル開発を実践できる技術力が足りないからだと思っている。 テスト駆動開発を実践するには、JUnitを使いこなさねばならない。 常時統合
チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
チケット駆動開発は進捗報告作りをどのように解決しようとするか？ - プログラマの思索
【1】管理者は、プロジェクトの進捗報告のためのくだらない作業が必要になる。 まず、初期段階で、WBSとして必要な成果物、作業を洗い出す。 そこから、工数を見積もり、MSProjectやExcelでスケジュールを作っていく。 しかし、実際に作業していくと、そのスケジュールの保守は面倒きわまりない。 当初は分からなかったタスクを追加したり、仕様変更で対応すべきタスクを入れたり、実際は不要になったタスクを削除するなどを、逐一スケジュールへ反映しなければならない。 スケジュールで、先行・後行の関係まで考慮したり、工数の標準化などを行おうとすると、もはやExcelで手作業で管理するのはもはや人間の手を超える。 MSProjectでは、そのような作業をアプリでやってくれるが、だからと言って、スケジュール保守が楽になるわけではない。 そのスケジュールを管理者が常に保守し続けなければならない理由は二つある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[#TiDD] チケット駆動開発はプロセスを軽量化する - ソフトウェアさかば
[#TiDD] チケット駆動開発がもたらすプロセス - ソフトウェアさかば
http://www.machu.jp/posts/20090911/p01/
http://www.machu.jp/posts/20090301/p01/