Comments 25
Многообещающее начало у статьи, а в итоге совершенно ничего не описали. Кроме прописной истины, что если в команде «в основном неопытные» программисты, то завалят и Scrum в тарарам.
Эт же самое вкусное и наиболее частый кейс — попытаться запустить Scrum в неопытной команде. Один из работающих вариантов — жесткая иерархия профессиональной компетенции через «парное программирование» с руководителем отдела разработки :-) и другими профильными гуру в компании с последующим тотальным аудитом результатов спринтов.
Это будет уже не Scrum, а ваша собственная методология. В Scrum не допускается «иерархия профессиональной компетенции», там в команде все равны. Scrum не предусматривает парное программирование и не приветствуются очень большие команды ввиду сложности самоорганизации большой команды (а с большим количеством новичков и парным программированием большая команда неизбежна).
Нельзя просто щелкнуть пальцами и начать работать с неопытной командой по какой-либо agile методологии сразу, не подвергнув проект существенному риску быть заваленным.
Я бы рассматривал 2 подхода:
1. Пилотный проект для обучаемой группы (и разработчики, и PM группы) под присмотром 1-2 тренеров. В этом случае появляются издержки на обучение, но в последствии, такой подход дает выигрыш за счёт уменьшения типичных ошибок членами команды как в управлении процессом, так и в понимании методик.
2. Включение обучаемого в уже опытную команду работающую над проектом, причем проект находится не в начальной стадии. Обучаемого, в этом случае, можно познакомить и с проектом, и с технологиями, которые в нем используются, и Agile методиками, используя «парное программирование». При чем возможно регулировать обучение и не подвергать проект дополнительным рискам за счёт регулирования обучения с помощью назначаемых обучаемому заданий в итерации (ну, или спринте, если использовать терминологию Scrum).
Я бы рассматривал 2 подхода:
1. Пилотный проект для обучаемой группы (и разработчики, и PM группы) под присмотром 1-2 тренеров. В этом случае появляются издержки на обучение, но в последствии, такой подход дает выигрыш за счёт уменьшения типичных ошибок членами команды как в управлении процессом, так и в понимании методик.
2. Включение обучаемого в уже опытную команду работающую над проектом, причем проект находится не в начальной стадии. Обучаемого, в этом случае, можно познакомить и с проектом, и с технологиями, которые в нем используются, и Agile методиками, используя «парное программирование». При чем возможно регулировать обучение и не подвергать проект дополнительным рискам за счёт регулирования обучения с помощью назначаемых обучаемому заданий в итерации (ну, или спринте, если использовать терминологию Scrum).
У такой «полупарности» есть еще один неприятный аспект. Разработчику более высокого уровня через некоторое время становится скучно, или просто не хватает терпения все время «тащить» своего напарника. Приходится его дополнительно мотивировать.
Еще смущает мутность определения «равенства» членов команды. Неопытному разработчику, которому нужно учиться и учиться, «равенство» с опытным — конечно льстит. Опытный, который каждый день нянькается с отстающими, по-другому ощущает мнимое «равенство» — как дополнительную нагрузку по разжевыванию кашки :-) ИМХО о «равенстве» можно говорить лишь в контексте «равенства в отношении и уважении, как равноправного члена команды» (но, опять таки, далеко не равноценного, с различным коэффициентом взаимозаменяемости).
Значит при ВУЗах нужно создавать кузницы кадров или при крупных вендорах. Задача же проста до безобразия — мне в команду нужен квалифицированный программист, с сертификатом, которому я могу инвестиции.
Медиков сколько лет учат, а потом еще ординатура. И только потом можно брать в руки скальпель и кромсать :-). А что с программистом — коллеги учатся на живых проектах и ошибочно удаленные почки и случайно оставшиеся вне тела «лишние» органы приводят к разрушению, загниванию в конвульсиях проекта, в который инвесторы вложили много много денег.
Медиков сколько лет учат, а потом еще ординатура. И только потом можно брать в руки скальпель и кромсать :-). А что с программистом — коллеги учатся на живых проектах и ошибочно удаленные почки и случайно оставшиеся вне тела «лишние» органы приводят к разрушению, загниванию в конвульсиях проекта, в который инвесторы вложили много много денег.
ПТУ (лицей) и техникум (колледж) — вот здесь должны давать начальное (верстальщик?) и среднее (кодер?) профессиональное образование.
Но пообщавшись с некоторые выпускниками по ИТ специальностям готовят там на уровне книг «MS Office за 24 часа для чайников». Может есть исключения, нагуглил вот Высший колледж информатики НГУ — описано солидно
Но пообщавшись с некоторые выпускниками по ИТ специальностям готовят там на уровне книг «MS Office за 24 часа для чайников». Может есть исключения, нагуглил вот Высший колледж информатики НГУ — описано солидно
imho «облегчённые» методологии и Agile вообще изначально предполагают довольно высокий уровень если не всех, то большинства участников команды. Кому не хватает опыта, помогает самомотивация, но на одном энтузиазме без опыта далеко не уедешь.
Вижу вы не поклонник гибких практик разработки. :)
Отнюдь. Гибкие методологии с точки зрения инвестора/менеджера — очень привлекательны! В идеале я получаю оценки более-менее точные, демонстрации каждые 2-4 недели, постоянная гигиена проекта через рефакторинг, а через ретроспективы, я верю, что процесс самосовершенствуется. И конечно в коллективе по идее такая атмосфера создается, что уходить не хочется и наоборот должны приходить в команду :-)
Да и команда должна встречать изменения в требованиях… с радостью! Рай короче для ProductOwner, мечта, дримтим.
А какая альтернатива то? Сидеть и писать попобронирующие технические задания и кидаться артефактами через полудуплексные трубочки.
Но на практике найти путь в этот эффективный рай что-то сложно, одни мины вокруг и волки.
Да и команда должна встречать изменения в требованиях… с радостью! Рай короче для ProductOwner, мечта, дримтим.
А какая альтернатива то? Сидеть и писать попобронирующие технические задания и кидаться артефактами через полудуплексные трубочки.
Но на практике найти путь в этот эффективный рай что-то сложно, одни мины вокруг и волки.
ИМХО, кросфункциональность команды достигается со временем. Благодаря ежедневным стэндап митингам, каждый член команды знает чем занимаются другие. Это и позволяет, при необходимости, заменить какого либо члена команды, оперативно переложить задачи на других членов.
Знаю людей, которые ненавидят ежедневные митинги =) Благо, у меня на работе все проще пока что.
Scrum без ежедневных митингов, не scrum. Если люди их ненавидят, значит либо они не прониклись идеей scrum или что то не то в организации процесса. Значит они не команда. Держать людей, которые не прониклись общей идеей, считаю не выгодно ни кому.
Ежедневные стендапы для разработчиков это разновидность, прошу прощения, секса по расписанию — нужно отчитываться, что ты делал/делаешь/будешь делать. Это снижает конечно мотивацию, имхо, но зато какая польза менеджеру от этого — команда в курсе о происходящих процессах, менеджер тоже, процесс прозрачен :-)
Ну, допустим, по тикетам можно посмотреть кто что делает и над чем работает. Историю коммитов посмотреть, если так интересно.
Выступать ртом не все любят =) Особенно перед клиентами, особенно, если клиенты иностранцы.
И есть другие, которые из кожи вон лезут потрепаться-показаться, не привнося реального вклада в работу команды.
Знаю людей из первой категории, которые лютобешенно не любят вторых. =Ъ
Выступать ртом не все любят =) Особенно перед клиентами, особенно, если клиенты иностранцы.
И есть другие, которые из кожи вон лезут потрепаться-показаться, не привнося реального вклада в работу команды.
Знаю людей из первой категории, которые лютобешенно не любят вторых. =Ъ
Очень хорошая статья, спасибо. Надеюсь на продолжение.
Критикам статьи: может, что-то и кажется очевидным, но все ли думают о результате, сажая двух юниоров в связке? Наверное, статья не для гуру Agile, больше вводная.
Критикам статьи: может, что-то и кажется очевидным, но все ли думают о результате, сажая двух юниоров в связке? Наверное, статья не для гуру Agile, больше вводная.
Спасибо, за вашу инициативу и, пожалуйста, продолжайте публикации. Тем не менее, хочу высказать некоторые замечания:
1. Статья больше относится к управлению любыми проектами, а не только проектами с использованием Agile методик. Конкретнее, к управлению рисками и управлению готовностью.
2. Было бы хорошо увидеть продолжение в виде Case Studies: Что было вводной для проекта? Какая предметная область? Были ли какие-то ограничения (сроки, бюджет, специфические требования и т.д.)? Какой был опыт членов команды в используемых технологиях? А какой был опыт в использовании Agile методик? С какими трудностями пришлось столкнуться? На каких этапах? Как эти трудности были разрешены? Чем закончился проект? Были ли выполнены все поставленные задачи проекта в срок и в пределах бюджета?
Хорошо разобранный частный случай будет более информативным и полезным, чем выводы и обобщения на основании частного случая или специфических проектов. Я не являюсь бескомпромиссным фанатом Agile методик и мой опыт показывает, хороший процесс разработки и управления тот, который эффективно работает для вашего проекта и для вашей команды в пределах проектных ограничений. И при этом нет разницы какие методики или их комбинации используются. Как говорится: «Being Agile rather than Doing Agile.» :)
1. Статья больше относится к управлению любыми проектами, а не только проектами с использованием Agile методик. Конкретнее, к управлению рисками и управлению готовностью.
2. Было бы хорошо увидеть продолжение в виде Case Studies: Что было вводной для проекта? Какая предметная область? Были ли какие-то ограничения (сроки, бюджет, специфические требования и т.д.)? Какой был опыт членов команды в используемых технологиях? А какой был опыт в использовании Agile методик? С какими трудностями пришлось столкнуться? На каких этапах? Как эти трудности были разрешены? Чем закончился проект? Были ли выполнены все поставленные задачи проекта в срок и в пределах бюджета?
Хорошо разобранный частный случай будет более информативным и полезным, чем выводы и обобщения на основании частного случая или специфических проектов. Я не являюсь бескомпромиссным фанатом Agile методик и мой опыт показывает, хороший процесс разработки и управления тот, который эффективно работает для вашего проекта и для вашей команды в пределах проектных ограничений. И при этом нет разницы какие методики или их комбинации используются. Как говорится: «Being Agile rather than Doing Agile.» :)
Sign up to leave a comment.
Подводные камни Scrum — разношерстные кадры