インタビューには3つの段階がありました。
- テナント企業の主要プロジェクト開発者と
- 顧客企業の主要な開発者（既に英語）
- 顧客企業の建築家と
インタビューの中で、会社は非常に大きく、開発は最初の会社と同じツールを使用して実行されることが判明しました。 すべてが非常に近いです。 多くのデータベースタスク。 私は彼らが技術についてどれほど詳細に尋ねたかが好きで、専門家のレベルが高く、プロジェクトが興味深いことは明らかでした。
私はこの申し出を受け入れて会社に来ることにしました。興味深い仕事に取り組み、アメリカの会社のプロセスがどのように組織されているかを見るためです。 ピンクのメガネを持っていたので、ここで予約する必要があります。 会社がアメリカにある場合、その中のすべてのプロセスは調整され、リーダーはStephen CoveyとYitzhak Adizesの原則に従って働くと思いました。 驚いたことに、これは事実ではありませんでした。 ピンクのメガネは脱がれましたが、会社の仕事にはたくさんの便利で新しいものがありました。
1.スクラム
方法論自体の長所と短所は、別の記事に値します。 今のところ、開発は「スプリント」に分割されているとだけ言います。 各スプリントは2週間です。 この期間中は、すべてのタスクが終了することを前提としています。 突然、誰かが自分のスプリントタスクにすばやく対応できるようになったら、時間がない人たちをつなぎ、助けるでしょう。 私の意見では、タスクの複雑さを評価することは非常に有用なことであり、まとめて実行されます。 週に1回の呼び出しがあり、その間、チームはまだ評価されていないタスクを議論し、複雑さを割り当てます-閉じた投票で。 そして、誰もが投票したとき、評価に大きな違いがある場合、誰がどのくらいの額を投じているかはすでに明らかです-タスクを評価した人々が発言して議論します。 その結果、グループは問題の全体的な評価を行います。 物事は長い（めったに2時間もかからない）が、私の意見では、役に立つ。 第一に、誰もが主要なタスクについて最新のものです。 第二に、この方法により、タスクの複雑さとボリュームをより客観的に評価できます。
2.各スプリントをガイドするデモ
会社の経営者がプログラマーが何をしているのか理解していないときに問題が発生する頻度はわかりません。 私の最初の会社では、これが痛い点でした。 私たちはあらゆる種類のレポートを試しましたが、その結果、経営陣は読んでいませんでした。その結果、質問がハングアップしましたが、誤解は残りました。 そして、そのような簡単な解決策がありました。 プレゼンテーション-2週間に1回（ここでは各スプリントの最後）、言語でビジネスマンが理解できるようになった内容の簡単な概要。 これにより、経営陣は人々が何をしているかを理解し、プロジェクトがそこで動いているかどうかを理解する機会を得ることができます。
3.すべての手会議
これは、管理職の従業員向けのデモです。 会社の主な開発優先事項、成果、およびさらなる開発の方向性の説明。 私の意見では、素晴らしいことです。 まず第一に、経営者がどのタスクを解決し、何に取り組んでいるかを人々に理解させます。 第二に、それはあなたの優先事項と開発原則を会社開発の優先事項と原則と相関させることを可能にします-この方法であなたは常にチェックできますが、あなたは途中ですか？
通常、会社全体がこのような「コール」に参加します。 そして、誰もがオンエアで質問をする機会があります。 約1時間続きます。 会社に応じて、月に1回または四半期に1回開催されます。
4.コードレビュー
これは技術的な部分ですが、非常に便利です。 最初の会社での変更の適用の構成は次のとおりでした。開発者が変更を行い、テストし、テスターに提供し、その後、必須の部分に続いてヘッドからの詳細なコードレビューを行いました。 さらに、管理者はすでに作業システムに変更を適用しています。 コードを見ながら部品を取り除く方法を理解できませんでした。 また、ソリューションは非常にシンプルです。コードのレビューは開発者自身が行う必要があります。 コードを書いた人だけでなく、他の2〜3人。 彼らのすべてのコメントと発言は慎重に研究され、適用されなければなりません。そうでなければ、著者-開発者は彼の同僚が彼の解決策が優れていることを納得させなければなりません。 1つのポイントは、開発者がコードレビューを行う意欲があることです。 他の人からのフィードバックを待つには、タスク自体と同じくらいの時間がかかることがあり、その後、すでに記述されたコードに戻って編集するのは不便です。
5.問題発生時のブリッジコール
たとえば、稼働中のサーバーのCPU負荷が90％に達し、5分以内にこの問題を解決できないなど、予期しない状況が発生した場合、ブリッジコールは会社の専門家によって編成されます。 現在のDBAと主要な開発者。
最初は、そのような「電話」についてかなり懐疑的でした。 これはむしろ問題の解決を妨げるはずだと私には思えた。 ただし、この方法の有効性は確認できました。通常、解決策が見つかり、問題は解決しました。 このような共同作業により、何人かの人々が仮定を立て、問題とその解決策の検索に従事しているという事実により、理由を見つけることができます。
私の経験がお役に立てば幸いです。