私はUniSenderメールサービスの PMです。 6年前、私はプログラマーとして来ましたが、現在は製品チーム間のやり取りを担当しています。 以前は、開発は1つの分散チームで構成され、2つのトラブルがありました。 しかし、愚か者や道路ではなく、スプリントと退屈なスタンドアップの遅れは30分です。
どのように解決したかを説明します。
私が言ったように、2つのトラブルがありました。
- スプリントは1つのタスクの誤りのために残るかもしれません 。 QAとDevは同じスプリントに取り組み、作業範囲は作業の最初に修正され、チーム全体がそれを実装するために勇敢に駆けつけました。 「マスター」ホットフィックスに向かう緊急のバグが時々到着しました。 スプリントタスクは非常に膨大になる可能性があります。 一部のタスクのリリース準備が整ったとき、他のタスクはまだ開発中でした。 その結果、チームは1つのタスクのためにスプリントを遅らせる可能性があります。
- スタンドアップは時間がかかり、疑わしい実用性がありました 。 チームは成長し、スタンドアップはスカイプで行われ、最初は何もトラブルを引き起こしませんでした。 スタンドアップが20〜30分間伸び始めたときに、何かがおかしいと疑い始めました。 出席者は、他のチームメンバーが何をしていたかを必ずしも理解していませんでした。
しばらくの間、私たちはこれらの問題を抱えて生き、戦いを試みました。
- 私たちは、人間に対する規制の導入によりスタンドアップを削減しました。
- 彼らは出席者の数を減らしました-ティムリッドだけがスタンドアップに行きました。
- 毎週のスプリントを試しました。
- スプリント内のタスクの数を減らしました。
これらの試みは期待した結果を与えませんでした。 根本的な変化をなくすことはできないという理解が生まれました。
ここで、製品についていくつかの言葉を言う必要があります。
私たちは24時間365日利用可能なSaaSソリューションです。 ユーザーに表示される部分-GUI-に加えて、時刻や国の政治状況に関係なく機能するシステムロジックの大きなレイヤーもあります。 つまり、サービスの開発と更新は、停止することなく継続的に行われます。
かんばんに行く
最初の大規模な革命は、「スクラムは私たちにふさわしくない」と気付いたときに起こりました。
かんばんに切り替えることにしました。 もちろん、私たちはトヨタではなく、完全な実装を開始しませんでした。 したがって、「私たちのかんばん」は「あなたのかんばん」とは異なります。
スプリントとチームワーク
バージョンの概要：
- スプリント（完成した機能）を作業単位と見なしました。
- タスクのチームは、負荷と必要なスキルに応じて収集されました。 通常、1つのチームには最大3人の開発者と1人のQAがいました。 スタンディングチームはありませんでした。
- 同時スプリントの数は複数になりました。
- かんばんの物理的なボードやその他の属性はありませんでした。タスクはJiraに追加することで実行されました。
この場合、チームは最初から最後までスプリントをしなければなりませんでした。 これはテスト段階にも当てはまりました。スプリントに取り組んだ同じ人がエラーを修正しました。
結果。
- 大きなタスクの遅延により、他のタスクは影響を受けず、その開発は完了しました。
- 展開中の問題の数が減少しました-1つのスプリントでは、雑多なタスクが少なくなりました。
スタンドアップ
スタンドアップは変容しました-彼らは別々のスプリントで働いていた各チームから1人の代表者によって訪問されました。
結果。
- スタンドアップはスタンドアップのようになり、標準の10〜15分に収まり始めました。
したがって、重大な問題を解決することができました。
しかし...氷山全体が島から浮かび始めました！
かんばんに切り替えた後、専用のフロントエンドチームを獲得し、バックエンドおよび製品チームの従業員が増えました。 部門間の相互作用はより複雑になりました-複数のチームが1つのプロジェクトに取り組むことができました。
いくつかの問題を解決しましたが、新しい問題が前面に出ました。
- すべての人がスタンドアップに参加したわけではありません-多くの場合、チームは情報を伝え直す必要がありました。
- 1つのQAで、異なるチームと2〜3個の並行スプリントを行うことができます。 私は切り替えなければなりませんでした。スプリントの機能を覚えて、テスト環境にコードを絶えず再デプロイします。
- QAはスプリントの作業プロセスに完全には関与していませんでした。 多くの場合、タスクはスプリントの終わりに彼らに到達し、開発が完了した後に要件が研究されました。
- プロジェクトのためにチームが集まり、その構成が頻繁に変更されました。 2人の開発者のチームは、3つのスプリントで同時に作業できます。テストで2つのスプリントと1つの現在のスプリントです。
- 開発時間を見積もることは困難でした。 前の未完成のスプリントがどれくらいの時間食べるかは明確ではありません。
しばらくの間、私たちは新しいルールに従って生き、新しい挑戦に苦しみました。 さまざまなアプローチを試して、多くのコーンを埋めました。
その結果、何かがおかしくなっているのではないかと再び疑い始めました。 あるべき新しい革命。
チームへの分割、新しいスタンドアップ、Fireteamの導入
私たちは、アイデアの開始から完成した実装のprodへの展開までのプロセスを分析しました。 他社でアジャイル手法がどのように機能するかを見ました。 開発プロセスへのアプローチはそれほど悪くないことがわかりました。
稼働中のシステムを壊す必要はありません。痛みを引き起こす瞬間を修正する必要があります。これは、開発プロセス中に変更したものです。
スプリント
私たちはまだ「スプリント」のコンセプトで運営していました。 スプリントは、チームの「ほぼ2週間」の作業範囲です。
プラスとは何ですか。 コードは「悪化」せず、大幅な遅延なしに製品に到達します。 チームが2週間でスプリントを行う場合は、1か月に引き締める必要があります。
改善できるもの。 多くの場合、マークを逃し、スプリントは少し遅れます。 一部のスプリントで作業する時間は、最初は評価が困難です（たとえば、多くのリファクタリング）。 この問題を解決する必要があります。
チームへの分割
1つの大きなチームをいくつかの小さなチームに分割しました。 それぞれに2〜3人の開発者と1つの専用QAが含まれています。 現在、チームは安定しており、プロジェクトごとに変更されません。 名簿を最適化したり、必要な専門知識をチームに追加したりするために、チームを切り替えることがあります。 BAはチームに参加しますが、同時に2〜3つのプロジェクトをリードできます。
残りはまだ1つのチームですが）
同時に、チーム全体が最初から完了まで1つのプロジェクトに取り組みます。 1つのプロジェクトは複数のスプリントで構成できます。
プラスとは何ですか。
- チームは同じ部屋にいます。 それ以前は、誰もが部門に座っていました。
- チームはプロジェクトの最初から最後までの作業に含まれているため、バスファクターが削減されます。
- チームメンバーは、レトロ、スタンドアップ、プレニングなど、すべてのイベントに参加しています。 すべての従業員は現在のタスクを最新の状態にしています。
- チームは、他の人のスプリントでは動作しなくなりました。 今ではすべてがネイティブです。
改善できるもの。 チームでBAを完全に紹介したいと思います。 通常、VAはチームの他の部分よりも早く作業を開始するため、これは問題です。
チームワーク
作業中のチームは、「まだテスト中のスプリント」と「これから見る新しいスプリント」の2つしかスプリントを使用できません。 原則として、開発の終了後、全員がリリースされると、新しいスプリントの作業を開始します。
プラスとは何ですか。 チーム作業がより予測可能になり、誰もがコードに精通しており、テスト中にスプリントをサポートできます。 参加者はタスクを切り替える可能性が低くなり、切り替えのプロセスが高速になりました。
改善できるもの。 理想的には、チームの作業中のスプリントは1つだけにする必要があります。 しかし今のところ、理想的な世界は私たちの世界ではありません。
消防隊
各チームは1週間選出されます。 このコマンドは、他の部門からの呼び出し、サービスの異常な動作、ホットフィックスなど、すべての外部刺激物に応答します。 このチームを「Fireteam」と呼びます。
プラスとは何ですか。 Fireteamウィークは、スプリントタイムのチームにカウントされません。 消防活動の合間に、従業員はタスクに集中できます。
- リファクタリング。
- スプリントタスクを完了します。
- ドキュメントを書きます。
- 他のチームと知識の伝達を行います。
欠点。 ファイアチームの1週間で、チームの人生は非常に波乱に富んでいます。 すべての部門は、これらの人々、特に技術サポートを直接愛し、知っています。 借方記入、ログの読み取り、緊急タスクのソーイング、すべての火災の消火など、さまざまなタスクを常に切り替える必要があります。 これらはすべて同時に行う必要があります。
スタンドアップ
2種類のスタンドアップを導入しました：
- チーム 彼らはプロジェクトに取り組むチームを巻き込みました。
- 全般 週に1回合格し、各チームのリードが参加します。
プラスとは何ですか。
- チームには、スプリントの状態が通知されます。
- 従業員は、他のチームが何をしているかを認識しています。
- スタンドアップは、「紙の一部の数字を読むための退屈な活動」にはなりません。 出席者は全員、危機にしているものを理解しています。 職場で問題のある領域を検出することが容易になりました。
- 立ち上がりには5〜10分かかります。
欠点。 チームはまだ情報をチームに伝えています。
まとめ
したがって、プロセスを徐々に変更して、差し迫った問題のほとんどを解決しました。
- 2〜3人の開発者とQAから安定したチームを編成しました。 各チームのスプリントは2つ以下になり、参加者は他の人のプロジェクトに取り組みません。
- 他の部門からのメッセージを処理し、サービスおよびホットフィックスの異常な動作に対応するチームがありました。 他のチームはこれらのタスクに気を取られません。
- 現在、同社にはチームと一般の2種類のスタンドアップがあります。 すべての従業員にはスプリントの状況が通知され、立ち上がりには5〜10分かかります。
まあ、私たちは取り組んでいます。
