アジャイルチーム内でカスタマーサポートを担当するのは誰ですか？
現在、チーム内のメンテナンスの役割があり、チームの開発者が2週間のスプリントごとにローテーションを行っています。
これは：
- ユーザーのバグレポートへの対応とそれらのストーリー/問題の作成
- 否定的なアプリストアレビューへの対応
- ユーザーの問題のトラブルシューティング
- ユーザーからの全体的なフィードバックと機能リクエストへの対応
- スプリントの計画時に知られていない緊急の欠陥の修正
これらのタスクはすべて開発者ドメイン内にありますか、それともプロダクトオーナーまたはスクラムマスターの責任の一部ですか？
アジャイルチーム内でカスタマーサポートを担当するのは誰ですか？
"顧客サポート"？真剣に、カスタマーサポートは「カスタマーサポート」チームによって処理されます。プログラミングとは大きく異なるスキルが必要です。開発者に、管理者または会計士と同じリーグに所属させる必要があります。多分特定の開発者ができたが、一般的に言えば、それは本当に悪い考え。
ユーザーのバグレポートへの対応とそれらのストーリー/問題の作成
これは製品所有者の仕事です。利害関係者からフィードバックを受け取り、チームの作業パッケージに反映させることが、製品所有者の主な仕事です。
否定的なアプリストアレビューへの対応
どのように応答しますか？マーケティングのように？コミュニティ関係のように？それはjobsとは異なります。また、開発者が通常持っているのとは異なるスキルセットが必要です。
ユーザーの問題のトラブルシューティング
それは開発者の仕事かもしれませんし、そうでないかもしれません。ほとんどの企業もこれを行うために別のチームを持っていますが、少なくとも、これらすべてのポイントの中で、これは開発者が行う必要がある資格である必要があります。
ユーザー全体のフィードバックと機能リクエストへの対応
利害関係者と話すことは、製品所有者の仕事です。
スプリントの計画時に知られていない緊急の欠陥の修正
製品所有者による優先順位付けの後、欠陥タスク/ストーリーがスプリントバックログにあるとすぐに、thatは実際に開発者タスクです。
TL; DR
カスタマーサポートはjobです。開発者が昼休みに行うことではありません。別のスキルセットも必要です。あなたは会計士を雇うのと同じ方法で誰かのために雇う必要があります。開発者に会社の本を週に1度書いてもらうこともありません。
決定的な文書 The Scrum Guide は何と言っていますか？
- ユーザーのバグレポートへの対応とそれらのストーリー/問題の作成
- 否定的なアプリストアレビューへの対応
- ユーザーの問題のトラブルシューティング
以下に示すように、プロダクトバックログを管理するプロダクトオーナー以外は何もありません。これらは、製品をサポートする他のチームが処理することができ、おそらく処理する必要があります。対処可能な問題が特定されると、スクラムチームは、以下で説明するように、スクラムフレームワーク内でアクションを実行できます。
- ユーザー全体のフィードバックと機能リクエストへの対応
- スプリントの計画時に知られていない緊急の欠陥の修正
これらの懸念については、ガイダンスと期待があります。
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
このイベントは、フィードバックおよび追加の要求の主要なソースでなければなりません。
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
欲求が特定されると、プロダクトオーナーまたはデリゲートは、洗練されるプロダクトバックログアイテム（PBI）を作成できます。
バグが重大であると判断された場合、さまざまな方法で優先順位を付けて実行できます。
- これは、次のスプリントで対処するために、プロダクトバックログの上部に配置されます。現在のスプリントがほぼ完了しているため、このオプションを選択できます。現在のスプリントでは見積もられた労力を完了できません。
- 開発チームと製品オーナーは、現在のスプリントバックログを変更するために交渉します。
Only the Development Team can change its Sprint Backlog during a Sprint.このオプションは、開発チーム、スプリントのタイムボックス内で問題に対処できる場合、スプリントの目標が危険にさらされない場合などに選択できます。 - プロダクトオーナーは、問題に対処できるようにスプリントをキャンセルします。
In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.
[〜＃〜] a [〜＃〜]gileはありません（tm）; アジャイル 哲学があります。
開発者は、サポートをまったく行わないことで間違いを犯しています。チームが関与する時間と場所があります。
多くの企業が、カスタマーサポートこそがビジネスのすべてであることを学んでいます。ソフトウェア会社、特にアジャイルにしようとしている会社（それがスクラムを使用する理由だと想定しています）が従来の会社よりもサポートに開発者を巻き込むことを期待しています。これは、製品の初期リリースでは非常に重要です。
サイロでサポートを提供する場合、バランスの取れた開発チームを配置することのポイントは何ですか？ユーザーの近くにいることで、コミュニケーションのラインがはるかに効率的になります。繰り返しになりますが、それがアジャイルの本質です。時間が経つにつれて、サポートチームが解決できる問題に当てはまる問題が増えます（パッチを適用する、ユーザーに回避策を示す、設定を変更する、アプリの使用方法を説明するなど）。ここで、 "個人とプロセスとツールの相互作用" に焦点を当てることが重要になります。
ほとんどの開発者は絶対にこれを嫌うと思います。彼らはむしろコーディングです。ただし、アプリがどのように使用されているのかを開発者が理解していない場合、開発者は販売グループやマーケティンググループの気まぐれや要求の犠牲になります。営業担当者はユーザーを知っているわけではありませんが、ストーリーを伝えて自分の主張をする方が得意です。
すべてのソフトウェアにバグがあります。あなたのチームは、それらをすばやく解決するという第一印象を与える必要があります（それが目標ではありませんか？）。二度目のチャンスはありません。
チームはサポートの責任を負わないという回答には同意しません。チームで何かを作成する場合は、その責任を負う必要があります。バグが報告されている場合は、修正する必要があります。チームのバックログにバグを含めることができます。サポートと開発を担当するチームを交代させることができます。または、スプリント中のある時間をサポート作業のために予約することもできます。
私の組織では、3つのレベルのサポートがあります。最初のレベルは、顧客で実装するコンサルティング組織です。 2番目のレベルはサポートセンターです。私たちは研究開発の第3レベルです。リリースされたバージョンにバグが見つかった場合は、修正します。
アジャイルチーム内でカスタマーサポートを担当するのは誰ですか？
一般に、カスタマーサポートチームまたは個人がカスタマーサポートを処理する必要があります。 Wordの従来の意味での適切な顧客サポートには、多くのソフトウェア開発者が持っていない一連の明確なスキルが必要です。それは、マーケティングや財務、管理サービスを誰が処理するかと同じです。
つまり、「アジャイル」はビジネスを運営するための方法ではなく、ソフトウェアを開発するための方法です。あなたのビジネスを運営する方法についての答えを提供するためにアジャイルに目を向けることはできません。
言われていることすべて、アジリティの最も純粋な形では、これはあなたのチームだけが決定できる問題です。一般的に、リストしたもののいくつかは開発チームに属し（実際のソフトウェア開発に関連するタスク）、製品所有者に属します（顧客とのやり取り）。あなたが言及したものはどれもスクラムマスターには属しません。
開始から最終的なデリバリーおよびサポートまでのソフトウェア開発のすべての側面をチームが担当している場合、ソリューションは会社とチームに固有であるため、ソフトウェア以外のデリバリータスクを処理する方法を理解するのはチームの責任です。 。
開発チームはソフトウェアを開発し、サポート作業は行わないでください。小さな会社ではpeopleが流動的であることを望みますが、通常、ほとんどの役割をかなり明確に定義しておくことをお勧めします。特定の従業員が優れた開発者であると同時に、カスタマーサポートを行うのに最も適したスキルと態度を持つチームの人である場合、その従業員は2つの帽子をかぶることができます。しかし、1人の開発者がサポートハットも着用しているからといって、残りの開発者チーム全員がサポートハットを着用する必要があるという意味ではありません。製品の所有者として採用された人が熟練した開発者でもある場合は、開発者の帽子をかぶらせてください。スクラムマスターも資格のある会計士である場合は、帽子をかぶらせてください。サポートハットを記入する必要があり、チームでこれを行うのに最適な人物が開発者である場合は、開発者とサポートハットの両方を着用できます。
個々のスキルと適性に基づいて複数の帽子を提供しますが、1つの帽子の責任を、それを効果的に着用できる一人を雇うことが不可能になるほどに拡大しないでください。
ハードコアのアジャイルを使用している場合、フィードバックはフィードバック入力の大部分を占めるため、サポートリクエストは私たちと同じくらい好きになるはずです。そうは言っても、サポートチームがいなくてもプレッシャーを取り除くことができずに圧倒されて遅れをとるのは簡単です。