タグ付けされた質問 「waterfall」

2つの主要なソフトウェア開発方法論は、ウォーターフォールとアジャイルです。これら2つを議論するとき、それらを区別する特定のプラクティス（ペアプログラミング、TDDなどと機能仕様、大きな先行設計など）に多くの焦点が置かれることがよくあります。 しかし、実際の違いははるかに深く、これらの慣行は哲学に基づいているという点です。 Waterfall氏は次の ように述べています。 アジャイルは言う： 変化は避けられないので、変化を安くする。 私の質問は、TDDや機能仕様についてどう考えているかにかかわらず、ウォーターフォール開発の方法論は本当に実行可能かということです。 ソフトウェアの変更を最小限に抑えることは、貴重なソフトウェアを提供することを望む人々にとって実行可能なオプションであると本当に考えている人はいますか？それとも、避けられない変化を管理するために、私たちの状況でどのような実践が最も効果的に機能するのかという質問ですか？

47 agile  development-methodologies  waterfall 

一部のソフトウェア開発者はこれに非常に熟達しており、抽象的な要件を備えた実用的なコンセプトを提供できることで称賛されることがよくあります。率直に言って、これは私を夢中にさせ、私は行くにつれて「作り上げる」のが好きではありません。以前はこれが問題だと思っていましたが、変化を感じ始めました。そして、方向性がほとんど与えられていないときに思考（およびプログラミング）プロセスを調整する必要があるかどうか疑問に思っています。この能力をスキルとして習得し始める必要がありますか、それとも要件の収集とビジネスルールが最優先事項であるという考えに固執する必要がありますか？

44 agile  programming-practices  waterfall 

アジャイルに関する本を書くことができませんでした。私は彼らのプロセスをアジャイルと呼ぶいくつかの店で働いてきました。アジャイル開発の主なポイントの1つは、定期的なクライアントの関与です。スプリントの後、フィードバックを得るためにクライアントに作業をデモすることができます。すすぎ、繰り返します。 私が出くわす問題は、多くのクライアントがそのようになりたくないということです。彼らは、ウォーターフォールアプローチを好むでしょう。要件を事前に収集し、完了したら戻ってください。私の経験では、滝は機能しません。クライアントは、それを見るまで何が欲しいかを知りません。ウォーターフォールのジレンマは、すべての要件を事前に取得したい開発者の大規模なコミュニティによってさらに広まります。このようにして、彼らは自分が何を構築しているのかを知り、それに応じて設計することができます。そして、クライアントは、前述の要件に「サインオフ」したので責任があります。 私は間違っていますか？クライアントの関与なしにアジャイルは機能しますか？もしそうなら、私が議論した問題をどのように、どのように克服しますか？

23 agile  waterfall 

Vモデルは、滝の下半分が上に曲がってVを形成しているウォーターフォールモデルに過ぎないようです。新しいものを追加する方法がわかりません。 図から、私もフローを理解していません。すべての方向を指す矢印があり、最初に来るものを理解できません。Vを左上から下の中央まで、続いて右上まで戻ってきますか？または、アイテムが低くなる前にすべてを高くしてVを下に進めますか？ インターネットには、このモデルの十分な説明がありません。誰かがそれを本当のStackExchange形式で説明できたら素晴らしいでしょう:)

19 development-process  model  waterfall  engineering 

私の経験では、Waterfallモデルは柔軟性に欠け、要件の変更に無反応であることが証明されており、ソフトウェア開発の現代世界で実行可能な方法と見なされているようです。より俊敏で反復的な方法の成長と実証済みの実績は、プロジェクトの開始から製品の提供までほとんど変わらないことを前提とするリジッドブロックのプロセスに従う必要がある理由がないことを示しているようです。 ウォーターフォール開発方法論は、時間、コスト、および品質に関して、ソフトウェアシステムを提供するためにまだ実行可能ですか？

14 development-methodologies  waterfall 

最近、プロジェクトがあり、クライアントはツアーで忙しかった。通常のスクラムチームが結成されたため、経営陣はクライアントが積極的に参加できないため、アナリストをプロダクトオーナーとして任命することにしました。アナリストは、要件分析と仕様の草案作成のためにクライアントと密接に協力した人でした。 クライアントには、最初の2つのリリースをレビューする時間がありません。クライアントが3番目のリリースを見るまで、すべてが順調に進みました。彼はいくつかの機能に満足していませんでしたが、それらはmake shiftプロダクトオーナー（私たちのアナリスト）によって導入されました。 設計チームがすべてのページのモックアップを完了し、クライアントが各ページをチェックし、作業を継続することを承認するまで待つように言われました。スクラムチームは存在しますが、スプリントはありません。従来のウォーターフォール方式とほぼ同じように作業を終了しました。 スクラムチームメンバーまたはマスターをプロダクトオーナーとして任命するのは良い考えですか？クライアント/製品所有者の参加がない場合、スクラムに従う必要がありますか？

13 agile  scrum  waterfall 

一部の組織ではアジャイルの採用が失敗する場合があります。ウォーターフォールが唯一の（真の）方法である会社で働いていましたが、それは彼らがプロジェクトでアジャイルを試みて失敗したためです。 まだ覚えている人たちに聞いたとき（私は後輩でした）、本当に起こった悪い悪夢を思い出させたように、私は激しくシャットダウンされました。 プロジェクトが失敗した理由はわかりません。一部の企業ではアジャイルが失敗する理由がウェブ上に記載されていますが、その理由は主に経済的です。そこで、私はここでいくつかのフィードバックをお願いすると思った。 一部の組織でアジャイルの採用が失敗する理由は何ですか？または、別の言い方をすれば..アジャイルで成功するには何が必要ですか？

11 agile  methodology  waterfall  technique 

プロジェクトマネジメントチームの間では、「機能する」とは100％完成したものと見なす必要があることを意味するというこの考え方があるようです。ほとんどのプログラマーは、常にそうであるとは限らないことを知っています。機能の一部を機能させるために別のアプローチを試みている場合、それは必ずしも最良の解決策を見つけたことを意味するわけではありません。私はよく何かをやり終えて、一歩下がって、ビジネスルールが満たされた後、自分に何ができるかを自問します。この「もっと上手にできる」時間は、タイムライン内のどこかに実際に収まるでしょうか。私は、最良のアプローチは、コードを見つけたときよりも常に（ある程度）そのままにしておくことであると考えています。これは、リリース後のリファクタリングを意味する可能性があります。しかしながら、

10 agile  refactoring  optimization  waterfall 

約一年半前、私はアジャイル開発をしていると主張する職場に入りました。私が学んだことは、この場所はいくつかのアジャイルプラクティス（毎日のスタンドアップ、スプリントの計画、スプリントのレビューなど）を採用しているが、原則（ジャストインタイム/十分に良いメンタリティ、失敗を早期に公開する、リッチなコミュニケーション）を採用していないことです。 私は今、チームをより機敏にすることを任されており、開発者とビジネスチームから完全に賛同できることを確信しています。パイロットプログラムとして、15か月の要件収集を完了し、110ページの分析と設計ドキュメント（「石で書かれた」と見なされる）があり、最後にアクセスできないプロジェクトが与えられました。ユーザー（実際に製品を使用しないユーザーのマネージャーで構成される委員会のみ）。 私は小さく始めて、最初の5つのスプリントに期待される成果物のリスト（将来のスプリントは未定義のまま）、最初のスプリントの目標のリストを与え、最初のスプリントの目標を満たすのに十分なユーザーストーリーを取得するためにA＆Dドキュメントを分析しました。 それ以来、彼らはなぜすべてのスプリントのすべての要件がないのか、なぜ私が3番目のスプリント（もっと重要だと考えているが最初のスプリントの成果物に基づいている）の作業に着手していないのかと尋ねてきました。 2つのスプリント）そして、私のITチーム全体が忙しい作業または私たちとは無関係であると考えるさらに多くのドキュメントを求めています（ユーザーマニュアルを前に書く、すべてのスプリントのすべてのデータフィールドを前にドキュメント化するなど） 「前払い」作業）。 これは私にとって新しいプロジェクトマネージャーとしてはかなり大雑把でしたが、ストーリー管理のスクラムバン、ペアプログラミング、顧客に受け入れテストを（要件ドキュメントの一部として）提供してくれるなど、効果的に実装した改善点があります。 。 だから私の質問は： 抵抗力のあるビジネスに変更をより効果的に導入するにはどうすればよいですか？ ビジネスにアジャイルの利点を示すためにIT側に導入できる他のプラクティスはありますか？ 文書化の負担は私たちを苦しめています-ビジネスはそれをリスクとしてではなくリスク管理戦略としてまだ見ています。文書化の懸念と要求を緩和するために何ができるか（具体的には、文書化の量とそのすべてに対する事前のニーズ）。 私たちは私たちのビジネスとは別の建物にあり、約3ブロック離れています。彼らは、プロジェクトに参加している人に、同じ場所に他のプロジェクトに取り組むことはできません。建物。" 彼らは私たちがいつもそこに行って質問をまとめることを期待しています。そうすればすべてを一度に尋ねることができ、その人の時間を「絶え間ない中断」で無駄にしないでください。彼らからより豊かなコミュニケーションを得るために私たちは何ができるでしょうか？ 追加のアドバイスもいただければ幸いです。 ありがとう！

9 project-management  agile  waterfall 

私は大学の最終学期にいて、ソフトウェアエンジニアリングのコースを受講しています。クラスでは、さまざまなソフトウェア開発方法について学びます。私たちが重点を置き、プロジェクトの開発に使用したのは、ウォーターフォール法でした。 インストラクターが間違って実装したようです。クラス図では、プライベートプロパティを含むすべてのプロパティとメソッドをリストする必要がありました。私はいくつかの本、つまりClean Codeを読みましたが、これは関数を可能な限り短くし、焦点を絞っていると述べています。他の開発者の助けにならない場合、ダイアグラムにすべての小さな関数をリストするのは面倒です（それらは非公開で、他の誰も使用しません）。さらに、プログラムを設計するときにすべての小さな関数について考えることはないかもしれません。リファクタリングするときにそれらが一緒に来るかもしれません。 インストラクターは、すべての機能をリストするように依頼して、私たちに間違ったことを伝えましたか？そして、これらの設計方法は、開発者の個人主義を押しつぶして、コードを最もよく理解できるようにコードを記述しますか？

9 design  development-process  coding  waterfall 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私たちのチームは、私たちの開発努力をプロジェクト計画に表すよう求められました。私たちの仕事に不満を抱いたり、提供能力に疑問を投げかけたりする人はいません。プロジェクト計画のIT牛募集に参加しているだけです。問題は、私たちがアジャイルチームであり、正式なプロジェクト計画の観点から私たちの仕事について考えたことがないことです。 私たちは次に何をしているのかについての一般的な考えを持っていますが、反復を計画するまで100％確信が持てません。これまでのところ、私たちのチームは大部分が孤立していて、私たちの方法論や測定基準を外部の関係者に提示する必要はありませんでした。私たちは、エクストリームプログラミングで採用されているほとんどのプラクティスに従います。 四半期ごとに計画する会議を開催して、四半期に向けて取り組むストーリーの概要を把握します。とは言っても、私たちのストーリーは3x5カードで文書化されており、それらが機能するイテレーションの開始時にのみ推定されます。見積もりの​​後、そのストーリーをTeam Foundation Severに文書化します。イテレーション中、ストーリーにコードを添付し、ストーリーが完了したらストーリーに完了のマークを付けます。このデータから、バーンダウンチャートと速度チャートを生成できます。最も重要なのは、反復の平均速度がわかっているため、噛む以上に噛み付かないようにすることです。 私は開発方法を変更するつもりはありませんが、ウォーターフォールに精通している人だけが理解できるレポートで開発活動を紹介したいと思います。ではアジャイルプロジェクト計画のように見えるが何をするか、ケントマクドナルドはアジャイルとウォーターフォールプロジェクト計画との違いをレイアウトする良い仕事をしていません。彼は消耗品の弾丸の違いを明記しています： アジャイルプロジェクト計画は機能ベースです アジャイルプロジェクト計画は反復に編成されます アジャイルプロジェクト計画には、時間枠に応じて詳細レベルが異なります アジャイルプロジェクト計画はチームが所有しています 違いを説明できるのは素晴らしいことですが、データを提示するにはどうすればよいでしょうか。

9 project-management  agile  waterfall 

滝には通常、次のものが含まれます。 必要条件 機能設計 技術設計 ビルド テスト レビュー （展開） そして、このリスト全体の反復。ステップを忘れた場合はお知らせください。

9 project-management  waterfall