here here. This is my approach every time with a client. I find it helps them understand their own business as well as how ofbiz can help. I get their story of how they do business before implementing ofbiz. We sometimes discuss how they do business now, before ofbiz could be changed to help the bottom line. I then link the functionality of ofbiz to their story, as a migration to they can say we do this now and ofbiz will help this way in doing this.
When ofbiz does not do part of their story I show what can be done to make ofbiz help in that part of the story. and I keep the detailed steps to accomplish that in a separate project manager software,linked to their story, for implementation should they want that. i can then hand the project task and story to a programmer to implement. I have found it very successful. A typical slice of a story is like I open the door and go to my desk the first thing I usually do is check emails for any major issues. As I go get coffee I let the orders print out to review. and so on. Though this story is probably not quite what we want, it has the basic to pull a story like you suggest. ========================= BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro> Jacopo Cappellato sent the following on 4/13/2010 12:34 AM: > I would like to keep this conversation alive because I think it is an > important one. > What do you think about the idea of creating and maintaining stories (*) that > have to be referenced in commit logs (ideally each and every commit log > should be associated to a story; the same story can be associated to several > commit logs) as a way to focus the attention of the community around > requirements behind commits? > I think it would be a valuable approach to enable the community interaction > around requirements (instead of implementation as it is happening now) with > the final goal of: > 1) documenting the high level requirements (stories) available implemented by > screens and artifacts in OFBiz > 2) facilitate the participation in the growth of OFBiz of less technical > contributors (e.g. analysts) > > Jacopo > > (*) An example of story could be the following one: > "Sales Orders are approved automatically when paid by credit card and CC > authorization is successful. > Sales Orders are placed in Pending status approval after checkout then > auto-approve once third-party payment processor (PayPal, GoogleCheckout, etc) > sends notification. > Sales Orders are placed in Rejected status when authorization fails. > Once order is approved inventory is automatically reserved, reducing > Available To Promise (ATP) quantity. If inventory is not available negative > inventory reservations are created and the order is placed on back-order." > > Company sends confirmation email to the Placing Customer." > On Apr 8, 2010, at 2:34 PM, Jacopo Cappellato wrote: > >> This is an interesting comment. What we can d to improve this? >> Here is a suggestion: from now on each and every commit to trunk will have >> to contain the reference to a (short) story that describes the context (i.e. >> generic business process) that the commit is enhancing. >> This doesn't mean that there will be a story for each commit since several >> commits will share the same story; over time we will create a good set of >> stories and it will be easier, when a new story is added, to verify if it >> represents an alternative/redundant feature etc... >> At the beginning there will be some overhead on the shoulders of committers, >> but if we are good at keeping the stories consistent this would also help >> the participation to non-tech guys. >> The stories could stay in Confluence or (maybe better) in Jira (easier to >> associate commits to Jira tasks). >> >> Jacopo >> >> >> On Apr 8, 2010, at 12:50 AM, David E Jones wrote: >> >>> This may or may not help this conversation, but to be clear I no longer >>> believe in the vision of a developer friendly community. Some good things >>> certainly come from the model of community over code and developers being >>> the most important part of a community, but my opinion these days is that e >>> problems trump the benefits. >>> >>> In an effort where there is a clear design with a written and accepted >>> specification this model seems to work fine. However when the project is >>> not simply implementing an established design what ensues is nothing short >>> of chaos and fighting over design with no clear targets or requirements to >>> help people make decisions. >>> >>> In short that is why I don't believe in this model for OFBiz. We have >>> problems with designs and not so much with implementation. Most of the >>> problems in the project are due to bad design (or no design other than >>> whatever the code happens to do) and no amount of good implementation can >>> fix that. With testing efforts this will only become more pronounced. >>> Testing efforts will reveal the lack of designs more and more,and while >>> writing tests some functionality gaps will certainly be filled in, but the >>> mind set of testing that includes trying all possibilities will result in >>> enormous scope creep to add to the already staggering amount of unused >>> code. Actually I'm wrong in using the term scope creep because that would >>> imply that some sort of scope had been established before. >>> >>> I mentioned some stuff about a better approach, or better priorities, in >>> another email where I wrote a little about the NUMMI car plant as an >>> interesting example of a possibly better way to go. Maybe it was silly to >>> think it would ever work well this way and you can't get around >>> prioritizing users over developers and code quality and good design over >>> developers. >>> >>> -David >>> > >
