Hi, I have a question about general development methods in the context of agile development. I''m currently reading ''practices of an agile developer'' and it''s said that feedback and interaction with customers are really important. Imagine you''re a developer in a team (not the project leader). You''ll have several tasks to do, let''s say 1/ a blog 2/ a pdf generator 3/ a form You''ll have 2 months to deploy your application (others developers have others modules to build) and a meeting is scheduled in a month with all the team members and the customer. Tell me if I''m wrong. An agile developer will write those 3 modules, even if the code is not ''perfect'' (that''s to say, perhaps, the ''reply'' function doesn''t work on comments in the blog, there are bugs with the margins in the pdf generator and the form doesn''t interact with the db yet), to have feedback from the customer and the rest of the team to see if it''s what the customer really wants whereas writing a perfect-tests-passing-with-all-functionalities blog and a semi-generator pdf? And he will use the second month to proprify the code, write tests, correct the functionalities among with the objections of the customer wheras writing the second part of the pdf creator and the entire form? Thanks for your comments, -- pam, who wants to become a better programmer. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Pam, this really depends on the agreement that you have with your customer. In my prior experience, you would generate a schedule of deliverables with your customer before starting any development. This schedule would change if it''s agreed upon by both the developing organization and the customer. Next, when a deliverable is scheduled to be released to the customer, it should meet the functionality that the customer defined in their specification. Thus, it''s the responsibility of the developing organization to get feedback during development before the deliverable is due. Also, if there''s a change in the specification, then it''s the responsibility of the customer to make this aware to the developing organization before the deliverable is due. In short, it''s the responsibility for both customer and developing organization to provide feedback and interact with one another during implementation. If this doesn''t exist, then the developing organization can be building something that doesn''t meet the customer''s expectations no the due date. -Conrad On 3/18/07, Pierre-Alexandre Meyer <pam-1sEOgp2Wo8Qdnm+yROfE0A@public.gmane.org> wrote:> > Hi, > > I have a question about general development methods in the context of > agile development. > > I''m currently reading ''practices of an agile developer'' and it''s said > that feedback and interaction with customers are really important. > > Imagine you''re a developer in a team (not the project leader). You''ll > have several tasks to do, let''s say > 1/ a blog > 2/ a pdf generator > 3/ a form > > You''ll have 2 months to deploy your application (others developers have > others modules to build) and a meeting is scheduled in a month with all > the team members and the customer. > > Tell me if I''m wrong. An agile developer will write those 3 modules, > even if the code is not ''perfect'' (that''s to say, perhaps, the ''reply'' > function doesn''t work on comments in the blog, there are bugs with the > margins in the pdf generator and the form doesn''t interact with the db > yet), to have feedback from the customer and the rest of the team to see > if it''s what the customer really wants whereas writing a > perfect-tests-passing-with-all-functionalities blog and a semi-generator > pdf? And he will use the second month to proprify the code, write tests, > correct the functionalities among with the objections of the customer > wheras writing the second part of the pdf creator and the entire form? > > Thanks for your comments, > > -- > pam, who wants to become a better programmer. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Pierre, Pierre-Alexandre Meyer wrote:> I''m currently reading ''practices of an agile developer'' and it''s said > that feedback and interaction with customers are really important. > > Imagine you''re a developer in a team (not the project leader). You''ll > have several tasks to do, let''s say > 1/ a blog > 2/ a pdf generator > 3/ a form > > Tell me if I''m wrong. An agile developer will write those 3 modules,Nope. An agile developer will write the code for the first module, after they''ne confirmed that that''s the customer''s highest priority and not just an accidental artifact (like maybe somebody just listed stuff in alphabetical order) and they probably won''t write all of that. They''ll seek feedback from the customer as soon as possible. Way before ''time is up.'' hth, Bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Pierre-Alexandre Meyer wrote:> I''m currently reading ''practices of an agile developer'' and it''s said > that feedback and interaction with customers are really important.That''s not just lipservice. That means you show them your work-in-progress as often as possible, and they review it and tell you if it''s done. If they tell you a given feature is done, you don''t argue.> Imagine you''re a developer in a team (not the project leader). You''ll > have several tasks to do, let''s say > 1/ a blog > 2/ a pdf generator > 3/ a form > > You''ll have 2 months to deploy your application (others developers have > others modules to build)A team is a team. Everyone should work on all the modules, as they grow. Don''t plan-ahead what modules you will need, then distribute them among workers. That causes friction and waste.> and a meeting is scheduled in a month with all > the team members and the customer. > > Tell me if I''m wrong. An agile developer will write those 3 modules, > even if the code is not ''perfect''Don''t write for a month before showing anything to the customer. If the customer is legitimately not available for a month (and if your team doesn''t mind this warning sign), then appoint someone to be the customer liaison; to research what the customer does and how they work. Let them review the features.> (that''s to say, perhaps, the ''reply'' > function doesn''t work on comments in the blog, there are bugs with the > margins in the pdf generator and the form doesn''t interact with the db > yet)Your list of items was too broad. Don''t say "A blog", say "write a post with a date and have it show up. No HTML input, images, replies or anything". That''s just one line-item of a blog. Fully write that one narrow feature, with its GUI, database, and tests, and don''t write anything else. Don''t throw mud against the wall just to see what sticks. Then let the customer liaison use the feature, and (if possible) put it online so end-users can use it. This usage will quickly reveal what the next feature should be.> , to have feedback from the customer and the rest of the team to see > if it''s what the customer really wants whereas writing a > perfect-tests-passing-with-all-functionalities blog and a semi-generator > pdf? And he will use the second month to proprify the code, write tests, > correct the functionalities among with the objections of the customer > wheras writing the second part of the pdf creator and the entire form?Write the tests at the same time as you write the tested code. Work in iterations of one week, not three months. Seek any excuse to strike any line-item from the feature list. Then make sure all remaining features are bug-free. -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---