web-dev-qa-db-ja.com

単一のプログラマとして課題追跡を使用する

これがtl; drの場合は、[質問]までスクロールします

これが重複しない理由:

リンクされた質問 は、バージョン管理(私が持っている)、1ステップのビルドスクリプト(私が持っている)、および「問題トラッカーをまったく持っている」(私は持っていますが、私は持っています)について話します最適化の問題)、その質問への答えのどれも私の質問のいずれにも答えません。

この質問は「最小のサブセット」についてではなく、特定の現実世界の状況における実際的な問題についてです。

バックグラウンド:

私の会社の唯一の開発者は5人です。私の同僚の1人だけが開発経験があり、彼はどの生産コードにも取り組んでいません。彼は私のボスですが、特定の問題の詳細には興味がありません。私の仕事は正直なところ、パートナーの1人(上司の上司)のサイドプロジェクトであり、会社はすでに私とは何の関係もないことから収益を得ています。このプロジェクトが実行可能であることを証明できるまで、彼は私にもっとリソースを与えることをためらっています。私がやると、彼は私にもっと多くのリソースを与えるつもりですが、それまではこれが私の状況です。

問題:

その結果、私のプロジェクト管理プラットフォーム(現在はRedmine)を使用するのは難しいと感じています。プログラマーやテスターさえあれば、素晴らしいコミュニケーションツールになると思います。ただし、私は開発作業の100%とテストの95%を行っているので、ケースを最新の状態に保ち、場合によっては作成することも、非常に時間のかかるように思えます。

ほとんどの場合、バグを見つけたらすぐに修正します。それが問題追跡に入る唯一の時間は、それが30分未満で修正およびテストできるものでない場合です。

唯一のプログラマーであるコードレビューはありません。ここで働く誰も私のredmineサーバーの使用に興味がありません。電子メールでバグレポートを受け取った場合、私は幸運です。通常、彼らは私のデスクに歩いて行き、私に伝えます-それはまれです。私は上司にサーバーを使用させ、多くのケースを監視させ、変更を加えたら上司にメールを送らせようとしましたが、彼は過去3.5か月間サーバーにログオンしていません。

Redmineを使用する前は、Wunderlistを使用していました。正直なところ、はるかに適しているようです。それは機能の観点からは明らかに劣っていましたが、それはうまくいきました-物事をはるかに迅速にメモすることができました。

注:ほとんどの場合、バージョン管理ルーチンに慣れています。これは、問題の追跡と非開発者とのコミュニケーションの詳細です。

質問:

これらの質問についてのご意見をお待ちしております。

  • 一人のプログラマーとして、redmineのようなフル機能の課題追跡システム、またはWunderlistやEvernoteのようなよりシンプルな個人組織システムを好みますか? -redmineなどを使用している場合、ほとんどの機能を使用していますか?
  • 過去に課題トラッカーを使用することにまったく興味がなかったあなたのボスに、それを使い始めるためのヒントはありますか?
  • 既存のコード(TDDで記述されていないコードを想定)をテストするときに、バグを見つけた場合、どのような状況で課題トラッカーに課題を追加しますか?
  • 私に関連すると思われるその他のアドバイス。
4
durron597

状況次第です。小さいままであるようにインデントされている小さなプロジェクトで作業している場合は、タスクリストを使用するとよいでしょう。 Wunderlistを使っています。典型的なプロジェクトは、「これをaからzに行う」アプローチに従うブログシステムの作成などです。

プロジェクトが大きくなると思う(または期待する)場合は、問題マネージャーまたはカンバンスタイルのボードを使用します。

過去にAtlassians Jiraを何度も使用していましたが、5人のチームで使用しても、完全に誇張されていました。このようなシステムは、カスタマイズするための多くのオプションがあるため、エンタープライズレベルで作業している場合に適していますが、小規模で俊敏なチームには適していません。

今日、私はTrello.comをタスク指向のものに使用しています。問題についてもです。これは私の現在のスーパーアジャイルチームではかなりうまくいきます。 Redmineではリリースバージョンを割り当てることができますが、1日に複数のリリースを作成することを決定したため、その機能は "多すぎる"ものになります。代わりに、カードを移動しながら移動し、非常に満足しています。

ツールはあなたに役立つ必要があり、その逆ではありません。私があなたの投稿から読んだものから、あなたは間違いなく簡単なものを使うべきです、また Trello.com を調べてください(非常に簡単で、無料で使用でき、タスクを監視するのに少し良いです)。

あなたの上司:仕事を整理する必要があると彼に伝えてください。たとえば、タスクのリストがある場合、集中できます。それがない場合は、毎日約30分間、何をする必要があるかを考える必要があります。お金は通常、ほとんどのボスを納得させるものです。

作成に関する問題:バグが見つかった場合(タイプミスと言ってください)、すぐに修正します。現在修正できないバグが見つかった場合は、問題を作成しています。バグが単純な修正で行われない場合、またはシステムの動作が大幅に変更されない場合、私も問題を作成します。その理由は、それを文書化してもらいたいからです。個人的にはアジャイルにしていますが、すべての手順を文書化する必要がない限り、時間を節約するためにそうするべきです。

その他のヒントはありますか?何が最善か、何がタスクに集中できるかを試してください。多くの課題トラッカーがあり、彼らはあなたに天国を約束します。しかし、それらのほとんどに問題があります。多くの機能を備えているため、多くの時間を消費します。私のビジョンは、それについて何も考えずに私をサポートするテイクを持つことです。前述のように、私のTrelloとWunderlistの組み合わせはうまく機能します。

4
Christian

私は、問題トラッカーに大きく依存しています。人々の立ち寄りを防ぎ、問題を説明するのに10分かかります。問題について何かする時間があれば、完全に忘れてしまいます。

彼らにそれを書き留めさせることにより、彼らは彼らが言いたいことを構成することができ、結果はより簡潔になる傾向があります。 1つの場所ですべての未解決の問題が発生します。また、自分の考えや進捗状況について簡単に注釈を付けることもできます。

あなたの主な問題はそれを設定することにあるようです。これは段階的に行うことができる場合があります。

ステージ1。上司が来たら、彼らが問題を説明するのを待ち、メモを取ります(可能な場合はコンピュータ上)。最後に、上司にリマインダーメールを送信してもらい、シャッフルで迷子にならないようにします。

ステージ2。上司がリマインダーメールの送信に使用されたら、上司にメールに概要を記載するよう依頼します。

ステージ3。彼らがあなたにそれを説明した後、彼らにメール全体の問題を書いてもらう

ステージ4。問題の説明を始めたらすぐに、問題全体をメールで送信します。

ステージ5問題全体をバグトラッカーに入れてもらいます。

それらに対する抵抗ができるだけ少ないことを確認してください。可能であれば、必要なフィールドがなく、ログインも不要なバグトラッカーを入手してください。問題を配置するための編集ボックスは1つだけです。特定のアドレスにメールでバグを追加できる場合は、さらに良いです!

ステージ2に到達できる場合は、メールを切り取ってバグトラッカーに貼り付けることができます。

2
AMADANON Inc.

それの音で、ツールはあなたのために働いていません。あなたの上司はそれを使用していないので、あなたがしていることは、データを供給するために貴重な時間を費やしているだけです。それなら、なぜそれを駐車して別のものを使用しないのですか?私自身クリスチャンのように自分でトレロを使っていたので、私もそれを完全に支持しています。すべてオンラインで、スマートフォンでも使用できます。意味のない大量のデータを入力する必要もありません-必要なものを入力するだけで完了です。

私が見ているあなたの仕事は、あなたが開発しているプロジェクトに興味を持ち、伝道者になることです。 OK、あなたは問題を見つけて修正していますが、なぜ上司はこれを気にする必要がありますか?

地元の人には言わないでください。TDDは、完成した/部分的に開発されたプロジェクトに後付けすることができます。一連のテストを作成するだけで、すぐに利用できます。もちろん、この方法ではそれほど有用ではありませんが、まだ確かに得られる価値があります。

何を追跡するかについて-それがタイプミスであるか、何かが画面上の適切な場所にない場合、私はこれらに注意を向ける傾向があります。同様に、あなただけが発見した問題で、簡単に修正できる場合は、修正してください。より複雑なものを追跡します。経験則として、上司からデモを依頼された場合、言及することが重要だと思う問題は何ですか。

1
Robbie Dee

問題は、問題追跡がワークフローの一部ではないようです。もしそうなら、あなたはどんな仕事でも成し遂げるためにそれを使う必要があるでしょう。

IMOの良い目標は、小さな問題または機能を分離し、トラッカーに入力してから、一致するブランチを作成することです。タイプミス、言語の変更など、すべての問題が発生してもかまわないという点で、以前の回答に同意しません。その問題の作成に時間がかかる場合は、ワークフローを改善して、問題の作成にかかる時間を短縮してください。 。

利点は、課題トラッカーだけではなく、トラッカーを使用してプロジェクトの方向性とワークフローを改善する方法にあります。

時々私は問題をタイプして「これは大きすぎるタスクのように聞こえます、私は本当にこれに取り組むつもりですか?多分私はこれをより小さいタスクに分解するべきです」または「私の説明はほとんど意味がありません、多分私はすべきですこれを調べて、コーディングする価値があるかどうかを確認してください。」また、自分の進捗状況を確認して評価することもできます。

多くの人は気にしませんが、それは上司よりもあなたとあなたの将来のチームのためです。上司は、それが医師の診療所にある患者ファイルフォルダーのような、ソフトウェアの開発の一部であることを知っている必要があるだけです。

課題追跡の統合の例:

ヒューボットとレッドマイン

SubとJira

1
FMJaguar