こんにちは、Habrの読者の皆さん！
投稿とイベントの対象読者：チームリーダーとプロジェクトマネージャーを含む
C＃/。Netで開発中のマネージャー。 そして
、リーダーシップの地位に
移動することを計画している人々。
Go＃会議の2日目のプログラムを作成するロジックを共有します。私たちは、開発においてリーダーシップの地位にあるべきトピックを取り上げました。 さらに、この知識の具体的な実装は、C＃/。Netエコシステムに固有でなければなりません。
トラックが1つのイベントの場合、プログラムは集中していることがわかりました。 スケジュールには、15〜30分のレポート10件、カフェでの昼食、コーヒーブレークが含まれます。これらはすべて10.00〜17.00です。
トピック： .Netアプリケーションのアーキテクチャから、チームビルディングおよびタスク分散ソリューションの仕組みまで。 そして、もちろん、プロジェクトとソースコードの管理。 スピーカーは、古典的なTFSベースのアプリケーションライフサイクル管理と、GitおよびDevOpsツールを使用した代替アプローチという2つの極地のパラダイムを提示します。
私たちのスピーカーはC＃/。ネット開発者として始まりましたが、多くの開発者は数十または数百の開発者でチームとプロジェクトを管理した経験があります。
チームリーダーの会議日のサイトGo＃
-www.gosharp.ru/TLD2014
チームリーダーが知っておくべきこと
私たちの多くは
心の底からプログラマーです。 そして、私たちはコードを書くのが大好きです。 しかし、リーダーシップはこれにかかる時間が少なくなります。 これは、3人の小さなチームのチームリーダーでも気づかれています。 時間の30〜50％が外部コミュニケーションとチーム管理に費やされています。 管理能力が彼の仕事と成長の鍵となります。
彼は何を知るべきですか？ この質問はHabréで議論されました（たとえば、
here 、
here ）が、Toasterの回答（
here ）のほうが好きでした。
必要なスキルの範囲は非常に広く、目標を設定して実装を監視する一般的な管理スキルから、開発方法論とプロジェクト管理ツールとソースコードを習得するまでです。 コンピテンシーの一部は非常に普遍的です-コミュニケーションスキル。 また、たとえば、アジャイル手法はさまざまなスタックの開発者に共通です。
.Net / C＃開発エコシステムに固有の知識の領域について
説明します 。
- プロジェクトおよびソースコード管理。 これは、チームリーダーの職務に直接含まれています。
- アプリケーションアーキテクチャ。 さまざまなチームや開発者が対処できるシステムのブロック間の境界を定義するのは彼女です。
- 労働団体。 組織構造の主題はビジネス文献でよく研究されていますが、読むのは退屈です。 .Netのさまざまなスキルの組み合わせを持つ開発者をグループ化する方法と、誰に何を任せるかという特定のタスクがあります。
プロジェクトおよびソース管理
多くのチームと開発者は、独自のスタイルのプロジェクト管理とソースコードを既に開発しています。 たとえば、私はクライアントとしてGitExtensionsを使用するため、すべての.NetプロジェクトをBitBucket上に持っています。 タスクの管理には、Asanaを使用します。 JiraとTrelloはまったく役に立たなかった。
選択肢の選択について深く掘り下げる時間はありません。 味を試してみましょう。 しかし、コミュニティで尊敬されている人が、
私が別の楽器に
切り替えることの恩恵を受けると説明した場合、それについて考えます。
レポートとディスカッションから、次の質問に対する回答を取得します。
1.ソース管理ツールとプロジェクト管理ツールの比較。 TFSとGit。
2.それぞれに関連付けられている時間と費用。
3.より重要なもの-ツールまたはその使用方法。
また興味深いのは、以下のスピーカーと参加者の経験です。
4.マージバージョンの組織管理。
5.請負業者がいる場合のリポジトリの分割。
6.プロジェクト管理、タスクと作業項目、メトリックの収集と監視。
.Net環境の実践者からアドバイスを聞きたいです。 そのため、すべてのヒントが適用可能であり、抽象的ではありません。 まず、TFSの使用に関連するレポートから始めます。
TFSの実践に関するレポートを収集したときに、友人たちが「はい、すべてが私たちとは異なる」と言ったのは興味深いことです。
セクションが「宗教的」に見えるのを防ぐために、別のウィングを追加しました。
- まず、DevOpsに関するレポートが本当に必要でした。 これは今やファッションのトレンドであり、理解したいのですが、本当にこのDevOpsが必要なのでしょうか？ この概念には実用的な利点がありますか？
これは、カザンのイゴール・ジノビエフによる報告でした。 - 第二に、実際には、ツール自体は単なるツールです。 そして、それらをどのように使用するかが重要です。
たとえば、 作業組織のモデルとリリース戦略は何よりも重要です。 プロジェクト管理システムとソースコードの間に接続がありますか？ 彼女は両面ですか？ ブランチポリシーは何ですか？
これらの質問への回答は、 Victor Glushenkovのレポートで提供されます。
.Netアプリケーションアーキテクチャ
なぜアーキテクチャが重要なのですか？ さまざまなチームや開発者が対処できるシステムのブロック間の境界を定義するのは彼女です。
アプリケーションアーキテクチャは非常に包括的なトピックです。 ソリューションでコードを整理する方法について説明します。 さまざまなプロジェクトとライブラリを接続するときに使用されるデザインパターンの必要性。 CQRSやEventSourcingなどのトレンディなものについて学びます。
しかし、1.5時間のセクションは非常に小さいです。 それらは飽和状態になり、4つのレポートが聞こえます。
「1日でデスクトップアプリケーションの2層アーキテクチャから3層アーキテクチャに切り替える方法」というタイトルのプレゼンテーションを行い
ます 3層アプリケーションを作成および変更するときに、コードの重複を回避する方法についてです。 フィールドとエンティティを追加する場合、開発者は特定のパターンに適合するアクションを実行することがよくあります。 この作業は「ロープを引く」と呼ばれることもあります。 レポートは短く、むしろいくつかのレシピを明らかにしていますが、建築のトピックに関するものです。 ソリューションのプロジェクト間で3層アプリケーションコードがどのように分散されているのか、なぜこの依存関係組織スキームを選択したのかについて質問があります。
Visual Studio SDKとSnippetizerの使用に関する短いレポートがあります。 そして、
Amazon Web ServicesのDenis BatalovとAbbyyのEvgeny Agafonovからの 2つの複雑なレポート。
これら2つのレポートが、アーキテクチャに関するだけでなく、クラウドに関するものなのはなぜですか？
配布資料の雲について常に耳にします。 しかし、今それを急いで必要とするかどうかを理解する時間はありますか？ 通常のコロケーションホスティングからクラウドへの切り替えにはメリットがありますか？ そして、これは抽象的なものではなく、.Netプロジェクトに興味があります。 これは私たちがスピーカーに尋ねるものです。
セクションの年代順と会議の喜び
免責事項：非コンテンツ会議の形式について（
Habréに投稿 ）、イベントの経験を考慮に入れて（
Habréに投稿 ）。
楽しみのためにプログラムしています。 そして彼のためにイベントに行きます。
「すべてを語る」という不可能な目標を設定するわけではありません。 しかし、私たちは参加者の時間を楽しく充実したものにするよう努めています。
したくないことは何ですか？ 一日の終わりに技術報告書で人々を「緊張させる」。 したがって、最初に、より技術的で議論の余地のないトピックを配置します-これが「アーキテクチャ」セクションです。
何を取得したいですか？
夕食とアフターパーティーで一緒にチャットする満足した参加者。したがって、途中で-誰にとっても重要なトピックは、プロジェクトとソースコードの管理です。 そして最後に-労働組織や「チームリーダーが成長する」など、読みやすく、柔らかく、議論の余地のあるトピック。
178人がすでに12月12日を有効に使う方法を決定しています;）より多くの人を受け入れたいという希望にもかかわらず、225人が快適にサイトに座ることができます。 残り50か所未満です。今すぐ登録してください。
プログラムと登録： http : //gosharp.ru/TLD2014お待ちしております！