最も重要なことは、プログラマーが顧客やお互いとのコミュニケーションの仕方を理解していないということです。継続的な高品質の製品開発プロセスを構築する方法。あなたの仕事の日とスプリントを計画する方法。
そして、これらすべては最終的に、締め切りの混乱、残業、誰のせいにするかについての絶え間ない対決、そして顧客の不満、つまりすべてがどこでどのように動いているかということにつながります。多くの場合、これはすべて、プログラマー、さらにはチーム全体に変化をもたらします。顧客の喪失、評判の低下など。
かつて、私はそのようなプロジェクトに参加しました。そこでは、これらすべての魅力がありました。
誰もプロジェクト（大規模なサービス市場）の責任を引き受けたくありませんでした、売上高はひどいものでした、顧客はただ引き裂かれ、打ちのめされました。 CEOが私に近づいてきて、あなたには必要な経験があると言ったので、ここにあなたの手にあるカードがあります。プロジェクトを自分で行ってください。あなたは失敗します、私たちはプロジェクトを閉じて、みんなを追い出します。それは判明し、クールになり、それからそれを導き、あなたが適切と思うようにそれを開発します。その結果、私はプロジェクトのチームリーダーになり、すべてが私の肩にかかった。
私が最初にしたことは、当時の私のビジョンに一致するワークフローを最初から設計し、チームの仕事の説明を書くことでした。実装は簡単ではありませんでした。しかし、1か月以内にすべてが落ち着き、開発者とクライアントはそれに慣れ、すべてが静かに快適に進みました。これが単なる「ガラスの嵐」ではなく、状況からの本当の方法であることをチームに示すために、私はチームから不快なルーチンを取り除き、最大限の責任を負いました。
すでに1年半が経過し、プロジェクトは残業もなく、「ラットレース」やあらゆる種類のストレスなしに発展しています。古いチームの誰かがそのように働きたくなくて去りました、それどころか、誰かが透明なルールが現れることに非常に熱心でした。しかしその結果、チームに参加するすべての人は非常に意欲的であり、フロントエンドとバックエンドの両方で巨大なプロジェクトを完全に知っています。コードベースとすべてのビジネスロジックの両方を含みます。私たちが単なる「漕ぎ手」ではなく、私たち自身が多くのビジネスプロセスやビジネスが好みに合わせて見つけた新機能を思いついたということさえあります。
私たちのこのアプローチのおかげで、顧客は私たちの会社に別のマーケットプレイスを注文することを決定しました。これは朗報です。
それは私のプロジェクトで機能するので、誰かを助けることもできるかもしれません。したがって、プロジェクトの保存に役立ったプロセス自体は次のとおりです。
プロジェクト「私のお気に入りのプロジェクト」のチームワークプロセス
a）社内チームプロセス（開発者間）
- すべてのタスクはJiraシステムで作成されます
- 各タスクは可能な限り説明し、厳密に1つのアクションを実行する必要があります
- 機能が十分に複雑な場合は、多くの小さなスワップに分割されます
- チームは、単一のタスクのような機能に取り組んでいます。まず、1つの機能をすべてまとめて実行し、テスト用に送信してから、次の機能を取得します。
- 各タスクは、バックエンドまたはフロントエンド用にマークされています
- スワップとバグの種類があります。あなたはそれらを正しく示す必要があります。
- タスクが完了すると、コードレビューのステータスに転送されます（これにより、同僚のプルリクエストが作成されます）
- タスクを完了した人は誰でも、すぐにこのタスクの時間を追跡します。
- , , , , , .
- , , ( ), , - . —
- ,
- ,
- , , . ,
- : To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- , . , , .
- . , .
- .
- , .
- , , , , .
- , , , , . ( ) . , /.
- ( 12.00)
- , , , . . , . , , .
- , . .
- , , , , .
- . .
- . , , . . , , , .
- , . . .
- , , . .
- 開発者は毎日、クライアントのチャットに、昨日取り組んだタスクと今日取り組むタスクについて書き込む必要があります。
- ワークフローはスクラムに基づいています。すべてがスプリントに分解されます。各スプリントは2週間続きます。
- スプリントは、チームリードを作成、埋め、閉じます。
- プロジェクトの期限が厳しい場合は、すべてのタスクを概算するように努めます。そして、それらからスプリントを収集します。お客様がスプリントにタスクを追加しようとした場合、優先順位を設定し、他のいくつかのタスクを次のスプリントに転送します。
b）顧客と協力するプロセス
- 各開発者は顧客と通信でき、通信する必要があります
- 顧客がゲームの独自のルールを課すことを許可されるべきではありません。私たちが私たちの分野のスペシャリストであることを顧客に明確にするために丁寧かつ友好的な方法で必要であり、私たちだけが作業プロセスを構築し、それらに顧客を関与させる必要があります
- , , - , - (). . , , , .. , , , , , , .
- /-/ .. /, .
- . , , -, /.
- , . , , . .
- , . . , .
- , , . , . , . , . .
- , , . , . , .
- 顧客が頭からさまざまなタスクを考え出し、想像して指で説明し始めた場合は、ページレイアウトと、レイアウト全体とその要素の動作を完全に説明するロジックを備えたフローを提供するように依頼します。
- タスクを実行する前に、この機能が契約/契約の条件に含まれていることを確認する必要があります。これが当初の合意を超える新機能である場合は、この機能を確実に評価し（（推定リードタイム+ 30％）x 2）、時間がかかることを顧客に示し、期限を変更する必要があります。見積もりの2倍。タスクをより速くしましょう-素晴らしい、誰もがこれからのみ恩恵を受けるでしょう。そうでない場合、私たちは保険をかけられます。
c）チームで受け入れないもの：
- オプション性、組み立ての欠如、忘却
- „ “. , , , .
- , . , , :)
- . , , . , , — . -, .
- .
- ! - - , .
そして、私が時々顧客にすべての誤解を取り除くように頼む他の多くの質問/論文：
- あなたの品質基準は何ですか？
- プロジェクトに問題があるかどうかをどのように判断しますか？
- システムの変更/改善に関するすべての推奨事項とアドバイスに違反すると、すべてのリスクはあなただけが負担します
- プロジェクトに大きな変更を加えると（たとえば、あらゆる種類の追加フロー）、バグが発生する可能性があります（もちろん、修正します）。
- プロジェクトでどのような問題が発生したかを数分間理解することは不可能であり、それ以上にすぐに修正することは不可能です。
- 特定のフロー製品に取り組んでいます（Fatのタスク-開発-テスト-デプロイ）。これは、チャットでのリクエストや苦情のストリーム全体に対応できないことを意味します
- プログラマーは単なるプログラマーであり、プロのテスターではなく、プロジェクトテストの適切な品質を保証することはできません。
- , , ( )
- ( ), ,
- — ,
- , , , ,
- , , , ,
- .
- , ( ),
原則として、顧客はソフトウェア開発においてすべてがそれほど単純ではなく、欲求だけでは明らかに十分ではないことにすぐに気づきます。
一般的には、それだけです。多くのネゴシエーションとすべてのプロセスの初期デバッグを舞台裏に残しましたが、結果としてすべてがうまくいきました。このプロセスは、私たちにとって一種の「銀の弾丸」になっていると言えます。すべてのプロセスが説明されており、図の形式のドキュメントとアーキテクチャが私たち全員がここで何をしているのかをすぐに理解したので、プロジェクトに来た新しい人々は最初の日からすぐに仕事に参加することができました。
PS私たちの側にはプロジェクトマネージャーがいないことを明確にしておきたいと思います。それは顧客側にあります。技術者ではありません。プロジェクトはヨーロッパ人です。すべてのコミュニケーションは英語のみです。
プロジェクトの皆さん、頑張ってください。燃え尽きてプロセスを改善しようとしないでください。
ソースは私のブログにあります。