IT プロジェクトにおけるチーム内のワークフローの組織化

皆さん、こんにちは。 特にアウトソーシングにおいては、同じ状況をよく目にします。 さまざまなプロジェクトにおけるチーム内での明確なワークフローの欠如。

最も重要なことは、プログラマーが顧客とのコミュニケーション方法、およびプログラマー同士のコミュニケーション方法を理解していないことです。 高品質の製品を開発する継続的なプロセスを構築する方法。 勤務日とスプリントを計画する方法。

そして、これらすべてが最終的には締め切りの違反、時間外労働、誰の責任であるかについての絶え間ない対立、顧客の不満、つまりすべてがどこでどのように進んでいるのかという結果につながります。 多くの場合、これらすべてがプログラマーの変更、さらにはチーム全体の変更につながります。 顧客の喪失、評判の悪化など。

かつて、私はそのようなプロジェクトに参加したばかりで、とても楽しいことがたくさんありました。

誰もそのプロジェクト (大規模なサービス市場) の責任を負いたがらず、売上高はひどいもので、顧客はただ引き裂いて投げるだけでした。 CEO はどういうわけか私に近づき、あなたには必要な経験があるので、カードを手にしていると言いました。 自分自身でプロジェクトに取り組んでください。 失敗した場合はプロジェクトを終了し、全員を追い出します。 それは結果的にクールになるでしょう、そしてそれを導き、あなたが適切だと思うようにそれを発展させてください。 その結果、私はプロジェクトのチームリーダーになり、すべてが私の肩にかかりました。

私が最初にやったのは、当時の自分のビジョンに合ったワークフローを一から設計し、チームの職務記述書を書くことでした。 それを実装するのは簡単ではありませんでした。 しかし、XNUMX か月以内にすべてが落ち着き、開発者もクライアントもそれに慣れ、すべてが静かに快適に進みました。 これが単なるガラスの中の嵐ではなく、この状況から抜け出す真の方法であることをチームに示すために、私は最大限の責任を引き受け、チームから不快なルーチンを取り除きました。

すでに XNUMX 年半が経過しましたが、プロジェクトは残業もなく、「ラットレース」やあらゆる種類のストレスもなく開発されています。 古いチームの誰かがそのように働きたくなくて辞めました。逆に、誰かが透明なルールが登場したことに本当に夢中になりました。 しかしその結果、チームの全員が非常にモチベーションが高く、フロントエンドとバックエンドの両方で巨大なプロジェクトを完全に理解しています。 コードベースとすべてのビジネスロジックの両方が含まれます。 私たちは単なる「漕ぎ手」ではなく、企業が好む多くのビジネス プロセスや新機能を自分たちで考案するようになりました。

私たちのこのアプローチのおかげで、お客様は当社に別のマーケットプレイスを注文することに決めました。これは良いニュースです。

これは私のプロジェクトで機能するので、もしかしたら誰かの役に立つかもしれません。 プロジェクトを保存するのに役立つプロセス自体は次のとおりです。

プロジェクト「私のお気に入りプロジェクト」のチームワークのプロセス

a) チームプロセス内 (開発者間)

• すべてのタスクは Jira システムで作成されます
• 各タスクはできる限り詳しく説明し、厳密に XNUMX つのアクションを実行する必要があります。
• 十分に複雑な機能であれば、多くの小さなタスクに分割されます。
• チームは単一のタスクとして機能に取り組みます。 まず、XNUMX つの機能を一緒に実行し、テスト用に提供してから、次の機能を実行します。
• 各タスクにはバックエンドまたはフロントエンドのラベルが付けられます
• タスクとバグには種類があります。 それらを正しく指定する必要があります。
• タスクが完了すると、コード レビュー ステータスに転送されます (同僚に対してプル リクエストが作成されます)。
• タスクを完了した人は、このタスクに費やした時間をすぐに記録します
• コードをチェックした後、PR は承認され、その後、このタスクを独自に実行した人が PR を master ブランチにマージし、その後ステータスが開発サーバーへのデプロイの準備ができた状態に変更されます。
• 開発サーバーにデプロイする準備ができているすべてのタスクは、チーム リーダー (彼の責任範囲) によってデプロイされますが、緊急の場合はチーム メンバーがデプロイすることもあります。 デプロイ後、「デプロイの準備完了」から「開発」までのすべてのタスクが「開発でのテストの準備完了」ステータスに転送されます。
• すべてのタスクは顧客によってテストされます
• 顧客は開発環境でタスクをテストした後、実稼働環境にデプロイできる状態に移行します。
• 本番環境へのデプロイメントのために、デプロイメントの直前にマスターをマージする別のブランチがあります。
• テスト中に顧客がバグを発見した場合、顧客は改訂用にタスクを返し、改訂用に返されたステータスを設定します。 これは、新しいタスクをテストされていないタスクから分離する方法です。
• その結果、すべてのタスクは作成から完了まで進みます。 To Do → 開発中 → コードレビュー → 開発へのデプロイ準備完了 → 開発での QA → (開発への戻り) → 本番へのデプロイ準備完了 → 本番での QA → 完了
• 各開発者は、サイトのユーザーとしてなど、独自にコードをテストします。 コードが機能することが確実にわかっている場合を除き、ブランチをメインのブランチにマージすることはできません。
• すべてのタスクには優先順位があります。 優先順位は顧客またはチームリーダーによって設定されます。
• 開発者は優先タスクを最初に実行します。
• システム内で異なるバグが見つかった場合、または XNUMX つのタスクが複数の専門家の作業で構成されている場合、開発者は互いにタスクを割り当てることができます。
• 顧客が作成したすべてのタスクはチーム リーダーに送信され、チーム リーダーがタスクを評価し、顧客にタスクを最終決定するよう依頼するか、チーム メンバーの XNUMX 人にタスクを割り当てます。
• 開発または本番環境にデプロイする準備ができているすべてのタスクもチーム リーダーに渡され、チーム リーダーがいつ、どのようにデプロイするかを独自に決定します。 導入のたびに、チーム リーダー (またはチーム メンバー) はこれについて顧客に通知する必要があります。 また、タスクのステータスを開発/本番環境でのテストの準備完了に変更します。
• 毎日同じ時間 (12.00:XNUMX に開催します) にチームメンバー全員で集会を開催します。
• チームリーダーを含む集会の参加者全員が、昨日何をしたか、今日何をする予定かを報告します。 何がうまくいかないのか、そしてなぜうまくいかないのか。 したがって、チーム全体が、誰が何をしているのか、プロジェクトがどの段階にあるのかを認識しています。 これにより、必要に応じて見積もりと期限を予測し、調整する機会が得られます。
• ミーティングでは、チーム リーダーはプロジェクト内のすべての変更点と、顧客が発見できなかった現在のバグのレベルも発表します。 すべてのバグは分類され、解決するために各チームメンバーに割り当てられます。
• 集会では、チーム リーダーが、開発者の現在の作業負荷、専門トレーニングのレベル、および開発者が現在行っていることと特定のタスクの近さを考慮して、それぞれにタスクを割り当てます。
• 会議では、チーム リーダーがアーキテクチャとビジネス ロジックの一般的な戦略を策定します。 その後、チーム全体で話し合い、調整するか、この戦略を採用するかを決定します。
• 各開発者は、単一のアーキテクチャとビジネス ロジック内で独立してコードを記述し、アルゴリズムを構築します。 誰もが実装のビジョンを表現できますが、誰もこれをこの方法で実行することを強制することはありません。 すべての決定は正当化されます。 もっと良い解決策があるが、今はそれをする時間がない場合、コードの特定の部分の将来のリファクタリングのためにタスクがファットで作成されます。
• 開発者はタスクを引き受けると、それを開発ステータスに移行します。 顧客とのタスクの明確化に関するすべてのコミュニケーションは開発者の肩にかかっています。 技術的な質問はチームリーダーまたは同僚に尋ねることができます。
• 開発者がタスクの本質を理解しておらず、顧客も賢明に説明できない場合は、次のタスクに進みます。 そして、チームリーダーは現在のものを取り上げて顧客と話し合います。
• 毎日、開発者はクライアントのチャットに、昨日取り組んだタスクと今日取り組む予定のタスクを書き込む必要があります。
• ワークフローはスクラムに基づいています。 すべてはスプリントに分割されます。 各スプリントは XNUMX 週間続きます。
• スプリントは、チーム リーダーによって作成、記入、終了されます。
• プロジェクトの期限が厳しい場合は、すべてのタスクを大まかに見積もろうとします。 そして私たちは彼らからスプリントを集めます。 顧客がスプリントにさらにタスクを追加しようとすると、優先順位を設定し、他のタスクを次のスプリントに転送します。

b) 顧客との作業プロセス

• 各開発者は顧客とコミュニケーションを取ることができ、またそうすべきです
• 顧客が独自のゲームルールを課すことを許可することはできません。 私たちがその分野の専門家であり、私たちだけが作業プロセスを構築し、それに顧客を巻き込むべきであることを、丁寧かつフレンドリーな態度で顧客に明確にする必要があります。
• 理想的には、機能の実装を進める前に、機能の論理プロセス全体のフローチャート (ワークフロー) を作成する必要があります。 そして確認のために顧客に送信します。 これは、支払いシステムや通知システムなど、複雑で明白ではない機能にのみ適用されます。 これにより、顧客が何を必要としているのかをより正確に理解し、その機能のドキュメントを保存できるほか、顧客が将来、私たちが要求したことをしなかったと言うかもしれないという事実に備えることもできます。
• すべての図/フローチャート/ロジックなど。 Confluence/Fat に保存し、コメントでお客様に将来の実装の正確性を確認するよう求めます。
• 当社では、技術的な詳細についてお客様に負担をかけないよう努めています。 顧客がどのように望んでいるのかを理解する必要がある場合は、顧客が理解し、すべてを自分で修正/変更できるフローチャートの形式で原始的なアルゴリズムを作成します。
• 顧客がプロジェクトのバグを見つけた場合は、Fat で詳細に説明するようお願いします。 テスト中に顧客がどのような状況で、いつ、どのような一連のアクションを実行したか。 スクリーンショットを添付してください。
• 私たちは開発サーバーへのデプロイを毎日、最大で XNUMX 日おきに試みます。 その後、顧客は機能のテストを開始しますが、プロジェクトはアイドル状態ではなくなります。 同時に、これは顧客にとって、プロジェクトが完全に開発中であり、誰もおとぎ話を話していないことを示す目印でもあります。
• 顧客が自分が何を必要としているのかをまったく理解していないことがよくあります。 彼は、まだデバッグされていないプロセスを使用して、自分自身の新しいビジネスを作成するためです。 したがって、非常に一般的なケースは、コード全体をゴミ箱に捨てて、アプリケーション ロジックを再構築する場合です。 このことから、テストですべてを完全にカバーする必要はないことがわかります。 重要な機能のみをテストでカバーし、その後予約でカバーするのが合理的です。
• チームが期限に間に合わないことに気づく場合があります。 その後、タスクの簡単な監査を実施し、それについてすぐにお客様に通知します。 この状況を打開する方法として、重要かつ重要な機能を予定通りにリリースし、残りはリリース後に残しておくことをお勧めします。
• 顧客が頭からさまざまなタスクを思いつき始め、空想したり指で説明し始めたら、ページ レイアウトと、レイアウト全体の動作とその動作を完全に説明するロジックを備えたフローを提供するよう依頼します。要素。
• タスクを引き受ける前に、この機能が契約条件に含まれていることを確認する必要があります。 これが当初の合意を超える新機能である場合は、この機能を確実に見積もり ((概算リードタイム + 30%) x 2) し、完成までに非常に時間がかかることを顧客に示す必要があります。締め切りは見積時間の XNUMX 倍にずらされます。 タスクをより速くしましょう - 素晴らしいです、これは誰もが恩恵を受けるだけです。 そうでない場合は、保険が適用されます。

c) チーム内で受け入れられないもの:

• 矛盾、支離滅裂、物忘れ
• 「朝食の授乳」。 タスクを完了できない、方法がわからない場合は、最後まで待たずに、すぐにチームリーダーにそのことを通知する必要があります。
• ブロバダと、自分の能力とプロフェッショナリズムを行為によってまだ証明していない人の自慢です。 証明されれば、良識の範囲内でそれは可能です 🙂
• あらゆる形で現れる詐欺。 タスクが完了していない場合は、ステータスを完了に変更せず、クライアントのチャットに準備ができていることを書き込む必要があります。 コンピューターがクラッシュした、システムがクラッシュした、犬がラップトップを噛んだ、これらすべては受け入れられません。 本当に不可抗力が発生した場合は、チームリーダーに直ちに通知する必要があります。
• 専門家が常にオフラインで、勤務時間中に連絡を取ることが難しい場合。
• チーム内での有害行為は禁止です！ 誰かが何かに同意しない場合は、全員が集まって集会を開き、議論して決定します。

そして、すべての誤解を取り除くために、私がお客様に時々尋ねるいくつかの質問や論文は次のとおりです。

1. 品質基準は何ですか?
2. プロジェクトに問題があるかどうかをどのように判断しますか?
3. システムの変更/改善に関する当社の推奨事項やアドバイスに違反した場合、すべてのリスクはお客様のみが負担します。
4. プロジェクトに大きな変更があった場合 (あらゆる種類の追加フローなど)、バグが発生する可能性があります (もちろん、修正します)。
5. プロジェクトでどのような問題が発生したかを数分以内に理解することは不可能であり、その場で修正することはさらに不可能です。
6. 私たちは特定の製品フロー (Zhira のタスク - 開発 - テスト - デプロイ) に取り組んでいます。 つまり、チャットでのリクエストや苦情の流れ全体に対応することはできません。
7. プログラマーは単なるプログラマーであり、プロのテスターではないため、プロジェクトのテストの適切な品質を保証することはできません。
8. 最終テストと販売に関するタスクの承諾に対する責任は完全にあなたにあります
9. すでにタスクを引き受けている場合、現在のタスクを完了するまですぐに他のタスクに切り替えることはできません（そうしないと、さらに多くのバグが発生し、開発時間の増加につながります）。
10. (休暇や病気のため) チームの人数が減り、仕事が増え、あなたが望むすべてに対応する物理的な時間がなくなります。
11. 開発環境でテストされたタスクを行わずに実稼働環境にデプロイするよう要求するのは、開発者のリスクではなく、開発者のリスクだけです。
12. 正しいフローやデザインレイアウトを持たずにあいまいなタスクを設定すると、お客様の代わりに私たちが追加の作業を行わなければならないため、より多くの労力と実装時間が必要になります。
13. バグに関するタスクは、発生の詳細な説明やスクリーンショットがなければ、何が問題で、どのようにしてこのバグを発生させるかを理解する機会を与えてくれません。
14. このプロジェクトでは、パフォーマンスと安全性を向上させるために、継続的な改良と改善が必要です。 したがって、チームはこれらの改善に時間の一部を費やします。
15. 残業（緊急修正）があるため、その分を他の日に補う必要があります。

一般に、顧客は、ソフトウェア開発ではすべてがそれほど単純ではなく、欲望だけでは明らかに不十分であることをすぐに理解します。

一般的にはこれですべてです。 私は舞台裏で多くの交渉とすべてのプロセスの初期デバッグを任せていますが、結果としてすべてがうまくいきました。 このプロセスは私たちにとって一種の「特効薬」になったと言えます。 すべてのプロセスが説明されており、図形式のドキュメントとアーキテクチャにより、私たちが何をしているのかがすぐに理解できるため、プロジェクトに参加した新しい人は初日からすぐに仕事に取り組むことができました。ここ。

PS 私たちの側にはプロジェクトマネージャーがいないことを明確にしたいと思います。 それはクライアント側です。 決して技術者ではありません。 ヨーロッパのプロジェクト。 すべてのコミュニケーションは英語のみで行われます。

プロジェクトに携わる皆さんの幸運を祈ります。 燃え尽きてしまわないように、プロセスの改善に努めてください。

私の中のソース ブログ記事.

出所： habr.com