Comments on: Embracing Agile Modeling http://thesherpaproject.com/2005/07/11/embracing-agile-modeling/ Thoughts by Ben Carey Tue, 06 Jan 2009 21:11:09 +0000 http://wordpress.org/?v=2.6 By: symer http://thesherpaproject.com/2005/07/11/embracing-agile-modeling/#comment-8 symer Mon, 12 Jun 2006 10:51:27 +0000 http://www.thesherpaproject.com/?p=15#comment-8 beautiful online information center. greatest work... thanks beautiful online information center. greatest work… thanks

]]> By: Ben Carey http://thesherpaproject.com/2005/07/11/embracing-agile-modeling/#comment-7 Ben Carey Mon, 06 Mar 2006 01:42:34 +0000 http://www.thesherpaproject.com/?p=15#comment-7 The biggest tip that I have is to actively think about eliminating waste. Forget about freezing your designs and try and get into the mindset of "organic architecture" and let your designs evolve as you learn (about the system, culture, constraints, market, etc.). Agile Modeling helps because it focuses on improving communication rather than contributing novels to for everyone to daydream over. My suggestion would be if you need a rigidly defined class diagram and you need to document why it changes - then find a way to do it. I think the ideal situation (at least in my mind) would be to keep the class diagram on a whiteboard (or wiki) and change it as it needs to be communicated to the other team members. Another alternative would be to generate the diagram as part of the build process so that it is alway up to date. Maintaining a design and evolving code requires too much duplication if it's not needed. If the intent is to think through scenarios and to "model storm" then a whiteboard is a great place to start. In my experience, it's usually a good place to end as well. Let me know how you end up approaching it. I'm always interested in hearing how others work to change these issues that we've overlooked for so long. The biggest tip that I have is to actively think about eliminating waste. Forget about freezing your designs and try and get into the mindset of “organic architecture” and let your designs evolve as you learn (about the system, culture, constraints, market, etc.).

Agile Modeling helps because it focuses on improving communication rather than contributing novels to for everyone to daydream over.

My suggestion would be if you need a rigidly defined class diagram and you need to document why it changes - then find a way to do it. I think the ideal situation (at least in my mind) would be to keep the class diagram on a whiteboard (or wiki) and change it as it needs to be communicated to the other team members. Another alternative would be to generate the diagram as part of the build process so that it is alway up to date.

Maintaining a design and evolving code requires too much duplication if it’s not needed. If the intent is to think through scenarios and to “model storm” then a whiteboard is a great place to start. In my experience, it’s usually a good place to end as well.

Let me know how you end up approaching it. I’m always interested in hearing how others work to change these issues that we’ve overlooked for so long.

]]> By: rishi http://thesherpaproject.com/2005/07/11/embracing-agile-modeling/#comment-6 rishi Mon, 06 Mar 2006 01:41:59 +0000 http://www.thesherpaproject.com/?p=15#comment-6 Hey Ben, I am going to try this with my next project. Any tips for people starting out? One of the problems that I run into is that as the project veers on, the class diagram veers aaway from the planned UML class diagram and the reasons for the change remain undocumented. Does the Agile modeling help any with that? Thanks. Rishi Hey Ben,
I am going to try this with my next project. Any tips for people starting out? One of the problems that I run into is that as the project veers on, the class diagram veers aaway from the planned UML class diagram and the reasons for the change remain undocumented. Does the Agile modeling help any with that?
Thanks.
Rishi

]]>