「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
ゲーム業界のプロジェクトマネジメントの資料 - プログラマの思索
スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がとても良かったのでリンクしておく。 【元ネタ】 スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がスゴイ！ at ミネルヴァの梟は黄昏とともに飛び始める 【1】ゲーム業界のソフトウェア開発案件を元にしているが、仕様・納期・人員・品質などの要素が当初見積りよりもわずかに増えるだけで、実績工数が10倍以上に膨れ上がることを簡単な例で説明している。 更に、10倍に膨れ上がった工数は、仕様を減らし、納期を延ばし、人員を大量投入し、品質を落とし、更に開発者の労働時間を80％増やせば帳尻が合うという話から、簡単にデスマーチに陥ると説明しているのが分かりやすい。 実際は簡単なモデルでは説明できないだろうが、感覚的にはフィットする。 プロジェクトがデスマーチに陥るきっかけは、各要素の些細なギャップから生まれる。 それ
工数見積もりで陥りやすい罠 - プログラマの思索
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
Scrumの見積りと計画づくりは何故優れているのか？ - プログラマの思索
「ソフトウェア見積り」を読みながら、「アジャイルな見積りと計画づくり」「アジャイルサムライ」に書かれている見積り技法が何となく理解できてきた気がするのでメモ。 ラフなメモ書き。 間違っていたら後で直す。 【1】Scrumの見積りは、規模見積り(ストーリーポイント)と工数見積もり(理想時間・理想日)の2種類がある。 初期のスプリント計画では、ストーリーカードに対して、規模見積りをまず行う。 その時、ストーリーポイントの単位で、フィボナッチ数列の数値で相対比較する。 そして、更に実作業であるタスクカードへ分割する場合、各タスクは理想時間、つまり割込みがなく集中して作業できる最短工数を見積る。 スプリントを実施してリリース後、実際の実工数や作業期間が確定する。 つまり、初期のスプリント計画で見積もった規模見積りに対して、納品したストーリーポイント数、実際に作業した実績工数、納品までにかかった期間
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
