小さな開発チームのワークフローを自動化する（パート2）

以前の出版物で、私たちの組織の仕事に必要な製品とその設定のリストを説明しました。



この記事では、開発チーム全体の日常業務でこれをどのように使用するかを説明します。



4年間にわたり、開発チーム向けに次の形式を開発しました。

• 1プロジェクトマネージャー、別名プロダクトマネージャー、別名デリバリーマネージャー。
• 4〜5人のプログラマ
• 1チームリーダー
• 3-4 QA
• 1アナリスト
• 1 Techpeace（彼は一人のアナリストでもある場合があります）。

その結果、チームの規模は約10〜11人です。 このようなチーム（セル）がいくつかあります。



具体的かつ詳細な声明がない場合、作業は主にスタートアップのスタイルです。 非常に多くの場合、「でも試してみて、何が起こるか見てみましょう」や「素晴らしい仕事をしましたが、今ではすべてが完全に異なっている必要があります。」

長年にわたり、私たちの作品のコンセプトは一言で表現できます。これは「コンセプトの急速な変化」です。

このような状況では、さまざまな方法論を適用することができなかったことは明らかです。



私はこのシステムをプログラマーとして始め、チームリーダーとして、そして今はPM（DM）として始めました。 つまり 私はリードし、デザインに完全に参加し、時にはおしっこもします。 プログラミングの時点で、ワークフローの自動化に関するすべてのアイデアをサポートしてくれた素晴らしいPM（テスターのネイティブ）がいました。 それ以上に、このプロセスは概念的に彼女によって発明され、私はすでにいくつかの場所でそれを技術的に実装し改善することができました。

ポイントに行きましょう。

以前にJiraとSVNのみを使用して作業したため、

1. つまり、顧客や上級管理職からタスクを受け取りました。
2. PMはJIRAで特定のタスクを作成しました。
3. プログラマーが実行し、SVNにアップロードし、テストのためにJIRAにプッシュしました。
4. テスターはリードにビルドをビルドするように依頼しました。
5. 新しいビルドをダウンロードし、タスクをテストしましょう。
6. ポイント3で再び悪いもの、クローズドで良いもの。
7. バージョンの最後に、tehpisは発生したすべてのことを説明しました。
8. リードはすべてを集めて、インストーラーを準備しました。
9. PMはパッケージ化され、顧客に引き渡されました。

困難な試行錯誤の後、3年後、次のプロセスに進みました。

問題の声明

すべてのタスクは、上級管理職とのミーティングの後、または顧客からの希望の後に表示されるか、自分で何かを考え出します（またはバグを見つけます）。



タスクが単音節でない場合は、PM、チームリーダー、QAリード、アナリストのミニミーティングが開催されます。 何をどのように開発するかを議論し、理解した後、通常はすぐにそれを論理的に完了した小さなタスクに分割し（プログラマーの初日以下）、実装の時間枠を概算します（上級管理職の計画の場合）。



アナリストは座って、思慮深くConfluenceで声明を発表します。 その後、この声明は首相と合意され、必要に応じて上級管理職と合意されます。



次に、このステートメントに基づいて、Jiraでタスクが作成されます。

多くの場合、タスクはすぐにJiraに表示され、Confluenceでステージをバイパスします。



Jiraに表示されるタスクは、すぐに「タスク設定」ステップに進みます。 この段階では、次のようなデータ：

• タスクのタイプ（新機能、機能の変更、エラー、技術的作業、ドキュメント）
• バージョン（通常は開発中）
• コンポーネント（例：admin、interface、home、finance、reporting ...）
• タスクの説明

設定の段階では、タスクはその作者にあり、他の誰もそれを見ず、それについても知りません。

著者が問題のステートメントを最終的に定式化するとすぐに、彼はそれをワークフローの次の（可能な場合のみ）ステップ-ステートメントの改訂にプッシュします。

生産改訂

この手順に進むと、Jiraトリガーは重要なタスクを自動的にPMに変更します。

このステップは、PMがタスクの説明を読み直し、作成者がステートメントを正しく理解し、プログラマーにタスクを正しく説明したことを確認するためのものです。 非常に多くの場合、理解不足のため、タスクは最後まで実行およびテストされ、リリース中にのみ、本来必要だったものがまったくなかったことは明らかです。



また、このステップで、PMはこのタスクを実装するかどうかを決定します。 または、このバージョンで実装する必要があるかどうか。



この段階では、ワークフローに2つのオプションがあります。ステートメントに戻る（説明の調整）か、作業に進むかです。



また、このステップでは、責任あるチームリーダーを指名し、彼自身がアーティストを決定するようにします。

仕事を待っています

このステップを選択するとき、エグゼキューター、「プログラマー」フィールド、および予定時間を指定する必要がある画面を設定します。



このステップはプログラマのタスクプールであり、優先度フィールドで指定された順序で、または優先度が同じ場合は任意の都合の良い順序でバージョンごとに実行する必要があります。



あるバージョンの作業中に、このリストが頻繁に更新されることがあります。

仕事中

「To work」ボタンをクリックすると、タスクは「At work」状態になり、「Automated Log Work for JIRA」プラグインのおかげで、時間ロギングカウンターが自動的に開始され、タスクが他のステータスに転送されると現在の値を停止および維持します。 このステップでは、プログラマは次のことができます。

• 仕事の一時停止（仕事を待っています）;
• コード改訂時;
• 生産の監査について（何をする必要があるか、またはこの生産での実装に技術的な障害があるかどうかはわかりませんでした）
• テスト用（再現できませんでした）。

FishEye + Crucible + Bitbucket + Jira bunchが機能するためには、プログラマーはコミット時にコメントでタスク番号（PRJ-343）を指定する必要があります。



チームでは、ボタンを右に移動したり、緑色を緑色にしたりするなどの小さな編集を行うことで、すぐにアセンブリを実行できることに同意しています。 それ以外の場合-コードの改訂には必須。



そのため、コードを修正するタスクを残し、同時にチームリーダーを割り当てます。

コード修正

このステップで、Jiraの開発の特別セクションのチームリーダーは、プログラマーが特定のコミットを行ったことを確認し、特別なボタン「コードレビュー」をクリックします。







Crucibleをクリックすると、自動的に開き、指定したコミット（または複数のコミット）のレビューが作成されます。

ティムリッドは、プログラマーがルールとそれに応じて差分を管理するファイルのツリーを見ることができます。 コードの任意の行またはリビジョンの一般的なコメントを残すことができます。 るつぼでは、プログラマーのドライブの重要度を指定することもできます。



他の誰かのグアノコードを学習する苦痛の後、チームリーダーはタスクをビルドステップにプッシュするか、作業を見越してプログラマに返します。



この場合、プログラマーは開発セクションでコードレビューとそのステータスを確認します。 このCode Reviewに切り替えると、Crucibleが再び開き、プログラマーは自分が設定した場所を正確に確認できます。



「組み立て待ち」ステップに移行するとき、チームリーダーは、特別なフィールドに示されている責任者、または記入されていない場合はQAリーダーを選択します。

組立待ち

共通のテストサーバーが1つあるため、スケジュールされたアセンブリは適切ではありません。 テスト中にサイトを置き換えることはできません。



したがって、通常、テスターは私たちに同意し、誰も反対していない場合は、リソースの最新バージョンを収集します。

彼らはジェンキンスでこれを行います。 プロジェクトごとに3つのアセンブリを作成しました。テスト用のアセンブリ、開発用のアセンブリ、データベースのアセンブリです。



ソースアセンブリでは、次のアルゴリズムが構成されています。

1. Gitから新鮮なソースを引き出します。
2. それらをFTPにコピーします。
3. 「アセンブリの待機」ステップでJiraのすべてのタスクを見つけて、テスト待ちに転送します。
4. 手紙を送ります。

データベースアセンブリではすべてが同じですが、ステップ3の代わりに、サーバーでsshコマンドを使用して次が実行されます。

3.1。 データベースへのすべての接続を切断します。

3.2。 データベースを削除します。

3.3。 以前のバージョンのデータベースを復元します。

3.4。 新しいバージョンのすべてのスクリプトをスクロールします。

テスターが変更されたsqlファイル内のスクリプトを確認した場合にのみ、データベースを収集することはほとんどありません。

保留中のテスト

このステップでは、すでにテスト中だったタスクがあるかもしれませんが、おそらく初めてかもしれません。 タスクがすでにテストにあった場合、チームリーダーはタスクを仕事に戻したテスターの責任を負います。

それ以外の場合、すべてのタスクはQAリードに蓄積されます。 彼はタスクプールと各テスターの負荷を見て、テストにタスクを割り当てるユーザーを決定します。 さらに、ペアテストのテスターをすぐに決定します。

テスト中

このステップから、タスクをワークフローのほぼすべてのステップに転送できます。 テスターは次のことができます。

• ステートメントにタスクを返します（PMが今必要かどうか、またはテスト中に見つかったものを修正する必要があるかどうかを判断します）。
• 待機中のプログラマーに戻ります。
• ReadMeの説明を送信します（そして技術tepisに割り当てます）。
• ペアテストのためにプッシュする（そして適切なテスターに​​割り当てる）
• 機能の改訂版に移行します（PMは自動的に割り当てられます）。

「At Work」ステップと同様に、このステップではタイムカウンターが自動的に開始され、作業に費やされた時間を記録します。

保留中のテスト

このステップは、いくつかの理由で考案されました。 多くの人はその便宜を理解していませんでしたが、結局、しばらくしてから、それが必要であることに同意しました。



その本質は、タスクのメインテスターがあり、あらゆる種類の側面からタスクを非常に深く集中的に選択するという事実と、最初のテストが完了した後にのみ表面的にタスクを調べるペアのテスターがあるという事実にあります。 これは、プログラマーによるコード改訂に非常に似ています。



その結果、この機能またはその機能の配置方法を知っているのは1人のテスターだけではないという事実がわかります。 プログラマーとテスターの間でタスクが10回行われた場合、ペアのテスターの見た目は何かが足りないことに気付くかもしれません。 最も重要なことは、各テスターが独自の方法で動作し、特定の方法でソフトウェアを使用することに慣れていることです（マウスを使用せずにログインする、ドラッグアンドドロップを使用してファイルをアップロードする、フィルターの代わりに並べ替えを使用する、データを入力するときにテキストをコピーして貼り付けるなど）。 同じ機能をさまざまな方法で使用できることがよくあり、ペアのテスターはメインでチェックされたエラーにつまずきますが、独自の方法で少しです。

ペアテスト

このステップで、通常、タスクがほぼ完了しているとすでに仮定できる場合。 そして、非常に頻繁に、彼らがバージョンをリリースするために急ぐとき、それは正式に完了することができます。

Readme

テストが成功すると、機能とその実装が最終的に決定されます。 そして現在、技術的なタスクがこのタスクに従事しています。 通常、非常に重要ではないタスクまたはバージョンの作業中に自分自身で中断したタスクを除くすべてのタスクは、「ReadMe」とマークされます。



ペアのテスターがこのタグを見つけた場合、タスクを「ReadMe」ステップに送信し、技術者に割り当てます。

特別なフィールドの技術的な説明では、このタスクのリリースノートについて簡単に説明しています。 通常、これは、機能の変更やバグ修正、または新しい機能の外観とその使用方法に関するユーザーへの通知です。



同じステップで、techpecはConfluenceのリソースヘルプを修正または補足します。

作業が完了すると、タスクは最終機能「機能の改訂」に進みます。

機能改訂

タスクがこのステップに移動すると、Jiraが自動的に責任者としてPMを割り当てます。

このステップで、PMはチーム全体の作業をチェックします。 彼らが望んでいたものが、彼らが望んだとおりに実装されたかどうか、説明がReadMeで正常かどうかなど。



このステップで、プログラマーとテスターが自分たちの間で何かを決定し、「不要な機能」を切断または変更したことが判明しました。この機能は上級管理職とこの形式で必要でした。 その後、タスクは再び「作業待ち」に進みます。



このステップの価値は、優れたPMまたはDMが、「何をしましたか？」というフレーズで顧客をリリースして呼び出した後、タスクの実装方法、ボタンの名前、メッセージテキスト、アルゴリズムのニュアンスを正確に把握し、「愚か者自身」と大胆に答えることです。 ためらうことなく推測しますが、どのようにしてそのフォームを作り、その中にあるボタンを...

閉店

さて、ここではすべてが明確です。 機能が正常に改訂されると、タスクは閉じられます。

または、このステップへの移行は他のステップから可能であるため、タスクはいつでも誰にとっても不要であることが判明する場合があります。

作業台

便宜上、Jiraは4つのガジェットを使用して各プロジェクトのデスクトップを開発しました。

1. 私の仕事はどこにでもあります。 これはすべてのワークフローステップのリストであり、各ステップの反対側のタスクの数を示しています。ここでは、プログラマーまたはテスターとしてマークされています。 つまり このガジェットを見ると、現在テスト、開発、または策定中のタスクの数がすぐにわかります。 タスクのおおよその範囲を理解できます。
   
   
   
   
   
   
2. 私には責任があります。 私のソリューションを待っているタスクのリスト。 私がそれらを処理するまで、他の誰も自宅でそれらを見ることができません。
   
   
3. 各タスクの数。 開発チーム全体のリストと各タスクの数。 リーダーがより多くの負荷をかける方向を決めるために使用されます。
   
   
4. 2次元フィルター統計。 現在、誰がどのステップでいくつのタスクがあるのか​​を詳しく見ることができます。
   
   

GreenHopperの助けを借りても、このようなボードをセットアップしました。



プロセス全体をレビューするのに非常に便利です。

リリース版

バージョンがリリースされると、2つの列の形式ですべてのバージョンタスクをJiraからアンロードします：コンポーネントとReadMeフィールド。 そのため、ReadMeをセクションにグループ化します。

「スクロールHTMLエクスポーター」を使用して、ヘルプページをConfluenceとそのすべての子ページにエクスポートし、Confluence内で同じように美しく、相互に参照するHTMLファイルのセットにエクスポートします。

まとめ

ここでは、数年前からこのようなワークフローに取り組んでおり、時にはそれを修正して仕上げています。

しかし、全体的に非常に便利です。



PMにとっては、誰がどのステップでタスクを保持しているかをいつでも見ることができます。

開発者が自分の作業範囲のみを確認できると便利です。



そして、もちろん、あらゆる段階での自動化。 つまり 作業プロセスを停止できる人はいません。