スクラムはプロジェクト管理の方法論ですが、現在の状況にかなり満足しているチームの開発者にどのようにそれを「販売」しますか？
スクラムがどのようにして定期的なリリースを取得し、要件を修正し、最初に優先度の高いストーリーにチームを集中させることができるかをプロダクトマネージャーに説明するのは簡単なようです。TDDまたは継続的インテグレーションが開発者の日常生活にもたらすものを簡単に説明できました。
しかし、開発者はどのようにしてスクラムを採用することを確信できますか？スクラムはどのように彼らの人生を楽にしますか？
回答:
大きな目標（「ソフトウェアを完成させる」）を小さな断片（ストーリー）に分割し、現在のスプリントでどれを行うかを決定すると、生産性が向上し、ストレスが軽減されます。あなたが今何をすることになっているのかを具体的に知っているとき、強調することはほとんどありません。そして、あなたは大きな全体に圧倒されるのを感じるのではなく、小さな部分に集中できます。
スタックランク/バックログにより、マイルストーンの終わりが死の行進から守られる
開発者として、私がソフトウェア開発で最もよく目にする「破壊的なパターン」は、「外部コントローラー」（プロジェクト管理、経営管理など）が「お気に入り機能」が「オン」にならないという事実に非常に興奮したときですカレンダーの日付」と死の3月を注文します。
スクラムは、バックログリストで「重要な機能」の上位にランクされるため、開発者はこの緊張を2つの方法で積極的に管理するのに役立ちます。最初に、バックログで「お気に入り機能」を上位にランク付けして、彼/彼女が幸せになる可能性が最も高くなります。第二に、「点滅ウィジェット」をランク1に移動したため、非常に視覚的かつ具体的な回答が得られます。ランク7になったため、このスプリントで「バニーのバウンス」に到達しない可能性が非常に高くなります。このトレードオフに満足していますか？」
また、短いスプリントでは、「外部コントローラー」が作業を延期することにあまり動揺しないこともわかりました。「ウィジェットの点滅」が「マイルストーン1」にならず、「マイルストーン2」が今から9か月後に終了しない場合、「ウィジェットの点滅」のスポンサーは非常に怒っています。しかし、最初に完了しなければならない重要なことが6つあるため、「ウィジェットの点滅」が1ではなく7のスタックである場合、これはおそらくスプリント+ 1または最悪の場合はスプリント+ 2で到達することを意味します12週間または18週間後に表示されます（6週間のスプリントを使用）。私の経験では、せっかちな人は3か月待つのは「受け入れられる」だけでなく、3か月以上のマイルストーンの「滝」モデルに戻って、
最後に、スプリントの終わりに近づいていて、予想よりも時間がかかった場合、バックログアイテム5-6-7を次のスプリントにプッシュして、1-2-3が完了していることを確認できると非常に便利です。 -4、高品質で、70時間の週なし。結局のところ、次のスプリントは必ず5-6-7になります。繰り返しますが、延期に関係する時間枠が短いことを考えると、「外部コントローラー」は一般的にこれに慣れており、マイルストーンを2週間ずらして、毎晩夕食を注文することを主張しません。
スクラムチームのメンバーは、次のスプリントで何をするか、このストーリーをタスクでどのように分割するか、誰が何に取り組むかなど、多くのことを自分で決定することができます。 -管理。
要件が変更されるという事実は、最初から考慮されます。開発者は、正確な見積もりで詳細な仕様を作成する必要はなく、顧客が結果を見てすぐに気が変わることを理解するためだけに機能を開発するために数週間を費やす必要はありません...
いくつかのこと：
要件を最初から変更するというXavierのポイントを基に、クライアントが期待するものではないことを最初からすべての人が受け入れると、政治的な雰囲気が少なくなります。迅速な配信とレビューは、誤通信のコストが低いことを意味します。開発者は、非難ゲームをプレイする代わりに、クライアントが期待するとおりに動作するように変更することができます。
ストーリーポイント！開発者が物事を行うためのポイントを取得するのが好きではないもの!!？！真剣に、SC2またはStack Overflowでバッジを取得するよりも優れています。
開発者としてスクラムについて好きなことはいくつかあります。
開発者は、より多くの情報を事前に提供される傾向があります。製品の所有者は、次のスプリント中に行われるすべての作業を、適切な見積もりを可能にするために十分詳細に説明する必要があります。
Just in time推定とは、その推定がかなり正確であることを意味します。通常、誰もがスプリントで何が終了するかについてかなり良い考えを持っています。これにより、プログラマーとプロジェクトマネージャーは、不当な要求に反発するツールを利用できます。
3〜4週間ごとに後退し、息を吸い、少なくともペースを変えるのは良いことです。
自己組織化チームは、仕事にもう少し多様性を与えているようです。
少なくとも理論的には、スプリント中は中断や「緊急事態」が少なくなります。
毎日のスタンドアップミーティングでは、プログラマーは毎日いくつかの言葉を言うように強制されます。
ストーリーが各スプリントの終わりに明示的に終了およびレビューされるため、進捗状況が見やすくなります。
バーンダウンチャートは、進捗を追跡するための非常に効果的な軽量の手段です。