Узкая специализация в команде
Serge Levin
Бежим четвертый спринт и уже стала возникать узкая специализация в
команде. Другими словами, все знают общую структуру проекта, все
понимают что где и как происходит. Но, получилось что одному человеку
удобно брать таски интеграции с внешней системой. Он их все время
берет и стал делать довольно быстро. Базы он ни разу не видел. Другие
работают с базой, третьи с интерфейсом. Те, кто работат с интерфейсам
не видели системы с которой интегрируются. Задачи по "своей" части
делаются быстро и качественно. Скорость классная. Заваленых спринтов
пока нет. В случае болезни одного из участников, нет второго, кто бы
видел и писал код в области другого.
Большая ли эта проблема? Нужно ли с ней бороться и как?
Спасибо,
Сергей
Олег Яворский
кардинальными мерами, вроде перевода задач на "непрофи". Можно
попробовать ребятам поработать в паре над кодом. Для начала, одного
"бекапа" для каждой специализации будет достаточно, чтобы уменьшить
риски при болезни или отпуске.
Олег.
14 сент. 2009, в 22:37, Serge Levin написал(а):
Alexey Maslov
Yuriy Mann
Что бы ни говорили теоретики аджайла, специализация не так уж и плоха,
может прилично повысить среднесрочную эффективность команды. До тех
пор, естественно, пока "специалист" доступен.
Мы стараемся выявлять такие места в проекте на ретроспективах. Если
подсаживание людей в пару выглядит слишком уж искусственно, то создаем
прямо такой backlog item: расшарить знание такого-то кода. Либо
заблаговременно планируем, что очередную задачу по такой-то
функциональности возьмет другой человек. Как правило, ему естественным
образом приходится работать в паре с "экспертом" какое-то время. Такой
себе неформальный риск-менеджмент.
Когда в какой-то области два эксперта, это уже покрывает большинство
рисков. Мало того, по нашему опыту, где два эксперта, там и третий и
четвертый со временем появляются. Главное: избавить команду от
ощущения, что этот код безопасно может минять только Петя и больше
никто.
И, кстати, code review! После того, как мы ввели обязательные code
review, у нас ситуации, когда код видел только один человек, почти
пропали. Исполнитель не может закрыть таску, пока кто-то не проведет
code review. Его ответственность: найти ревьювера и добиться, чтобы
тот потратил на это время. Альтернатива, конечно, парное
программирование. Но у нас оно так и не прижилось как обязательная
практика, хотя в каждый момент времени 20-50% команды реально в парах
работает.
Alexey Tigarev
> Что бы ни говорили теоретики аджайла, специализация не так уж и плоха,
> может прилично повысить среднесрочную эффективность команды. До тех
> пор, естественно, пока "специалист" доступен.
Не просто доступен, а "доступен достаточное количество времени".
А вот случаются такие итерации, когда почти все user stories - на одну тему.
Скажем, velocity команды - 20 story points.
Но команда в результате может сделать только 5 story points в такую
итерацию, так как имеется только один "узкий специалист" по
актуальному вопросу. Он доступен, но его производительность заведомо
меньше производитльности всей команды, на которую рассчитывают при
планировании.
В результате планирование традиционным Scrum-способом не работает:
если просто забить в бэклог итерации N верхних задач из продакт
бэклога, таких что сумма их оценок оказывается меньше либо равна
velocity - получится набор задач, по которому команда не может дать
commitment.
Приходится выбрасывать из бэклога итерации часть высокоприоритетных
user stories так, чтобы узкий специалист справился, и набивать в неё
на освободившееся место низкоприоритетные истории, которые могут
делать остальные.
Что может существенно огорчить продукт-овнера, так как он привык к
тому, что а). первыми делаются всегда истории, которым он поставил
максимальный приоритет, б).
делается предсказуемое количество этих историй.
У команды возникает вопрос: как оценивать истории, по которым имеется
только "узкий специалист". Можно оценивать их как очень сложные -
тогда количество, вошедшее в итерацию в описанном выше случае, будет
таким, что специалист (с некоторым участием начинающих учиться этой
области остальных) таки успеет всё это сделать за итерацию. Но если
среди приоритетных user stories есть и те, которые могут делать
остальные - то узкий специалист сделает примерно столько же, плюс ещё
остальные кучу всего - т.е. следовательно, истории следовало бы
оценить меньшими числами при той же velocity.
Таким образом - не получается сделать user stories независимыми
(independent). Оценки в этом случае зависят не от порядка выполнения,
а от количества историй такого-то типа, приходящихся на итерацию.
Даже если не учитывать риски болезни узкого специалиста и отпуска -
выделение узких специалистов может привести к очень тяжёлой для
команды ситуации.
К тому же стоит вспомнить поговорку - одна голова хорошо, а две лучше.
При наличии альтернативного взгляда, скажем, на дизайн такой-то
функциональной области - можно сдизайнить её лучше, чем если бы этим
занимался один человек. Три головы - думаю, ещё лучше :)
То есть я считаю, что кроссфункциональность очень важна. Естественно,
стремиться достичь 100%-ой кроссфункциональности не стоит - при
приближении к ста процентам рентабельность дальнейшего улучшения
кроссфункциональности стремится к нулю, но отслеживать связанные с
этим риски и стремиться их минимизировать надо, например, способами,
про которые рассказал Юрий.
--
С уважением, Алексей Тигарев
<ti...@nlp.od.ua> Jabber: ti...@jabber.od.ua http://t_gra.livejournal.com/
Tim Yevgrashyn
Если не помогло в течении 2-3 спринтов, то Алексей достаточно подробно изложил "почему" это проблема для всего проекта. Имея такую теоретическую базу, команде нужно просто собраться и придумать свое решение ;-)
Еще по поводу проблем с "Компонентными командами" хорошо рассказывал Bas Vodde на прошлом ScrumAlliance Gathering. Посмотреть презентацию можно здесь (http://www.scrumalliance.org/resources/426). Это часть книги База и Крейга Лармана "Scaling Lean and Agile Development". Да и вообще судя по всему становится популярной проблемой для любого проекта, который длиться достаточно долго, чтобы у людей начали вырабатываться "специализации".
ИМХО, быть экспертом в области не должно означать, что ты делаешь все реквесты хоть как-то связанные с ней. Как говорил один сенсей: "бьют обычно не по цвету пояса, а выше или ниже пояса" ;-)
Tim Yevgrashyn,
Web: http://tim.com.ua
Skype: spidertim
Phone: +380 67 408 53 30
Олег Яворский
Artjom Serdyuk
С моей точки зрения, это не проблема, а риск. Им нужно управлять.
Алексей описал возможные сценарии, Юрий - варианты решения.
Задайте вопрос - насколько этот риск для вас критичен? Какая
вероятность реализации каждого из сценариев, и какой от каждого будет
ущерб?
И сколько вам будут стоить меры по предотвращению, и меры по
ликвидации последствий.
На основании ответом можно будет сделать вывод - либо вы принимаете
риск, либо инвестируете в меры по его предотвращению.
On 15 сен, 21:38, Олег Яворский <oleg.iavors...@gmail.com> wrote:
> Ну тут уже вопрос риторический, мол, могу копать, а могу и не копать :)
>
> Риски при узкой специализации есть и, как любые другие, их можно
> стараться предотвратить, а можно и игнорировать. Я бы не игнорировал :)
>
> 15 сент. 2009, в 11:49, Alexey Maslov написал(а):
>
>
>
> > А зачем бороться? :)
>
> > Regards,
> > Alexey Maslov
>
> > 2009/9/14 Олег Яворский <oleg.iavors...@gmail.com>
Serge
еще раз. О результатах и прогрессе отпишусь. Получается еще один плюс
к введению code review (как минимум).
Спасибо,
Сергей
VDU
Все-таки для agile команды узкой специализации быть не должно, так как
это противоречит духу командной работы. В частности оценка времени
должна быть без привязки к ресурсам (за редким исключением);
совместное владение кодом и т.д. У человека не может быть правильной
мотивации в проекте, если он копается только в какой-то отдельной
подсистеме, не интресуяси всей системой вцелом.
С другой стороны в больших и/или сложных проектах добиваться полной
универсальности тоже не стоит. Там борьба со специализацией должна
быть на уровне подсистем и модулей.
Сейчас специализация опасна, так как существует постоянная опасность
<<неожиданных>> сокращений в команде (раньше - был риск переманивания в
другую компанию).
Личный опыт показывает, что высококлассному программисту нужно
несколько часов, чтобы начать работать с самым сложным кодом. Тут
скорее вопрос психологический, а не технический. Гораздо сложнее с
бизнес знаниями (в сложных продуктах).
При увольнении сотрудника (по любым причинам) нужно резервировать
время на перераспределение знаний. Обязательно составлять план
передачи дел (что и кому). Важно, чтобы у человека была мотивация
передать свои знания.
Очень хорошая возможность (кроме уже упоминавшегося ревью кода) для
получения представления о всей системе - поработать (периодическая) в
команде поддержки (баг фиксинг), если таковая есть.