Are there any???. Well there is one I can think of, which may be applicable - too much stress on artifacts.I think artifacts should be decided by the team, involved in developing the solution.However, the good thing about UML is it process independent - which means you can develop the artifacts in the way you want.However, I think developing all the artifacts is mandatory - Would like to be corrected though . -- Sandeep
Originally posted by Avijeet Dash: Xp is promoting less design artifacts in form of user stories and more documented code.
Correction: XP encourages more self-documenting code. IOW, if you have to comment your code, it probably is not as clear as it should be. One drawback to UML is that not many users are familiar with the notations. In fact, I haven't met a whole lot of developers who are well-versed and experienced in using UML in real-world projects, myself included. Another drawback is that it is often mistakenly perceived as a "methodology", which it is NOT. It is merely a notation and does not imply any particular methodology except probably OOAD, in a broad sense. I have seen a lot of enthusiasm for adopting UML on projects but the real purpose of doing so quickly gets lost amid the efforts to educate project members on the different notations, arguments about the "methodology" and different "artifacts" that are "supposed" to be produced. Add to that the time and attention given to choosing, installing, and using modeling tools like Rational Rose. The whole point of using UML is to facilitate COMMUNICATION. If people on the project are not conversant in UML, you just might be better off sticking with the old flowcharts, ERDs, DFDs, or just plain CRC cards. Junilu
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck