初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ - プログラマの思索
初中級プロマネがIPAデータ白書の統計情報をどんな観点で活用できるか、説明した利用事例がとても良かった。 理解できた内容をラフなメモ。 【参考】 初中級プロマネのための 現場で活かせ！統計情報１ 初中級プロマネのための 現場で活かせ！統計情報２ 「ソフトウェア開発分析データ集2020」の発行：IPA 独立行政法人 情報処理推進機構 「ソフトウェア開発データ白書」のダウンロード：IPA 独立行政法人 情報処理推進機構 初中級プロマネのための現場で活かせ！統計情報 2019年4月19日| CITP Community CITPアニュアルレポート2018を公開しました | CITP Community 【0】「ソフトウェア開発分析データ集2020」をIPAデータ白書と呼ぶことにする。 【1】IPAのソフトウェア開発データ白書を使いたい動機は2つある。 1つ目は、プロマネとしてシステムの企画書や
Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索
Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。 以下、ラフなメモ書き。 【参考】 Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索 ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索 チケット管理システムは作業の構成管理と同じ: プログラマの思索 【1】以前、下記のツイートがあった。 最初はRedmineでチケット管理して上手く回っていたのに、ガントチャートで厳しく管理し始めたら、内容が空っぽのチケットが大量発生して、チケット駆動でなくなった、というアンチパターン。 【1-1】 akipiiさんのツイート: "ガントチャートは
アジャイル開発とウォーターフォール型開発の違いについて再考 - プログラマの思索
「カイゼンジャーニー」を一気に読んだ後で、もう一度、アジャイル開発とは何なのか、現時点で考えを整理しておく。 自分の中の暗黙知を整理するのにとても役立ったので、下記の記事をリンクしておく。 特に主張なし。 【１】アジャイル開発では「個人のパフォーマンスで駆動」されるので、チームワークや心理的安全を重視する。 一方、WF型開発では、プロジェクトの成功を「組織の力で担保」する。 となると、先日の冬季オリンピックで、日本女子がパシュートで金メダルを取った事例を振り返ると、日本人は組織の力を重視する方が好きなのか？ ならば、個人のパフォーマンスで駆動する開発プロセスを志向するアジャイル開発は、日本人の文化とは本来合わないものなのか？ アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート (引用開始) このプロジェクトでは“本物”の「スクラム」を実施し
第9回東京Redmine勉強会の感想 #redmineT - プログラマの思索
第9回東京Redmine勉強会の感想をメモ。 【参考】 第9回勉強会 - redmine.tokyo 参加者は80名と過去最高の人数、そして渋谷dotsという素晴らしい会場のおかげで、内容の濃いRedmineの議論ができたと思います。 手作りのクッキーやコーヒーなども協賛のおかげで参加者に配布でき、リラックスした雰囲気で議論できたかなと思います。 勉強会の講演やオープンディスカッションで気づいたことはいくつかある。 【1】チケットに書かれた情報は管理情報とは異なる、という@sakaba37さんの指摘。 チケットには、開発チームで必要な情報が記載されているので、必ずしも管理上必要な情報が書かれているとは限らない。 例えば、障害の症状や解決方法、問合せの内容とその対応の経緯などは、作業者が必要だから記録しておく。 しかし、その作業の実績工数、対応時間などの情報、あるいは障害管理に必要な区分や種
【事前公開】【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ #redmineT - プログラマの思索
【事前公開】【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ #redmineT 第7回redmine.tokyo勉強会で予定している講演資料を事前に公開します。 勉強会のオープンディスカッションの元ネタになるので、参加される方は事前に読んで頂いて、自分なりの意見を持参してくれると嬉しいです。 【元ネタ】 第7回勉強会 - redmine.tokyo 第7回redmine.tokyo勉強会 - PARTAKE 【1】議題にしたいテーマ 第7回redmine.tokyo勉強会のテーマは「Redmineのアンチパターン集」です。 披露するアンチパターンは、私が過去6年、Redmineをいろんな現場で導入して運用した時、こうやればもっとうまくできたのに、と後で気づいたノウハウです。 おそらく他の人も同じように頷いてくれるアンチパター
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？ - プログラマの思索
チケット駆動開発を運用していると話すと、必ず「チケットの粒度はどれくらいが妥当ですか？」という質問が来る。 僕はまだその質問に完全な回答は持っていない。 その質問について考えていることをメモ。 【1】RedmineやTracで、全てのタスクからQAまでチケットを起票してから作業を始めるようにすると、チケットの粒度がかなり細かくなってしまう。 粒度が小さいと作業しやすいが、チケットの完了速度よりもチケットの登録速度が上回ってしまう時が多いため、どんどんタスクが増えていってしまうような感覚に陥ってしまう。 かと言って、チケットの工数が5人日以上になってしまうと、進捗がはかどっているのかどうかも分からない。 チケットの粒度が問題になる状況は、顧客へ進捗報告を出したい時だ。 RedmineやTracによるチケット管理はあくまでも開発者のためのタスク管理が目的だから、粒度が細かすぎて、顧客から見れば
CCPMの考え方 - プログラマの思索
CCPM（Critical Chain Project Management：クリティカル・チェーン・プロジェクト・マネジメント）の解説記事があったのでリンクをメモ。 【元ネタ】 CCPM とは：梅田弘之のプロジェクトマネジメント講座：【第６章】大型プロジェクトにはCCPMを取り入れよう サルでもわかるTOC/CCPM(第五回)｜ザ・プロジェクトマネジャーズ TOC流の開発型プロジェクト管理術「CCPM」（1）：なぜプロジェクトの進行計画はいつも壊れるの？ 「クリティカルチェーン・プロジェクトマネジメント」とは (1/3) - MONOist（モノイスト） TOC流の開発型プロジェクト管理術「CCPM」（2）：PDCAサイクルに潜むプロジェクト管理の問題点 (1/3) - MONOist（モノイスト） TOC流の開発型プロジェクト管理術「CCPM」（3）：TOCのPMが本当に管理すべきポイ
ソフトウェア開発の「新」3種の神器 - プログラマの思索
ソフトウェア開発の「新」3種の神器に関する記事を見つけたのでメモ。 日経Systems2013年6月号に掲載されている。 【元ネタ】 記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro 記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro 記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro 【1】興味深いのは、アンケート結果では、「「Microsoft Project」（MS Project）で48.7％、2位はオープンソースソフトウエア（OSS）の「Redmine」で40.4％、3位も同じくOSSの「Wiki」で32.4％だった」こと。 他に、TracやTFSも上位に上がっている。 日本でRedmineの人気は高いのが意外だった。 Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP B
【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 #47redmine - プログラマの思索
【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 #47redmine 本日行われた第4回品川Redmine勉強会の発表資料をCCアトリビューションライセンスで公開します。 スタッフの皆さん、参加者の皆さん、お疲れ様でした。 第4回shinagawa.redmine勉強会 : ATND 今僕が考えている「チケット駆動開発をパターン言語で表現できるか」という問題に対して、勉強会のお題「チケットの粒度」「チケットの完了条件」について当てはめると、どれだけ本質に迫れるか、考えた結果を話しました。 内容は完成版でないし、解法は一つではないです。 オープンディスカッションの前座として、どれだけ皆の議論を引き出せるか、という観点で話しました。 オープンディスカッションでは7チームで議論してもらった結果、白熱したチームもあれば、違
Jenkinsでプロジェクトの状況をウォッチするRedmineMetricsPlugin - プログラマの思索
Jenkinsでプロジェクトの状況をウォッチするRedmineMetricsPluginが公開されていたのでメモ。 【元ネタ】 Jenkinsでプロジェクトの状況をウォッチする - mitoma_ryoの日記 mitoma/redmine-metrics-plugin RedmineMetricsPluginはJenkinsのプラグインで、Redmineのチケット情報を元にバージョン単位にステータスごとのチケット推移を表示してくれるらしい。 このプラグインを有効活用するには、バージョンをフィーチャないしビジネス要求単位に作る方がグラフが意味あるものになるだろう。 似たようなメトリクスとしてパーキングロットチャートがある。 パーキングロットチャートはバージョンをビジネス要求に対応付けて、バージョン単位にざっくり集計したメトリクスを出してくれる。 それに対して、RedmineMetricsPl
Redmineチケットの階層化の実装方法 - プログラマの思索
Redmineチケットのテーブルissuesテーブルにlft, rgtというカラムがVer1.0からあって、何に使うのか分かっていなかったが、下記の記事を読んでようやく理解した。 ラフなメモ書き。 【元ネタ】 【Redmine】issuesテーブルのlft・rgtって？ | Roppi.net SQLアタマアカデミー：第5回 SQLで木構造を扱う～入れ子集合モデル （1）入れ子集合モデルとは何か ｜gihyo.jp … 技術評論社 SQLアタマアカデミー：第5回 SQLで木構造を扱う～入れ子集合モデル （2）入れ子集合モデルにおける検索 ｜gihyo.jp … 技術評論社 SQLアタマアカデミー：第5回 SQLで木構造を扱う～入れ子集合モデル （3）入れ子集合モデルにおける更新 ｜gihyo.jp … 技術評論社 SQLアタマアカデミー：第6回 SQLで木構造を扱う～入れ子区間モデル （1
SCMコミットログはファイルのメタ情報 - プログラマの思索
バージョン管理ツールがCVS、Subversion、MercurialやGitへ進化するに連れて、構成管理の意味合いが変化しているのに気付いた。 考えたことをメモ。 【元ネタ】 Twitter / @akipii: 良い記事。僕もPrivateファイルはMercurialで管理している。コメントや履歴のようなファイルのメタ情報はコミットログで保持すべき。重要ファイルはSubversionで管理する - Basic 重要ファイルはSubversionで管理する - Basic SVNのコミットログの書き方: プログラマの思索 TortoiseSVNの差分機能は素晴らしい: プログラマの思索 TortoiseSVNからBTSと連携する: プログラマの思索 TortoiseHgはSVNクライアントとしても優秀: プログラマの思索 TortoiseHgからBTSチケットへリンクできるようになった:
チケット駆動開発がもたらした新しい観点part3～トラッカーの考え方 - プログラマの思索
Redmineを運用してみると、トラッカーの概念が分からないという声をよく聞く。 トラッカーについて考えたことをメモ。 ラフなメモ書き。 【1】Redmineのトラッカーはワークフローそのもの。 Redmineのトラッカー管理画面で、ロール単位にステータスのデシジョンマトリクスで自由に設定できる。 デフォルトのトラッカーは「機能」「バグ」「サポート」の3つだが、実際の運用では使いづらい場面があるので、各現場で独特のトラッカーがあるだろうと思う。 個人的には、一人一人の運用ユーザに一番聞いてみたい内容だ。 トラッカーが難しいのは、ワークフローを意識していないからだろうと思う。 ソフトウェア開発の作業は、チケットを一人で担当して終わらせるだけではない。 バグ修正やリリース作業では、必ず複数人のチェックを入れなければ、作業ミスが重大な過失につながる。 だから、それら作業はワークフローに複数人の担
チケット駆動開発の適用範囲 - プログラマの思索
日本のSI企業がチケット駆動開発について記事を書かれていたのでメモ。 以下ラフなメモ書き。 【元ネタ】 「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL 補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索 [#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば ユーザの力を利用するアジャイル開発: プログラマの思索 チケット駆動開発の戦略: プログラマの思索 僕はチケット駆動開発がどこまで知名度が上がっているのか、正直知らない。 でも、チケット駆動開発のアイデアをアジャイル開発だけでなく、従来のWF型開発にも適用すればその恩恵が受けられるのではないか、という意見は、既に@sakaba37さんたちが色々試されている。 チケット駆動開発をWF型開発に適用する場合、「チケット
Redmineの唯一の弱点～工数管理 - プログラマの思索
僕は、Redmineは現在、世界中で一番優れたBTSだと思っている。 何と言ってもプロジェクト管理機能が強力で、このおかげでチケット管理を更に活用できる。 しかし、唯一の弱点があると思う。 それは、工数管理。 Redmineチケットには、予定工数と実績工数を入力できる。 その実績工数は、レポート欄でログ検索のように検索できる。 しかし、使い勝手は正直悪い。 実績工数を単に表示するだけでは面白くないからだ。 また、Redmineの実績工数には作業分類という属性があり、デフォルトでは「デザイン作業」「開発作業」がある。 これは、Redmineでは作業トラッキング(タイムトラッキング)と呼ばれている。 つまり、実績工数を更新するたびに、実績工数を色づけできるから、後で、作業分類ごとに工数集計できる。 しかし、この作業分類を上手に使って集計する機能がない。 結局、MySQLへ直接SQLを発行して、
工数見積もりで陥りやすい罠 - プログラマの思索
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ～BTSから始まる進化の歴史」 #devlove0917 - プログラマの思索
【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ～BTSから始まる進化の歴史」 #devlove0917 DevLove関西は2009年にも開催されていましたが僕は参加できませんでした。 ですが、下記のBlogからその情熱は感じ取りました。 だから、僕自身も無意識に熱くなっていたのかもしれません。 DevLOVE関西に心を込めて花束を - fkino diary(2009-09-26) DevLoveは情熱的なコミュニティと知ってましたが、今日のDevLove関西も懇親会(渾身会と呼ぶらしい)も、高校生の文化祭や高校野球みたいなノリノリの雰囲気でした。 楽しかったです。 肝心の発表は50分枠だったので余裕で話せるだろうと思ったのですが、1時間近く話しても言い足りなかった。 よしうみさんから、今日のあきぴーさんは1.5倍速でしたよ、と言われてしまった(笑) 上記の資
WF型開発にとらわれすぎたTiDDのアンチパターン #tidd - プログラマの思索
チケット駆動開発を運用してみて、悪いWF型開発のアンチパターンを頻繁に見かける。 考えたことをメモ。 【1】WF型開発がうまくいっているプロジェクトは、手戻り作業をできるだけ減らすように、前工程の品質チェックに力を入れる。 過去の経験値が生きる場合、いわゆるフロントローディングのやり方は有効に作用する。 しかし、僕はWF型の開発スタイルで上手くいった経験はあまりない。 ソフトウェア開発では、技術革新のスピードが早いため、過去の経験値が有効に作用せず、試行錯誤する回数がとても多い。 WF型開発が前提とする手戻り作業を減らす手法は、あまりにも綺麗過ぎる。 試行錯誤やリスクをあまりにも恐れている気がする。 Redmine・Trac・Mantisでチケット駆動開発をやってみると、リリースに至るまでの作業はいつも初めての問題にぶつかって試行錯誤して、どのイテレーションでも同じようにはならない。 チケ
チケットの粒度と進捗ビューの関係 - プログラマの思索
チケットの粒度と進捗ビューの関係について、考えたことをメモ。 【元ネタ】 TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？: プログラマの思索 【1】チケットの粒度はどれくらいが妥当か？という質問はよく聞く。 RedmineやTrac、Mantisで色々試行錯誤した結果、気にせず登録した方がいい、という回答にしている。 その代わり、トラッカー(ワークフロー)単位では粒度を揃えて、ビューによる切り替えを上手く使えばいい、と回答することにしている。 前者の回答は、チケット駆動開発を運用した場合、チケットはタスク、要望、課題、問合せなど色んな種類があるので、そもそも観点が異なるし、粒度を揃えること自体が無意味だからだ。 開発者の観点では、チケットの粒度を揃えて綺麗にチケットを書くよりも、成果物を早く作るための作業記録代わりにみなした方がいい。 Agile開発な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
