さまざまな規模のチームの開発を自動化する方法

Yandexでの1月のチームリーダーのミートアップでは、 2時間のビデオだけでなく、会議の参加者が特別なチャットで選択した2回目の会議のトピックも提供されました。 見出しから明らかなように、開発の自動化についてお話します。

自動化ツールの選択は、チームの規模に大きく依存するため、開発ツールを作成する巨大企業への小さなスタートアップの成長を考慮して、チームの進化を追跡することが重要です。 チームリーダーが何に直面するかを理解するために、私たちは専門家にいくつかの質問をしました。イヴァンジンケージポドゴフ、ローマンシャダートプジコフ、セルゲイプロフィットウェアソブコ、アレクセイアレクシモグモギレフスキー 。

1. スタートアップを開くことにしたとします。 小規模なチーム（5人のプログラマー）が開始時に作業します。 どの開発自動化ツールを実装しますか？
2. スタートアップが点灯しました！ 今では多くの人が働いています。 何が変わるのでしょうか？ 何が追加されますか？
3. どのような存在しないツール（またはツールのタイプ）があなたにとって必要で、我慢できず、自分で作成できなかったでしょうか？

Vitaly Levchenko 、MegaFon.TV、開発グループ長

スタートアップを開くことにしたとします。 小規模なチーム（5人のプログラマー）が開始時に作業します。 どの開発自動化ツールを実装しますか？

開始するには-最も理解しやすいとシンプル。

• Github。 タスク、かんばんを使用したプロジェクト、プルリクエスト、シンプルなウィキなど、開始するために必要なものがすべて揃っています。
• CI：drone.ioなどのクラウドサービス。
• Ansibleのオーケストレーションとリリース管理。
• 通信と通知：スラック。

スタートアップが点灯しました！ 今では多くの人が働いています。 何が変わるのでしょうか？ 何が追加されますか？

• JetBrainsスタック（YouTrack / Upsource / TeamCity）：高速で柔軟性があり、比較的シンプルなソリューション。 Java / Python / JSの場合は非常に便利です。
• Kaiten.io：複雑なかんばんプロセスが必要だった場合。
• Confluence：知識ベース。 競争から。
• システム構成とリリース管理-タスク用。 仮想ネットワークとCI / CDを内蔵したKubernates / Mesosスタックは、自動スケーリングに便利です。 また、cron /バッチタスクの起動とA / Bテストのオーケストレーションを簡単にするためです。
• 日常的な通信プロセスを自動化するためのアドホックボット。

どのような存在しないツール（またはツールのタイプ）があなたにとって必要で、我慢できず、自分で作成できなかったでしょうか？

既製のツールを使用することと、それに基づいて新しいツールを作成することの間で線引きをするのは困難です。 数千行のコードと構成にサービスをデプロイすることは、すでに新しいですか、古いですか？ A / Bテスト用の柔軟なルーティングでマイクロサービス環境を動的に作成しますか？ トリガーへの自動応答を使用して、データベース内の集計された統計を表示および分析するシステムですか？ まったく新しい-サービスを統合するためのシンプルなボット：CIからのデプロイの起動、スラックボット、YouTrackからのレポートのアップロード。

Alexey Mogilevsky 、Yandexの主要なインターフェイス開発者

過去-MS OfficeおよびInternet Explorer、Microsoftの開発者および設計者

スタートアップを開くことにしたとします。 小規模なチーム（5人のプログラマー）が開始時に作業します。 どの開発自動化ツールを実装しますか？

率直に言って、私は常に少なくとも20人の開発者を雇用し、少なくとも100万人のユーザーにサービスを提供するプロジェクトで働いていました。 したがって、私は仮説的に現代のスタートアップについて推測することができます。 ただし、明らかに、バージョン管理システムとトラッカーが必要になります。 Visual Studio Onlineを使用すると、コード制御のすべてのタスクが適切に解決されます。 さらに、彼は大規模なプロジェクトに取り組みます。 5人のコミュニケーションには、Slackが適していると思います。

スタートアップが点灯しました！ 今では多くの人が働いています。 何が変わるのでしょうか？ 何が追加されますか？

大規模なプロジェクトの場合、特に非常に動的な場合は、Microsoft Teamsを真剣に検討する必要があります。 メッセンジャー、カレンダー、ビデオ会議プログラムなど、相互接続されていないツールによって通常解決される多くのニーズがここに統合されています。

どのような存在しないツール（またはツールのタイプ）があなたにとって必要で、我慢できず、自分で作成できなかったでしょうか？

ほとんどの自家製ツールは、不十分に統合された標準システムの問題を修正します。 テレメトリには、ほとんど常に自家製のものがあります。 たぶん。 これは通常のことです。または、有用な製品を作成できる可能性があります。

Ivan Podogov 、Googleシニアソフトウェアエンジニア

過去には、リアルタイム広告テクノロジーサービス、Yandexの責任者

スタートアップを開くことにしたとします。 小規模なチーム（5人のプログラマー）が開始時に作業します。 どの開発自動化ツールを実装しますか？

ツールの選択は、スタートアップが何をするかによって異なります。 Webサービス、デスクトップアプリケーション、モバイルアプリケーション、およびPCBレイアウトの作成は、アクティビティの非常に異なる領域です。 これらの場合のテスト自動化およびパフォーマンス最適化ツールはまったく異なります。 また、決定は、選択したプログラミング言語、オープンソースへの終了の必要性などに依存します。 一方、小さなチームでは、ほとんどの参加者が作業に慣れているツールに集中する必要があります。 そのうち5つしかないため、全員の意見を見つけることは問題になりません。スタートアップにとって、できるだけ早く動く機会を全員に与えることが重要です。 最後に、スタートアップは一種の冒険ですので、長い間会いたいと思っていたのに手が届かなかったツールを試してみませんか？ 私にとって、これは、たとえばYandex.TrackerとPVS Studioです。

スタートアップが点灯しました！ 今では多くの人が働いています。 何が変わるのでしょうか？ 何が追加されますか？

大規模なチームの場合、スタイルガイド、コードの自動フォーマット、ドキュメント、テストカバレッジ（および事前送信チェック）、および神聖な知識の最小化が重要になります。 言い換えれば、バス要素を増やすには、チームメンバーの互換性を確保することが重要です。 小規模なチームでは、通常、知識の交換は有機的に行われますが、大規模なチームでは、スタンドアップミーティング、企業のメール、本格的なタスクトラッカーが必要です（一方、5人はかんばんで対応できます）。 ツールの選択は、主にそのスケーラビリティによって決まります。 独自のwikiとコードレビューを備えたGitHubは、おそらくメインリポジトリとして適しています。 チームがJiraを使用している場合、リポジトリ用にBitbucket、ドキュメント用にConfluence、コードレビュー用にCrucibleを購入できます。 会社が非常に大きくなると、自社のツールの外観はほぼ必然的になります。

どのような存在しないツール（またはツールのタイプ）があなたにとって必要で、我慢できず、自分で作成できなかったでしょうか？

かつて、多くのアプリケーションでRAMの消費を最適化する必要がありました。 これを行うには、Androidの機能を考慮し、個々のクラスではなくコンポーネント全体のレベルでメモリ使用量を評価できるように、リンクグラフを大きなクラスターに「折りたたむ」ことができるJavaヒープアナライザーを記述する必要がありました。 このタスクは、Android Studio、Eclipse MAT、およびahat [ https://android.googlesource.com/platform/art/+/master/tools/ahat/README.txt ]によって部分的に解決されますが、すべて独自の欠点があり、制作を許可しませんでした私自身のツールと同じくらい速くて正確な分析。

ローマン・プジコフ 、Yandex、組織サービス部長

スタートアップを開くことにしたとします。 小規模なチーム（5人のプログラマー）が開始時に作業します。 どの開発自動化ツールを実装しますか？

5人の開発者のスタートアップは完璧です。たとえば、コードの操作、単純なタスク管理、プロジェクトドキュメントの保守を行うGithubです。 さらに、Slackは、チームの運用上の相互作用のために統合されました。 最初はこれ以上必要ありません。

スタートアップが点灯しました！ 今では多くの人が働いています。 何が変わるのでしょうか？ 何が追加されますか？

今ではプログラマーだけが私のために働いているわけではないようです！ そのため、さまざまな分野の専門家が仕事の結果を共有したり、一般的なドキュメントを操作したり、計画を同期したりできるような、ある種の共通の場所が必要です。 この場所は、組織の長期的な記憶です。 ここでは、最小入力しきい値、適切な検索およびナビゲーションが重要です。 どんなウィキでもできます-シンプルであるほど良いです。 さらに、組織が成長するにつれて、古いプロセスは必然的に複雑になり、新しいプロセスが出現します。 したがって、Githubのタスクから、タスクトラッカーにもっと真剣に移動する必要があります。ここでは、柔軟にワークフローを構成でき、開発だけでなく、その場所でも実行できます。 トラッカーには優れたAPIも必要です。その後、他のツール（CIツールや展開からユーザーからのフィードバックの収集まで）との多数の統合にすぐに成長します。 JiraまたはYandex.Trackerは良いです。

どのような存在しないツール（またはツールのタイプ）があなたにとって必要で、我慢できず、自分で作成できなかったでしょうか？

予想外に難しい質問。 あなたの仕事が作業ツールを改善することである場合、1つのものを選択することは困難であることがわかります。 今、私はトップレベルの計画のための便利なツールの欠如について最も心配しています。

このツールの作成方法を正確に説明する場合は、最も単純なプロトタイプを組み立てて、本当に必要かどうかを確認してから、高価な開発に関与してください。 それが何であるかは関係ありません。何かを完全にゼロから書くか、大きく複雑な何かをプロセスに統合します。

ポジティブテクノロジーズ、アプリケーションファイアウォール開発チーム長、 セルゲイソブコ

スタートアップを開くことにしたとします。 小規模なチーム（5人のプログラマー）が開始時に作業します。 どの開発自動化ツールを実装しますか？

一般に、スタートアップとは、ゼロから再構築された構造と、大企業のフレームワーク内のスタートアップ（いわゆる「内部スタートアップ」）の両方を意味します。

最初のケースでは、「説明する時間がない」という原則に基づいて選択された無料の（そして好ましくはオープンソースの）機器である可能性が最も高いでしょう。 内部インフラストラクチャとそれをサポートする機能が既に存在する場合、それはGitlab CEになります。そうでない場合-Bitbucket：無料のプライベートリポジトリを持つ機能を提供します。 少しお金を払う意欲がある場合は、おそらくGithubを使用することをお勧めします。 このツールキットには、Wikiページとタスク管理のサポートが既に組み込まれています。 そして、それに応じて、Travis CIなどのあらゆる種類のクラウドベースのCIシステムとの統合。 内部インフラストラクチャがある場合は、無料のJenkinsを使用できます。

2番目のケースでは、会社の他のチームが使用しているものを使用することは論理的です。なぜなら、彼らはあなたの前にすべてのレーキをすでに収集しているためです。誰かがすでにそれを使用する方法を知っているので、チームに適応できるいくつかの構築されたワークフローがあります。

スタートアップが点灯しました！ 今では多くの人が働いています。 何が変わるのでしょうか？ 何が追加されますか？

この段階で、チームはすでにすべてを反映し、独自のワークフローを開発しました。 ここでツールの違いが明らかになり、チームに合ったものを選択できます。 最も重要なことは、それを移動または実装できるが、チームに暴動を起こさないことです。 たとえば、Gitlab CEを使用した場合、Gitlab EEにアップグレードして追加機能を取得できます。 開発プロセスに十分な分析ツールがない場合は、タスクトラッカーをもう少し強力に選択することもできます-JiraまたはTFSなど。 後者は、私が理解しているように、箱から出してすぐに容量のある休日を考慮し、燃焼スケジュールを作成することができます。

同時に、すべての制御プロセスの自動化の大部分は、異なるシステム間の統合にあります。 つまり、1つのプラグインを接続してバージョン管理システムとタスクトラッカーを統合する機会があれば、これは非常に良いことです。 このような統合が存在しない場合、またはすべての必要なシナリオをカバーしていない場合、問題が発生する可能性があります。

これは、私がそれを呼ぶとき、外部自動化に役立つかもしれません。 この場合、いくつかのシステムの相互作用のアクターは、それらの外部のシステムです。 いくつかの重いBPMシステムを例にとると、ビジネスプロセスを実行するためのRed HatのKIE Execution Serverです。 それにもかかわらず、大量の血まみれの企業を開始したスタートアップに引き込むことなく、外部の自動化を実装できます。

実際、チームが5人以上になり、多くの定型業務が登場したとき、チーム内の明らかなツールセットに外部自動化のみを追加しました。

どのような存在しないツール（またはツールのタイプ）があなたにとって必要で、我慢できず、自分で作成できなかったでしょうか？

悪名高い外部自動化を実装しました-一方では、自分で本格的なBPMパラダイムに入らないようにし、他方では、チームの管理を完全に制御できるようにしました。 当初は、今日まで機能するプロトタイプを実装しましたが、現在は徐々に実稼働ソリューションに置き換えています。 これを行うために、Positive Technologiesのサポートにより、このプロダクションソリューションの大部分をGithubのオープンソースとしてレイアウトしました。これは、バージョン管理システム（GitlabおよびGithub）、タスクトラッカー（Jira、TFSなど）およびインスタントメッセンジャー（Slack、交換）。 これはほんの始まりに過ぎません。これについては、Habrに関する別の記事で説明します。

アイデアは、誰もが既製のレゴブロックからゼロから自動化を組み立てることができ、最終的なソリューションの開発者が必要なものを完全に制御できるようにすることです。 たとえば、正規表現と単純なルール（これは私の場合です）の形式で能力のマトリックスに従ってタスクを分散するためのルールが必要であり、そのような決定を下すための機械学習では不十分です。 同時に、タスクトラッカーの変更またはバージョン管理システム（スタートアップが点灯している）がある場合、概念と一般的なロジックを変更せずに接続アドレスを変更するだけで十分です。

チームで何を自動化しましたか？ 先ほど言ったように、能力のマトリックスを使用したタスクの分散。 2つ目は、クロスレビューを通過するときに、タスクを完了ステータスに自動的にマージおよび転送することです。 次に-新しい従業員の到着、誕生日のリマインダー、現在のタスクなどのアプリケーションの作成とメッセージの送信。些細なことですが、同じタイプの手動アクションが必要です。

Pavel Solomin 、プラットフォームエンジニアSberbank Onlineのリーダー

スタートアップを開くことにしたとします。 小規模なチーム（5人のプログラマー）が開始時に作業します。 どの開発自動化ツールを実装しますか？

参加者の最小数の条件では、各分野の能力に対して1人が責任を負います。 この段階では、すべての人に共通のツールを導入しようとすることは、有用というよりも有害です。なぜなら、すべての人を共通の分母と訓練に導くために多くの努力が費やされるからです。 これにより、MVPの取得が遅くなる可能性が高く、将来的に何らかの形で役立つという事実ではありません。 ただし、一般的なツールが役立つ分野があります。 たとえば、クライアント側とサーバー側の間のAPI。設計から開発にタスクを転送します。 どんなwikiシステムもAPIの作業に適しています。私は他の人よりもAtlassian Confluenceが好きです。 Zeplinは、デザインを伝えるのにこれ以上良いものを思いつきませんでした。 さらに、5人のプログラマでさえ、なんとか管理する必要があります。 JiraまたはTrelloでやります。

スタートアップが点灯しました！ 今では多くの人が働いています。 何が変わるのでしょうか？ 何が追加されますか？

Sberbankには、100人以上の開発者が同時に取り組んでいるプロジェクトがあります。 その組織には、非常に具体的なツールと実践が必要です。 この特異性から逃れようとするなら、次のように言えます。 コラボレーションには、間違いなくバージョン管理システムが必要です。 さらに、継続的インテグレーション、継続的デプロイメント環境を整理するための何らかのソフトウェアが必要です。 どこかにドキュメントをまとめる必要があります。 タスクを追跡する場所。 ある会社が作ったソフトウェアを使用してこれらすべての問題を解決します-この場合、統合により、多くのパンを無料で手に入れることができます。 ここで私のお気に入りはアトラシアン製品です。 竹、ジラ、ビットバケット、合流点。 それとは別に、私はあなたのアプリケーションがどのように相互作用するかのアーキテクチャに注意を払い始めます。そうしないと、構造全体が管理不能になる可能性があります。 私はここでSparx Enterprise Architectが好きです。

どのような存在しないツール（またはツールのタイプ）があなたにとって必要で、我慢できず、自分で作成できなかったでしょうか？

私たちには、80人以上の小さなチームがプロジェクトに取り組んでいます。 各アプリケーションには100人以上の開発者がいます。 これらのチームのパフォーマンスを管理するために、各チームの指標ではなく、通常の指標からの逸脱を考慮したケースで作業することにしました。 これを行うために、独自のアプリケーションを作成しました。 より正確には、ブランチの販売管理用に開発されたアプリケーションを採用しました。 どのように機能しますか？ たとえば、スプリント用に計画された構築ポイントの80％が燃え尽きる場合、正常と見なされます。 チームがこれを満たさない場合、理由を整理する作業は製品の所有者にかかっています。 状況がスプリントを通して繰り返される場合、タスクは製品所有者の頭にエスカレートし、スプリントがまだ解決されない場合、タスクはさらに高くなります。 したがって、タスクは取締役会の副議長に届く可能性があります（そして問題が体系的なものである場合、それは非常によく起こる可能性があります）。 同様のシステムを使用すると、組織構造の各レベルで状況を管理できます。 しかし、私たちの会社よりも小さな会社では必要だとは思いません。

---

まだ登録できる次の会議は、2018年5月22日にYandexのモスクワ事務所で開催されます。 スピーカーに質問をして、彼らの経験を共有することが可能になります。