tag:blogger.com,1999:blog-21080042.post2902886008540186645..comments2024-03-17T17:03:47.760-07:00Comments on Agile World: Agile means no documentation - common misconeptionVenkatesh Krishnamurthyhttp://www.blogger.com/profile/11471239057569635943noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-21080042.post-68114839660419772782012-11-28T23:15:27.529-08:002012-11-28T23:15:27.529-08:00It is just unfortunate that, Agile values/principl...It is just unfortunate that, Agile values/principles are being mis-interpreted. If documents add value to business and the project teams, just do it. At the end of the day, the metholodologies are designed to help the business and team, and not to block them.Venkatesh Krishnamurthyhttps://www.blogger.com/profile/11471239057569635943noreply@blogger.comtag:blogger.com,1999:blog-21080042.post-77626668271631883622012-11-28T10:49:27.066-08:002012-11-28T10:49:27.066-08:00I work in company on application that is used by a...I work in company on application that is used by around 2mln people, but they all tell me that agile means no documentation at all, comments in code only in header of file (only meaningless info about when file was created etc, nothing more) so working on a few million lines of code without documentation and almost no comments in code is lets say "interesting" experience :| but I'm only young and stupid junior software engineer. People are leaving and then no one knows how some parts of the app work and they still have problems with regressions because no one even knows how app should behave haha.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-21080042.post-64281969880775002632012-11-28T10:48:30.259-08:002012-11-28T10:48:30.259-08:00I work in company on application that is used by a...I work in company on application that is used by around 2mln people, but they all tell me that agile means no documentation at all, comments in code only in header of file (only meaningless info about when file was created etc, nothing more) so working on a few million lines of code without documentation and almost no comments in code is lets say "interesting" experience :| but I'm only young and stupid junior software engineer. People are leaving and then no one knows how some parts of the app work and they still have problems with regressions because no one even knows how app should behave haha.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-21080042.post-37504636249918996562010-02-16T15:01:22.006-08:002010-02-16T15:01:22.006-08:00Nice, simple truths.. enough said..Nice, simple truths.. enough said..Ben Pirihhttps://www.blogger.com/profile/02960043504493271361noreply@blogger.comtag:blogger.com,1999:blog-21080042.post-58100196487808254462009-11-20T12:12:45.548-08:002009-11-20T12:12:45.548-08:00It was rather interesting for me to read this arti...It was rather interesting for me to read this article. Thank author for it. I like such themes and everything that is connected to them. I would like to read a bit more soon.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-21080042.post-77132727127333291902009-01-08T11:11:00.000-08:002009-01-08T11:11:00.000-08:00Good points, all.One thing that going Agile really...Good points, all.<BR/><BR/>One thing that going Agile really affects, vis-a-vis documentation, is the rate of change. In the company where I was the Agile Manager, we adopted an Agile methodology because we couldn't keep up with the rate of change our owners/customers were experiencing if we did things the traditional way. However, once we started doing 1-month Iterations, the rate of change increased <I>even more</I>, as those making the requests now assumed we cold adapt to anything!<BR/><BR/>In that scenario, doing comprehensive documentation is a huge challenge, because you're constantly trying to hit a moving target. So one bit of advice that I'd offer from that experience is that you should work out with your customer, in clear and precise terms, what degree of documentation <I>they</I> require (you can worry about what documentation you need internally yourself). Once you have that decided and agreed upon, then you can account for the time to produce documentation in your estimates or velocity when you plan. Without that in place, you may run into all kinds of problems later on when your customers express shock and outrage at how little documentation is available reflecting their constant changes in direction.Kimota94 aka Matt aka AgileManhttps://www.blogger.com/profile/00404161474780005815noreply@blogger.comtag:blogger.com,1999:blog-21080042.post-59053660806574929182008-12-14T03:03:00.000-08:002008-12-14T03:03:00.000-08:00Would appreciate your views on the book about agil...Would appreciate your views on the book about agile documentation patterns. <BR/><BR/>http://agilebooks.blogspot.com/2008/12/agile-documentation-pattern-guide-to.htmltbizhttps://www.blogger.com/profile/07749896293893114966noreply@blogger.com