背景と準備
2016年3月以来、 Cofounditは手動モードで働いていました。私たち自身がスタートアップの従業員と共同創業者を選び、ユーザーのニーズを調査しました。 要件を収集し、6月にサービスの開発を開始しました。 プロトタイプの作成には2か月、最終バージョンの完成には1か月かかりました。 6月中旬に製品の開発を開始し、8月にクローズドベータをリリースし、9月下旬に正式に開始し、引き続き機能します。
最初から、アジャイルのみを方法論と考えていました。 最初の1週間は計画に専念しました。タスクを1週間ずつ、小さなタスク、計画されたスプリントに分割しました。 ほとんどのタスクは1つのスプリントに収まりますが、最初は2つと3つのスプリントが必要でした。
最初のスプリントは率直に言って失敗しました。リリースを1週間遅らせ、スケジュールに遅れ始めました。 しかし、この経験はタイムラインを正しく評価し、余分な機能を放棄するのに役立ちました。 最初は、対称検索でサービスを作成したかったので、スペシャリストとプロジェクトの両方が互いのプロファイルを表示して、コミュニケーションを開始できるようになりました。 その結果、最初の部分のみが作業に残りました。候補者はスタートアッププロファイルを表示および選択でき、プロジェクトには、彼にすでに興味を示した専門家のみが表示されます。 つまり、実際には、最小限の実行可能な製品を発売しました。
パフォーマンス管理
JiraとTime in statusプラグインの助けを借りて、チームの動作とタスクライフサイクルにかかる時間を常に監視しました。 開発（タスクの作成からレビューへの送信まで）、コードレビュー（アウトソーシングチーム側での作業）、展開、テスト、承認（サービス側、つまり私による）の5つの主要な段階の時間を考慮しました。
この表は、タスクが開発の各段階にあった日数を示しています。 私たちの場合、一度に1人の専門家（開発者、テスター、またはマネージャー）のみがタスクに取り組んでいたという事実にもかかわらず、このデータは工数とは異なります。 具体的には、要件のコレクション、リリースタイムアウト、およびチームの速度を反映しないその他の段階は示していません。 6月の統計は実際には収集できなかったため、これらのデータは表にありません。
7月の作業結果に基づいて、作業中、テスト中、およびレビュー中のタスクの状態が最も長く3つの状態にあることに気付きました。 最も簡単な方法は、長時間のテストの問題を解決することでした。 私たちのチームのテスターはパートタイムで働いており、すべてのタスクをすばやくテストする時間がないだけでした。 請負業者と話し合い、フルタイムでプロジェクトに転送しました。 これにより、テスト時間が半分に短縮されました。
主な反復シナリオでは、セレンのセルフテストを開始しました。 これにより、テスターは回帰テストをより迅速に実施できました。 アンケートへの記入時間を短縮しました。これを行わないと、サービスの新しい機能をテストすることはできません。 その後、自動テストの数を増やし続け、パフォーマンス指標を改善しました。
第二に、開発段階で遅延に対処し始めました。 毎週の繰り返しでは、5日間（スプリント全体）仕事でタスクをハングさせることができませんでした。 最終リリースの前に、作業中の機能を少なくとも数回見たかった。 タスクを小さなものに分割することで問題を解決しました。
8月の結果によると、「レビューの時間」に関してアウトソーシングチームに遅れをとっていました。 最初は、コードを見てコメントをする必要があることを常に実行者に思い出させました。 11月に、この責任をテスターに移しました。 この時点から、タスクの作業が終了するとすぐに、彼自身がレビューの責任者に通知しました。 このアプローチは、テストサーバーへの展開にかかる時間が短縮され始めた11月にのみ完全に実装されました。
9月には、サービスチームによる「承認」と「テストサーバーへの展開の待機」が弱かった。 「受諾」は、単に注意を集中し、タスクに迅速に対応することで加速できます。 さらに、この時点で開発プロセスはすでにリズムに入っており、それを維持するために費やした時間はあまりありませんでした。
9月のテストサーバーへの展開時間は15％以上かかりました-非常に奇妙でした。 タスクのレビューを行った後、最後の実行者がテストのためにそれをレイアウトしたことが判明しました。 ブランチをマージする必要があり、競合が発生することがあり、実行者は現在のタスクから気をそらされました。 10月に、タスクをリポジトリに自動的にアップロードするメカニズムを固定し、展開時間を大幅に短縮しました。 その後、プロセスをデバッグし、その結果、2か月で展開時間を8（8！）時間短縮しました。
合計で、5か月で、問題を解決する時間をほぼ4倍短縮しました。 以前は、設定から結果の承認までのタスクパスには平均20暦日かかりました。 時間が5暦日に短縮されたため、開発段階の制御、問題解決の最終期限の評価、チームのロードの計画が容易になりました。
タイミング予測
もう1つの重要なタスクは、タイミングの正確な推定です。 請負業者との契約条件の下では、私が評価に入ることは一般的に不採算でした。 タスクがより迅速に行われた場合、私たちはそれに費やした時間に対してのみ支払い、チームが期限に間に合わなかった場合、私たちはより少なく支払いました。
しかし、正確なタイムラインを取得する他の理由がありました。 たとえば、実装速度が機能の選択に影響する場合があります。 1つの機能を実装するのに1日かかり、別の機能を実装するのに3日かかる場合、マネージャーはおそらく開発でより速いオプションを選択します。 同時に、実際の「1日」機能には同じ3日間かかることがあります。これが事前にわかっている場合、オプションの選択は異なる可能性があります。
すべてのプログラマーが評価に入る精度の割合を計算しました。 その結果、タイムラインをより正確に計画するのに役立つオッズを得ました。 たとえば、プログラマがタスクを10時間で評価したが、エラー率が約40％である場合、タスクには14時間かかると安全に想定できます。 利益
難しさは、用語の推定におけるエラーが体系的ではないという事実にあります。 プログラマは、4倍遅いタスクもあれば、2倍速いタスクもあります。 これにより、計算と計画が非常に複雑になります。
したがって、各開発者の用語の推定における平均偏差だけでなく、平均からの偏差の割合も計算しました。 20％未満の場合、これは良い結果であると考えました。このようなタイミングのエラーは、計画を妨げませんでした。 しかし、30％と50％の両方に偏差があり、リリースの作業に大きく干渉しました。
たとえば、開発者は締め切りを10日と見積もっており、締め切りからの標準偏差は40％であるため、タスクを完了するための実際の締め切りは14日間になります。 しかし、平均からの偏差が50％の場合、これはタスクの作業のさらに7日間です。 合計で、任期は約束された10日と予想される14日ではなく21日となります。このような遅延に対処することは不可能であるため、原因を見つけて修正しようとしました。
「ジラ」では、遅れとその理由を分析しました-計画時間からの大きな逸脱は、私から上流に渡らず、テスターがテスト後に数回戻るタスクにかかるという結論に達しました。
最初に、「受け入れ」からのタスクで状況を修正しました。 返品の主な理由は、テスターがタスクを十分に分析しなかったことです。 テスト中、彼は「状況に応じて」行動し、機能がどのように機能するかをまったく理解しなかった場合もありました。 テスターは各タスクの定義済み（DoD）を準備することを決定しました。詳細なテストケースではなく、何をどの方向に向けるかのおおよその説明です。
私の側では、これらのDoDに目を通し、誤解や不十分なテストの場合には、すぐにこれをテスターに指摘しました。 その結果、「受け入れ」からの返品数はほぼゼロに減少し、期限の評価が容易になりました。
テストから開発へのタスクの頻繁な戻りについては、ケースのほぼ3分の1がデプロイメント中のエラーが原因であることが判明しました。たとえば、必要なスクリプトが実行されていません。 つまり、このオプションはまったく機能しませんでしたが、これはテスターの助けがなくても理解できました。
サーバーにタスクを展開するとき、プログラマーは簡単なスクリプトをチェックして、すべての特性が機能することを確認することにしました。 その後のみ、タスクはテストに進みます。 この手順は5分以内で完了し、テストからのリターン数は30％以上減少しました。
複雑なタスクについては、開発者、チームリーダー、テスターと電話することにしました。 ドキュメントにコメントし、具体的にどのように実装したいかを詳しく説明しました。 開発チームがこの段階で欠陥を見つけた場合、すぐにドキュメントに変更を加えました。 このような場合、少なくとも2人の開発者とチームリーダーがタイミング評価に関与しました。
4か月間、計画の平均誤差は1.4倍減少しました。 平均誤差の50％を超える偏差の数は、9％から1％に減少しました。
統計を収集して分析することで、弱点を見つけてチーム管理エラーを修正するのに間に合いました。 それらのいくつかは「ホーム」デベロッパーに起こる可能性があり、一部はアウトソーシングで作業する機能です。 内部統計の取り扱いの原則が役に立つことを願っています。