開発途中で開発仕様が変更されないようにするにはどうすればよいですか？
問題：私が関わっているほとんどすべての開発作業で、開発を開始する前の計画にどれだけの時間を費やしても、常に途中または最後の方で大量の変更が必要になりますプロジェクトの。これらは、多くの再開発を必要とする大きな変更である場合があります。
私はお金を払うクライアントのために働きません、これは社内開発ウェブサイトの社内開発チームです。だから、私はそれを何でも請求できるようなわけではありません。そして結局、締め切りに間に合わなければなりません。
質問：仕様の変更が途中または開発後に発生するのを最小限に抑え、防止するために皆さんが見つけた最良の方法は何ですか？
ヘルムートフォンモルトケに起因する有名な軍事的なことわざがあります。「敵との接触に生き残った戦闘計画はありません」。同じように、将来を予測して利害関係者の心を読むことができない限り、変更する必要のない仕様を作成することは不可能だと私は思います（たとえ関係者がまだ決心していない場合でも、彼らは主張した）。代わりに、いくつかの方法でそれにアプローチすることをお勧めします。
- 変更できるものと変更できないものを明確に区別します。それを利害関係者に明確に伝え、できるだけ早く変更不可能なことを明示的に承認させる。
- 事前に変更の準備をしてください。変更可能な部品をより簡単に変更できるようにするコード手法を使用し、構成可能性、カプセル化、明確なプロトコルに投資して、部品を個別に変更および交換できるようにします。
- 利害関係者と頻繁に話し合い、フィードバックと承認を求めます。これにより、同期が保たれ、手遅れになったときに「ああ、それは私たちが望んでいたことではない」と言われることはありません。他の回答で述べたように、アジャイルな方法論と頻繁なミニリリースがそれを支援します。
- 避けられない変更に対応する時間をスケジュールに入れます。あなたがそう思うと思うなら、早く「もっと時間が必要だ」と言うことを恐れないでください-あなたが与えられたスケジュールが非現実的であるなら、それよりも最初にそれを知っている（そしてそれを言っていることを記録している）方が良いです終わり。
- 変更が広すぎて締め切りを脅かしている場合-プッシュバックして、「この変更は可能ですが、締め切りをX時間でプッシュします。選択してください」のようなことを言います。
- 変更を要求し、変更に優先順位を付け、バージョンまたはリリースに変更を割り当てる正式なプロセスを作成します。 「このリリースではできませんが、次のリリースの予定に入れて喜んでくれるでしょう」と人々に伝えることができれば、「遅すぎる、変更を入れることができない」と言うよりもはるかに優れています。 、さようなら」と彼らをあなたの友達にするでしょう-彼らはあなたが時間内にリリースするのを幸せにしてくれるので、あなたの敵ではなく、彼らの変更を含む次のリリースに早く自由に行くことができます。
何かを届ける（私はWordを何でも使うのをためらいます）と頻繁に届けます。つまり、ある種の反復的な開発方法論を使用します。
これはアジャイル開発の基礎ですが、（ほとんど）どの方法でも使用できます。
プロジェクトを一連のミニプロジェクトに分割することで、クライアントの前に何かを置くことができるため、より細かく制御でき、クライアントが気が変わったときに古くなる長い開発スケジュールに縛られることはありません（彼らは）。
システムが進化するのを見ると、一部の要件は変化し、一部は冗長になり、その他は優先順位が高くなります。ただし、プロジェクトのライフサイクルを短くすることで、これらの変更に対処できます。
重要なサイズのソフトウェアプロジェクトを完全に仕様化することが可能であるという理論は、完全なファンタジーです。この理論は、ソフトウェア開発の歴史のほぼ全体にわたって、大小の組織で機能しないことがわかっています。
変更に対応するための方法を見つける必要があります。彼らが発生するのは、ほとんどの利害関係者が「はい、それが私が欲しいものだ」と言っても、実際に彼らが彼らの前にいるまで、彼らが何を望んでいるのか分からないからです。これが、反復法を採用する非常に多くの人々がいる理由です。
製品を反復するかどうかに関係なく、変更を適用する方法を見つける必要があります。変更を加えない方法を見つけるのは、重力を数分間オフにして飛行できるようにすることです。
変更を防止しようとしないでください抱擁それ。計画を立てれば進めるほど、計画が変わる可能性が高くなります。したがって、計画はlessであり、それ以上ではありません。小さなチャンクの作業コードを頻繁に配信するアジャイル開発方法論を採用し、顧客に数週間ごとに仕様を変更する機会を与えます。
あなたは間違った質問をしています。仕様の変更は常にあらゆるサイズのソフトウェア開発プロジェクトで発生します。
多くの場合、それはビジネス要件の変化が原因ですが、顧客（内部または外部）が何を反復するかを確認せずに何ができるかを視覚化するのが難しいために発生することもありました。現像液。
あなたが尋ねるべき質問は、「どうすればスペックをロックダウンできるか」ではなく、「すでに書いたものをすべて捨てずに、変化する環境に対応するためにコードとプロセスをどのように構成できるか」です。
次に、流行語のビンゴアリーナに進みます。アジャイル手法、反復開発、コンポーネントベース/モジュラーコーディングなどの技術的ソリューション、継続的な統合など、リストは続きます。
これらがすべての問題への特効薬であると言っているわけではありませんが、それらはすべて、あなたが説明しているまさにその状況を管理したいという願いから生まれました。
それが具体的な解決策を提供していない場合は申し訳ありませんが、変更を受け入れて管理するという考え方の転換は、それを回避しようとするよりも大きな利益を生むと思いがちです。
変化はただの驚きです...それが驚きであれば！
次のことを考えることをお勧めします。
- とにかくこれらの変化はどこから来るのですか？
- なぜ以前に気づいていないのですか？
- なぜあなたはこれらの変更に貢献していないのですか？
変化は私たちがすることの本質です。アルゴリズムをコーディングしたのはいつからですか正確に 1日目に想定したとおりですか？
しかし、もしあなたが変更に「驚いた」欲求不満な開発者であり続けるのを避けたいのであれば、私はあなたが決定がなされる場所の行動により近いところにあなたを見つける必要があると思います。結局のところ、あなたはあなたが製品をより良くすることができる方法のアイデアのバケットロードを持っていると確信しています。テーブルに着くか、「サプライズの変化」に対処しなければならないことを永遠に受け入れましょう。
開発サイクル全体でアクティブユーザーが関与し、できるだけ多くのアジャイル手法を使用することで、当社の製品を実際に支援できます。
仕様の変更は避けられませんが、ユーザーに対して透過的であり、何よりも頻繁に参照することで、ほとんどの変更ができるだけ早く取得されます。
まあ、それは「Throw Call」ですが、クライアントは常にもっと多くを望んでいますが、ここでは考慮すべきいくつかのポイントがあります。
HTMLモックアップ：アプリケーションのUI部分を定義するために常にHTMLモックアップを作成し、どのように見えるかを示し、意見を求めます。変更するのに妥当なものがあれば、それをHTMLプロトタイプで発生させます。これを使用して、UIの問題、基本的なフロー、およびいくつかのアドオン（並べ替え、ページ付け、表示するレコードの数など）などの多くのものを整理します。
相手側からの積極的な参加：ビジネス組織のために開発している場合、これは非常に重要です。彼らのビジネスに参加して、疑いを明確にするよう依頼し、間違いなく彼らに変更を依頼してください彼らは彼らの流れを望んでいる（必要ならば）。
モジュラーリリース：モジュール方式でコードをリリースし、リリース、テスト、フィードバックを取り、再度リリースします。
このため、事前に計画しすぎることはほぼ不可能ですが、まったく計画しないことの言い訳にはなりません。あなたの計画にあまり深く恋に落ちないでください、そしてあなたはそれらがあなたの心を壊すことについて心配する必要はありません。
あなたの会社の内部では、誰かがそれを認めるか、追跡するか、またはそれに予算をかけなければならないかに関わらず、ITリソースの使用にはコストがかかります。実際のところ、チームが作成できるコードは一定の時間内に限られます。すべての部門とプロジェクトがこの予算で共有しています。
誰もが要件を変更するのを防ぐことはできませんが、結果を免れることはできません。変更により、開発時間が大幅に増加する可能性があります。それは彼らが対処するか、変更を行わないことを決定しなければならないという事実です。ある部門からのリクエストは別の部門に影響しますか？変更リクエストは別のグループのタイムスケジュールに侵入するため、プロジェクトを別の部門の背後に完全に移動する必要がある場合があります。
私にとってはとても簡単です。
機能を注文した「製品所有者」に、これで問題ないことを伝えますが、カップルを選択する必要があります彼はこの締め切りのために欠けているかもしれない計画された機能の。
POとのハーフスプリントミーティングと考えて、スプリントが0に焼き切らないことを伝えます。
Ps。それが「PO」ではない場合「PO」を介して話をしないでください
私は、直接的または間接的に、顧客がほとんどの変更の原因であることがわかりました（また、最も重要なバグ、BTW）。したがって、明白な解決策は、顧客を排除することです。 （とにかく彼らは何が良いのですか？）
仕様変更が途中または開発後に発生するのを最小限に抑え、防止するために皆さんが見つけた最良の方法のいくつかは何ですか？
最善の方法はありません。開発の特定の段階で仕様への変更を制限するのは管理者の責任です。
ただし、変更を期待するような方法でソフトウェアを設計する必要があります。そうすれば、変更による影響はずっと少なくなります。 反復的および段階的な開発 は良い出発点です。
変更を防ぐことはできないので、それを受け入れる必要があります。あなたができる最も重要なことは次のとおりだと思います：できるだけ早く顧客から変更要求を取得するを試してみる必要があります。したがって、プロトタイプ（おそらくは紙のプロトタイプ）を使用して、顧客にできるだけ早く設計を提示したり、アジャイル手法を使用したりする必要があります。
SCRUMのような方法論を使用して、開発プロセスに一定の規律を導入することを検討できます。 SCRUMでは、チームは機能の実装をストーリーに分割し、各ストーリーに作業時間の見積もり（そのストーリーの実装に必要な作業時間または日数）を割り当てることにより、初期計画を作成します。
（すでに実装されているストーリーの）遅い変更が要求された場合、新しいストーリーを作成し、その実装作業を見積もる必要があります。次に、マネージャー（製品所有者）にアクセスして、新機能の追加の時間がかかることを説明します。その後、プロジェクトマネージャーは、追加の作業を受け入れてスケジュールを調整する（おそらく、まだ実装されていない他のストーリーをキャンセルする）責任があります。
チームがSCRUMまたは別の開発プロセスを完全に実装しない場合でも、少なくともstoriesに基づいて計画を導入し、各ストーリーの開発作業を見積もり、新しいストーリーが要求されたときにスケジュールを調整できます。
http://teddziuba.com/2010/05/why-engineers-hop-jobs.html
ソフトウェアビジネスがどのように機能するかをまだ理解していない、または気にしていないため、仕事後の夕方にストレスを感じ、不満を感じました。私は上層の誰かに立ち向かっても問題はありませんが、仲間のオタクの支持はありません。子供を持つことは雌犬です、え？もうすぐやめるだろう。
率直に言って、プログラマーがもっとボールを持っていることを望みます。これを見てみましょう：
「」私はお金を払うクライアントのために働きません、これは社内開発ウェブサイトの社内開発チームです、それで、私がそれのために何かを請求することができるようではありません。そして結局のところ、締め切りに間に合わなければなりません。 "" "
$を支払うクライアントと取引していて、契約（http://vimeo.com/22053820?utm_source=swissmiss）でお尻をカバーしていた場合、仕様の変更により、このクライアントにはより多くの時間と費用がかかります（または潜在的に同じまたはより少ない時間ですが、指数関数的により多くのお金）。あなたの会社は、より多くの時間とお金のコストを負担することなく、仕様の変更を回避しようとしています。
それまでの間、期限を守ろうとすると、あなたや同僚に不必要なストレスが生じます。友人/家族と質の高い週末を過ごすことはできません。あなたに仕事を投げている人はおそらくそれさえ知らないので、それは本当に不必要です。それは悲しいことです。
私が提案する解決策：それらに対抗するためのボールをまとめて持ち、無料の昼食はなく、すべてに費用がかかること、自動車整備士は時間がかかり、仕様が作業中に変更された場合はより多くの料金がかかること、請負業者は時間がかかることを説明する作業中に仕様が変更された場合はさらに料金がかかりますが、それには正当な理由があります。彼らがあなたと合理的な方法で協力する気がない場合は、グループとしてあなたは立ち上がって出発し、中断されたプロジェクトをピックアップして予定どおりに納品できる開発者を雇う必要があります。
次に、アジャイル開発の約束もあります。これは、厳しい期限がないことを意味します。
プログラマーがストライキをするのを私はまだ見ていませんが、これは何かあったでしょう。ソフトウェア会社は無能なマネージャーが多すぎます。 Craigslistで、または実際の企業内で、あまりにも多くの人々が無料で何かを得たいと思っています。 http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html
プログラマーはもっとボールが必要です。
私が見つけたアプローチは、ある程度うまくいく（明らかにすべてのマネージャーではない）です。「私はそれができると思います、はい。それは、このプロジェクトに割り当てる時間はどれくらいあるか？それはかなり大きな変更です。要求しています。」