チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
納期が延びる要因を指標化する － スケジュールのDRAGとはどんな尺度か | タイム・コンサルタントの日誌から
久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。 いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の６つの作業項目（アクティビティ）のみからなると考える。 1. 基本設計 （推定所要期間＝20日） 2.1 ハード調達 （推定所要期間＝35日） 先行作業：基本設計 2.2 設置調整 （推定所要期間＝ 5日） 先行作業：ハード調達 3.1 詳細設計 （推定所要期間＝10日） 先行作業：基本設計 3.2 ソフト開発 （推定所要期間＝20日） 先行作業：詳細設計 4. 総合テスト （推定所要期間＝15日） 先行作業：設置調整、ソフト開発 さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネッ
ＷＢＳのつくり方 | タイム・コンサルタントの日誌から
ＷＢＳは、「仕事のＢＯＭ」である。私は最近、そう説明することにしている。プロジェクトという、始まりと終わりがある仕事の全体像を表現するには、それを構成している仕事の部分品ひとつひとつに分解して、どういう構成になっているかを示すのが一番分かりやすい。それがＷＢＳである、と。 ＷＢＳはWork Breakdown Structureの略である。プロジェクト・マネジメントで使う用語だ。このWorkという英語はいささか多義語で、仕事（人の作業）のこともさすが、加工対象物（モノ）のことをも意味する。そのせいかどうかしらないが、ＷＢＳの作り方には従来、二通りの考えがあった。 まず、ＷＢＳは人の作業の構成表である、とする考え方がある。システム開発プロジェクトという仕事は、「要求分析」「設計」「実装」「テスト」「移行作業」などとブレークダウンしていく。「設計」はさらに「基本設計」「詳細設計」「実装設計」に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
