やっぱり事例だよねということで、自分とこの事例をまとめてみる。 お仕事の概要 規模 => 当初の見積もりは900時間。ただし、途中で2割くらい減った。 期間 => 2ヶ月 メンバー => 3~4名。自分込み。 2〜3名が設計書作成、自分はレビュアーとして参加しつつ雑務。 概要設計に先立ち、要件定義は完了。30項目ほど。 滝。 Redmineの設定など 「概要設計」をバージョンとして作成。 30項目の要件をチケットとして登録。 ターゲットバージョン => 「概要設計」 開始日 => 登録したその日 期限日 => 概要設計完了予定日の2w前 予定工数 => それぞれの見積もり値を設定 担当者 => 設定しない ユーザの権限は全て「管理者」。 5名程度なら問題ないんじゃないの? チケットのフロー 新規 -> 担当 -> 作成済 -> レビュー済 -> 完了 運用方法 タスクの割り振り それぞれが
Hudsonの下記記事を読んだ感想をメモ書き。 【元ネタ】 Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記 近年、HadoopやSeleniumなど、複数のサーバ上で動作する事が前提のツールが増えてきており、マルチコア化・クラウド絡みで、このトレンドは今後も続くと予想されます。 ところが、こういったツールはセットアップと運用保守に手間がかかるという欠点があります。 Hudsonで僕がやろうと思っている事の一つは、Hudsonのクラスタ上にこういったツールをインストールするのを簡単にすることです。 Hudsonのクラスタはインストールがとても簡単ですし、プラグインのインストールも容易なので、この環境の上に他のツールをオーバーレイすることで、手間なく様々なツールを利用できるようになります。 「ThoughtWorksアンソロ
チケット駆動開発(TiDD)について考えていることを書く。 ※注意:チケット駆動開発(Ticket Driven Develpment)の略語は、「TDD」だとテスト駆動開発(Test Driven Develpment)と間違えやすいので、「TiDD」と以降呼ぶことにする。(命名者:えと~さん) 【元ネタ】 チケット駆動開発は、まちゅさんによって提唱されている。 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) 【1】チケット駆動開発のプラクティス チケット駆動開発は定義そのものがあやふやなのだが、僕は下記4個ののプラクティスがあると思う。 ※注意・下記のプラクティスはあくまでも僕個人の考えであることを断っておく。 【1-1】チケット・ファースト(Ticket First) プロジェクト内部の作業は、チケットを受け取ってから始まる。 つまり、工数が発生す
プロジェクト管理は何のためにあるのだろうか。それはプロジェクトを円滑に進めるためにある。決して上司を納得させるためでも、クライアントに良い顔をするためのものでもない。開発工程を含め、全体の進行状況を管理するために存在するのだ。 ダッシュボード。奇麗なインタフェースだ そう考えるとあまりに多機能なプロジェクト管理はその運用コストばかりかかってしまう。使い勝手の良い、それでいて必要十分な機能を備えたプロジェクト管理を使おう。 今回紹介するオープンソース・ソフトウェアは9arrows、Ruby on Rails製の使い勝手の良いプロジェクト管理システムだ。 9arrowsはRuby on Rails製で、Webベースのプロジェクト管理システムだ。Ajaxを効果的に使って、スムーズで使い勝手の良い作りになっている。WBSを使ってタスクを分割し、担当者や日程を決めることで見栄えのいいガントチャートも
プロジェクト管理はオンラインの情報だけで学べるものではないとは思いますが、情報がなくならないようにメモしておきます。 ■プロジェクト管理 プロジェクトマネジメント入門:ITpro プロジェクトマネジメント連載記事インデックス プロジェクトマネジメントの理論と実践:ITpro 計画部分を重視したプロジェクトマネジメント連載記事インデックス プロマネ最強マニュアル---目次:ITpro プロジェクトの火消し方法解説記事インデックス プロジェクト・マネージャの「やってはいけない」---目次:ITpro プロジェクトマネジメントアンチパターン解説記事インデックス なぜプロジェクトは失敗するのか インデックス - @IT自分戦略研究所 プロジェクト失敗理由の連載記事インデックス EnterpriseZine:コーナー:実務で役立つプロジェクトレビューの心得 リスク管理などのプロジェクト管理解説記事イ
【1】下記の記事を読んで、Redmineによるチケット駆動開発はアジャイル開発の実装なのだ!と改めて認識して震えた。 下記の記事はスクラムの話なので、Redmineによるチケット駆動開発と直接関係ないけれど、考えたことを書く。 #あくまでも感想。 塹壕より Scrum と XP ◆Scrum and XP from the Trenches v.2.2 日本語訳(PDF)ダウンロード 1.Scrumのスプリント計画はRedmineのロードマップと同じ。 どのスプリントにどのストーリーを入れるか、という話は、どのバージョンにどのチケットを入れるか、という視点に置き換えられる。 XPならイテレーション計画に相当するだろう。 2.チケットの取捨選択の基準は、スコープ、重要度、見積の三角形だ。 品質を下げることは許さない。 お客はスコープ、重要度の決定権がある。 開発者は見積の決定権がある。 品質
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く