tag:blogger.com,1999:blog-234465125505359244.post1183449695831640213..comments2023-09-16T07:09:07.674-07:00Comments on Lean Transformation: The Purpose of ModelingJeff Andersonhttp://www.blogger.com/profile/17502868241692630528noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-234465125505359244.post-43037577434462386902008-03-10T11:48:00.000-07:002008-03-10T11:48:00.000-07:00I'm sure all of us have been in similar situations...I'm sure all of us have been in similar situations with other clients who are not quite sure of how much analysis goes into modelling. Some of the best modelling experiences I have had involved both functional and technical resources throughout the requirements gathering and analysis phases.<BR/><BR/>The common disagreement with clients is that, "You can't be sure you've modelled it correctly if you can't find a home for all of the fields." IMO, this is an issue of trust. Once you nail the trust, you can use effective AGILE methodologies as you please.DannyBhttps://www.blogger.com/profile/17680272667489576526noreply@blogger.comtag:blogger.com,1999:blog-234465125505359244.post-22569309020569158172008-02-28T10:25:00.000-08:002008-02-28T10:25:00.000-08:00Scott,your http://www.agilemodeling.com/essays/amd...Scott,<BR/>your <A HREF="site" REL="nofollow">http://www.agilemodeling.com/essays/amdd.htm</A> is definitely an inspiration for many of my views on modeling and documentation, and SDLC in general. <BR/><BR/>It does an excellent job of highlighting the value and limitations of modeling without discounting the value of modeling altogether whic which I've sometines seen other agile practitioners do.Jeff Andersonhttps://www.blogger.com/profile/17502868241692630528noreply@blogger.comtag:blogger.com,1999:blog-234465125505359244.post-2665599120210021162008-02-28T07:47:00.000-08:002008-02-28T07:47:00.000-08:00A lot of people might be interested in the Agile M...A lot of people might be interested in the <A HREF="http://www.agilemodeling.com/essays/amdd.htm" REL="nofollow">Agile Model Driven Development (AMDD) lifeycle</A>. In it I describe how agile teams do some initial high-level requirements envisioning and architecture envisioning to think through some of the bigger issues. Detailed modeling, if required, can be done on a JIT basis throughout the lifecycle. <BR/><BR/>Modeling is clearly an important technique for <A HREF="http://www.ibm.com/developerworks/blogs/page/ambler" REL="nofollow">scaling agile software development</A>.<BR/><BR/>- ScottScott W, Amblerhttps://www.blogger.com/profile/07416328932753598174noreply@blogger.comtag:blogger.com,1999:blog-234465125505359244.post-85683329902219057002008-02-28T07:12:00.000-08:002008-02-28T07:12:00.000-08:00Jeff,This posting resonated with me and I think yo...Jeff,<BR/><BR/>This posting resonated with me and I think you outlined the "true value" of modeling. It is an invaluable tool for communication and analysis. Unfortunately, like you pointed out it is too often abused in design work as there seems to be a natural tendency to over-design. <BR/><BR/>With my experiences as well, I have yet to find a practical and manageable way to keep detailed design models in sync with the requirements churn that every project experiences.<BR/><BR/>An approach I find practical and valuable is high-level modeling of key concepts like you pointed out and then proceed directly to implementation. It's just as fast to code up the model as it is to detail a model fully. And it's compilable, executable and testable.Anonymousnoreply@blogger.com