RE: Re[2]: RE: Customer involvement and process improvement
STEURS Stefan <[email protected]> Wed, 8 Jan 2003 08:50:08 +0100
| Newsgroups | gmane.comp.programming.extreme-customering |
|---|---|
| Message-ID | <5983E4DAC939D311B2F20008C7E62E7A0A4009A0@clsh01xch.office.cfmu.eurocontrol.be> |
> -----Original Message----- > From: Doug Swartz [mailto:[email protected]] > Sent: Wednesday, January 08, 2003 4:20 AM > In our environment the customers also do not necessarily want new > functionality to appear in production every iteration. We create a > "production ready" release every iteration, but we implement into a > customer testing environment rather than production. This environment > runs a parallel of production data (not necessarily full-size > databases). The customer and QA testing folks do any final checks > against this environment. On any date, the customer can say: > "Implement it tomorrow", and we do, because it's already production > ready from the IT perspective. In all the places I've worked and whatever development process we've applied, I cannot remember having done it differently. One problem I have seen however is that when moving from pre-roduction to production, there are always some issues coming up. Why, because you use a different class of machine, because you have a different network, because you have different volumes of data, because the pre-production machines are less stressed (otherwise you would need as many operators there as in your production area). It may be production from a pure engineering point of view, but it is still not real production from the user point of view. I've seen particular problems which seem hard to avoid. E.g. when the preproduction machine uses new features, the new features are not present in the production data, so a parallel cannot be made. > > This arrangement allows the customer to stage releases into > production and spend time "evaluating" at their own pace. If the new > features are urgently needed, they can implement after every > iteration. If not, they sometimes go two or three iterations between > actual production implementations. I have trouble with an approach that delivers features that are not going to be evaluated immediately. That increases the risk of slumbering fires. Of course, some things cannot be avoided totally and improving is not about making things perfect. Talking to myself here I guess. > > > What I also have some trouble with is that XP seems to > treat features as if > > they were functionally independent. I've got a lot of > trouble with that > > concept. E.g. take adding a new "object" to a database. > Most likely this > > object will have associations and corresponding business > validation rules > > coming along with it that provide syntactical and > semantical correctness > > (not to forget database integrity). Adding a story that > requires a new > > object, or even a new attribute, may seem like a "small > incremental issue" > > but I've seen otherwise. For the sake of business > continuity it may be wise > > to couple a few of these changes together to allow a > complete and thorough > > "validation" as it will make this validation more efficient > and effective. > > We've found that "from a coding perspective" features are, in fact, > mostly functionally independent. Of course, you are right that > sometimes multiple stories make sense to implement into production > together. The two stage implementation arrangement allows the customer > to decide when stories ought to be linked together. If the stories > completed in iteration 11 don't quite make a complete logical unit of > delivery from the business perspective, the customer simply waits > until the end of iteration 12 to move the new version into "real" > production. Of course, the customer knew at the beginning of iteration > 11 that she'd probably wait until after iteration 12. What is the added value of delivering iteration 11 to the customer anyway. Should all iterations be delivered? What is the impact to business if we deliver iterations which are not going to be evaluated or not going to production. Is there possibly a risk or disruptive effect? Perhaps it may also cause too much work/cost for too little benefit? Even installations on pre-production machines have to be carefully planned and cost time/effort. I must be overlooking something, but what is it? > > Doug Swartz > [email protected] Regards, Stefan Steurs. ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. ------------------------ Yahoo! Groups Sponsor ---------------------~--> Flexible Keyboard is the ideal accessory for PDA users that are on the move. http://us.click.yahoo.com/dCBVZC/WnCFAA/xGHJAA/NhFolB/TM ---------------------------------------------------------------------~-> To unsubscribe from this group, send an email to: extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/