急激な変化のコストにどのように対処しますか？

最近のほとんどの開発者と同様に、顧客コラボレーションや変更への対応などのアジャイルプリンシパルを高く評価していますが、製品所有者（または要件と優先順位を決定する人）が頻繁に要件と優先順位を変更するとどうなりますか？1日に数回好きですか？

私は最近、バグがあり、不完全であり、想定される最も単純なシナリオを処理することさえできなかった小さなコードベースを継承しました。技術的な問題に対処することはできますが、1日に数件のメール、テキスト、または電話があります。さらに悪いことに、ほとんどのことは、ソフトウェアが実際に行うこととは関係なく、実装するのに何日もかかるような些細なことです。時間は非常に長く、最も重要なことに最初に集中する必要があることを説明しようとしましたが、翻訳が1日か2日後に起こるため、翻訳で何かが失われるようです。

無駄な努力の量を減らすのに役立つ、または少なくともこの混oticとした行動のコストを説明するのに役立つ製品所有者ハンドラーの役割、詳細な研究、比phor、または引用がありますか？

これがバックログの目的です。新しいリクエストはバックログに書き込まれ、優先順位は反復境界でのみ変更できます。平均して1週間の遅延（2週間のスプリントの半分）は、非常に急を要する緊急事態を除くすべてを処理するのに十分な俊敏性を備えています。

ここに、私が同様の問題にどのように対処したかを示します。

変更要求の場合、顧客は優先度を設定します。開発者は、優先度の高いタスクで作業するために、タスクの作業を停止することしかできません。優先度が同じタスクは、到着順にスケジュールされています。（作業の開始後、タスクの優先度を変更することはできません。）

お客様に、最新のリクエストと同じ優先度を持つ重要ではないタスクXで作業しているため、彼のタスクで作業できないことをお客様に伝えると痛いでしょう。次に、その優先度レベルでは、最新の要求の前に50の些細で重要でないタスクがあることを彼に伝えます。本当のキャッチ-これらのタスクはすべて優先レベル1（最高）に設定され、... HIM ...したがって、彼はあなたがしているタスクからあなたを追い出すことはできません。さて、めったに使用されない設定オプションで、アイスランド語の翻訳の長い単語のためのスペースを空けるために、ウィンドウフレームを3ピクセル左に移動し終えたら...

また、SDオフィスのドアを閉めてロックし、電話を外しました。メールは午前10時、午後12時、および午後2時まで無視されました。人々が何を考え、感じていたとしても、世界はまだ日が暮れており、私たちは仕事を終わらせ、「顧客」はこれまでよりも速く、より良いソフトウェアを彼らに届けました。

優先順位がより現実的なものに落ち着くまでに数週間かかりました。ドアのロックを解除することなどができました。しかし、システムはかなり長い間残っていました。あなたはそれほど極端である必要はないかもしれませんが（私たちはそうしました）、上級管理職からのサポートが必要になります。しかし、それは動作します....

SOP。標準操作手順（または、少なくとも管理チームによって承認された緩やかなプロトコル）。部署で開発するか、管理チームと協力して開発する必要があります。話をする必要がある人は、製品の所有者/アカウントマネージャーの上です。

SOPが定義すべきものの例。

• クライアントまたは内部エンティティが変更を要求する場合に従うべき手順
• この製品の品質管理または検証にどのような影響および/または影響がありますか？
• 納期を合理的に決定する方法は何ですか？この繰り返し？次のバージョン？

そのような手順がなければ、誰もがゾンビに追いかけられているようにあなたに向かって走り、今すぐすべてを期待します。そのような人々はあなたの礼儀正しい「いいえ」または「お待ちください」を尊重しません。しっかりとした方針が整っていれば、これらのコード渇望のミュータントは、そのようなゆるいベースで物事を求めるとき、彼らが間違っていることを理解するでしょう。

最終結果はあなたにとって不幸であり、それはあなたの会社にとって最大の利益ではありません。

副次的な注意として、あなたは彼/彼女の位置と義務に対するそのような露骨な無礼によって引き起こされた誰かの混乱を相続したかもしれません。そのような状況の人々は、高品質の製品を生産するのが難しいと感じる傾向があります。何か不思議だろうか？ソフトウェアエンジニアリング101。

これらの「準備、射撃、照準」条件下で作業することは非常に困難です。あなたは非常に不安な人から要件を受け取っているように聞こえますが、その意見は、上層の人が概念的なアイデアを提案するたびに変わります。

このような状況では、メールに応答する前に少なくとも1時間待つことが重要であることがわかりました。（テキストが組織全体で電子メールに広く置き換わっていない限り、私はテキストを無視します。）それらを読んでください。このようにして、明日、または2、3通の電子メールとは無関係になる可能性のあるランダムな緊急性の議論ではなく、必要な実際の作業に集中して時間を費やすことができます。私の最後の仕事では、何かが本当に緊急である場合、誰かがやって来て、私にまだメールを見ていなかったと仮定して、私に話しかけます同等）。

対面または電話での会話がある場合は、その人が自分の言葉で何を求めているのかを繰り返してから、新しい要件と優先度について質問してください。「正しく理解できたら、現在の最優先事項Xの作業をやめて、今度は最優先事項Yに焦点を当てる必要があると言っています。これは大きな変化です。ビジネスの変化を説明できますか？ UIを変更するだけでは機能しません。請求や在庫などの他のビジネスプロセスに変更はありますか？これらの新しいデータ要素がすべての月次レポートに表示されると期待していますか？」また、「この新しい取り組みを進めると、現在の最優先事項Xのリリースが少なくとも（週、月、

それが本当の緊急事態である場合、リクエスターはこれらの種類の質問に答えることができるか、すぐに可能性のある人にあなたを紹介することができるはずです。それが本当の緊急事態ではない場合、この種の会話はリクエスターにあなたがより多くの情報を取得する必要があることを考えると、変更を遅くし、変更が実際にどれほど重要であるかを決定させます。多くの場合、すでにパイプ内にあるものがより重要であるか、少なくとも停止する価値がないことがわかり、新しい要求がリストに載ることがあります。

変更が必要であると判断された場合、リクエストされた内容と変更についての理解をメールで書き留め、元のリクエスターに送信して、変更の範囲に同意するかどうかを尋ねると便利です。再度、説明として。このようにして、現在の最優先事項Xに取り組んでいない理由に反発がある場合、または元の締め切りが間に合わない理由を説明する必要がある場合に、何を行う必要があるのか​​、なぜそれが要求されたのかについて文書を作成しました満たされる。

これにより、リクエスターとの関係が改善されることが期待されます。これは、知識を実証し、彼らが望むものに取り組んでいることを確認しているが、変更に必要なものについて正直であることを確認しているためです リクエストについて詳細に尋ねることで、彼らはあなたが先を考えていることを理解し、本来持っていなかったかもしれないことを考慮します。

誰もが、まだそれを言及していないように見えますスプリントとそのユーザーストーリーをideally should be locked till the next sprint（典型的なスプリントは2-4週間かかります）。ロックすることにより-すでに開始されたSprintに追加のタスクを追加しないでください。

ユーザーのストーリーがスプリントに収まらないほど大きい場合は、スプリント中に達成可能なより小さなタスクにブレーキをかけます。また、前述のように、優先順位付けされたタスクでさえbacklogに保持する必要があり、次のスプリント計画では、一度フラグを立てると優先度が高くなります:)

編集：春には小さな変更のみを導入できます。それらが緊急状態を運ぶ場合。ただし、スプリント中に常にいくつかの緊急事態が発生する場合は、スプリント計画自体を変更する必要があります。

スクラムにはスクラムマスターの役割があります。これは、あなたが言及した問題に取り組むべき人です。

チームリーダー、プロジェクトマネージャー、スクラムマスターなど、責任のある人がいる場合は、その人と話します。

時間はあまりにもあり、最も重要なことに最初に集中する必要があると説明しようとしましたが、翻訳が1日か2日後に起こるため、翻訳で何かが失われるようです。

それを何度も何度も説明し続ける必要があると思います。一緒に仕事をしている特定の人々が役に立たない習慣を持っていることを受け入れる必要があるかもしれません。幸運な場合、最終的に変更が表示されます。

アジャイルマニフェストは、最も基本的な原則の1つは次のとおりであると言います：

開発の後期であっても、要件の変更を歓迎します。アジャイルプロセスは、顧客の競争上の優位性のために変化を利用します。

しかし、それらが日々の変化を意味するとは思わない。製品の基本価格を1日に何度も変更する必要があるかもしれませんが、その製品が1日に何度も販売される方法を変更しないでください。むしろ、製品の販売のワークフローは1週間ごとに変わる可能性があります（応答性が高く、動的なビジネスの場合）。

繰り返しますが、製品の販売のワークフローは毎週変更される可能性がありますが、製品全体は毎週変更されないと思います。今日マイクロソフトにOfficeを提供するマイクロソフトを想像することはできませんが、明日はOffoooseを提供し、1週間後にOffasooooooooooosを提供します。

いいえ、それはアジャイルが変化によって意味するものではありません。私はそれが貧弱なビジョンと変化の概念に対する大きな深い誤解から来ていると信じています。

開発者が洞窟に行き、自分の行動に集中する必要があるスプリントでは、変更を歓迎することは言うまでもありません。むしろ、変更を製品バックログに追加し、スクラムチームの手に渡る前に分析して優先順位を付ける必要があります。言い換えれば、スプリントバックログは不変ではありません。1日何回も変更を開発者の部屋に直接注入するのではなく、より短いスプリントを使用して俊敏性を高める必要があります。