私は、Extreme Programming(XP)のような、ソフトウェア開発のための独自の実践方法を指定する方法論を知っています。ただし、管理面に重点を置いているスクラムとは異なり、XPは、従う必要のあるソフトウェアプラクティスを指定します。 この記事を読むことから 、これらの手順は明示的なモデリングを排除しますBPMNやUMLなどのツールを使用したフェーズ。Martin Fowlerの 別の記事 で、彼はそのような落胆をさらに説明しています。
個人的には、モデル駆動の方法論を好みます。それは、企業や人々の好みによると思います。アジャイルの目標の1つは、「開発者をドキュメントの作業から解放する」ことです。 XP=のような方法論は簡単にドキュメントの下につながるようです。私はその目標を達成すると思います。解決策は、開発者がドキュメントを書く負担を軽減するツールを実装することです。既存の図から情報を収集し、レポートを自動的に生成する(Enterprise Architect of Sparx Systemの場合はRTF、PDF、HTMLで)。
一部のソフトウェアエンジニアは、時間のかかる図の描画についても不満を述べています。私の意見では、解決策は図を描くことではなく、ツールを使用することです。現在のモデリングツールは、コードとダイアグラムを同期できる往復エンジニアリングをサポートしているため、コードベースが変更された場合(特にクラスダイアグラム)にダイアグラムを手動で修正する手間が省けます。
モデリングは、エクストリームプログラミングを使用しているチームにどのように適合しますか?
XPはモデルの作成を明示的に要求していませんが、モデルを作成してはならないというわけではありません。モデルの開発がシステムの構築と文書化に役立つ場合は、絶対に行う必要があります。違いは、 アジャイルモデリング は、計画主導の環境でのシステムモデリングとは異なる焦点を持っているということです。実際、アジャイルモデリングサイトでは、具体的に 極端な環境でのモデリング方法 についても取り上げています。
アジャイル環境では、よりリーンな(リーンエンジニアリングまたはリーン製造と同じ意味で)アプローチを採用しています。主要なテナントの一部には、無駄を減らし、遅れて決定し、迅速に提供することが含まれます。無駄をなくすために、必要なドキュメントのみが適切な粒度で提供されます。成果物を作成する場合、その成果物は最終的に顧客に付加価値をもたらすことが期待されます-廃棄物は、それを支払う人に価値を付加するのに役立たないものと見なされます。
実際、 あなたがリンクしたXProgrammingブログ記事 はこれをサポートしています:
プロジェクトに適切にフォーマットされたUMLが必要になる場合があります...これらのものが本当に必要な場合は、必ず実行する必要があります。しかし、必要な情報はより効果的な会話の媒体を通じて伝達されるため、配置されたチーム全体では、おそらくそれらを必要としないでしょう。
リンクしたMartin Fowlerの記事 もこれをサポートしています:
確かにXPは、図を大幅に非強調します。公式の位置付けは「役立つ場合にそれらを使用する」という線に沿っていますが、「実際のXPersは図を行う」。
A アジャイルメソッドの中心的な考え方は、「個人とプロセスとツールの相互作用」 です。プロセスをフォローしたり、ツールを使用したりするために、プロセスをフォローしたり、ツールを使用したりしない。取り組んでいるタスクが価値をもたらさない場合、またはそれが誰か(顧客または他のエンジニア)にとって有用な何かを生み出さない場合は、それを行わないでください。
マーティン・ファウラーは続けてこう言います:
主な価値はコミュニケーションです。効果的なコミュニケーションとは、重要なものを選択し、それほど重要でないものを無視することです。この選択性は、UMLをうまく使用するための鍵です。 ...図の一般的な使用に関する一般的な問題は、人々がそれらを包括的にしようとすることです。
繰り返しますが、同じ考えです。ドキュメントの目的はコミュニケーションです。システムの伝達に役立たないものを作成している場合、なぜそれを行うのですか?細部に焦点を当てるのではなく、他の人に役立つ付加価値のある情報を提供するメッセージを伝えることに焦点を当てます。
記事の後半でも、Fowler氏は、CASEツールの問題の1つは、非同期になる可能性があることを指摘します。コードとドキュメントが同期しなくなるとすぐに、ドキュメントは価値を追加しません。私はこれをさらに一歩進めて、それを使用して決定を下そうとするすべての人に誤った誤解を招く情報を提供するので、それは負の価値を追加すると言います。同期を維持するプロセスがある場合、それは良いことです。ただし、そうしないで、ドキュメントの同期が外れるようにすると、別の疑問が生じます。なぜそれらを持っているのですか?それらは明らかに使用されていないか、そうでなければ維持されます。
XP実際に顧客に価値を提供するのに役立つものに時間とリソースを費やすことを求めています)/client。特定のモデルが実際にプロジェクトに付加価値を与えることを正当化できる場合は、必ずそれらを生成する必要があります。ただし、他の情報を複製したり、付加価値を付けたりしないモデルを生成するべきではありません。