I agree with Steven's point. Agile development is all about 1) allowing devs to work in small, stable, clearly defined chunks, uninterrupted, and 2) delivering working software to internal stake-holders as often as possible allowing them to change course as needed without upsetting the org. Devs stay happy, biz folks stay happy.
Once a series of internal releases to stake-holders merits an update to the consumer public, you do so. The public release schedule is only tied to the internal iterations, in that a public release has to be sized and scheduled into a sprint like every other work item does. I've seen it work very well this way - roughly: sprint 1 (features), sprint 2 (features), sprint 3 (features), sprint 4 (final polish / major testing), sprint 5 (release). Ignore the specific numbers - the point is that you iterate and demo working software along the way, and the next set of things to be worked on isn't decided until you finish the prior set. At some point, you say - we should get this out, so you batten down the hatches and get it out to the public. - Joe On Jun 1, 10:50 pm, Steven Herod <[email protected]> wrote: > To me, agile is for delivering to internal stakeholders frequently, > people actively engaged in the development process. > > For end users.... no. That's asking too much. > > On Jun 2, 1:52 am, Casper Bang <[email protected]> wrote: > > > > > Yes, pushing a new version every day is bound to create negative > > associations. It's not unique to the Android app update model though, > > it works much the same way in NetBeans and Firefox, except updates are > > typically much less frequent (unless you added a bunch of "private" > > update centers). The fact is that it's quite invasive to have 10+ > > updates a day to handle manually. > > > On Android that is about to change though, the moment a user can just > > mark an application as "automatically update to latest" or click > > "Update all" that should mitigate the problem somewhat. After all, > > most users do not need to know an application was updated, let alone > > see a changelog. What many applications seem to do is show their own > > changelog Intent the first time the application is run after a major > > release - but never for a maintenance/security release. > > > Google is likely still investigating these issues and how to provide > > the best user experience. A custom policy for how often to check for > > updates would go a long way I think, currently it's pretty dumb, i.e. > > right after an app was manually updates the daily update service pops > > up to remind the user that there is an update for that app. > > > On Jun 1, 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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
