私たちの役割は、単なる製品開発ではありません。また、社内および社外のお客様に「第一線のサポート」も提供しています。これらのタスクは、その性質上、常に製品開発の優先事項よりも優先されます。
製品開発とサポートの問題を管理するために、SCRUM のスプリントをどのように使用できますか?
質問する
1387 次
8 に答える
3
かんばんまたはスクラムばんを確認することをお勧めします。私はファンではありませんが、気が散ったり中断したりすることが避けられないシナリオには適しているかもしれません。スプリントを捨てますが、それでも優先順位の高いバックログを保持します。ばね速度を追跡して測定するのではなく、すべてのフェーズでレイテンシを測定します。
http://leansoftwareengineering.com/ksse/scrum-ban/
ただし、一歩下がることをお勧めします。効果的なアジャイルチームになりたい場合は、経営陣の買収が必要です...なぜ開発チームは第1レベルのサポートを行っているのですか？チームを内部顧客の気を散らすことから隔離することができる強力なスクラムマスターがいますか？あなたのサポート量はわかりませんが、チームメンバーを順番に回して、他のメンバーが集中できるように、すべてのサポート/内部顧客の失敗を一度に1週間受ける障害のある壮大な位置に移動します。いずれにせよ、スクラムマスターを選んでください...あなたが仕事にふさわしい人を見つけるまで、その位置を通してチームメンバーを交代させてください。
于 2010-08-20T04:46:42.193 に答える
0
両方を行うことはできません。スクラムを使用するか、顧客をサポートします。
スプリント中に中断されない少なくとも5人の開発者のチームを構築できる場合は、スクラムを使用することをお勧めします。通常、サポートが必要な場合でも、お客様はSprintが終了するのを待つことができます。一方、顧客サポートを実現することを仕事とする予備の開発者が1人いる場合もあります。
その後、チームはより価値の高い製品を開発することでその仕事を遂行できるようになり、カスタマーサポートの要件が減少します。そうすれば、私の意見では、あなたの組織はあなたのスクラムの経験から利益を得るでしょう。
于 2010-10-29T02:36:14.783 に答える
0
私のチームもこの状況です。私たちは多くの継続的な開発作業を行っていますが、いくつかのサポートも行っています。また、本番サービスをサポートしているため、問題が発生した場合は、すべてを破棄して修正する必要がある場合があります。
これまでのところ、以前と同じようにスクラムを使用し続けることを選択しましたが、進行中のチケットやその他の事前に知られていない作業のために、スプリントごとに時間を確保しています。毎日、受信チケット、Nagios 通知などを処理する専任担当者がいます。必要な場合、その担当者はいつでも別のエンジニアに相談したり、物事を引き渡したりできますが、私たちはこれを避けるようにしています。これにより、他のエンジニアの流れの乱れが軽減されます。
予約時間を計画するのは非常に難しいように思えるかもしれません。サポートの負荷は変動する傾向があります。ただし、私たちの経験では、ほとんどの場合、予約時間は適切な範囲内にあります。もちろん例外もありますが、数日余分に失うこともありますが、最悪の場合、スプリントからアイテムを削除します。しかし、これが最後に起こったのはいつだったか思い出せません。
要約すると、ほとんどの場合、サポートの負荷はかなり予測可能です。このためにスプリントの時間を確保すれば、うまくいくはずです。しかし、私ができる最も重要なアドバイスは次のとおりです。たとえそれが正しいことであるか確信が持てなくても、何かを試してみて、振り返ってみてください。一度試してみて、熟考して初めて確実にわかります。
于 2010-08-22T18:41:57.443 に答える
0
私はトレイに同意します。カンバンまたはスクラムバンを検討できます。しかし、あなたが真の開発チームのポスト プロダクションであり、奇妙な組織上の理由でかんばんに従うことができない場合はどうしますか?
私はあなたと同じような状況にあったチームのスクラム マスターでした。ここではっきりさせておきますが、「最初の行」と言うとき、ユーザーは製品所有者またはチームに直接連絡しますか? はいの場合、これを処理できる別のスクラム チームが必要だと思います。
通常、これを行う運用サポート スクラム チームがありました。このチームは、リリースおよび展開の活動も行う場合があることに注意してください。また、サポート活動のためにスプリントごとに別の開発スクラム チーム メンバーを運用サポート スクラム チームに参加させます。
重要な点は、開発スクラム チームのスプリントが開始されると、現在のスプリント中にプロダクション イシュー バックログの追加を開始することは推奨されないということです。現在のスプリントの価値を奪い、チーム メンバーの士気をくじく可能性があります。スプリント バックログ リストを安定させることは PO の責任であり、時にはこれを行うためにビジネスとの戦いを戦わなければならないこともあります。SM は、外部の影響からチームを保護し、スプリント バックログが安定していることを保証するために PO を支援するために必要なことを確実に行う必要があります。
これとは反対に、スプリントの目標が廃止された場合、経営陣はスプリントをキャンセルする必要がある場合があります。これは、会社の方向性が変わった場合、市場や技術の状況が変化した場合、または生産上の問題が多すぎる場合に発生する可能性があります。一般に、状況を考慮して意味がなくなった場合は、スプリントをキャンセルする必要があります。ただし、スプリントの期間が短いため、そうすることはほとんど意味がありません。
要約すると：
- 運用サポート スクラム チームを編成し、生産サポート バックログに取り組む第一線のサポートにします。
- 生産サポート バックログの作業を支援するために、スプリントごとに開発者が運用サポート スクラム チームに参加する順番を交代します。
- スプリントの目標がスクラム チームの PO にとって時代遅れになった場合、スプリントをキャンセルし、新しいスプリント バックログで新しいスプリントを開始できます。
参考文献: スクラム ガイド - Ken Schwaber と Jeff Sutherland (スクラムの作成者)
于 2010-09-15T20:53:42.320 に答える
0
少ない約束。スプリントを計画するときは、予想される最小速度を指定します。在庫が増えた場合は、いつでもバックログからアイテムを引き出すことができます。
利用可能なリソースがスプリント間で大きく変動する場合は、他の人が提案しているように、かんばんへの移行を検討してください。
于 2010-08-20T14:32:51.807 に答える
0
私は、開発、バグ修正、メンテナンス、作業を含む 2 つのツールをサポートするチームを持っています。したがって、私たちの状況はそれほど違いはありません。たぶん、私たちのソリューションもあなたのために働くかもしれません...
最近、2 週間のイテレーションでスクラムを使い始めました。私たちのやり方では、すべてのお客様に受け入れられるサービス レベル アグリーメントがあります。SLA の対象外のリクエストはスプリント計画中にのみ取り込まれますが、対象のリクエストはすぐに取り掛かることができます。
次に、各スプリントに「一般的なサポート」のユーザー ストーリーがあり、SLA に従うだけで済みます。その下に、何時間にもわたって評価される「不明なリクエスト」のタスクを入れました。新しい正当なタスクが発生すると、新しいタスクの評価を未知数から差し引くため、仕事の純利益は得られません。サポート作業の量を適切に見積もれば、開発時間の純損失にはなりません。そしてもちろん、最初の 1 ～ 2 回は過小評価する可能性がありますが、それは次のスプリントから学ぶことができます。
計画ですでにサポートが考慮されているため、1 つのスプリントで開発に関して何を達成できるかをより適切に評価できます。サポート リクエストを受信すると、チームがランダム化される可能性がありますが、一度に 1 つのタスクに集中できれば、この影響はそれほど深刻ではありません。
(また、Rational Team Concert をすべての追跡に使用し始めたばかりですが、この状況での有用性を説明できるほど長く使用していません)。
于 2011-09-15T13:21:11.023 に答える
0
こんにちは、言うのは簡単ですが、最初は少し複雑だと思います。
チームの各メンバーは、チームに存在する役割に慣れる必要があります。たとえば、私の会社では、約 1 か月の期間を使用して反復し、ローテーションを行います。
また、SCRUM と他のソフトウェア開発技術を組み合わせる必要があると思います。
スルタン
于 2010-08-20T04:37:50.123 に答える
0
スプリントの問題に取り組む前に、チームがスクラムの役割を中心に組織化されているかどうかを知ることが重要だと思います。
- プロダクト オーナー- プロダクト バックログ アイテムに優先順位を付ける
- ScumMaster - 毎日のミーティングを実施し、チームを軌道に乗せ、障害を取り除きます...
- チーム- 完了したバックログ アイテムの提供に専念する人々のグループ
プロダクト オーナーとスクラム マスターは、2 人の異なる人物でなければなりません。これらの役割はあなたの部署で定義されていますか? そうでない場合は、誰がこれらのスロットを埋める必要があるかを検討することをお勧めします.
とにかく、小さく始めて、いくつかのプロジェクトを選んで、プロセスを試験運用する方がよいと思います。過ちから学びましょう。何が機能し、何が機能しないかを確認してください。
他の作業が計画された活動よりも優先される可能性があることを知っているからです。数か月間、4 週間間隔でスプリントを完了してみてください。繰り返し、反映し、調整します。
最後に、顧客を巻き込み、スプリント レビューに招待します。素晴らしいフィードバックを得ることができ、製品はより速く改善されます。
于 2010-08-20T05:50:39.363 に答える