Move People Around
Материал из AgileWiki
Содержание |
Определение
Обсуждения
Меняйтесь задачами
Необходимо периодически менять задачи у разработчиков для уменьшения риска концентрации знаний и узких мест в коде. Если только один человек в вашей команде может работать в данной области и этот человек уходит или вам просто надо много всего сделать в данном сегменте программы, вы обнаружите что ваш проект еле-еле продвигается вперед.
Cross Training обычно является важным аспектом в компаниях которые стараются избежать концентрации знаний в одном человеке. Перемещение людей по коду в комбинации с парным программированием незаметно делает Cross Training для вас. Вместо одного человека, который знает все о данном куске кода, каждый в вашей команде знает много о коде в каждом модуле.
Команда становится намного более гибкой если все знают достаточно о каждой части системы чтобы начать работать над ней. Вместо того чтобы ждать пока "гуру" закончит работу над критическим куском кода, несколько программистов могут работать над ним одновременно.
При начале новой итерации каждый разработчик должен перейти на новую задачу. Парное программирование помогает преодолеть проблему адаптации (это значит что новый разработчик может начать работать в паре с опытным в данной области разработчиком).
Такая практика также стимулирует появление новых идей и улучшение кода.
Наш опыт.
До сих пор в нашей системе есть куски в которые разработчики опасаются залезать. Люди которые их писали ушли, куски вроде бы работают, но менять их опасно. Проблему можно решить с помощью рефакторинга и Unit Test-ов, но это требует времени. Это сильно тормозит работу.
...
Move People Around
Move people around to avoid serious knowledge loss and coding bottle necks. If only one person on your team can work in a given area and that person leaves or you just have numerous things waiting to be done in that section you will find your project's progress reduced to a crawl.
Cross Training is often an important consideration in companies trying to avoid islands of knowledge, which are so susceptible to loss. Moving people around the code base in combination with pair programming does your cross training for you. Instead of one person who knows everything about a given section of code, everyone on the team knows much of the code in each section.
A team is much more flexible if everyone knows enough about every part of the system to work on it. Instead of having a few people overloaded with work while other team members have little to do, the whole team can be productive. Any number of developers can be assigned to the hottest part of the system. Flexible load balancing of this type is a manager's dream come true.
Simply encourage everyone to try working on a new section of the system at least part of each iteration. Pair Programming makes it possible without losing productivity and ensures continuity of thought. One person from a pair can be swapped out while the other continues with a new partner if desired.
Switch Teams Around
In general , we have had our best results by switching teams around. There are a few areas where one developer has so much experience or knowledge that they tend to come back to that area whenever there’s more to do.
Sometimes this has worked well, usually when it is specialized domain knowledge that’s in question. We’ve had developers who have tried to stick with internal parts of the system, and by and large that works out less well. I suspect that it’s because it’s hard to build good systems tools if you don’t have to use them. In any case, if you have someone who is stuck on some area, it’s to your advantage and theirs to move them to something else: you’ll get cross-training in their specialty area, and you’ll keep everyone fresh.
As a general rule, in every iteration, move the person who has been on the team longer to a new area.
