この投稿では、最も人気のあるバグ追跡システムBugZillaと、 Twins Web Studioでの実装と運用の成功についてお話したいと思います。 何らかの理由で、ハブでは、BagZilluが常に言及されています。 しかし、誰も彼女と詳細に立ち止まったことはありませんでした。 しかし、無駄に...
一見したところ、悪魔は足を骨折するようです。 しかし、このシステムで作業するとき、すべてが正しく明確に考え出されていることを理解します。 このシステムは非常に優れた機能を備えており、カスタマイズ可能で、Webプロジェクトの開発プロセスに簡単に統合できます。
前文
率直に言って、どうだったか...私はリーダーシップが私を打ち負かさないで、私を解雇しないことを望みます。 私は若くて経験のないプロジェクトマネージャーとして会社に来ました。 彼は生産プロセス全体を素早くマスターし、それに完全に統合しました。 彼はプロジェクトの管理を始めました。顧客のニーズを特定し、すべてをウェブの言語に翻訳し、開発者向けのタスクを策定しました。
会社は成長し、発展しました。 プロジェクトはますます複雑になりましたが、プロジェクトに取り組んでいる間の組織プロセスは変わりませんでした。 すべてが非常に簡単でした。すべてのタスクは口頭で設定されるか、電子メールリストでテクニカルディレクターに送信され、彼はすでにプログラマにタスクを再配布しました。 また、プロダクションが遠隔地にあるという事実（一部の開発者は別の都市にいた）により、テクニカルディレクターはタスクを再編成し、プログラマに直接送信しました。
その結果、次の問題が発生しました。
- 現在作業中の作業、実行されている作業、実行されている作業、実行されている作業についての真の理解はありませんでした。
- フィードバックを得ることは不可能でした。
- 突然病気になった人や辞めた人は、巨大な文字の鎖を復元して、作業中、何の段階で、何が行われたかを見つけなければなりませんでした。
- タスクの追加要件の調整と明確化のプロセスには長い時間がかかりました。
- 小さなタスクは、しばしば後ほど延期され、完全に忘れられました。
- 完了したタスクの検証も無効でした。 実装の結果は数時間でもたらされました。
- 調整や改善に加えられた変更の履歴をまとめることは、単に非現実的でした。
バグ追跡システムの選択
私たちが追求した目標：
- タスクのイニシエーター（マネージャーから最終的なエグゼキューター）への通過の連鎖を減らします。
- さらに、必要に応じて、すべての明確な問題は、エグゼキューターとタスクのイニシエーターの間で直接議論する必要があります
- いつでも、完了した進行中の作業のステータスに応じてカットを取得します
- すべての作業と改善を含む、プロジェクトの作業履歴を保存します
- プロジェクトの作業時間を制御する
- タスクの優先順位付け
- プロジェクトデータの分析
Bugzilaは当初、ソフトウェア開発とエラーロギングのために研ぎ澄まされました。 デフォルトのbugsilで受け入れられている名前の名前を変更し始めておらず、次のことがわかりました。
- 製品はプロジェクトです。
- セクション-プロジェクトが含まれます。 私たちはプロジェクトを論理的なグループに分けました：仕事中、完成、サポート中、プロモーション。
- コンポーネントはステージです：コンセプト、デザイン、レイアウト、プログラミング
- エラーはタスクまたはバグです。
- プロジェクトでエラーが発生するだけでなく、作業のタスクを設定するようになりました。設計、レイアウト、塗りつぶしなどのタスクです。 つまり すべてのワークフローはBugZillaにコミットされています
- 出演者のための時間管理システム。 タスク時間はBugZillaで修正されています。 毎月末に、勤務時間の削減が行われ、これを考慮して、賃金が計算されます（これは後で紹介されました）。
- 柔軟な方法論に従ってプロジェクトが開発されているクライアント向けのレポートシステム。 彼らはいつでもログインでき、何が行われているかを見ることができます。 新しいタスクを設定したり、優先順位を変更したり、特定のタスクで発生した質問に必要なコメントを加えたりします。
プロジェクトへのアクセス権の差別化
システムの実装は、いくつかの段階で行われました。
- 限られた数の従業員の間でのシステムの実装と対話のデバッグ
- 生産プロセスのすべての段階でのすべての従業員の関与
- サードパーティの開発者とクライアントのシステムへのアクセス
そして、ステージ3について、またサードパーティの開発者、マネージャー、クライアントが使用できるようにバギーを適切に設定する方法について説明します。 しかし同時に、サードパーティの開発者がプロジェクトで既に設定されたエラーを確認することを禁止し、会社のプロジェクトにまったくアクセスできないようにします。
長い間、私たちは社内でのみバグトラッカーを使用しており、プロジェクトへのアクセス権の差別化については考えていませんでした。 新しいプロジェクトと新しいユーザーを開始できる管理者がいました。 また、タスクを設定し、編集し、実装のステータスを記録できるユーザーがいました。
バギーは主にオープンソースプロジェクトのサポートに使用されるため、デフォルトでは明示的に禁止されていないものが許可されるという原則にデフォルト設定されています（つまり、デフォルト設定はそのように構成されています）。 つまり 新しいタスクまたはプロジェクトを作成すると、自動的にすべての人に表示されます。
次の2つの主なタスクに直面しました。
- 作成済みのプロジェクトとタスクへのアクセスを区別します。
- 新しいプロジェクトを作成するときに、システムにログインしているすべてのユーザーへのアクセスを自動的にブロックします。 管理者は、このプロジェクトを誰が利用できるかを選択できます。
作成済みのプロジェクトに対する権利の差別化：
- デザイン開発があるため、新しいプロジェクトごとに、対応する製品がバグトラッカーに導入されます。
- プロジェクトごとに、プロジェクトの名前に一致するグループを作成しました。 これは、「管理」->「グループ」-「グループの作成」セクションで行います。
- 各プロジェクトのプロパティで、アクセスを構成します（「管理」->「製品」->製品を選択->「グループごとのアクセス権」）
- 製品のグループへのアクセスを公開します。 作成されたグループのメンバーのみがこのプロジェクトのエラーにアクセスできるように、図に示すようにパラメーターを設定します：「グループ」->「有効」、「その他」->「禁止」。 他のグループについては、「Forbidden」、「Forbidden」を配置します。
- 「管理」->「ユーザー」セクションの適切なユーザーに必要なユーザーを選択し、「グループに含まれる」という名前のグループの列で、対応するグループ（プロジェクト）、ユーザーに表示されるすべてのタスクを割り当てます。
- また、検索でアクセスが拒否されたすべての製品がユーザーに表示されないようにします。 これを行うには、システム設定で「管理」->「システム設定」->「グループアクセス権」セクション->「useentrygroupdefault」パラメータが「オン」として選択されていることを確認します。
- ここで、以前にプロジェクトに関連する間違いを犯し、適切なグループに連絡して、appropriate索好きな目からそれらを閉じる必要があります。
-検索に移動します
-製品を選択してください
-すべてのエラーを選択します（新規、クローズ、完了など）
-グループ編集を選択
-すべて選択
-最後に、[このグループにエラーを追加]を選択します-プロジェクト用に作成されたグループの名前
-保存
ちなみに、各プログラマーまたはデザイナーが作業するプロジェクトグループを毎回割り当てる必要はありません。 実行者としてタスクが彼に設定されていない場合、このプロジェクトの特定のタスクが表示されます。
これを行うには、システム設定で「管理」->「システム設定」->「グループ権限」セクション->「strict_isolation」パラメータが「オフ」に選択されていることを確認する必要があります。互いのタスク、マネージャーにはプロジェクトの全体像が表示されます。
では、新しいプロジェクトを作成し、それらによって作成されたエラー/タスクをデフォルトで誰もアクセスできないようにする方法を見てみましょう。
- システム設定「管理」で設定->「システム設定」->「グループアクセス権」セクション->「makeproductgroups」パラメータが「オン」として選択されている
- これで、新しい製品を作成すると、その製品用のグループが自動的に作成されます。
- 以上です。 これで、このプロジェクトのエラーを作成するときに、このプロジェクトのグループが割り当てられているユーザーのみがエラーを利用できるようになります。
おわりに
そして2.5年後、BugZillaを支持する決定は正しかったと言えます。 現在、このシステムがなければ、マネージャーも開発者自身もクライアントもできません。 現在では、プロジェクトで作業する際の主要なツールの1つです。 いつでも、選択した開発者のスライスを作成して、彼が自分の作品に何を持っているかを確認できます。 したがって、開発者のロードと問題解決の優先順位を計画するため。
オレグ・デミャノフ
ウェブ開発責任者
双子