И ещё, из написанного можно сделать следующий вывод: я не буду думать над тем, как написать простой код, реализующий бизнес-задачу,
а буду писать как мне хочется и использовать ту технологию, которую хочется,
т.к. я всегда могу пополнить «технический бэклог» заданиями, по исправлению моих ошибок,
который «крышуется» «техническим директором»,
который важнее владельца продукта,
а так же пользы для бизнеса, которую несет продукт.
Без обид. Я просто хочу понять, что же вы имеете в виду.
Один из принципов итеративной разработки — на каждой итерации поставлять продукт имеющий ценность для бизнеса.
Вы же, получается, пишите о некоем техническом бэклоге, который прикрывает «техдир», который, по сути, провоцирует несогласованное с Product Owner-ом уменьшение ценности релиза для бизнеса, причем, из написанного вами, чем дальше отстоит итерация от начала проекта, тем больше.
Появление технических историй в ходе проекта — это нормально. Искать решение вне проектной команды — не уверен, что правильно. Правильнее найти компромисс между Product Owner и командой. Например, через согласованное снижение количества функциональности, которое планируется реализовать на новой итерации для реализации каких-то технических историй.
А что такое «технический бэклог»? У команды может быть 1-2 бэклога (в идеале 1), за которыми следят Product Owner-ы. И всё.
Что брать на следующую итерацию решается совместно, т.е. технические извраты и излишества проскочить не должны. Если это не так, то что делают в проекте Scrum Master и что делает, если есть, Team Lead. Team Lead — вполне допустимая роль, которую можно использовать как раз по вопросам, связанным с выбором технологий.
Спасибо, за вашу инициативу и, пожалуйста, продолжайте публикации. Тем не менее, хочу высказать некоторые замечания:
1. Статья больше относится к управлению любыми проектами, а не только проектами с использованием Agile методик. Конкретнее, к управлению рисками и управлению готовностью.
2. Было бы хорошо увидеть продолжение в виде Case Studies: Что было вводной для проекта? Какая предметная область? Были ли какие-то ограничения (сроки, бюджет, специфические требования и т.д.)? Какой был опыт членов команды в используемых технологиях? А какой был опыт в использовании Agile методик? С какими трудностями пришлось столкнуться? На каких этапах? Как эти трудности были разрешены? Чем закончился проект? Были ли выполнены все поставленные задачи проекта в срок и в пределах бюджета?
Хорошо разобранный частный случай будет более информативным и полезным, чем выводы и обобщения на основании частного случая или специфических проектов. Я не являюсь бескомпромиссным фанатом Agile методик и мой опыт показывает, хороший процесс разработки и управления тот, который эффективно работает для вашего проекта и для вашей команды в пределах проектных ограничений. И при этом нет разницы какие методики или их комбинации используются. Как говорится: «Being Agile rather than Doing Agile.» :)
Нельзя просто щелкнуть пальцами и начать работать с неопытной командой по какой-либо agile методологии сразу, не подвергнув проект существенному риску быть заваленным.
Я бы рассматривал 2 подхода:
1. Пилотный проект для обучаемой группы (и разработчики, и PM группы) под присмотром 1-2 тренеров. В этом случае появляются издержки на обучение, но в последствии, такой подход дает выигрыш за счёт уменьшения типичных ошибок членами команды как в управлении процессом, так и в понимании методик.
2. Включение обучаемого в уже опытную команду работающую над проектом, причем проект находится не в начальной стадии. Обучаемого, в этом случае, можно познакомить и с проектом, и с технологиями, которые в нем используются, и Agile методиками, используя «парное программирование». При чем возможно регулировать обучение и не подвергать проект дополнительным рискам за счёт регулирования обучения с помощью назначаемых обучаемому заданий в итерации (ну, или спринте, если использовать терминологию Scrum).
я не буду думать над тем, как написать простой код, реализующий бизнес-задачу,
а буду писать как мне хочется и использовать ту технологию, которую хочется,
т.к. я всегда могу пополнить «технический бэклог» заданиями, по исправлению моих ошибок,
который «крышуется» «техническим директором»,
который важнее владельца продукта,
а так же пользы для бизнеса, которую несет продукт.
Без обид. Я просто хочу понять, что же вы имеете в виду.
Вы же, получается, пишите о некоем техническом бэклоге, который прикрывает «техдир», который, по сути, провоцирует несогласованное с Product Owner-ом уменьшение ценности релиза для бизнеса, причем, из написанного вами, чем дальше отстоит итерация от начала проекта, тем больше.
Появление технических историй в ходе проекта — это нормально. Искать решение вне проектной команды — не уверен, что правильно. Правильнее найти компромисс между Product Owner и командой. Например, через согласованное снижение количества функциональности, которое планируется реализовать на новой итерации для реализации каких-то технических историй.
Что брать на следующую итерацию решается совместно, т.е. технические извраты и излишества проскочить не должны. Если это не так, то что делают в проекте Scrum Master и что делает, если есть, Team Lead. Team Lead — вполне допустимая роль, которую можно использовать как раз по вопросам, связанным с выбором технологий.
И, наконец, причем здесь технический директор?
Как это нет? А это?
1. Статья больше относится к управлению любыми проектами, а не только проектами с использованием Agile методик. Конкретнее, к управлению рисками и управлению готовностью.
2. Было бы хорошо увидеть продолжение в виде Case Studies: Что было вводной для проекта? Какая предметная область? Были ли какие-то ограничения (сроки, бюджет, специфические требования и т.д.)? Какой был опыт членов команды в используемых технологиях? А какой был опыт в использовании Agile методик? С какими трудностями пришлось столкнуться? На каких этапах? Как эти трудности были разрешены? Чем закончился проект? Были ли выполнены все поставленные задачи проекта в срок и в пределах бюджета?
Хорошо разобранный частный случай будет более информативным и полезным, чем выводы и обобщения на основании частного случая или специфических проектов. Я не являюсь бескомпромиссным фанатом Agile методик и мой опыт показывает, хороший процесс разработки и управления тот, который эффективно работает для вашего проекта и для вашей команды в пределах проектных ограничений. И при этом нет разницы какие методики или их комбинации используются. Как говорится: «Being Agile rather than Doing Agile.» :)
Я бы рассматривал 2 подхода:
1. Пилотный проект для обучаемой группы (и разработчики, и PM группы) под присмотром 1-2 тренеров. В этом случае появляются издержки на обучение, но в последствии, такой подход дает выигрыш за счёт уменьшения типичных ошибок членами команды как в управлении процессом, так и в понимании методик.
2. Включение обучаемого в уже опытную команду работающую над проектом, причем проект находится не в начальной стадии. Обучаемого, в этом случае, можно познакомить и с проектом, и с технологиями, которые в нем используются, и Agile методиками, используя «парное программирование». При чем возможно регулировать обучение и не подвергать проект дополнительным рискам за счёт регулирования обучения с помощью назначаемых обучаемому заданий в итерации (ну, или спринте, если использовать терминологию Scrum).