マネージャーなしで働いて、田園地帯にたどり着いた方法。 パート2.秘密の部屋

読者の皆さん、こんにちは！ 前回の記事で、 28人の開発者がマネージャーロールのないワークフローをどのように構築できたかについて説明しました。 私たちは楽しみながら仕事を続け、一つ一つ複雑な機能を生み出しています。 すぐにリリース前に眠れない夜があります。 そして、最も楽しいステップは、テクニカルスプリントとレトロリリース、そして次のリリースのイベントを計画することです。



今日は、ワークフローの透明性を最大限に高め、開発者が会社全体、特に他のチームで発生するイベントから抜け出せないようにするアクティビティについて説明します。 質の高いプロセスを構築し、喜んで作業したいですか？ 猫へようこそ！







開発プロセスの整理に関する私の経験を共有し続ける前に、会社の詳細に関するいくつかの質問を明確にしたいと思います。 同社の事業構造には、社内での製品開発とその後のソリューションの顧客への販売が含まれます。 同社には、マーケティング部門、営業部門、および開発部門以外の部門があります。 これにより、製品の基本的な要件のサプライヤーである製品アナリストと直接やり取りする可能性が大きく決まります。 通常の意味では、外部顧客はいません。 私たち自身が要件を開発し、開発し、販売しています。 伝統的な食品会社。



それでも、開発チームとチーム内の開発者との間でプロセスを整理する経験は、アウトソーシングされたソリューション開発者であろうと製品会社であろうと、会社のプロセスを構築するための例として使用できると主張しています。 「本による」古典的なスクラムは、経験が示すように、実際の製品の開発の現実には適用できません。そのため、製品の特異性がプロセスの特性を決定します。



現在、当社では28人の開発者が働いています。 7チームに適用されるもの（チームごとに4人の開発者）は、15チームが作業するときに不適切になる可能性があり、その逆も同様です。 同時に、コードベースの高品質アーキテクチャの開発と高品質プロセスの構築は、高コストなしで拡張できることを意味します。 また、ほとんどの企業では、大型製品の一方向の開発部門はわずか5〜7チーム（20〜30人）で構成されています。 そのような部門には、原則として、独立したアーキテクチャ上の決定を下す自由、内部の相互作用を組織し、プロセスを構築する自由があります。





だから、5-7チーム、独自の製品を開発しています。 マネージャーの参加なしでプロセスを構築する方法は？ 記事の最初の部分では、グルーミング、スケジューリング、レトロチームなどのアクティビティについて既に説明しました。 さらに、複数のチームの作業を同期し、一方向に移動できるアクティビティについて説明します。





Renga Structureのサンプルプロジェクト

チーム同期

私たちのスプリントは10営業日です。 デモ、レトロ、プランニングの各スプリントの間には2日間あります。 スプリントの間に、レトロ、デモ、および計画の2日間がある場合-これは、この2日間でコードが記述されていないことを意味しません。 これは、最近では、アクティビティはコードを書くよりも優先度が高いことを意味します。 この2日間は、スプリントの過小評価/再評価を償却するのに適したバッファーです。 チームの同期-スプリントスケジュールに関連付けられていないアクティビティ。 この同期は、毎週金曜日の昼食後に同時に行われます。 すべての開発者、テスター、製品アナリストが同期に参加しています。 一般的な意味では、チームの同期はスタンドアローンであり、1人の開発者が各チームから行動し、チームが何をしたか、コードのどの部分が影響を受け、これが他のチームにどのように影響するかを伝えます。



多くの場合、企業では、同期はチームチーム会議の形式で実行されます。 このアプローチにはマイナス点があり、これについては前の記事で詳しく説明しました。ある人は忘れることができ、他の人にとって重要な多くの詳細に注意を払うことはできません。 したがって、チームリードの同期はチームの時間を節約しますが、コミュニケーションの品質よりも著しく劣ります。 このような会議の後、チームリーダーは各チームに他のチームの進捗状況を伝え、それが各チームの時間を無駄にすることが理解されます。 これは、チームリードからチームにナレッジを転送するときに「デッドフォン」のマイナスが表示される場所です。 したがって、チームは、他のチームの作業から「あたかも」のように残り、チームリーダーを通じてのみ通信します。 その結果、関心が低下し、部門全体の一般的な開発の動きを理解する際のギャップが広がります。 チームの時間を節約することは、開発の一般的な方向や開発者間のコミュニケーションから隔離されることの欠点を決してカバーすることはできません。



チームの各パフォーマンスの後、原則として、出席者から明確な質問が出されます。 質問に対する答えが長くて遠い議論に発展することを誰かが理解した場合、彼/彼女は対話を中断し、それを別の時間に移動することを提案できます。 したがって、7つのチームの同期は40分以内で終了し、すべての開発者が他のチームによる製品開発の流れにとどまることができます。



同期して議論されているもう1つの重要な側面は、開発タイムラインの更新です。 原則として、2週間に1回、チームは「リリース時間に追いつく」可能性を公に評価します。 議論の過程で、どのチームに時間がなく、どのチームが時間通りにタスクを実行するかが明らかになります。 さらに、製品アナリストの存在により、開発の優先順位を変更できます。 たとえば、あるチームにはリリースのための機能をリリースする時間がありません。 もう一方のチームにも時間がありませんが、アナリストは最初のチームのビジネス価値が高いことを理解しているため、2番目のチームはリリース予定の機能を延期し、最初のチームが時間通りに作業を完了するのを助けます。 チームの各メンバーが、そのような決定に至った理由と議論を聞くことが重要です。 チームリーダーの同期についてこのような決定が行われるほとんどの企業では、一部の機能が他の機能よりも重要である理由をチームが明確に誤解していると確信しています。 ここでは、すべての質問をすることができ、理解できない瞬間はないはずです。



このような同期の結果は、実際の開発スケジュールと優先順位の開発プロセスの各参加者による認識と受け入れです。 また、各参加者は、アプリケーションコードのさまざまな部分の現在の変更を理解するため、マージ中の誤解、バージョンの競合、およびアプリケーション操作中の他の予期しない変更を回避できます。





Renga Architectureのサンプルプロジェクト

デモ

製品の変更について知ることができるもう1つのアクティビティは、コードレベルではなく、ユーザーレベルです-デモ。 デモはスプリントの翌日に開催されます。 デモは、投資家、マーケティング部門、企業幹部、社内開発部門など、すべての製品の利害関係者を対象に製品アナリストによって編成されています。 チームの主要なデモ分析。各チームは、開発、テスト、および製品開発機能のメインブランチへの統合を表します。 各デモスクリプトは、ショーの前夜に、要件を満たしているかどうかを確認します（完了の定義）。 未完成の機能やスクリプトはデモに表示されないことを理解することが重要です。 デモに示されているスクリプトは、製品のエンドユーザーがエラーなしで十分な確率で使用できることが理解されています。



スクリプトを表示するプロセスでは、原則として、この機能を開発する主な動機が説明され、主なユーザーの作業シナリオが表示されます。 スクリプトの完了後、出席者全員が質問をすることができます。 原則として、利害関係者は、機能の複雑さ、マーケティング部門、クライアントへの機能の適用可能性、およびいくつかの実装機能を明確にし、改善の要望を表明します。 ショー中に複数回、マーケティング部門から次のスプリントの開発計画に追加された機能を改良する要求がありました。



デモの結果は、すべての関係者向けの製品機能の次の増分の公開です。 マーケティング部門の開発者、テスター、従業員のデモでの存在のおかげで、多くのことが明確になり、製品のシナリオに関する関連情報の交換があります。 このような製品知識の透明性により、特定の機能からの期待の違いが最小限に抑えられ、オファーに迅速に対応できます。

レトロリリース

最も長く、最も労働集約的な活動の1つは、レトロリリースです。 このアクティビティは約5時間続き、昼休みがあります。 誰でもレトロをリードすることができますが、原則として、それは福音主義のチームリーダーによって行われます。 レトロリリースは、各チームによって実行されるいくつかのセマンティックブロックタスクに分割されます。 各タスクの結果に基づいて、特定のアーティファクトが表示されます。たとえば、成功カード、失望カード、リリース中の有益で不安な瞬間のマップです。 そのような各成果物は、原則として、チームの異なるメンバーによって提示されます。 レトロな結果によると、各チームは他のチームの積極的な実践を実践し、他のチームの作業方法のネガティブな側面の解決策を見つけようとします。 各レトロリリースは、各チーム内で適用されるプラクティスの透明性を高め、開発プロセス中に発生する問題を解決するためのさまざまなアプローチについてチームが議論できるように設計されています。



おそらく、レトロリリースは、会社で使用されているすべてのアクティビティの中で最も興味深く有用なイベントです。 短期間で、すべてのチームがポジティブな経験とネガティブな経験を交換し、ワークフローの編成、タスクの評価、機能の説明の作成の問題の解決策を互いに見つけるのを助けます。

秘密の部屋

秘密の部屋は、説明されているすべてのアクティビティが開催されるデモルームです。 フリップチャート、チーム数のテーブル、ボード、プロジェクターなど、必要なものがすべて揃っています。 開発部門には、ハリー・ポッターに関する多くの建設的な参照があります。 Sirius、Ravenclaw、およびOrde​​r of Phoenixもありますが、これについては今後の記事で詳しく説明します。





私たちの開発部門には、ハリー・ポッターへの多くの言及があります。

結論の代わりに

前の記事へのコメントで、このようなプロセスでは「マネージャーなし」で開発者が会議に出席するのに時間がかかりすぎるという考えが表明されました。 私は自分が活動の邪魔をすることを認めました。



正味時間では、スタンドアップに約0.4時間、計画に5時間、レトロに2時間、デモに2時間かかります。 28 * 0.4 * 10 + 5 * 28 + 2 * 28 + 2 * 28 = 28人の場合は12日間で364人時間、 1人の場合は1日1時間 。 開発プロセスの不可欠な部分であると考えているため、コードレビューやアーキテクチャの議論などのアクティビティは考慮しませんでした。



あなた（またはあなたのチーム）が開発以外の活動に一体的にどれだけの時間を費やしていますか？ 私の意見では、1日1時間の「話す」ことは、知識の普及、チームの反映、透明性の向上のための非常に少ない費用です。



Anatoly Osokin、Renga Softwareのリーディングソフトウェアエンジニア。