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
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.