どのようなソフトウェア開発プロセスを使用していますか?[閉まっている]

StackOverflow https://stackoverflow.com/questions/121839

  •  02-07-2019
  •  | 
  •  

質問

私は常にアジャイルを使用してきました 機能駆動型開発 ソフトウェアを開発するプロセス。他の人は何を使っていますか?なぜそれを好むのですか?私は FDD の方が好きです。それは私が大学を卒業したばかりの頃から FDD を始めたからです。大学では、すべてが非常に自由形式で、私の「顧客」は通常、大学での研究以外には業界での経験があまりなかったかも知れない教授でした。

現在、私の顧客はそれほど寛容ではなく、私は医療分野で多くの仕事をしています。俊敏性と高レベルの品質は必須です。

役に立ちましたか？

解決

仕事では ICONIX プロセスを使用します。これは AGILE テクニックのサブセットであり、動作要件主導型です。ICONIX プロセスは、簡単に最新の状態に保つことができるように、できるだけ祝賀を少なくし、ドキュメントをできるだけ少なくすることを目指しています (これは他の AGILE プロセスとの大きな違いです。たとえば、XP 実践者がよく行うプロセスです)彼らのコードは は ドキュメント）。

プロセスの実際的な概要は次のとおりです。

  1. 機能要件のクイックドラフト
  2. ドメインモデルのクイック定義
  3. 前のステップのベースにあるモデルユースケース
  4. オプション - クラス間の関係を理解するために、各ユースケースのスローアウェイの堅牢性図を描く
  5. 各ユースケースのシーケンス図を描きます
  6. ユースケースに基づいてテストケースをモデル化する
  7. 埋め込む
  8. テスト

各ステップで、ドメイン モデルを更新し (最初から正しく理解するのは不可能です)、ユース ケースに関するコメントを追加して、作業全体をレビューします。ステップ 5) が終わるまでに、リファクタリングや変更を行った場合に必要なドキュメントがほとんどなく、すぐに実装できるクラスとロジックが完成します。

  • ユースケース図
  • ユースケースごとのシーケンス図
  • テスト ケース図 (またはテスト計画)

機能を追加する必要がある場合は、新しいユースケースを追加し、プロセス全体に従います。

リソース：

Iconix プロセス Web サイト

Iconix ソフトウェア エンジニアリング Web サイト

参考書籍:

ICONIX プロセスを使用したアジャイル開発

他のヒント

XP エンジニアリング プラクティスを組み合わせたアジャイル開発手法:

  • リファクタリングと組み合わせた TDD
  • ヤグニ（それは必要ないでしょう）
  • KISS (単純にしてバカにして)
  • デザインパターンへのリファクタリング
  • ペア切り替えによるペアプログラミング
  • 共有コードベース
  • 早期かつ頻繁に導入する

現在のプロジェクトで必要なものは何でも。

私は自分の時間を使って、さまざまな (主に PHP ベースの) Web 開発に関するコンサルティングを行っています。私はこれらのプロジェクトの TDD にまだ時間を割いていませんし、その多くは TDD をそれほど簡単にしない既存のフレームワークを使用しています。

職場ではまだ TDD 用のツールが導入されていないため、アジャイルなプロセスと古いスタイルの仕様ベースのプロセスのハイブリッドを使用しています。TDD に向けた動きを起こそうとしていますが、私たちは小規模なショップであり、しっかりとした既存のプロジェクト (メンテナンス作業が多く) と ERP システムとの統合作業を行っています。私自身の統合作業で TDD を進めることはできると思います (そしてその方向に少しずつ前進しています) が、その他のことはほとんど失われた大義です。

ここでいくつかの混乱があるようです:

TDD は、より重要なのは、あなたがどのように行動するかです。 埋め込む ソフトウェア プロジェクトの開発全体の管理ではなく、コードのことです。TDD は、どの機能をスケジュールするか、いつ配信するか、優先順位を設定する方法を決定するのには役立ちません。

対照的に、リーン/アジャイルやウォーターフォールなどは、これらのより高いレベルの問題に関するものです。(私の投票は、リーン/アジャイル領域にしっかりと当てはまるスクラムです。)

XP (エクストリーム プログラミング) は、これら両方の分野のアイデアを融合させたものであるため、興味深いものです。

私は一緒に行きます アジャイルスクラム, それは「チームとつながっている」という感覚を与えてくれます。そして、マイルストーンと個々のタスクを適切に管理します。朝のスクラムは非常に役立ちます。を使用しております Team System のアジャイル スクラム プロジェクト テンプレート http://www.scrumforteamsystem.com/en/default.aspx

私はオールドスクールだと思います。クライアントの仕様に合わせて開発します。精力的な設計フェーズと、それに続く開発、テスト、バグ修正のサイクル。次に、実装します。

仕様が定義され、合意されると、それ以上の変更はできません。すべての変更は、開発とバグ修正が完了するまで待つ必要があります。これにより、スコープ クリープが防止され、ソフトウェアの作成、テスト、デバッグ、実装が可能になります。その時点での変更は機能強化や新機能などになります。

過去 10 年間で、ほとんどすべてのクライアントにとって、開発中に「投入」してスコープ クリープを引き起こしたであろうものの約 90% が、不要であると考えられていることがわかりました。どれだけ多くのクライアントが、彼らを寄せつけずに私に感謝してくれたのか、計り知れません。したがって、これをどのプロセスと呼ぶのかわかりませんが、私や私が知っている他の多くの開発者にとっては機能します。

私はのファンです 無駄のないソフトウェア開発, これはポッペンディークス夫妻によって推進されており、主にリーン生産方式の原則に基づいており、トヨタがその代表例となっている。これは他のアジャイル手法と多くの共通点があり、無駄の排除、キュー理論の利用、および「ジャストインタイム」の考え方 (例:責任ある最後の瞬間にストーリーを特定する）。

リーンはしばしば以下と関連付けられます カンバン, 、パイプラインを通じてタスクを追跡する方法です。

単体テストを補完した契約による設計

私が働いている場所ではウォーターフォールを使用していますが、私の側でいくつかのプッシュを行った結果、いくつかの新しいプロジェクトではアジャイル/TDD/CI ハイブリッド モデルにさらに移行しています。神様のご意志で、ウォーターフォール方式を廃止できるでしょう。私たちがメンテナンスリリースを行うたびに、主要顧客は要求の期限を無視して、最後の瞬間に要求の変更を私たちに渡し、なぜそれを続けられないのかを説明している間、ただぼんやりと私たちを見つめるだけです。

コードと修正 !!

冗談です、 TDD 本当に素晴らしい方法です。

テスト駆動設計 TDD

コードの変更によって微妙な部分が壊れていないことがわかると、大きな自信が得られます。

私はアジャイルに二番目に投票しました。私は最近リーンについて研究していますが、他の開発プロセスと同様に、現在のグループに簡単に参加できるものではありません。ただし、リーンとアジャイルには、現在のプロセスに簡単に導入してすぐに価値を得ることができる機能があります。

私の以前のプロジェクトではウォーターフォール手法を使用しており、それを誇りに思っていました。それ以来、彼らはウォーターフォールから離れ、プロトタイプに移行しました。これは良いステップです。

私はWeb開発とシステム開発の両方を行う会社に勤めています。私たちの開発モデルは迅速な開発です。私たちはより現代的な定義を使用しているため、アジャイル開発に似ています。XP の概念がなければ。

スクラムも使ってるんですが…スタンドアップはある意味では良いことだと思いますが、短い 15 分が少なくとも 30 分になる場合もあります。

過去数年間の私の個人的な傾向はリーン開発に傾いており、XP から学んだすべてのことが大きく影響しています。ここで注意しなければならないのは、スクラムはソフトウェア開発の作業を通知するのではなく、ソフトウェア開発タスクのフローを管理しようとする作業を通知するため、開発プロセスとしては不十分であるということです。私の考えはICONIXからも伝わってきました。これは、非生産的な官僚主義に陥ることなく、ユースケースとダイアグラム主導の環境にアプローチするための優れた方法だと思います。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top