lynx   »   [go: up one dir, main page]

タグ

TiDDに関するshiumachiのブックマーク (7)

  • 課題管理のチケット駆動開発 - プログラマの思索

    従来から言われているアジャイル開発の弱点として、スケールアップと上流工程への応用があった。 チケット駆動開発を実践してみて、スケールアップはアジャイルリリーストレインとスクラムオブスクラムで解決できると思っている。 しかし、上流工程への応用はチケット駆動開発でも試行錯誤している。 考えていること、まだ疑問に思っていることをメモ。 アジャイル開発を現場に導入する場合、開発やテストの工程から導入すると成功する。 テスト駆動開発、継続的インテグレーションのようなプラクティスを部分的に導入するだけでも、開発の生産性は大きく上がる。 更に、Scrumを導入すれば、プロジェクト管理も支援できるだろう。 しかし、要件定義というシステム開発で最も揺れる工程にアジャイル開発を導入するのは上手くいっていないように思う。 アジャイル開発では要件をストーリーカードで表現して、バックログに貯蔵して管理する。 バック

    課題管理のチケット駆動開発 - プログラマの思索
  • チケット駆動開発の概要と体験談

    小規模かつ高機能なソフトウェア開発の増加、環境のオープン化、ビジネス環境の変化など、近年増加する困難さから、BTS(障害管理ツール)を用いてタスクを管理するTiDD(チケット駆動開発)が注目されています。発表ではこのTiDDの概要と体験談をお話しします。 まずTiDDの概要として、普及の背景、歴史、事例、と共にTiDDとは何かを説明します。次にTiDDの体験談として総合文教ソリューションUniVisionのカスタマイズ開発での体験談を報告します。体験談のプロジェクトでは、リリースが近づくにつれ、細かな作業が増えて困っていました。そこで、TiDDを導入したところ、作業の抜けが少なくなっただけでなく、プロジェクトが元気になりました。Read less

    チケット駆動開発の概要と体験談
  • http://www.machu.jp/posts/20100406/p01/

  • チケット駆動開発のアンチパターンpart2 - プログラマの思索

    チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。 【元ネタ】 チケット駆動開発のアンチパターン: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】メトリクスの罠 RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。 管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。 メトリクスは万能ではない。 メトリクスだけではプロジェクトの現状を把握できないのが現実だ。 メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。 いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。 メトリクスはバッドノウハウの塊。過信しない方がいい。 【2】問合せは

    チケット駆動開発のアンチパターンpart2 - プログラマの思索
    shiumachi
    shiumachi 2009/12/02
    "顧客からの問合せや設計者への仕様の質問をチケットへ起票する時、そのチケットをバグ修正のワークフローで管理してしまいがち。"私のところは「問い合わせ」を別に作成してるな
  • チケット駆動開発のアンチパターン - プログラマの思索

    チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過

    チケット駆動開発のアンチパターン - プログラマの思索
    shiumachi
    shiumachi 2009/12/01
    "優先度がごちゃ混ぜのバージョン"これは本当に困る。というか、優先度を決める権限のある人が真っ当に優先度つける仕事してくれないとチケット管理の威力はガタ落ちする。それでもないよりマシだけど
  • チケット駆動開発のベストプラクティスを収集したい - プログラマの思索

    チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 1・チケット・ファースト(Ticket First) 【説明】 基は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル

    チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
  • チケット駆動開発のFAQ - プログラマの思索

    チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD:チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱ExcelRedmineアジャイル開発を楽々管理 - @IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

    チケット駆動開発のFAQ - プログラマの思索
  • 1
Лучший частный хостинг