Redmine プロジェクト管理プロセスで使用するヒントと「標準」は何ですか?
共有できる標準の wiki 挿入テンプレート、またはバグ機能タスクとサポートの問題を使用してプロジェクトを作業する標準的な方法はありますか?
問題や更新を Redmine にメールで送信できますか? フォーラムを利用していますか？SVN リポジトリを使用していますか? Eclipse で Mylyn を使用してタスク リストを処理していますか?
私は私たちの部門をドラッグしようとしています。あいまいな要件の Word ドキュメントを電子メールで送信し、それに続いて QA と展開の方法を説明する Word ドキュメントを Web ベースの PM に送信する代わりに、競合する更新プログラムやプロジェクトの山の中ですべてが失われるため、何かを修正する必要があるときまでに誰も見つけることができません。それがどのように機能するかに関するドキュメント。
一連の製造会社の社内アプリケーションを開発および保守しています。このコメントの時点で、私は IT チームの唯一の開発者/アナリストです。不況の最悪の時期に、私のプロジェクトの需要は爆発的に増加しました。そのため、私のプロジェクトと問題のバックログは非常に扱いにくいものです。現在、チームを拡大するためのリストラを進めています。
Redmine を使用して頭を真っ直ぐにし (可能な範囲で)、ユーザーを寄せ付けず、うまくいけば、将来的に新しいスタッフが過度に手を握るのを防ぐ方法を次に示します。
今後の計画
私はフリーランスの Ruby と Redmine の Web 開発者であり、1 つ (私) の開発ビジネスを実行しています。したがって、私の Redmine は、かなり軽量で顧客中心になるようにセットアップされています。私の Redmine は、私のオープン ソース プロジェクトをホストするという二重の役割も果たします。
私は新しい問題と更新をメールで送信できるようにしています。メールに接続しているユーザー (または常に iPhone を使用しているユーザー) には最適です。
私はgitリポジトリでリポジトリビューを使用してきましたが、うまく機能しています。チェックインのたびに #nnn でイシューを参照するので、実際の問題ページには機能を実装するためのすべてのコミットが表示されます。
フォーラムが十分に活用されていないことがわかりました。電子メールの統合があれば、もっと便利になると思います。
次のプラクティスが有用であることがわかりました。
1) 「Issue」および「Support」トラッカーを非表示にし、すべてをバグとしてファイルします。
2) マイルストーンとバージョン これは気に入っています。各リリースのステータスを簡単に追跡でき、いつでも古いパッケージをダウンロードして、クライアントが提出したバグをテストできます。
3) 「課題」タブの「保存」機能: もう 1 つの大きな時間節約機能です。日々のレポート タスク用にさまざまなクエリを保存しており、必要なのはそれだけです。
4) バージョン管理の統合。つまり、コメントで「#123」を使用すると、対応する課題へのリンクが作成されます。
システムでは Redmine を広く使用しています。営業チームが CRM として使用する「営業」プロジェクトも設定しました。このプロジェクトには大量のカスタム フィールドがあり、以前使用していた SugarCRM を置き換えます。
システム内には、サーバー ソフトウェアとクライアント ソフトウェアのプロジェクトがあります。サーバープロジェクトは、システムとサブリポジトリをどのように構築したかに基づいて、サブモジュールに分割されます。これは、Redmine がプロジェクトごとに個別のリポジトリを好むためです。
他の人が指摘しているように、チケットを参照するためにコミット メッセージで #nnn コードを使用します。すばらしいのは、同じプロジェクトのチケットである必要がないことです。したがって、販売チケットは、バグの問題またはサポート リクエストによってブロックされる可能性があります。
会議の議題/議事録に Documents を使用し始めたばかりです。バージョンを使用して、クライアントとサーバーの両方でリリースをグループ化します。
Redmine Time Tracker プラグインを使用して時間を追跡しようとしていますが、開始または終了をクリックするのをいつも忘れています。しばらく触れられていない問題 (Redmine Whining だと思います) や、期限が過去または近い将来にある問題 (Advanced Reminder) に関するメールを毎日受け取ります。
サポート メールはサポート プロジェクトに直接送られます。メールのインポートがもう少し堅牢であれば (Project: 行がメールに含まれていると、新しいチケットが適切に作成されない場合があります)、Web サイトからの問い合わせでセールス チケットが自動的に生成されるようにします。 . 現状では、サポート チケットを監視し、該当する場合はセールスに移動するだけです。
私ができるようにしたいこと：
これまでのところ、Redmine は私たちにとって素晴らしいものでした。マルチテナント チケット/アジャイル優先順位付けキューとして使用し、SVN にも関連付けています。特に：
svn switch https//.../branches/1.3-stable .SVN を介したインストール/メンテナンスは簡単でした (コマンドを使用して 1.1 から 1.2 へ、1.3 から 1.4 へ、rake migrateその間に必要な gem のインストールのみでコマンドを実行することで移行しました)。svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") に関連付けます。その問題を「ビルドを待機中」に移動させます (これは以前は「解決済み」でしたが、「解決済み」は誰かができるという意味ではないことを説明するのにうんざりしました)。まだリリースされていないことを期待してください）。ただし、Redmine-stuff-to-do プラグインを調査する必要があると思います。+1 質問。
私の会社は、国際的な起源のソフトウェアおよびハードウェア開発者と協力しています。私が入社する前は、MS Wordドキュメントで電子メールを使用して、ソフトウェアまたはハードウェアの問題やバグを中継し、修正を要求していました。このプロセスは、あらゆる種類のプロセスを追跡および維持することは不可能でした。ソフトウェアとハードウェアのバグを追跡する手段としてRedMineを実装しましたが、それ以来非常にうまく機能しています。私の状況には大きな言語の壁があります。ありがたいことに、RedMineはSipmlified中国語で表示でき、フィードバックによると、これは私の開発者からはこれまでのところ問題ありません。
ステータス-ソフトウェアまたはハードウェアの問題を見つけた場合、ステータスは「新規」です-ソフトウェア/ハードウェア開発者がこの問題を確認して作業している場合、ステータスは「進行中」に変わります。必要に応じて、0〜50の範囲で％doneを使用できます。問題が解決したと感じたら、％Doneを50に設定します。-問題が修正されたかどうかを判断し、ステータスを「解決済み」に変更し、％完了を100％に変更します。これにより、50％以下の問題を除外して、まだ開いている問題を見つけることができます。
優先度-低、通常、高、緊急、即時すべてが中国語にうまく変換されます。
期日-これを使用して、修正がソフトウェア開発者によって最初にアップロードされた日時を知らせます。何かをテストして問題を解決するのに4〜6日かかる場合があります。修正を承認するのにかかった時間ではなく、ソフトウェアチームの応答性を反映するガントチャートが好きです。
カテゴリ-これは、問題を見つけたソフトウェアまたはハードウェアのバージョンを常に反映しています。これを使用して、どのバージョンのソフトウェアに最も多くのバグがあったかを確認し、新しいバージョンのソフトウェアがリグレッションの影響を受けないようにします。
私はすべてのバグについてRedMineウォッチャーリストに全員を含めています。電子メールは（新規）、（解決済み）、または（進行中）として送信されるため、上司、および関係するチームのスーパーバイザーとヘッドエンジニアはすべて電子メールを確認し、現在進行中の進捗状況をすばやく読み取ることができます。関係する他のほとんどの人はRedMineにログインすることはありません。通常、私だけです。電子メールは、進歩が行われているかどうかだけが懸念されるすべての人に即座に更新を提供するのに最適です。
QA で Word 文書をやり取りすることについて言及されたように、私はこの気持ちを知っています。私にとっての主な問題は次のとおりです。QA 担当者はバグトラッカーに問題を追加することを好みません。テスト中に横にあるエディターにメモを書き留めます。
私たちは現在、Redmine を便利なアドオンであるUsersnapとともに使用しています (免責事項: この問題を解決するためのツールを自分たちで作成しました。
Usersnap は Web 開発者に最適です。Web プロジェクトに追加すると、Redmine チケットに直接添付されたスクリーンショットを取得できます。これには、使用されているブラウザー、オペレーティング システムなどに関するメタ情報が含まれます。
QA/顧客は Web アプリケーションに直接バグを入力できるようになり、開発者はバグ レポートを Redmine に簡単に再現できるようになりました。
他のコメントに加えて、「Stuff To Do」プラグインの使用をお勧めします (Eric Davis によって書かれたと思います:) そのプラグインを使用すると、複数のプロジェクト間で問題の順序をドラッグ アンド ドロップで並べ替えることができます。
https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do
以下を表示するための明確な方法として、ロードマップ セクションを使用しています。
それが私たちにとっての統合の主なポイントです。残りはそれに関連して使用されます (たとえば、「発表」セクションは、ロードマップで使用される主要なマイルストーン/リリース日を定義するために使用されます)
スプリントを定義する方法としてバージョンを使用するため、各バージョンは、進行状況を明確に示すロードマップ ビューを備えたスプリントです。スプリントの課題は、完了すると「レビューの準備完了」としてマークされ、QA が検証されるとクローズされます。
バージョンは、範囲外の問題や優先度を失った問題のバックログとして使用します。
Redmine を使用して約 1 年になりますが、Redmine はさまざまな点で独自の進化を遂げています。バージョンを使用してリリースの問題をグループ化し、カテゴリを使用して問題を分野ごとにグループ化します。
各問題は、新規 > 進行中 > 解決済みのワークフローを通過します。その後、テスターは満足したら問題をクローズします。
Redmine の使用方法を更新したいと考えています。すばらしいプラグインがたくさんあるようですが、それらの多くが壊れているか、インストールできないことがわかりました。
私たちは、開発者向けドキュメントとして wiki を包括的に使用しています。