【お前のチケット】チーム開発でのチケット改善術【解読不能】 - seri::diary
Issue管理システムを使っている開発現場では同僚の書いたチケットに悩まされる以下の様な光景が良く見られます。 事例１「何の目的で作られたのか分からないチケット」 ソースレビューを振られたのでチケットを見てみたら、何を変更したいかは分かるけどこの変更がどういう意味があるのか分からないケース 担当者の対応 作業したメンバーの席まで歩いて行って 「ねーねーこれさー、何のために作ったの？」 「あーそれはですね、まず○○という話がありまして、それで…」 （背景から説明されて１５分経過） 事例２「ソースを全部読まないと何を変更したか分からないチケット」 ソースレビューを振られたのでチケットを見てみたら１０コミットぐらい入れてあるけどチケットの説明が簡素過ぎて何の仕様をどう変更したか（もしくは新規に作ったか）がソースの差分を全部読み込まないと分からないケース 担当者の対応 作業したメンバーの席まで歩い
Redmineを全員で使ったらカオスになった話
タスク管理のツールとしてオープンソースのRedmineを使っていた。エンジニアだけで使っているうちは特に問題はなかった。エンジニアが10数名、全員でも40人規模の会社なので全員の作業を見える化したいよねという話が上がって全員でRedmineを使い始めることになった。そして何が起きたか。 プロジェクトが乱立した エンジニアであれば「プロジェクト」は単位は大体想像がつくと思う。しかしながらツール上ではその単位でプロジェクトは作られなかった。「正規のプロジェクト」の小規模な機能追加であっても「○○対応プロジェクト」と銘打たれツール上にプロジェクトが作成された。 「〜対応プロジェクト」「〜導入プロジェクト」「〜検討プロジェクト」「〜プロジェクト」・・・どんな言葉にもプロジェクトを付ければ”プロジェクト”にできるんだということは新鮮ではあったし、勉強にもなった。（そもそも”プロジェクト”って何だ？）
定量的プロジェクト管理ツール - 情報処理推進機構：ソフトウェア・エンジニアリング
IT利用度がかつて無いほどに高まってきており、情報システムの障害による業務・サービスの停止や機能低下の社会的影響が深刻化しています。一方、ソフトウェア開発の短納期化・低コスト化はさらに進んできています。そのため、ソフトウェアの品質の確保や、納期の遵守のためには、検出不具合数や工数の進捗具合などプロジェクト進行過程において測定する定量的なデータを用いて品質や進捗の状況を適切に把握することで、リスクを可視化し、問題を早期に発見する定量的プロジェクト管理が求められています。 IPA/SECでは、主にプロジェクト・マネージャを対象に、ソフトウェア開発プロジェクトの定量的プロジェクト管理を支援する「定量的プロジェクト管理ツール（EPM-X）」を公開しています。 ソフトウェア開発プロジェクトの定量的管理を行うプロジェクト・マネージャを支援するため、進行中の開発プロジェクトからプロジェクトデータを取得し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
