Pierre-Alexandre M. 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
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
mind this warning sign), then appoint someone to be the customer
research what the customer does and how they work. Let them review the
(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
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,
don’t write anything else. Don’t throw mud against the wall just to see
sticks. Then let the customer liaison use the feature, and (if possible)
it online so end-users can use it. This usage will quickly reveal what
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
Redirecting... ← NOT a blog!!!