開発中に開発仕様が変更されないようにする方法

問題：私が関与するほとんどすべての開発努力で、開発を開始する前に計画にどれだけ時間がかかっても、プロジェクトの途中またはプロジェクトの終わりに向かって大量の変更が常に必要と思われます。これらは時々大きな変更であり、多くの再開発が必要です。

私はお金を払っているクライアントのために働いていません。これは社内開発ウェブサイトの社内開発チームです。だから、私はそれまたは何かのために充電できるようではありません。そして、一日の終わりには、締め切りに間に合わなければなりません。

質問：仕様の変更が途中または開発後に発生するのを最小限に抑え、防止するために皆さんが見つけた最良の方法は何ですか？

ヘルムート・フォン・モルトケに起因する有名な軍の格言があります：「戦闘計画は敵との接触を生き延びません」。同じように、将来を予測して関係者の心を読むことができなければ（たとえ彼らがまだ心を決めていなくても、変更する必要のない仕様を作ることは不可能だと思います）彼らがやったと主張する）。代わりに、いくつかの方法でアプローチすることをお勧めします。

1. 変更できるものとできないものを明確に区別します。それを利害関係者に明確に伝え、できるだけ早く変更できないものを明示的に承認させます。
2. 事前に変更に備えてください。変更可能な部分を簡単に変更できるコード手法を使用し、構成可能性、カプセル化、明確なプロトコルに投資して、部分を個別に変更および交換できるようにします。
3. 利害関係者と頻繁に話し合い、フィードバックと承認を求めます。これにより、同期が維持され、手遅れになったときに「ああ、それは私たちが望んでいたものではない」と主張することを回避できます。他の回答で述べたように、アジャイルな方法論と頻繁なミニリリースがあなたの役に立つでしょう。
4. 避けられない変化に対応する時間をスケジュールに入れてください。あなたがそう思うなら、早く「もっと時間が必要だ」と言うことを恐れないでください-あなたが与えられたスケジュールが非現実的であるなら、それよりも最初にそれを知っている（そしてあなたがそれを言っている）終わり。
5. 変更が広すぎて期限を脅かす場合は、「この変更は可能ですが、X時間までに期限を延ばすので、選択してください」などのように言い返してください。
6. 変更を要求し、変更に優先順位を付け、バージョンまたはリリースに変更を割り当てる正式なプロセスを作成します。「このリリースではできませんが、次のリリースのスケジュールに入れて喜んでいる」と人々に伝えることができれば、「遅すぎて、変更を入れられません」と言うよりもはるかに良いです、さようなら」とあなたの友人になります-彼らはあなたが時間内にリリースして幸せになるので、あなたの敵ではなく、彼らの変更がある次のリリースにすぐに行くことができます。

何かを早く（私は何かという言葉を使うのをためらいます）早く、頻繁に届けます。つまり、ある種の反復的な開発手法を使用します。

これはアジャイル開発の基礎ですが、（ほぼ）あらゆる方法で使用できます。

プロジェクトを一連のミニプロジェクトに分割することにより、クライアントの前に何かを早く置くことができるため、より制御しやすくなり、クライアントが気が変わったときに古くなる長い開発スケジュールに縛られることがなくなります（彼らは）。

システムが進化すると、要件の一部が変更され、一部は冗長になり、その他は優先度が高くなります。ただし、プロジェクトのライフサイクルを短くすることで、これらの変更に対処できます。

あらゆる規模のソフトウェアプロジェクトを完全に特定できるという理論は、完全な空想です。この理論は、ソフトウェア開発のほとんどすべての歴史において、大小の組織では機能しないことがわかっています。

変更に対応するための方法を見つける必要があります！ほとんどの利害関係者は、「はい、それが私が欲しいものだ」と言っても、実際には彼らの前に来るまで何が欲しいのか分からないからです。そのため、反復法を採用している人が非常に多くいます。

製品を反復するかどうかに関係なく、これらの変更に対応する方法を見つける必要があります。変更しないようにする方法を見つけることは、飛行を開始できるように重力を数分間オフにするよう求めるだけではありません。

変更を防止しようとしないで、受け入れてください。事前に計画を立てるほど、計画が変更される可能性が高くなります。だから、計画はもっと少なく、もっと。作業コードの小さなチャンクを頻繁に配信するアジャイル開発方法論を採用し、顧客に数週間ごとに仕様を変更する機会を与えます。

あなたは間違った質問をしている。仕様の変更は、あらゆる規模のソフトウェア開発プロジェクトで常に発生します。

多くの場合、それはビジネス要件が変化するためですが、顧客（内部または外部）が反復するものを見ずに可能なことを視覚化するのが難しいと感じるために起こることもあります。開発ソリューション。

あなたが尋ねるべき質問は、「どのように仕様をロックダウンできますか」ではなく、「すでに書いたものをすべて捨てることなく、変化する環境に対応するためにコードとプロセスをどのように構築できますか？」

次に、アジャイル手法、反復開発、コンポーネントベース/モジュールコーディングなどの技術的ソリューション、継続的インテグレーションなど、流行語のビンゴアリーナに進みます。リストは続きます。

これらはあなたのすべての問題に対する特効薬ではないと言っているわけではありませんが、あなたが説明しているまさにその状況を管理したいという願望のために発生しました。

それが具体的な解決策を提供していない場合は申し訳ありませんが、変化を受け入れて管理することへの考え方の変化は、それを回避しようとするよりも大きな配当を支払うと思う傾向があります。

変化は驚きに過ぎません...驚きなら！

以下について考えることをお勧めします。

• とにかくこれらの変化は一体どこから来るのでしょうか？
• なぜ以前に気づいていないのですか？
• なぜこれらの変更に貢献していないのですか（そして潜在的にさらに多くの変更を行っているのですか）？

変化は私たちの仕事の本質です。1日目に想定したとおりにアルゴリズムをコーディングしたのはいつですか？

しかし、不満のある開発者が絶えず変化に「驚かされる」ことを避けたい場合は、意思決定が行われるアクションにより近い方法を見つける必要があると思います。結局のところ、私はあなたが製品をより良くする方法のアイデアのバケット負荷を持っていると確信しています。テーブルに着席するか、それらの「サプライズの変更」に対処するだけでよいことを永遠に受け入れます。

クライアントは常により多くを求めていますが、ここで考慮すべきいくつかのポイントがあります。

HTMLモックアップ：常にHTMLモックアップを作成して、アプリケーションのUI部分を定義し、どのように見えるかを示し、意見を求めます。変更するのに妥当なものを見つけた場合は、HTMLプロトタイプでそれを実行してください。これを使用して、UIの問題、基本的なフロー、いくつかのアドオン（並べ替え、ページネーション、表示するレコード数など）などの多くのことを整理します。

反対側からの積極的な参加：これは、あなたがビジネス組織のために開発している場合、彼らのビジネスにあなたの疑問を明確にするよう頼み、間違いなく彼らのフローにどんな変化が欲しいかを尋ねる場合に非常に重要です（必要な場合）。

モジュラーリリース：コードをモジュラー形式でリリースし、リリースし、テストし、フィードバックを取り、再度リリースします。

そのため、事前に計画を立てることはほぼ不可能ですが、まったく計画を立てないという言い訳にはなりません。あなたの計画に深く恋しすぎないでください。あなたの計画があなたの心を壊すことを心配する必要はありません。

社内では、ITリソースを使用するのにコストがかかります。だれかがそれを認めたり、追跡したり、予算を立てたりする必要があるかどうかは関係ありません。現実には、チームは一定の時間内に大量のコードしか作成できません。すべての部門とプロジェクトがこの予算で共有しています。

誰かが要件を変更することを防ぐことはできませんが、結果を逃れることはできません。変更により、開発時間が大幅に増加する可能性があります。それは、彼らが対処しなければならないか、変更しないことを決定しなければならないという事実です。ある部門からのリクエストは別の部門に影響しますか？変更要求は別のグループのタイムスケジュールに違反するため、プロジェクトを別の部門の背後に完全に移動する必要がある場合があります。

開発サイクル全体でユーザーが積極的に関与し、可能な限り多くのアジャイル手法を使用することで、製品の開発に本当に役立ちます。

仕様の変更は避けられませんが、ユーザーに対して透過的であり、何よりも頻繁に相談することは、ほとんどの変更ができるだけ早くキャプチャされることを意味します。

私にとってはとても簡単です。機能を注文し
た「製品所有者」に、これで問題ないことを伝えてください。ただし、この期限までに予定していない機能をいくつか選択する必要があります。
スプリントが0に燃え尽きないことを彼に伝えるPOとのハーフスプリント会議と考えてください。

追伸 「PO」ではない場合、「PO」を介して話をしないでください

仕様の変更が途中で発生したり、開発後に発生したりするのを最小限に抑え、防ぐためにあなたが見つけた最良の方法は何ですか？

最善の方法はありません。開発の特定の段階で仕様の変更を制限するのは管理者の責任です。

ただし、変更を期待するような方法でソフトウェアを設計する必要があります。そうすれば、変更の影響ははるかに少なくなります。反復的かつ漸進的な開発は良いスタートです。

直接的または間接的に、顧客がほとんどの変更（および最も重大なバグ、BTW）の原因であることがわかりました。したがって、明らかな解決策は顧客を排除することです。（とにかく彼らは何がいいの？）

変更を防ぐことはできないので、それを受け入れる必要があります。あなたができる最も重要なことは、あなたができるだけ早く顧客から変更要求を取得しようとする必要があると思います。そのため、プロトタイプ（おそらく紙のプロトタイプでも）を使用して、アジャイル手法などを使用して、できるだけ早く設計を顧客に提示する必要があります。

SCRUMのような方法論を使用して、開発プロセスに何らかの規律を導入することを検討できます。SCRUMでは、チームが機能の実装をストーリーに分割し、各ストーリーに作業時間の見積もり（そのストーリーの実装に必要な労働時間または日数）を割り当てることにより、初期計画を作成します。

（すでに実装されているストーリーの）遅い変更が要求された場合、新しいストーリーを作成し、その実装作業を見積もる必要があります。次に、マネージャー（製品所有者）にアクセスして、新しい機能には余分な時間がかかることを説明するだけです。その後、プロジェクトマネージャーは、余分な労力を受け入れ、スケジュールを調整する（おそらく実装されていない他のストーリーをキャンセルする）責任を負います。

チームがSCRUMまたは別の開発プロセスを完全に実装しない場合でも、少なくともストーリーに基づいた計画を導入し、各ストーリーの開発作業を見積もり、新しいストーリーが要求されたときにスケジュールを調整できます。

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

プログラマーはより多くのボールを持っている必要があります。

（明らかにすべてのマネージャーではない）うまくいくとわかったアプローチは、「私はそれができると思います。はい。それはこのプロジェクトにどれくらいの時間を割り当てますか？あなたはかなり大きな変化です」要求しています。」