私は常に、ソフトウェアの開発にアジャイル機能駆動開発プロセスを使用してきました。他の人は何を使用していますか?なぜそれを好むのですか? 私が FDD を好むのは、大学を出たばかりの私が FDD から始めたからです。大学では、すべてが非常に自由な形式であり、私の「顧客」は通常、大学で研究を行う以外に業界での経験があまりない教授でした。
現在、私の顧客はそれほど寛容ではなく、私は医療分野で多くの仕事をしています. 敏捷性と高レベルの品質は必須です。
1903 次
15 に答える
10
職場では、ICONIX プロセスを使用しています。これは AGILE 手法のサブセットであり、動作要件駆動型です。ICONIX プロセスは、簡単に最新の状態に保つことができるように、ドキュメントをできるだけ少なくして、できるだけ目立たないようにすることを目指しています (これは、他の AGILE プロセスとの大きな違いです。たとえば、XP プラクティショナーがよく行うことです)。彼らのコードがドキュメントであると主張する最初のドラフトの後、ドキュメントを最新の状態に維持していないようです)。
プロセスの実際的な概要は次のとおりです。
- 機能要件のクイックドラフト
- ドメイン モデルのクイック定義
- 前のステップに基づいてユース ケースをモデル化する
- オプション - クラス間の関係を理解するためだけに、ユース ケースごとに使い捨ての堅牢性図を作成します。
- ユースケースごとにシーケンス図を描く
- ユース ケースでテスト ケースをモデル化する
- 埋め込む
- テスト
各ステップで、作業全体をレビューして、ドメイン モデルを更新し (最初から正しく行うことは不可能です)、ユース ケースにコメントを追加します。ステップ 5) の終わりまでに、実装の準備が整ったクラスとロジックが完成し、リファクタリングまたは何かを変更した場合に維持するドキュメントはほとんどありません。
- ユースケース図
- 各ユースケースのシーケンス図
- テスト ケース図 (またはテスト計画)
機能を追加する必要がある場合は、新しいユース ケースを追加し、プロセス全体に従います。
資力：
Iconix ソフトウェア エンジニアリング の Web サイト
書籍の参照:
于 2008-09-24T09:39:45.480 に答える
4
現在のプロジェクトが必要とするものは何でも。
私は自分の時間に、さまざまな (主に PHP ベースの) Web 開発者について多くのコンサルティングを行っています。私はまだそれらのプロジェクトの TDD に取り掛かる時間を割いていません。また、それらの多くは既存のフレームワークを使用しているため、TDD はそれほど簡単ではありません。
職場ではまだ TDD のツールが用意されていないため、アジャイルと古いスタイルの仕様ベースのプロセスを組み合わせて使用しています。TDD への移行を試みていますが、既存のプロジェクト (多くの保守作業) と ERP システムとの統合作業が十分に定着している小さなショップです。私は TDD を自分の統合作業に取り掛かることができると思います (そして、その方向への小さな一歩を踏み出しています) が、他のものは大部分が失われた原因です。
于 2008-09-23T15:59:51.970 に答える
4
XP エンジニアリング プラクティスを組み合わせたアジャイル開発手法:
- TDD とリファクタリングの組み合わせ
- YAGNI (あなたはそれを必要としません)
- KISS (Keep it simple バカ)
- デザインパターンへのリファクタリング
- ペア切り替えによるペアプログラミング
- 共有コード ベース
- 早期に頻繁に展開する
于 2008-09-23T15:58:14.643 に答える
3
ここにはいくつかの混乱があるようです：
TDD は、ソフトウェア プロジェクトの全体的な開発を管理することではなく、コードを実装する方法に関するものです。TDD は、どの機能をスケジュールするか、いつ提供するか、または優先順位を設定する方法を決定するのに役立ちません。
対照的に、リーン/アジャイルやウォーターフォールなどは、これらのより高いレベルの問題に関するものです。(私の投票は、リーン/アジャイル領域にしっかりと分類されるスクラムです。)
XP (Extreme Programming) が興味深いのは、これらの両方の分野のアイデアが融合されているからです。
于 2008-09-23T16:07:41.187 に答える
3
私はリーン ソフトウェア開発のファンです。これはポッペンディークスによって推進されており、主にリーン マニュファクチャリングの原則に基づいており、トヨタがポスター チャイルドとなっています。他のアジャイル方法論と多くの共通点があり、無駄の排除、待ち行列理論の利用、「ジャスト イン タイム」の考え方 (たとえば、最後の責任ある瞬間にストーリーを指定する) に重点が置かれています。
リーンは、パイプラインを介してタスクを追跡する方法であるかんばんに関連付けられることがよくあります。
于 2008-09-24T13:59:09.163 に答える
3
私は古い学校だと思います。私はクライアント仕様に開発します。精力的な設計フェーズに続いて、頭を下げて開発、テスト、バグ修正のサイクルが続きます。次に、実装します。
仕様が定義され合意されると、それ以上の変更は発生しません。すべての変更は、開発とバグ修正が完了するまでお待ちください。これにより、スコープクリープが防止され、ソフトウェアの作成、テスト、デバッグ、および実装が可能になります。その時点で、変更は機能強化、新機能などになります。
過去 10 年間のほとんどすべてのクライアントにとって、開発中に「投入」されてスコープ クリープが発生したであろうものの約 90% が、不要であると考えられていることがわかりました。何人のクライアントが私に彼らを寄せ付けなかったことに感謝したかわかりません. したがって、これをどのプロセスと呼ぶかはわかりませんが、私と私が知っている他の多くの開発者にとっては機能します。
于 2008-09-23T16:20:10.220 に答える
3
私はアジャイル スクラムを採用しています。「チームとつながっている」という感覚が得られます。また、マイルストーンと個々のタスクを適切に制御できます。朝のスクラムは非常に便利です。Team System http://www.scrumforteamsystem.com/en/default.aspxでアジャイル スクラム プロジェクト テンプレートを使用します。
于 2008-09-23T15:49:11.123 に答える
2
単体テストを補完する契約による設計
于 2008-09-23T16:05:58.603 に答える
2
私が働いている場所ではウォーターフォールを使用していますが、いくつかの新しいプロジェクトではアジャイル/TDD/CI ハイブリッド モデルに移行しています。神が喜んで、私たちは滝の方法を捨てることができるでしょう. 私たちがメンテナンス リリースを行うたびに、主な顧客は要件の締め切りを無視し、最後の 1 秒で要件の変更を私たちに渡し、私たちがそれを続けられない理由を説明している間、ぼんやりと私たちを見つめています。
于 2008-09-24T14:05:04.407 に答える
0
過去数年間の個人的な傾向はリーン開発に向けられており、XP から学んだすべてのことに大きな影響を受けています。ここで、スクラムはソフトウェア開発の作業ではなく、ソフトウェア開発タスクの流れを管理しようとする作業であるため、開発プロセスとしては不十分であることに注意することが重要だと思います。私の考えは ICONIX からも情報を得ています。非生産的な官僚主義に行き詰まることなく、ユースケースとダイアグラム駆動型の環境にアプローチするための優れた方法だと思います。
于 2010-08-05T23:38:35.307 に答える
0
Web開発とシステム開発の両方を行う会社で働いています。私たちの開発モデルは迅速な開発です。より現代的な定義を使用しているため、アジャイル開発に似ています。XP の概念がなければ。
于 2008-09-23T16:10:06.750 に答える
0
私たちもスクラムを使っています...スタンドアップはある意味では良いと思いますが、15分の短い時間が少なくとも30分になることもあります.
于 2008-09-23T16:10:14.270 に答える
0
テスト駆動設計 TDD
コードの変更によって微妙な部分が壊れていないことを知ることで得られる自信は素晴らしいものです
于 2008-09-23T15:47:16.603 に答える
0
私はアジャイルに賛成票を投じます。私は最近リーンを探求していますが、他の開発プロセスと同様に、現在のグループに簡単に立ち寄ることができるものではありません。ただし、リーンとアジャイルには、現在のプロセスに簡単に組み込むことができ、すぐに価値を得ることができる機能があります。
私の以前のプロジェクトではウォーターフォール方式を使用し、それを誇りに思っていました。それ以来、彼らは Waterfall から離れて Prototype に移行しました。これは良いステップです。
于 2008-09-23T15:56:50.417 に答える