On Tue, Jun 1, 2010 at 5:05 PM, Rakesh <[email protected]> wrote:
> Hi, > > you seem to be a bit confused. An end customer (such as someone > purchasing an app from a store) can not tell whether the app was built > using agile methods or waterfall. > I think you're missing the point, from my interpretation the OP was worried that frequent releases would harm the image of the product, giving it an appearance to be flawed and in need of constant fixes. > > The situation you refer to with an app requiring an update straight > after release may be because it was buggy and it took users using it > in the wild to find the bugs. > > Agile releases are meant to be 'working software', and should not > contain (serious) bugs. Perhaps if you are finding that to release > weekly you have to compromise on quality (something agile does not > compromise on) then increase your iteration to have more time to do > testing. > > Rakesh > > On Tue, Jun 1, 2010 at 2:10 PM, Viktor Klang <[email protected]> > wrote: > > The obvious alternative is to have one version for the masses and one for > > those on the edge, and then do few, bigger, releases to the first and > many > > small releases to the second > > > > On Tue, Jun 1, 2010 at 2:57 PM, Fabrizio Giudici > > <[email protected]> wrote: > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Many of us agree on the goodness of agile methods that lead to / > >> allows to have frequent releases. Since when we work as consultants > >> for a customer we have a good relationship with him/her (*), we can > >> explain him what's happening (in fact, sharing the perspective and > >> values is fundamental withing agile methods). > >> > >> But what about end customers? We can't and we shouldn't evangelize > >> them (they want to use the damn'd thing, not to learn about > >> techonology), so they'll have their own perception. At the moment, I'm > >> having a release per week for my Android application. I've still to > >> learn how to do automated UI tests, but the rest of the code has a > >> very good coverage; I'm manually filling the gaps, and since the > >> application is simple I can afford to do it manually. In the end, I > >> feel confident - when I have full UI tests I'll feel even more > confident. > >> > >> But yesterday I happened to read the blog of an italian journalist, > >> about the iPad application developed by one of the most spread italian > >> newspaper. He said "the app is poor and they published an update right > >> the day after the public release" - the tone was a critical one, as to > >> point out defects of the first release. So, suddenly, I realized that > >> maybe customers might see frequent releases... as a bad sign! What > >> should one do? Keep frequent releases internally and publish only once > >> in a while? > >> > >> PS Of course, this is related to the bad way the Android Market is > >> done. There's no official place for a changelog, if you put it in the > >> description field (which is short) it will consume room for a decent > >> description of the application; and even if you publish the change log > >> to your website, you have to find a way to have it read by the end > >> customers... > >> > >> > >> (*) If you don't have at least a decent relationship with your > >> customer, the project will fail even when done with Agile^3, Java 8 > >> with multi-dimensional closures, etc... > >> > >> - -- > >> Fabrizio Giudici - Java Architect, Project Manager > >> Tidalwave s.a.s. - "We make Java work. Everywhere." > >> java.net/blog/fabriziogiudici - www.tidalwave.it/people > >> [email protected] > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> > >> iEYEARECAAYFAkwFA6cACgkQeDweFqgUGxff3wCfXQL0Dw7IFPpaLsXG1bN8pX/p > >> /fgAnAsXKDrrYxsTBrHjCR32cnoX+mMX > >> =tjSV > >> -----END PGP SIGNATURE----- > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "The Java Posse" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<javaposse%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/javaposse?hl=en. > >> > > > > > > > > -- > > Viktor Klang > > | "A complex system that works is invariably > > | found to have evolved from a simple system > > | that worked." - John Gall > > > > Akka - the Actor Kernel: Akkasource.org > > Twttr: twitter.com/viktorklang > > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<javaposse%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/javaposse?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall Akka - the Actor Kernel: Akkasource.org Twttr: twitter.com/viktorklang -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
