Renga開発チーム：マネージャーなしで働いて、田園地帯に到達した方法

単一のマネージャーではなく7つのチーム-これは可能だと思いますか？ 各デモでチームの1-2の機能を表示し、レトロなチームを実施し、レトロなリリースを行い、同時に仕事から本当の喜びを得るプロセスを構築しました。 同じ方法で作品を整理したいですか？ それから猫にようこそ。







Renga Software社は、情報モデリングテクノロジー （ BIM ）に基づいて、建物や構造物の設計用のソフトウェア製品の開発に取り組んでいます。 スプリントを行い、3〜4か月ごとにリリースをリリースします。 毎週システムのユーザーが増えています。 製品は非常に新しいため、バックログには重要な、そして最も重要な興味深いタスクがいっぱいです。 しかし、住宅、幼稚園、病院、劇場の設計に使用される製品を迅速に開発するにはどうすればよいでしょうか？









「アプリケーションが設計された建物よりも優れているようにする」

-建築家の冗談



そのため、開発部門は28人の開発者、3人の製品アナリスト、6人のテスターで構成されています。 各チームには、製品アナリスト、テスター、および4人の開発者が含まれます。 私たちは、スプリント、計画、レトロ、デモ、毎日のスタンドアップなど、スクラムに必要なすべてのアクティビティに従います。 さらに、SAFe（Scaled Agile Framework）の一部の機能を使用して、複数のチームの作業を同期します（毎週のチーム同期、3〜4か月ごとのレトロリリース）。 また、異常なアクティビティもあります。グルーミングと呼ばれ、チーム全体とアナリストとともにビジネス機能を分析し、機能と準備基準（DoD）の理解可能な要件のリストを取得します。

不平を言うか、不平を言うか、それが問題です

古典的なスクラムには、ご存知のように、製品の所有者、開発チーム、テスター、その他の利害関係者が常に存在する「計画」と呼ばれるアクティビティがあります。 計画プロセスでは、スプリントの目標、機能またはストーリーの構成（ユーザーストーリー）を開発します。 製品所有者の存在は、計画を成功させるための前提条件です。なぜなら、機能の目的を理解し、タスクに分解する過程で、経験豊富な（だけでなく）開発者の頭に浮かぶ機能に関する非標準的な質問に答えることができるからです。



ここに古典的なスクラムの最初の落とし穴があります-1日で7チームの計画で製品の存在を可能にする方法は？ たぶん、チームの非同期化と異なる日の計画の可能性がありますか？ 製品所有者は、スプリント計画に割り当てられた14のうち7日間を費やすことがわかります。 さらに、このような非同期では、すべてのチームの統合結果を表示するデモを実行する方法が不明確になりますか？



この問題を解決しました。 計画はチームによってのみ実行されます。 計画では、チームは準備基準が既に形成されている事前に準備され、拡張された機能の分解に従事しています。 したがって、計画時に、チームの全員（注意深く耳を傾け、グルーミングに積極的に参加した場合）は、特定の機能で何をする必要があるかを正確に知っています。 これにより、製品所有者の時間を節約でき、チームの計画を同期して1日で実行できます。



私たちのスクラムの特徴は、特別なアクティビティを実行することにあります-グルーミング機能。 彼らには、製品の所有者、機能を開発するチーム全体、テスター、テクニカルライター、そして興味のあるすべての人がいます。 食料品店では、機能の内容、外観、および主な使用例について説明します。 グルーミングプロセス中、出席者は機能、使用シナリオ、境界条件に関する質問をすることができます。 原則として、製品所有者からの機能の準備にもかかわらず、存在するものから常に2〜3の重要な質問があります。これは、機能の分析に影響を与え、最終バージョンに影響を与えます。 さらに、分析の基本ではない問題については、開発者はこの機能またはその機能の実装方法を自分で決定できます。 アクティビティの期間は機能の複雑さによって異なり、30分から5時間続きます。







このような壁の記録からも含めて、知識ベースが形成されます



したがって、かなり高価な労働活動が得られます。 しかし、これはグルーミングの唯一のマイナス点であり、その利点は明白であり、議論に費やされる時間を大きく上回ります。 すでにいくつかのプラスについて言及しましたが、もう一度見ていきましょう。

1. すべてのチームの計画に製品分析を含める必要はありません。これにより、計画を同期できます。 グルーミングはスプリントの前夜に行われ、すべての参加者にとって都合の良い時間に機能に取り組むことが計画されています。
2. チーム全体が、機能の機能と微妙さを議論するプロセスに没頭しています。 これにより、期待と実装された機能の事実との間の既知の矛盾が回避されます。 さらに、集合的な議論により、元々定式化された機能の不正確さとあいまいさが明らかになり、存在するものからの予期しない質問による分析エラーを識別します（そして、ほとんど常にそのような質問があります）。
3. 出力は、機能の要件と使用シナリオの完全で理解可能なリストです。 開発者はコードをチェックして機能の要点を確認し、テスターはシステム動作のシナリオを知って統合テストを作成します。

マネージャー自身

開発スプリントは過去10営業日です。 スプリントの間には、デモとレトロの日と次のスプリントの計画の日があります。 その結果、スプリントは曜日に関連付けられず、稼働日の絶対数にのみ関連付けられます。



各チームは、電報でチームチャットを行います。これにより、開発のすべての問題、活動の組織、および政治と宗教の問題をすばやく議論できます。 原則として、レトロな毎日のスタンドアップを計画することは、チャットで書く時間があるさまざまな開発者によって開始されます。 希望する開発者は、アクティビティの責任を負うことができます。 活動の時間を設定し、チームとして集まって話し合います。 原則として、各チームには経験豊富なチームリーダーがいて、優れたソフトスキルも持ち合わせているため、ディスカッションを控えることができます。 ただし、各チームでは、ほとんどの開発者がソフトスキルを十分に開発しているため、問題の建設的な議論が可能になり、非建設的な議論に費やす時間が最小限に抑えられます。 ほとんどのディスカッションの結果はホワイトボード上のメモであり、その写真はチャットアーカイブと履歴用のクラウドストレージに慎重に保存されます。

計画中

プランニングタスクは抽象的な労働時間で評価されます。これは、楽観的には1日に5時間と考えられます。 つまり、評価タスクに1日かかる場合、5時に評価します。 評価にはポーカープランニングを使用します。 原則として推定値が異なる場合、これは参加者の1人が他の参加者よりも多くのことを知っていることを示します。 したがって、タスクのコンテキストの理解は調整され、結果として、タスクの再評価が行われます。



オウムやストーリーポイントを使用して評価しませんか？ 時間が経つにつれて、次のリリースで機能を開発するというもっともらしい約束をするために、チームが開発速度を正しく評価することが重要であるという結論に達しました。 評価の時間単位での主な批判は、開発者の経験とコードセクションへの精通度に依存していることです。 同時に、ストーリーポイントを使用すると、特定の開発者を参照せずに作業量を評価できます。 しかし、たとえば次のスプリントで、初心者がたとえば3ストーリーポイントでタスクをとるとどうなりますか？ 彼はそれに3日を費やしますが、経験豊富な人は1日で管理します。 したがって、スプリントスコープはスプリントの時間枠に関連付けられなくなります。 計画プロセスでは、時間をタスクに合わせます。 経験豊かな開発者が2時間でタスクを評価し、5時間で経験の浅い開発者が評価することがあります。 議論の後、最終評価は5時間になる可能性があります。 したがって、問題の評価を過大評価する可能性がありますが、一方で、スプリントスコープの開発のデフォルトから保護されています。



分解されたタスクに加えて、機能のバグプールが示され、テスターに​​よる評価も含まれます。 その意味は、機能の潜在的なバグの不確実性の程度を示すことです。 不確実性は常に30〜50％とみなされるようです。 それにもかかわらず、経験は、不確実性がタスク自体のコンテキストに依存することを示しています。 たとえば、GUIの非典型的な使用またはQtの不明な部分に関連するタスクのバグは、頭痛の種になる可能性があります。 同時に、よく知られている機能を拡張する機能は理解可能で予測可能です。 これにより、開発時間の基本的な見積りに加えて、バグを修正するためにスプリントに何時間もストックすることができます。

レトロ

私は、最もポジティブなスプリント活動に関する話を終わらせたいと思います。 レトロのプレゼンターは、原則として、ルールに従って選択されます。最も長い間レトロを実施していない人。 レトロでは、ポジティブなリストを作成し、それほどハイライトではありません。 原則として、プラスに関しては、「デモで3つの機能を表示」、「難しいバグを修正」、「チームの誕生日を祝った」などの記録があります。 短所に関しては、「機能を完成させる時間がありませんでした」、「再現性のないバグを発見しました」、「アーキテクチャの問題を発見しました」という正反対が見つかりました。 各マイナスについては、原則として白熱した議論が行われ、建設的な提案と対応する改善につながります。 以前のレトロを読み直し、各スプリントで以前のマイナスに戻らないことを確認すると特に便利です。







それぞれのレトロな雰囲気は素晴らしいものですが、いくつかのデメリットは非常に深刻です。「トリビュートは永続的ではありません」

道路上

議題は、チームの同期、デモ、リリース計画、レトロリリースの問題をカバーしていませんでした。 次の記事では、このことやその他について確実に説明します。



マネージャーなしで開発チームに参加してください。 BIMシステムをお試しください-夢の家をデザインしましょう。



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