Redmineのベストプラクティス
Redmineのプロジェクト管理プロセスでは、どのようなヒントと「標準」を使用していますか？
共有できる標準のWiki挿入テンプレート、またはバグ機能タスクとサポートの問題を使用してプロジェクトを操作する標準的な方法はありますか？
問題や更新をRedmineにメールで送信しますか？フォーラムを使用していますか？ SVNリポジトリを使用していますか？ EclipseでMylynを使用してタスクリストを操作していますか？
部署をドラッグしようとしています。いくつかのWebベースにPMあいまいな要件のメール送信されたWordドキュメントの代わりに、競合する更新とプロジェクトの山ですべてが失われるQAとデプロイの方法を説明するWordドキュメントが続きます。何かを修正する必要があり、それがどのように機能するかについてのドキュメントは誰も見つけることができません。
製造会社のファミリー向けの内部アプリケーションを開発および保守しています。このコメントの時点で、私はITチームの唯一の開発者/アナリストです。景気後退の最悪期に、私のプロジェクトの要求は爆発しました。そのため、私のプロジェクトと問題のバックログは非常に扱いにくいです。現在、チームを拡大するためのリストラを行っています。
Redmineを使用して、（可能な範囲で）頭を真っ直ぐに保ち、ユーザーを寄せ付けず、将来的に新しいスタッフがあまりにも多くの手を握らないようにする方法を紹介します。
- TortoiseSVNと適切な名前の Tortoise-Redmineプラグイン を使用して、ソース管理にSubversionを使用します。コミット後にRedmineプロジェクトのリポジトリを更新すると、問題がリンクされ、問題のリビジョンが表示され、電子メール通知で関係者が更新されます。
- プロジェクトの説明は、プロジェクトの目的、範囲、ライフサイクルの段階を関係のない人に伝える手段として扱います。そうすることで、ユーザーは自分の皿に何が入っているのか、遠くから目を光らせているビュッフェの何が残っているのかを知ることができます。
- 許可セットに特定のロール名を使用します。これは、文書化の手段として、複数の許可セットを示しています。私の役割は次のとおりです：プロジェクトマネージャー、プロジェクトチームメンバー、所有者、プライマリユーザー、セカンダリユーザー、オブザーバー、オーバーロード（上司...楽しく、間違いなく正しい）。
- WikiとDocumentsをドキュメントに使用しますが、どちらが適切だと思いますか。
- バージョンはほとんど役に立たないので、計画されたリリースに使用する代わりに、関連する問題をスプリントにグループ化するために使用します。
- Eric Davisの素晴らしいStuff-To-Doプラグインを使用して、前述のスプリントを整理/再整理してから、問題のターゲットバージョンを一括編集します。また、これにより、利害関係者は、自分が取り組んでいることや、利害関係をどのように優先したか（良くも悪くも）を知ることができます。
- ユーザーとの対話を促進するために、Redmineプロジェクトへのリンクをアプリケーションの[ヘルプ]メニューに追加しました。 [About]ボックスには、Redmineプロジェクトへのリンクも含まれています。
今後の計画
- Redmineとの統合のために、Visual Studioの拡張機能をいつか完成させたいと思っています。
- アプリケーションをRedmineプロジェクトと大まかに結合するコードライブラリを作成します。バグの送信の自動化、システムトレイからのサブスクライブする利害関係者への警告、RedmineのREST APIなどによって駆動される再利用可能な対話型ヘルプメニューWikiでのドキュメントの作成？）
私はフリーランスですRubyそしてRedmineウェブ開発者は1人の開発ビジネスを運営しています。したがって、私のRedmineは非常に軽量で顧客重視に設定されています。私のオープンソースプロジェクトをホストしています。
私は新しい問題や更新をメールで送信することを許可していますが、メールで接続しているユーザー（または常にiPhoneを使用しているユーザー）には最適です。
Gitリポジトリでリポジトリビューを使用してきましたが、うまく機能しています。すべてのチェックインで#nnnで問題を参照しているため、実際の問題ページには機能を実装するためのすべてのコミットが表示されます。
フォーラムは十分に活用されていません。メールの統合があればもっと便利だと思います。
次のプラクティスが役立つことがわかりました。
1）「問題」および「サポート」トラッカーを非表示にし、ファイルバグとしてのすべて：
- 開発者、テスター、管理者の時間節約。
- 一部のアクティビティが「追加」または「新機能」などとして請求される場合、それらを評価するためのクイックミーティングが手配されます。
2）これが大好きなマイルストーンとバージョン。各リリースのステータスを簡単に追跡でき、いつでも古いパッケージをダウンロードできます。つまり、クライアントが提出したバグをテストできます。
3）[問題]タブの[保存]機能：もう1つの大きな時間節約、多くの日常的なレポートタスク用に異なるクエリが保存されており、それだけで十分です。
4）バージョン管理の統合。つまり、コメントで「＃123」を使用すると、対応する問題へのリンクが作成されます。
Redmineはシステムで幅広く使用しています。営業チームがCRMとして使用する「販売」プロジェクトを設定しました。このプロジェクトにはカスタムフィールドのヒープがあり、以前使用していたSugarCRMを置き換えます。
システム内には、サーバーソフトウェアとクライアントソフトウェアのプロジェクトがあります。 Redmineはプロジェクトごとに別々のリポジトリを好むため、サーバープロジェクトは、システムとサブリポジトリをどのように構成したかに基づいて、サブモジュールに分割されます。
他の人が指摘しているように、チケットを参照するコミットメッセージでは#nnnコードを使用します。素晴らしいのは、同じプロジェクトのチケットである必要がないことです。したがって、販売チケットはバグの問題またはサポートリクエストによってブロックされる可能性があります。
会議の議題/議事録にドキュメントの使用を開始しました。クライアントとサーバーの両方で、バージョンを使用してリリースにグループ化します。
Redmine Time Trackerプラグインを使用して時間を追跡しようとしていますが、開始または終了をクリックすることを常に忘れています。しばらく触れられていない問題（Redmine Whining、私は思う）、および過去または近い将来に期限がある問題についてのメールを毎日受け取ります（Advanced Reminder）。
サポートメールはサポートプロジェクトに直接送られ、メールのインポートがもう少し堅牢な場合（Project：行がメールに含まれていると新しいチケットが適切に作成されない場合があります）、ウェブサイトの問い合わせで販売チケットが自動的に生成されます。現状では、サポートチケットを監視し、必要に応じてセールスに移動するだけです。
私ができることをしたいこと：
- チケットをシステム内のユーザーまたは会社に関連付けることができるように、システムとredmineの間に関係があります。また、関連するポイントで販売チケットから新しい会社を生成できるようにします。これには、いくつかの作業が必要です。
- サーバーエラーがredmineチケットを生成するように、エラー追跡ソフトウェア（sentry）とredmineの間に関係があります。繰り返しますが、現在の技術で解決可能です。
- デスクトップクライアントを再利用します。サーバーはLAN内にありますが、Webページ以外のデータにアクセスするためのより柔軟な方法を持つことができれば素晴らしいでしょう。 redmineのWebインターフェースで実際にできないことはありませんが、Things.appのようなものはsoで作業するのがはるかに良いです。
- すべてのサポートドキュメントをredmine内に置いて、公開サーバー上に生成します。そのようにして、サポートスタッフはドキュメントを維持し、素敵な方法で編集し、変更をdoc-serverに展開できます。
Redmineはこれまで私たちにとって素晴らしいものでした。マルチテナントチケット/アジャイル優先順位付けキューとして使用し、SVNにも関連付けています。特に：
- SVNを介したインストール/メンテナンスは非常に簡単です（
svn switch https//.../branches/1.3-stable .コマンドの後にrake migrateコマンドを使用して1.1から1.2から1.3から1.4に移行しました。 ）。 - データベースと保存されたファイルのバックアップは、1行のスクリプト実行です
- Time Tracker および Spent Time プラグインが大好きです。一部のオフィスユーザーのMac OS X時間追跡ファットクライアントを殺しますが、それはポイントの横にあります:)
- フォーラムはあまり使用しませんが、アクティビティとロードマップを頻繁に使用します。特定のバージョンに問題を結び付けることは天の恵みです。
- クライアント/サーバーの区別もありますが、作業中に区別するために、ターゲットバージョンを使用してチケットを結び付け、どこに行くか（およびオープンエンドのNEXT CLIENT RELEASE/NEXT SERVER RELEASEがある）を指定します。
- ステータスのメタファーを混合します-最初にこれらによってグループ化されたリストを使用します（「即時」、「拒否」、「ブロック」、「作業中」、「デッキ上」、「リスト」、「ビルド待ち」、「リリース済み」 「」、「確認済み」、「本番リリース」、「終了」、「キャンセル」）。
- 次に、上記の各グループ内に、この優先順位のソートされたリストがあります：（「即時」、「私を優先する」、「デザインとサイズを決める」、「P1」…「P5」、「P-ウォッチリスト」）。これに加えて上記により、すべての問題領域からの簡単なワークフローが可能になります。
- 基本的な問題のリストについては、「優先度」、「親タスク」、「更新日」の順にソートします。同じグループに子タスクがある場合にRedmineが適切にインデントできるように、真ん中のものが必要です。
- チェックインコミットを使用してコミットを問題に結び付けます（つまり、
svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns."）-そして、その問題を「Waiting For Build」に移動させます（以前は「解決済み」でしたが、「解決済み」と説明するのにうんざりしていました）誰かがまだリリースされるのを期待できるという意味ではありませんでした）。
Redmine-stuff-to-doプラグインを調査する必要があると思います。 +1質問。
私の会社は、国際的な起源のソフトウェアおよびハードウェア開発者と協力しています。私が入社する前は、MS Word文書で電子メールを使用して、ソフトウェアまたはハードウェアの問題やバグを中継して修正を要求していました。このプロセスは、あらゆる種類のプロセスを追跡および維持することは不可能でした。ソフトウェアとハードウェアのバグを追跡する手段としてRedMineを実装しましたが、それ以来非常にうまく機能しています。私の状況には大きな言葉の壁があります。ありがたいことにRedMineはSipmlified中国語で表示でき、フィードバックはこれまでのところ私の開発者からは問題ないことを示しています。
ステータス-ソフトウェアまたはハードウェアの問題を見つけた場合、ステータスは「新規」です-ソフトウェア/ハードウェア開発者がこの問題を確認し、作業中の場合、ステータスは「進行中」に変わります。 0〜50の場合は、％doneを使用できます。問題を解決したと感じたら、％Doneを50に設定します。 -問題が修正されたかどうかを確認し、Statusを「Resolved」に、％doneを100％に変更します。これにより、50％以下の問題を除外して、未解決の問題を見つけることができます。
優先度-低、標準、高、緊急、即時はすべて中国語に翻訳されます。
期限-これを使用して、修正がソフトウェア開発者によって最初にアップロードされた時期を通知します。何かをテストして問題を解決するには、4〜6日かかる場合があります。 Ganntチャートは、修正を承認するのにかかった時間ではなく、ソフトウェアチームの応答性を反映するのが好きです。
カテゴリ-これは常に、問題が見つかったソフトウェアまたはハードウェアのバージョンを反映しています。これを使用して、どのバージョンのソフトウェアに最も多くのバグがあったかを確認し、新しいバージョンのソフトウェアがリグレッションの影響を受けないようにします。
RedMineウォッチャーのリストには、すべてのバグが含まれています。メールは（新規）、（解決済み）、または（進行中）として届くので、私のスーパーバイザー、および関係するチームのスーパーバイザーとヘッドエンジニアはすべて、電子メールを見て、現在進行中の進捗をすばやく読むことができます。関係する他のほとんどの人は決してRedMineにログインしません。通常は私だけがログインします。電子メールは、進行中かどうかのみが懸念されるすべての人に即座に更新を提供するのに最適です。
あなたがあなたのQAでWord文書を前後に送ることについて述べたように-私はこの気持ちを知っています、そこにいた、それをしました。私にとっての主な問題は次のとおりです。QAの人々はバグトラッカーに問題を追加することを好まず、テスト中にその隣のエディターでそれらを書き留めます。
現在、NiceアドオンでRedmineを使用しています- sersnap （免責事項：この問題を自分で解決するためのツールを構築しました。
UsersnapはWeb開発者に最適です-Webプロジェクトに追加すると、使用中のブラウザー、オペレーティングシステムなどに関するメタ情報を含む、スクリーンショットがRedmineチケットに直接添付されます。
QA /顧客はバグをウェブアプリケーションに直接入力できるようになり、開発者はバグレポートをRedmineに簡単に再現できるようになりました。
他のコメントに加えて、「Stuff To Do」プラグインの使用をお勧めします（Eric Davisが書いたと思います:)このプラグインを使用すると、複数のプロジェクトにわたって課題の順序をドラッグアンドドロップでソートできます。
https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do
以下を表示する明確な方法として、ロードマップセクションを使用しています。
- 虫
- 機能（Word文書への参照、またはHTML要件ページへのリンク）
- 調整（生産値とテスト値の差）
- 等々...
それが私たちの統合の主要なポイントです。残りはそれに関連して使用されます（たとえば、 'announce'セクションは、ロードマップで使用される主要なマイルストーン/リリース日を定義するために使用されます）
スプリントを定義する方法としてバージョンを使用するため、各バージョンは、進行状況を明確に示すロードマップビューを備えたスプリントです。スプリントの問題は、完了時に「レビューの準備ができている」とマークされ、QAが確認したときにクローズされます。
範囲外の問題や優先度を失う問題のバックログとしてバージョンを使用します。
Redmineを使用してから約1年が経過し、さまざまな方法で独自に進化しました。バージョンを使用してリリースの問題をグループ化し、カテゴリを使用して分野ごとに問題をグループ化します。
各問題は、新規>進行中>解決済みのワークフローを通過します。その後、テスターは問題がなければ問題を解決します。
Redmineの使用方法を更新したいと思います。非常に多くの優れたプラグインがあるようですが、それらの多くは壊れているか、インストールされません。
開発者向けのドキュメントには、Wikiを包括的に使用しています。