「Redmineの情報のサイロ化を解決したい」問題がGoogleGroupにアップされていた。 その議論が興味深かったのでメモ。 【元ネタ】 情報のサイロ化を解決したい - Google グループ nanego/redmine_multiprojects_issue 【1】問題 (引用開始) Redmine便利に使っていますが、困っているのが情報のサイロ化です。 他PJに情報(チケット)を横展開する場合、コピーすることになると思いますが、どうもかゆいところに手が届かい感じがしています。 横展開するPJが1つか2つなら手作業でコピーできなくもありませんが、3を超えると忘れ（サボ）られがちです。 1つのチケットを一度に複数のPJへコピーする方法（プラグイン）、または情報のサイロ化を防ぐ手段、ツール、運用方法とあればご教授頂きたいです。 (引用終了) 問題の発端としては、あるチケットが他の複数の

Redmineなどのチケット管理ツールをタスク管理ではなくインシデント管理で運用する場合、従来の手法ではうまくいかない場合が多いし、そのような経験をたくさんしてきた。 思ったことをラフなメモ書き。 【1】例えば、自社でAmazonや楽天のようなショッピングカートのWebシステムを持っているとしよう。 すると、新しい機能を追加していく開発チームと、Webシステムのインフラ構築やインフラ周りの監視に関わる保守チームの2つのチームが自然に体制として現れる。 システムは自動車などの製品とは違って、リリースした後、ユーザに使われてからが本当の本番だ。 何故なら、システムが稼働して初めて、ショッピングカートにクレジット決済などで現金が入り、売上が上がっていくからだ。 システムが使われていくと、ショッピングカートの動きがおかしい、ここのユーザインターフェイスが使いづらい、404エラーが出た、突然画面に接

いろんな議論が出てきた。 皆同じような問題を持っているのね、と共感している人も多かった。 僕が興味を引いたのは、顧客との打合せ管理にRedmineを使っている人の話。 顧客との打合せや会議の準備で、タスク管理と工数管理をチケット管理で実施している。 トラッカー＝顧客単位でチケットを発行し、全て打合せや会議の工数を記録し、月末に工数集計して顧客報告して請求するという流れ。 実績工数の作業分類にも、打合せの作業の種類に分けて、実績工数に色付けして入力・集計しているらしい。 この事例は、RedmineをCRMソフトとして使おうという発想であり、更に工数集計ツールとしても使おうとしている。 このアイデアは、第8回勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索にも書いたけれど、顧客問合せ(つまり、コールセンターやサポートデスクの管理)の管理

「業務ロジックをデータモデリングはどこまで表現できるか？」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日本におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model

Redmineによるチケット駆動開発、タスクボードやバーンダウンチャートによる運用事例を見つけたのでメモ。 僕は、以下の事例のように、実際の現場で試行錯誤しながら自分たちの運用を見つけていくボトムアップのやり方が好きだ。 パターン言語の発想に通じるものがある。 【元ネタ】 ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第一回） ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第二回） ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第三回） ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第四回） ASE アドヴァンスト・ソフト・エンジ

RedmineのER図を作る方法が公開されていたのでメモ。 【元ネタ】 redmineのER図を生成してみた | ぷろぐらま Railsのテーブル名や主キーは、CoCで厳格なルールがあるおかげで可読性も高い。 だから、Redmineもこれだけの頻繁なVerUp、豊富な機能改善が可能だったのだろうと思う。 Railsの最大の特徴である「サロゲートキーの重視」については、渡辺さんが下記の記事を書かれている。 「強制されたサロゲートキー」の事例を眺める: 設計者の発言 複合キーをなくしサロゲートキーに統一する手法では、ER図に親子関係が発生せず、全ては外部キーによる参照関係になる。 多分、普通のRails開発では、テーブル間のリレーションシップはアプリケーション層で実装するだろう。 つまり、DBMSでリレーションを貼ることはしないので、テーブルは入れ物にすぎない。 DOAの立場の人がサロゲートキ

Twitterを眺めていたら、Redmine運用の感想が目を引いたのでメモ。 【元ネタ1】 Twitter / @polo_kwsk: Redmineが優秀すぎる・・・普通にソフト会社に開発させたらウン千万取られるところだ・・・PJ管理インシデント管理その他もろもろ使えるいいオープンソースソフトやでぇ。社畜SEさんにもおすすめ。 Twitter / @Sean_SF: そういうのってホントにあるんだなぁ? RT @sonoyu670 あるお客さんのところでは「それredmineでええやん」という使い勝手の悪い独自のPJ管理システムを持ってて、これウン千万とかかけて作ったんだろうな、馬鹿だな、って思ってた。 フリーのBTSがまだ普及していない頃、障害管理やタスク管理の重要性に気づいた会社は独自でBTSやITSを作り込んでいた。 そういう会社は先見の明があったに違いない。 だが、長年使ってくる

チケット駆動開発の適用範囲について考えたことをメモ。 【元ネタ】 チケット駆動開発の適用範囲: プログラマの思索 Twitter / @akipii: チケット駆動開発にはいくつかのパターンがある。タスクカードのように扱うタスク駆動が一番やりやすい。システム運用保守やコールセンターはインシデント駆動。システム提案や要件定義なら課題駆動。 Twitter / @akipii: チケット駆動開発では僕は課題駆動が一番難しいかもと最近思う。SEは顧客から本質的な問題を見つけるために課題を何度もぶつけて探す。設計書は課題の回答をパッチのように更新して出来上がる。ソースと同じだ Twitter / @akipii: チケット駆動開発はバグ管理からアジャイル開発へ発展した手法だ。チケット駆動開発をうまく運用できてないチームはバグ管理の基本から見直した方がいい。BTSの一つ一つの機能には今までの世界中の

@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine @daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を@sakaba37さんと読みながら、自分が理解してなかった点がたくさんあることが分かった。 気付いたことをメモ書き。 間違っていたら後で直す。 【shinagawa.redmineの講演資料】 【1】SVNリポジトリのスケールアップ チケット駆動開発の特徴は、ITSにSCM連携の機能があることで、トレーサビリティやソース変更履歴を即座に確認できる利点がある。 しかし、5人ぐらいの小規模開発チームから数百人以上の大規模な組織で運用する場合、SVNリポジトリがダウンしてしまうケースが出てくる。 そもそもRedmineのようなOSSのITSでは、大規模な運

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

Redmine・Trac・Mantisでチケット駆動開発を実践してみて、技術的に一番面白いのは、ツールの連携によるトレーサビリティの強化であり、その拡張だ。 この考え方は「ソフトウェア構成管理とはそもそも何なのか？」という問題に行き着くと思う。 以下ラフなメモ書き。 【1】チケット駆動開発の基本的な運用ルールは「No Ticket, No Commit!」だ。 実際の運用方法は、SVNやGit、Mercurialのコミットログに「refs #チケットNo」「fixes #チケットNo」を付けてcommitすると、自動的にチケットとリビジョンが相互リンクするやり方。 この運用ルールは、障害管理において、障害報告票に基づいてどのようにソースが修正されたのかをレビューしたり検証したり、リリース後に確認できるようにしたい発想から生まれた。 この単純な運用ルールこそが、従来のAgile開発には無かっ

Redmineを運用してみると、トラッカーの概念が分からないという声をよく聞く。 トラッカーについて考えたことをメモ。 ラフなメモ書き。 【1】Redmineのトラッカーはワークフローそのもの。 Redmineのトラッカー管理画面で、ロール単位にステータスのデシジョンマトリクスで自由に設定できる。 デフォルトのトラッカーは「機能」「バグ」「サポート」の3つだが、実際の運用では使いづらい場面があるので、各現場で独特のトラッカーがあるだろうと思う。 個人的には、一人一人の運用ユーザに一番聞いてみたい内容だ。 トラッカーが難しいのは、ワークフローを意識していないからだろうと思う。 ソフトウェア開発の作業は、チケットを一人で担当して終わらせるだけではない。 バグ修正やリリース作業では、必ず複数人のチェックを入れなければ、作業ミスが重大な過失につながる。 だから、それら作業はワークフローに複数人の担

2005年に書かれた@ITの記事を読んで、この記事に書かれている内容は全てRedmine＋チケット駆動開発で実現できると直感したのでメモ。 【元ネタ】 ＠IT：意外と知らない構成管理の正体（1）第1回 ファイルバージョンの管理だけで十分ですか？ ＠IT：意外と知らない構成管理の正体（2）第2回 プロジェクトの構成要素を探す手順 ＠IT：意外と知らない構成管理の正体（3）変更管理、その正体と対策 ＠IT：意外と知らない構成管理の正体（4）構成管理とプロジェクトマネジメントの関係 構成管理は誰のためのものなのか？: プログラマの思索 (引用開始) ただ、プロジェクトは、最後にきちんと納品さえすればよいというものではないのです。いつでも、指定された時点におけるプロジェクトの結果、状態を把握できなければいけないということなのです。そこには、タスクの依存関係、成果物の依存関係、それぞれに要したコスト

Redmineを初めて使う管理者が陥りやすいアンチパターンを見つけたのでメモ。 【元ネタ】 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 TiDD初心者が陥りやすい罠～マイルストーンの役割を誰も理解していない: プログラマの思索 Twitter / @cointoss: アジャイルの導入に二の足を踏む現場において、チケット駆動開発(=TiDD)であれば受け入れやすい理由は、プラクティスが少なく実践的なものに絞っているからだろう。リリース予定をバージョンとすることでイテレーションやスプリントが定義できるため、そこだけはアジャイルっぽくはなる。 【1】僕がRedmineを設定する場合、あらかじめヒヤリングした後にプロジェクト設定画面でカテゴリ・バージョンは登録している。 全てのチームがアジャイル開発に慣れているわけではないので、あらかじめ対象バー

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

TiDD初心者が陥りやすいアンチパターンを更に見つけたのでメモ。 【参考】 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 【1】WF型開発のプロマネとしてバリバリ腕を鳴らしている人がRedmineでタスク管理を運用していると、共通した特徴がある。 それは、工程単位にRedmineプロジェクトやRedmineバージョンを割り当てていること。 例えば、プロマネが1個のプロジェクトだけを抱えているなら、Redmineプロジェクトは1個だけだが、Redmineバージョンを設計、開発、テスト障害、本番障害のように工程単位にアサインしている。 大規模プロジェクトで、プロマネが複数チームをマネジメントしているなら、Redmineプロジェクトを課題、設計、開発、テスト障害、本番障害のように工程単位

メールでRedmineチケットを登録する機能の可能性について考えたことをメモ。 【2016/3/5 更新】 @netazoneさんのおかげで、現在も動作するThunderbirdのアドオンを見つけられました。 Redmine連携 :: Add-ons for Thunderbird ThunderbirdとOutlookのRedmineアドオン: プログラマの思索 【元ネタ】 Thunderbirdで受信したメールをRedmineのチケットとして登録できる「Quick Ticket to Redmine」 | Redmine.JP Blog メールによるチケットの登録 | Redmine.JP Email-ext plugin - hudson - Hudson Wiki RedmineとHudsonやTestLinkを連携させるプラグイン: プログラマの思索 Hinemos＋Redmin

最近、上流工程のモデリング技術として、DOAを見直している。 その過程で、忘れ去られた日本のIT技術とその歴史があるように感じた。 考えたことをラフにメモ。 【DOA(Data Oriented Analysis)】 DOAはデータモデリングというモデリング技法、上流工程の設計技術の一つ。 DOAは日本独自で発展してきた歴史がある。 椿正明さんのTHモデル。 佐藤正美さんのT字形ER。 渡辺幸三さんの渡辺式DOA。 THモデルは古くは1970年代から発展してきたようだ。 他のDOAも、日本で、メインフレーム上の業務システムを開発する経験から育まれてきた。 歴史があるからこそ、DOAを知れば知るほどノウハウがある。 例えば、エンティティにはリソースとイベントの2種類がある。 イベントには必ずタイムスタンプ（日付）が振られて、業務の流れに従ってイベントが変わる。 リソースとイベントの個数を比較

興味深いTwitterがあったのでメモ。 【元ネタ】 Twitter / kashisan: 最近行った #Redmine を使いこなせてチームに対するアドバイス。「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」、「各トラッカーのステータスがどういう状況を表すか定義する」「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」 Redmineを有効に運用出来ていないチームに対するポイントは3点ある。 １・「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」 ２・「各トラッカーのステータスがどういう状況を表すか定義する」 ３・「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」 ポイント1は、チケットファーストの原則。 プロジェクトにある全ての作業はチケットから始まる。 そのためには、チケットは成果物単位、つまりWB

リンク先から下記の記事を見つけたので、考えたことをメモ。 【元ネタ】 こんにちは。 ソフトウェアの不具合管理をしているのですが、現在はエクセルファイルを複数社で メール添付で行っています。 この方法だと、 ・どれが最新かわからなくなる.. - 人力検索はてな 不具合管理(障害管理)はソフトウェア開発の中で最も重要で、そしてコントロールが難しいマネジメントだ。 ウォーターフォール型開発で設計、開発、単体テストと順調に進んでも、結合テストや受入テストに入ると、バグが多発してしまって品質がボロボロになってしまうケースは数多い。 ソフトウェア開発が製造業など他の産業の工程と異なる箇所は、結合テスト以降の障害管理だと思う。 各種のモジュールを初めて結合して、インターフェイスが違っていたり、仕様通り作っていても性能が出なかったりする症状が分かる。 いわゆるビッグバン結合で頻発する。 上記の質問を読むと