スプリントの速度と顧客の保守的な採用スケジュールのバランスをどのように取っていますか？
3〜4週間続くスプリントが欲しいのですが、顧客は3〜4週間ごとに新しい機能を採用することを望んでいません。既存のお客様は保守的であり、機能と機能の最小基準を満たした後は、4週間以上安定したリリースを維持したいと考えています。 3ヶ月のサイクルでさえ彼らのためにそれを推進するでしょう。
一方、新しい顧客はより多くの機能要求を持っている傾向があり、スプリントを進んでフォローします。しかし、私たちが彼らのバーに会った後、この意欲は消えます。
迅速なスプリントの必要性と、アプリケーションの変更に対する顧客の保守的な見方とのバランスをどのように取っていますか？
私は特にSaaSシナリオに興味があります。
顧客の準備が整うまで、ショートリリースを社内に保管します。次に、4週間のサイクルのいずれかで顧客にリリースします。
可能であれば、顧客にソフトウェアレビューに参加してもらいます間リリース日。これにより、スプリントを順調に進めることができます。
スプリントは展開に関するものではありません
スプリントは開発者向けであり、顧客による展開ではなく、成果物への取り組みに関するものです。
スプリントの目標は、成果物を持つことです。実際に配信する必要はなく、デプロイする必要もありません。
私が参加しているすべてのチームは、運用チームが展開して本番環境にプロモートできるよりもはるかに多くの成果物ビルドを作成します。
サービスとしてのソフトウェア
SaaSは特定の状況であり、必要なときに必要なものを提供しますが、多くの通知なしに下位互換性を壊さないでください。新しいAPI機能を古いものと一緒にデプロイし、古いものにマークを付けることを妨げるものは何もありません非推奨。
非常に一般的なサポート終了/サポートポリシーを設定して、サポートの終了を誰もがいつ何を期待できるかを把握できるようにします。
迅速なスプリントの必要性と、アプリケーションの変更に対する顧客の保守的な見方とのバランスをどのように取っていますか？
私の見方では、顧客が3〜4週間以内に別の配達を必要としない、または望んでいない場合、迅速なスプリントは必要ありません。
ここでのバランスは、彼らの期待に合うように開発サイクルを変更することです。
彼らが頻繁にライブでデプロイすることを望まないというだけの場合は、公開デモサーバーをセットアップし、そこでスプリントのデプロイ/レビューを終了します。
彼らが本当にもはや製品を扱うのにそれほど多くの時間を費やしたくないと言っているなら、あなたは仕事量を軽くするか、やり直しのリスクを続けます。
後者の状況では、顧客が参加に興味がないため、スプリント期間に関係なく、PMまたは営業担当者が、とにかく顧客の役割を果たすことになります。残念ながら、より大きな手直しにつながりますが、それは本当です。