Small Tasks
26 07 08 19:51 Filed in: Code
Extraits de Getting Real, de
37signals :
Software developers are a special breed of optimist: when presented with a programming task, they think, "That'll be easy! Won't take much time at all."
So, give a programmer three weeks to complete a large task, and she'll spend two and a half procrastinating, and then one programming. The off-schedule result will probably meet the wrong requirements, because the task turned out to be more complex than it seemed. Plus, who can remember what the team agreed upon three weeks ago?
Give a programmer an afternoon to code a small, specific module and she'll crank it out, ready to move onto the next one.
Smaller tasks and smaller timelines are more manageable, hide fewer possible requirement misunderstandings, and cost less to change your mind about or redo. Smaller timelines keep developers engaged and give them more opportunities to enjoy a sense of accomplishment and less reason to think, "Oh I've got plenty of time to do that. For now, let me finish rating songs in my iTunes library.
—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide
C’est une description complètement réaliste de ce qui se passe dans la tête d’un développeur. En conséquence, diviser son travail en tâches de quelques heures au maximum permet de conserver une productivité constante tout au long des semaines et de rester réactif. C’est tout bête, mais sans ce conseil il faut un peu d’expérience pour le trouver par soi-même.
J’avais déjà lu des bribes de ce livre il y a longtemps, quand il était encore à l’état de quelques articles. Je le relis donc, grâce à un bon conseil, dans sa version complète et très bien structurée : C’est radical, et ça vaut vraiment le coup.
Software developers are a special breed of optimist: when presented with a programming task, they think, "That'll be easy! Won't take much time at all."
So, give a programmer three weeks to complete a large task, and she'll spend two and a half procrastinating, and then one programming. The off-schedule result will probably meet the wrong requirements, because the task turned out to be more complex than it seemed. Plus, who can remember what the team agreed upon three weeks ago?
Give a programmer an afternoon to code a small, specific module and she'll crank it out, ready to move onto the next one.
Smaller tasks and smaller timelines are more manageable, hide fewer possible requirement misunderstandings, and cost less to change your mind about or redo. Smaller timelines keep developers engaged and give them more opportunities to enjoy a sense of accomplishment and less reason to think, "Oh I've got plenty of time to do that. For now, let me finish rating songs in my iTunes library.
—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide
C’est une description complètement réaliste de ce qui se passe dans la tête d’un développeur. En conséquence, diviser son travail en tâches de quelques heures au maximum permet de conserver une productivité constante tout au long des semaines et de rester réactif. C’est tout bête, mais sans ce conseil il faut un peu d’expérience pour le trouver par soi-même.
J’avais déjà lu des bribes de ce livre il y a longtemps, quand il était encore à l’état de quelques articles. Je le relis donc, grâce à un bon conseil, dans sa version complète et très bien structurée : C’est radical, et ça vaut vraiment le coup.
|