少数の人々を集めて、「今、あなたはチームです、私たちはあなたからの結果を待っています」と言います、それはうまくいきません。 人々は整理し、健全な目標、動機付けを与え、問題を解決する必要があります。
TeamLead Confに関するEvgeny Fedoreevのレポートのこのデコードについて。 レポートでは、EugeneはBanki.ruで効果的な開発チームを編成するプロセスを段階的に説明しました。チームと部門内での採用、コミュニケーション、知識の共有、開発者とテスターの開発です。
講演者について ：Evgeny Fedoreev（ hardj ）は15年間ウェブ開発に従事しており、そのうち6人はチームリーダーの地位にあり、現在Banki.ruで新しいプロジェクトの開発を指揮しています。
Banki.ruとは何ですか？
会社の背景は、どの経験が議論されるかを知ることです。 Banki.ruは、毎月800万人以上のユニークユーザーを対象とするRunetの最大の独立した金融ポータルです。
IT部門の従業員数は50〜70人で、7つの開発チームに分かれています。 開発はすべて社内で行われ、リモート開発者はいないため、適切なプロセスとメトリックは必要ありません。
開発チームの主なタスク
レポートの準備中に、人々に質問をしました。
- 開発チームの目的は何ですか？
- 開発。
- それはどういう意味ですか？ 人が座って、リファクタリングし、利益をもたらさず、ビジネス上の問題を解決しない場合-これも開発ですか？
-...効果的に開発する必要があります。
開発効率
効率の概念は、マネージャーにとっても開発者にとっても1つです。
マネージャーにとって、効果的な開発は予測可能です。いくつかのビジネスイベントを実施するために、機能のリリース日またはタスクの完了期限がわかっている場合。
開発者にとって、これは技術的な負債を伴う作業です。 これは、それらを使用して以来の苦痛の1つです。 債務、リファクタリング、修正および改善のための時間はほとんどありません。
次のパフォーマンス基準は、バグの最小数です。 基準はバグの完全な欠如であると書くことができますが、これは起こらないことがわかっています。 さらに、テスターは必要ないため、気分を害します。
今後の課題 。 私は意図的に「思慮深い建築」を書きませんでした。 アーキテクチャをより深く掘り下げて事前に検討することは悪であるため、将来に向けて開発に手を加える必要がありますが、熱狂はありません。
すべてのチームが持っているその他の基準 。
開発プロセス
会社の開発と成長が始まった後、Banki.ruで開発プロセスの構築を開始しました。 新しいパートナーとプロジェクトが登場し、6〜9のバックエンド開発者では不十分でした。 開発プロセスを構築し、効果的な作業のために形式化する必要があるという結論に達しました。
最初は3つのチームがあり、それぞれに3人のバックエンド開発者と、サイトの一部を担当するマネージャーがいました。 バックエンド開発者は、作業に加えて、まだjQueryプラグインの組版と接続を行っていました。その時点では、フロントエンドには人がほとんどいなかったからです。
2人のフロントエンド開発者と2人のテスターをバグなしで生活させ、この構成で十分だと考えました。
理想的な世界では、開発プロセスは次のようになります。
- プロジェクトマネージャーはタスクをバックエンドチームにドロップし、実行します。
- 改訂が必要な場合は、フロントエンドチームにタスクを送信します。
- 改良後、フロントエンドはそれをQAに渡します。
- バグはありませんか？ -生産中。
私たちは、世界は完璧ではないことを提案し、バグはすべての開発に存在するため、QAはタスクを返します。さらに2つの矢印を追加しました。
スキームを更新した後、すべてがクールであると判断し、作業を開始しました。スプリント計画を実行し、バックエンドチーム自身がタスクを計画に入れました。 彼らは2ヶ月間働いて、何かが間違っていることに気づきました。
私たちのスキームは変容しました。 タスクはピンポンでボールのようにジャンプします。QAからフロントへ、そしてデベロッパーへ、そしてマネージャーにさえ届きます。
矢印は時間がかかります-サーバーと戦うためにタスクを配信するプロセスは長すぎます。 これは私たちに合わなかった。 タスクがより速く完了するように、矢印の数を最小限にしたかったのです。
納期を短縮する方法は？
最初に思いついたのは、 なぜタスクを返すのかについて質問することでしたか？ バックエンド、フロントエンド、およびQAが問題を異なる方法で理解するのはなぜですか？ ビューが異なるのはなぜですか？ プロジェクトマネージャーに有罪判決を受けたという結論に達しました。彼はタスクを完全に説明せず、PMにタスクをより完全に説明するように伝え、誰もが意味を理解できるようにしました。
3つのバックエンドチームが計画を立てました。 計画にはテスターとフロントエンド開発者が関与しましたが、3チームにはフロントエンド開発者2人とテスター2人しかいませんでした。 誰かが働かなければならなかったので、彼らはしばしば彼らを呼ぶことに成功しませんでした。
タスクを並行して開発に送信し、テストを高速化し、チェーン全体を待たないように、タスクをフロントエンドとバックエンドに分けました 。
すべてのソリューションを試しました。 その結果、時間が短縮されましたが、それでも私たちは幸せではありませんでした。
次に何をすべきか考えました。 市場には多くの企業や慣行があり、私たちは機能チームの研究、監視、掘り出し、入手を始めました。
機能チーム
これは、チームがタスクを完了するためのすべての完全なセットを持っているときです。
- バックエンド開発者。
- フロントエンド開発者。
- QA開発者。
それらの間にも接続があり、タスクはジャンプしてピンポンを再生しますが、接続ははるかに短く、時間がかかりません。 チーム全体が計画に参加し、彼女は結果に興味を持ち、単一の図を作成します。短時間で戦闘モードにタスクを実行する方法と方法を作成します。
その瞬間、アジャイルとスクラムに切り替えました。コーチとコーチを招待し、会社でマスタークラスを開催し、2週間のスプリント、評価、計画、グルーミングという古典的なスクラムを開始しました。 タスクは戦闘モードに入りますが、多くの問題が発生しました。
機能チームの問題
当時、6つの問題がありました。
- バスファクター 。
- 長期計画 。 計画のために、半日以上を割り当てました。タスクを整理し、昼食のために残してから、再度整理しました。 計画が終了したとき、誰も仕事をすることができず、やりたくありませんでした-その日は失われました。
- 閉じられていないスプリント 。 これは深刻な痛みです。スプリントのほとんどのタスクは「完了」列に達しませんでした。
- チームのタスクの異なる性質 。
- 新しいチームの出現 。
- チーム間での経験の交換 。
問題があります、私たちはそれを解決します。
バスファクター
当初、各チームはフロントエンド開発者、テスター、および3人のバックエンド開発者で構成されていました。 追加のフロントエンド開発者を雇いました- 役割を複製しました 。
指示で毎週の会議を導入しました 。 フロントエンド開発者は毎週別々に会い、新しい技術、問題解決について議論し、一般的な慣行とアプローチについて合意しました。 テスターはまた、収集し、授与し、テスト方法を決定し、自動テストについて議論しました。
フロントエンド開発者は、 1つの開発者が1つのチームのタスクを解決して他のチームにレビューするためにクロスコマンドコードレビューを導入し、少なくとも2つのステートメントの後にタスクをテストします。
自動テストが追加されました 。 チームには1人のテスターがいて、そのような量のタスクがなかったため、それを複製することはできませんでした。 私たちは別のチームのテスターの助けに同意しました 。彼は隣のチームのタスクの面倒を見て、休暇に行く従業員を置き換えます。 これにより時間が少し増えましたが、タスクはテストされました。
長期計画
計画に関するタスクを分析しました。 スプリントの時点で、全員が作業とコーディングを行い、ほぼ最初にタスクを開いて何をすべきかを考えたときに、テスターはタスクのテスト方法を理解するために「完了の定義」を明確にしました。
このプロセスには時間がかかりました。 計画する前にタスクを分解することにしました。開発者が空き時間にタスクを確認し、計画の準備ができるように質問することをお勧めします。
私たちは、マネージャーにタスクをより詳細に説明するように招待しましたが、大量のドキュメントを掘り下げないように、あまり多くしません。
意図的に、空き時間ではなく、追加のグルーミング時間を確保します。 彼らはチームとして集まり、タスクについて議論し、計画の準備をしました。
閉じられていないスプリント
これは苦痛です。 たぶん誰かがそれらを閉じますが、その瞬間はそうではありません。
スプリントキャパシティを10営業日から8日に減らすことにしました。 8日間の計画を立て、テスターを2日間残すと考えました。
実際には、開発者が見るタスクが少なくなると、タスクの実行が遅くなることが判明しました。 スプリントでのタスクが20％減ることで何も得られませんでした。
, , -. , , , . , , -, , — -, . , .
, - . . , «» — . , , .
! :
— . , !
— , ? , !
— , , ?
— , - . .
-. , , .
, , .
: . . . . . , . — . , . , , . . .
backlog . , backlog, . , , . — , .
. , , - , . .
, , , , . - , , — . , .
, - . , , 1-2 .
, : — , — . , — . Scrum , , , . , , — .
PM :
— , Agile, Scrum, , — , .
— , , 3 . . ? !
. .
— . , .
, Kanban Scrum: , , . . , , , .
, 2 : , , , , , .
, : , , , . — , , , - . -
Kanban, , , , . — , 1 .
2 1-2 , , , .
, , « ». .
— , . — .
:
— , , .
— !
:
— , - , .
— .
.
: … .
, .
.
wiki- , .
- , , , .
- Wiki- . , . , .
- - 1-2 , , .
.
- code-review. , -, . - code-review , , , . code-review , approve.
, , , — , . , , , . , code-review .
, . , , UI Symfony. .
: , - , . — Wiki, , , .
. , , . , , , . , . - , , , Debugger’ PHPStorm, .
, . - ?
KPI! KPI 2 . , .
, KPI, . . 100% KPI, - .
, . .
- , , . Scrum — Kanban, .
- . , . , . , , . , .
— .
. , , , : , PM, .
— , ., :
— .— , PM.
PM .
— , ?— PM , .
, , .
. .
, . Jira Slack, , , . Scrum-, .
, ..
. , . , . , - , — , — - . , . :
— ?
— !
— !
— , iMessage!
, - : , .
, : , , , 2 , .
« ».
— , , .
. , «», — , , . , , , . , , .
. , .
TeamLead Conf, 25 26 , . , , .