問題タブ [waterfall]

従来のウォーターフォールでは、難解なテンプレートに従って、通常は MS-Word 文書に要件がまとめられていました。「厳密な」ウォーターフォール モデルでは、このドキュメントは要件フェーズの後に凍結され、変更管理/変更管理プロセスが管理された変更の導入を担当します。(**) [通常、ドキュメントは「生きたドキュメント」になり、最終的には「生きた悪夢」になります]

現在、私は既存のデスクトップ アプリケーションを Web に (VB 6.0 から ASP.Net に) 書き直すプロジェクトを率いています。クライアントは、書き直したいアプリケーションのベースライン バージョンを持っています。[したがって、要件は凍結されています...スコープクリープはありません]。そのまま再利用するデータモデル。移行するフロント エンド/ビジネス ルールのみ。アプリケーションを見ると、それはせいぜい 3/4 の主要な画面であり、それだけです。

一部のチーム メンバーは、新しい開発に着手する前に、すべてを文書化したいと考えています (私の意見では古い考え方です)。UI を Web に変換し、古いコードを検索し、ビジネス ロジックを記述し、自動化された単体テストを実行し、統合テストに進み、画面ごと (または機能ごとにビジネス機能) を配信するのは、比較的簡単なはずだと私や他の人は感じています。

私の質問は次のとおりです。アジャイル開発では、これを最適化しない場合、どのように「アジャイル」を維持しますか。私の意見では、詳細なドキュメントを書くことは反アジャイルです。どう思いますか？アジャイルの第一人者は、上記の問題 (既存の VB 6.0 アプリを ASP.Net に書き直すという問題) にどのようにアプローチしますか?

免責事項: 1000 ページの機能仕様の作成は、契約上の義務、政治的必要性を満たすためである可能性があり、システムは本当に複雑になる可能性があります (現在、「複雑さ」の定義は暗い土地への旅です)。

もしそうなら、次のような「気分が良くない」ものにどのように対処しますか?

• 単体テストを書かない
• 継続的なビルドがない
• リファクタリングしない
• チームのコーディング標準がない
• ペアプログラミングではない
• 反復を行わない
• 毎日のスタンドアップはありません
• ふりかえりなし

現在、一部のアジャイル組織はこれらのプラクティスの一部を省略していますが、ほとんどの成功した組織にはそれらのほとんどが組み込まれています。

従来の開発プロセスの混乱に対処するために何をしていますか?

スクラムがウォーターフォール プロセスよりも優れている点を 1 つ挙げるとしたら、それは何ですか?

神話上の人月は今や古典的ですが、「外科チーム」の方法論は依然として興味深いものです。どの方法論がそれに最もよく似ているか、または同じ本質を持っていますか?

外科チームのアナロジーを要約すると: 外科医は問題/ビジネス領域を理解し、専門家です。彼らは、チーム内で疑問や対立があるときの権限です。外科医は、設計などの問題が発生した場合、専門家の小規模な緊密なチームとして機能し、互いに協力します。つまり、本質的に彼らはドメインの知識を持っており、正しいと思うことを任せられ、実際のコーディングを行うのでしょうか? チームの残りの部分は、サポート、テスト、文書化に重点を置いており、プロジェクト計画は委任されたタスクです。したがって、外科医は最も熟練した/訓練されたリソースでもあります。

答えは、プロジェクト、プログラミング、設計方法論である可能性があります。これは、主要な方法論ドメイン全体に影響を与えるように思われるためです。アジャイル、MDA、エクストリーム、ソーシング開発? この質問は、複雑なビジネス ドメインで大規模なソフトウェアの場合にも、より意味があります。COTS 開発者や一般的なユーティリティではなく、航空管制を考えてみてください。

以下の理由により、製品開発に携わるオフショア分散環境で働く従来の大規模なソフトウェア製品組織が、スクラムでのアジャイルの精神に従うことは容易ではありません。

1. 彼らの製品開発は反復的ではありません。製品エンジニアリング チームは、反復的なシステム エンジニアリングを数回繰り返した後、特定のリリースの製品要件、製品アーキテクチャ、および設計を事前かつ正式に最終決定します。これに対する変更は発生する可能性がありますが、大規模ではありません。

2. 製品エンジニアリング チームは、作成された仕様に基づいてオフショア チームがこの製品を構築するようになりました。これらの大規模なオフショア チームは、ここでは保証されていないため、反復的で経験的なモードで作業することはできません。

3. ただし、製品マネージャーは、オフショア チームによる製品開発を定期的に確認するために、短いイテレーションで段階的な納品を要求する場合があります。

4. これらのオフショア チームが、定義された正式なプロセス (経験的ではない)、管理者が管理する環境 (権限が与えられていない)、漸進的な開発アプローチ (反復的で適応的ではない) を使用してスクラムの変形に従うことができれば、彼らにとって非常に役立つでしょう。

5. この状況で実装された真のスクラム アプローチは、非常に偽善的に見えるかもしれません。ただし、従来のウォーターフォールのようなシナリオ向けのスクラムの正式な変形を彼らに提供できれば、彼らはそれを全員の利益のために使用する可能性があります。

このコンテキストについては、 scrumtales.blogspot.comのブログで詳しく説明しようとしました。

これはできますか？

私は、最初にプロジェクト管理のウォーターフォール方式を採用し、それに伴い、ソフトウェア設計への予測的アプローチを採用したことを知っています。これは、ドキュメント、UML、データベース スキーマ、データ ディクショナリ、ワークフロー、アクティビティ図などの膨大なパケットがあったことを意味します。

ソフトウェアに 10 年以上携わってきた今、リアクティブなアプローチからソフトウェア設計にアプローチする方がはるかに現実的であることがわかりました。私は頻繁にプロジェクト管理にスクラム アプローチを採用していますが、そのため、重いドキュメントはほとんど生成されません。ワークフローの仕様はほとんどありません (ただし、まだ使用されています)。これは、ソフトウェア作成に対するより動的なアプローチです。もちろん、時間の経過とともに頻繁にリファクタリングが行われます。時間の経過とともに、事前に計画していれば状況が劇的に変化していたであろう新機能が見つかるからです。

私たちにとっての大きな違いは、最初のアプローチは時間がかかり、ソフトウェア構築の世界ではより頻繁に失敗するように思われ、柔軟性に欠けることです。2 番目のアプローチは柔軟性を高め、失敗をより早く認識できるようにし (コースをより速く修正できるようにします)、すべての反復の最後に何らかの形の機能を提供します。

経験から両方の側面を知っているので、ソフトウェア開発のアジャイル アプローチよりもウォーターフォール アプローチを好む人が今でも多くいます。理解できません。

質問:アジャイルを裏付けるすべての研究がある何らかの形式のアジャイルではなく、なぜウォーターフォールを使用するのでしょうか? アジャイルではなくウォーターフォールを使用することの有力な議論は何ですか?

バッファに保存されている画像データのウォーターフォール表示を作成するのに助けが必要です。画像データのストリームは、カメラから取得されたときに画面を下にスクロールして表示する必要があります。Visual Studio C++ Windows フォームを使用しています。誰かがこの表示を実現する方法を理解するのを手伝ってもらえますか?

前もって感謝します

私はJava の世界でデス マーチプロジェクトに取り組んできました。このプロジェクトは、通常、複数のシステムにまたがり、ウォーターフォール アプローチに結び付けられていることが多く、管理が不十分で扱いにくく複雑なテクノロジが組み合わさったために、最初から失敗する運命にあります。

Rails と Django は、アジャイル開発テクノロジとしてもてはやされています。つまり、変化に迅速に対応できることを重視しています。

これは、大規模なエンタープライズ システムのデス マーチ シナリオの影響を受けないということですか? それとも、Rails/Django プロジェクトには、Java プロジェクトのように制御不能になるほどの複雑さの余地がまだあるのでしょうか?

さまざまな場所で、システムを事前に設計することで開発時間を大幅に短縮できるという主張を見てきました。つまり、設計に 1 時間費やすことで、コーディングを 1 週間節約できます。私の問題は、これが真実であることがわかった状況を見たことがないことです. だから私は人々がこれが真実である場所を持っているそこにある例を知りたい:

そう：

1. コーディング中にどのような問題が発生しましたか? （それとも避けられた？）
2. より多くの時間を設計に費やすことで、どのように問題を回避できた (または回避できた) でしょうか?
3. コードの問題を修正するのが難しかったのはなぜですか (または難しかったのでしょうか?)