Вопрос очень спорный, и лично я не нашел простого и очевидного ответа на него, хотя искал достаточно долго, и ищу до сих пор (до сих пор верю, что найду способ использовать на аутсорс-проекте чистую эссенцию скрама и ничего кроме). Тем не менее, сам по себе фреймворк дает много ништяков, пользу которых отрицать трудно, если не невозможно. И все же в вопросе, которым озаглавлена статья, между строк читается реальная проблема. Разрешите озвучить.
Скрам — это эджайл фреймворк, он предполагает гибкую разработку. Гибкая разработка предполагает гибкие сроки и аналогичный бюджет. Аутсорс-разработка, в свою очередь, в 95% случаев (кроме дедикейта) предполагает жесткие сроки и жесткий бюджет. Условно: “сделайте мне корпоративный портал за 3 месяца, бюджет 3 миллиона. Плачу вам за результат”. И заказчик прав, он хочет видеть результат. И менеджер должен привести команду к этому результату. Только вот, как это сделать, используя скрам?
Этот фреймворк предполагает неопределенность как в сроках, так и в бюджете. То есть уже на начальном этапе проекта скрам тебе сам говорит: “Постой, мне сюда нельзя, здесь четкие сроки и реальный бюджет, тебе надо искать критический путь, планировать все заранее, ищи что-нибудь вотерфолльное”.
С детства меня папа учил: “Не бывает черного и белого, везде ищи плюсы и минусы”. Да, вотерфолл устарел, да он не очень подходит для гибкой разработки, но он дает понимание и позволяет рассчитать критический путь с учетом всех рисков. Скорее всего критический путь будет неточным и даже пессимистичная оценка окажется весьма оптимистичной (если вы понимаете о чем я), но этот шаг даст примерное понимание объема работы вам самим и вашему заказчику.
Придется потратить много времени на оценку проекта с разработчиками. На обсуждение фич. И это то время, которое жалко тратить, потому что фичи все равно придется переоценивать потом, но пока без этого никуда: иначе проект не продастся и гончая аутсорс-разработки не сорвется с цепи, в погоне за очередной косточкой — не будет косточки.
(!) Этот шаг не говорит о прямой продаже, он лишь об определении условных “от” и “до” в деньгах и в сроках.
Проект взят. Вроде все сроки есть. Задача ясна, ну погнали делать. Алёрт! Не надо так шустро. Скорее всего многие вещи изменились, с тех пор, как вы оценивали проект в первый раз. Мог, например, появиться дизайн или прилетели новые хотелки от заказчика.
У меня предложение. Попробуйте скрам. Из бэклога продукта выделите бэклог спринта, проведите груминг. Тщательно распланируйте спринт, и посмотрите как команда справляется. Проводите дэйли скрамы в формате “Что разработчик сделал вчера/Что делает сегодня”. И ретро в конце спринта, чтобы резюмировать успехи каждого и успехи команды в целом. Вы достаточно быстро заметите, как KPI каждого разработчика растет от спринта к спринту, как уменьшается количество возвратов от QA и как уменьшается бэклог продукта.
P.S. Не спешите отказываться от новых хотелок заказчика. Может они имеют смысл и их можно безболезненно внести в бэклог продукта вместо какого-то другого функционала, который оказался больше не нужен бизнесу вашего заказчика (и соответственно самому заказчику).
Чаще всего, в компаниях, которые занимаются аутсорс-разработкой есть только один менеджер проекта. Без деления на скрам-мастеров и владельцев продукта, но это не такая большая проблема, как кажется на первый взгляд.
У меня на проекте, например, есть крутой тестировщик, которому я делегировал 90% обязанностей владельца продукта (оставшиеся 10% это то, что приходит мне от заказчика, а я уже передаю своему коллеге). Кроме того, что он занимается тестированием (а это он делает отменно), он еще ведет и пополняет бэклог, пишет доку, строит флоу и таблицы сущностей: проделывает огромную работу (не в ущерб своей основной), на которую у меня просто нет времени, ввиду занятости на других проектах.
В таком подходе есть еще один огромный плюс. Для опытного тестировщика (а только такому и можно доверить владение продуктом) это отличный шанс не заскучать и развлечься новыми задачами + почувствовать свою значимость. Не забывайте проявлять доверие к членам своей команды, как минимум потому, что так вы повышаете и свой авторитет в том числе.
P.S. Сейчас я работаю по такой модели не на всех своих проектах. Где-то скрам просто не нужен, потому что он усложняет. В основном это маленькие проекты сроком в один месяц или меньше.
Не самый важный шаг, можно работать и без него, но сложнее. Дело в том что, когда оцениваете таски в часах, то часы получаются у всех разные, у кого-то уйдет 6 часов на создание доменной сущности (условный таск), у кого-то 7, у кого-то 8. В стори поинтах же у всех будет одинаково = 8.
По стори поинтам будет удобнее рассчитывать KPI каждого разработчика, составлять performance review, да и отслеживать успешность продвижения проекта, в целом.
Договоритесь с разработчиками на 8 (мб 5 для джунов) стори поинтов в день, планируйте исходя из этого и смотрите за тем, как закрываются задачи и выполняется проект.
Если разработчик вдруг закроет 8 стори поинтов за 4 часа (5 стори поинтов, если верить числам Фибоначчи), не грузите его/ее новыми тасками. Цените ваши договоренности, уважайте его/ее труд. Часть из его/ее оставшегося “свободного” времени все равно уйдет на изучение следующей фичи, и подготовке к завтрашнему дню, а часть — на саморазвитие, ну или даже на досуг. Хороший досуг тоже мотивирует хорошо работать.
Не делайте все, как написано в скрам гайдах или в любых других пм-ских стандартизаторах. Принимайте решения гибко, и отталкивайтесь от ситуации. Тщательно подбирайте инструменты, предлагаемые разными фреймворками и не стесняйтесь пробовать новое.
Не нужно работать по вотерфоллу или по скраму, чтобы управлять проектами успешно. Нужно работать круто. Только и всего.
Скрам применять можно, и это будет очень даже полезно: отличный фреймворк, который предлагает кучу крутых инструментов для того, чтобы постоянно быть в курсе дела, развиваться самому и давать почву для роста команде, следить за прогрессом проекта и считать KPI членов своей команды.
Тем не менее, скрам это не панацея, и говорить, например, заказчику о том, что мы изначально не знаем во сколько вам встанет проект и сколько времени он займет в условиях аутсорс-разработки скорее всего не получится. Без элементов вотерфолла тут все равно не обойтись.
Не стесняйтесь комбинировать фреймворки и использовать те инструменты, которые нравятся вам и вашей команде, даже если они не предполагаются скрамом. Сделайте так, чтобы работать было удобно, ведь именно это основная цель каждого фреймворка. А как его назвать — дело ваше.
P.S. У меня это ГМС — генно модифицированный скрам.
Проблема
Скрам — это эджайл фреймворк, он предполагает гибкую разработку. Гибкая разработка предполагает гибкие сроки и аналогичный бюджет. Аутсорс-разработка, в свою очередь, в 95% случаев (кроме дедикейта) предполагает жесткие сроки и жесткий бюджет. Условно: “сделайте мне корпоративный портал за 3 месяца, бюджет 3 миллиона. Плачу вам за результат”. И заказчик прав, он хочет видеть результат. И менеджер должен привести команду к этому результату. Только вот, как это сделать, используя скрам?
Этот фреймворк предполагает неопределенность как в сроках, так и в бюджете. То есть уже на начальном этапе проекта скрам тебе сам говорит: “Постой, мне сюда нельзя, здесь четкие сроки и реальный бюджет, тебе надо искать критический путь, планировать все заранее, ищи что-нибудь вотерфолльное”.
Решение проблемы
Шаг 1. Начните с чего-нибудь вотерфолльного, чтобы продать свои услуги
С детства меня папа учил: “Не бывает черного и белого, везде ищи плюсы и минусы”. Да, вотерфолл устарел, да он не очень подходит для гибкой разработки, но он дает понимание и позволяет рассчитать критический путь с учетом всех рисков. Скорее всего критический путь будет неточным и даже пессимистичная оценка окажется весьма оптимистичной (если вы понимаете о чем я), но этот шаг даст примерное понимание объема работы вам самим и вашему заказчику.
Придется потратить много времени на оценку проекта с разработчиками. На обсуждение фич. И это то время, которое жалко тратить, потому что фичи все равно придется переоценивать потом, но пока без этого никуда: иначе проект не продастся и гончая аутсорс-разработки не сорвется с цепи, в погоне за очередной косточкой — не будет косточки.
(!) Этот шаг не говорит о прямой продаже, он лишь об определении условных “от” и “до” в деньгах и в сроках.
Шаг 2. Ура! Мы взяли проект, начинаем работу по скраму (по его образу и подобию)
Проект взят. Вроде все сроки есть. Задача ясна, ну погнали делать. Алёрт! Не надо так шустро. Скорее всего многие вещи изменились, с тех пор, как вы оценивали проект в первый раз. Мог, например, появиться дизайн или прилетели новые хотелки от заказчика.
У меня предложение. Попробуйте скрам. Из бэклога продукта выделите бэклог спринта, проведите груминг. Тщательно распланируйте спринт, и посмотрите как команда справляется. Проводите дэйли скрамы в формате “Что разработчик сделал вчера/Что делает сегодня”. И ретро в конце спринта, чтобы резюмировать успехи каждого и успехи команды в целом. Вы достаточно быстро заметите, как KPI каждого разработчика растет от спринта к спринту, как уменьшается количество возвратов от QA и как уменьшается бэклог продукта.
P.S. Не спешите отказываться от новых хотелок заказчика. Может они имеют смысл и их можно безболезненно внести в бэклог продукта вместо какого-то другого функционала, который оказался больше не нужен бизнесу вашего заказчика (и соответственно самому заказчику).
Шаг 2.1. Ввести на проект владельца продукта
Чаще всего, в компаниях, которые занимаются аутсорс-разработкой есть только один менеджер проекта. Без деления на скрам-мастеров и владельцев продукта, но это не такая большая проблема, как кажется на первый взгляд.
У меня на проекте, например, есть крутой тестировщик, которому я делегировал 90% обязанностей владельца продукта (оставшиеся 10% это то, что приходит мне от заказчика, а я уже передаю своему коллеге). Кроме того, что он занимается тестированием (а это он делает отменно), он еще ведет и пополняет бэклог, пишет доку, строит флоу и таблицы сущностей: проделывает огромную работу (не в ущерб своей основной), на которую у меня просто нет времени, ввиду занятости на других проектах.
В таком подходе есть еще один огромный плюс. Для опытного тестировщика (а только такому и можно доверить владение продуктом) это отличный шанс не заскучать и развлечься новыми задачами + почувствовать свою значимость. Не забывайте проявлять доверие к членам своей команды, как минимум потому, что так вы повышаете и свой авторитет в том числе.
P.S. Сейчас я работаю по такой модели не на всех своих проектах. Где-то скрам просто не нужен, потому что он усложняет. В основном это маленькие проекты сроком в один месяц или меньше.
Шаг 2.2. Переводить оценку в часах в стори поинты
Не самый важный шаг, можно работать и без него, но сложнее. Дело в том что, когда оцениваете таски в часах, то часы получаются у всех разные, у кого-то уйдет 6 часов на создание доменной сущности (условный таск), у кого-то 7, у кого-то 8. В стори поинтах же у всех будет одинаково = 8.
По стори поинтам будет удобнее рассчитывать KPI каждого разработчика, составлять performance review, да и отслеживать успешность продвижения проекта, в целом.
Договоритесь с разработчиками на 8 (мб 5 для джунов) стори поинтов в день, планируйте исходя из этого и смотрите за тем, как закрываются задачи и выполняется проект.
Если разработчик вдруг закроет 8 стори поинтов за 4 часа (5 стори поинтов, если верить числам Фибоначчи), не грузите его/ее новыми тасками. Цените ваши договоренности, уважайте его/ее труд. Часть из его/ее оставшегося “свободного” времени все равно уйдет на изучение следующей фичи, и подготовке к завтрашнему дню, а часть — на саморазвитие, ну или даже на досуг. Хороший досуг тоже мотивирует хорошо работать.
Шаг 3. Работайте круто
Не делайте все, как написано в скрам гайдах или в любых других пм-ских стандартизаторах. Принимайте решения гибко, и отталкивайтесь от ситуации. Тщательно подбирайте инструменты, предлагаемые разными фреймворками и не стесняйтесь пробовать новое.
Не нужно работать по вотерфоллу или по скраму, чтобы управлять проектами успешно. Нужно работать круто. Только и всего.
Вывод
Скрам применять можно, и это будет очень даже полезно: отличный фреймворк, который предлагает кучу крутых инструментов для того, чтобы постоянно быть в курсе дела, развиваться самому и давать почву для роста команде, следить за прогрессом проекта и считать KPI членов своей команды.
Тем не менее, скрам это не панацея, и говорить, например, заказчику о том, что мы изначально не знаем во сколько вам встанет проект и сколько времени он займет в условиях аутсорс-разработки скорее всего не получится. Без элементов вотерфолла тут все равно не обойтись.
Не стесняйтесь комбинировать фреймворки и использовать те инструменты, которые нравятся вам и вашей команде, даже если они не предполагаются скрамом. Сделайте так, чтобы работать было удобно, ведь именно это основная цель каждого фреймворка. А как его назвать — дело ваше.
P.S. У меня это ГМС — генно модифицированный скрам.
VolCh
Скрам нормально работает при фиксед прайс термс, если не зафиксирован скоуп работ.Сами говорите просто выполнение новых хотелок за счёт отмены начальных.
Дэйли митинги не про "сделал-буду делать", а про выявление проблем.
Jayalljust Автор
Владимир, спасибо за комментарий. Не хочу с вами спорить, просто скажу, что с проектом будет беда, если проблемы выявлять на дэйли митингах. Как правило, проблемы выявляются на грумминге и в процессе разработки и обсуждаются между командой сразу по мере их поступления.
В том формате, в котором работаю я, проблемы могут оговариваться в рамках митинга сделал/не сделал, потому что… Если начинать обсуждать каждую проблему на митинге, может быть: а) слишком поздно, ибо часть времени уже потеряна б) потеряно много времени на обсуждение.
VolCh
На грумминге выявляются предполагаемые проблемы, на дэйли озвучивается то, что на груминге было не выявлено по каким-то причинам. И решается как, кем и когда будет решаться проблема, если решение нельзя озвучить за 30 секунд. Имхо, конечно же.
Jayalljust Автор
Что я хочу сказать: ситуации всегда разные бывают. Здесь необходима гибкость. Конечно, если есть реальные проблемы почему бы их быстро не решить на митинге. Это будет адекватно. Но если проблема абстрактно-потенциальная, лучше разобраться с ней на следующем грумминге. А вообще, как заметил ранее, лучше всего, когда проблемы решаются не только на митингах, но и через «внемитинговые коммуникации».
VolCh
Может не точно выразился, я имел в виду, что на дэйлике прежде всего озвучиваются проблемы, которые могут помешать достигнуть целей спринта, закрыть весь бэклог спринта. Если проблему можно решить за 30 секунд, то тут же и решается, если нужен митинг, то собирается после дэйлика. А если проблема такая, что решить её в рамках спринта нельзя, то решается фэйлим или отменяем спринт вообще, делаем груминг, плэнинг и начинаем новый спринт.
Jayalljust Автор
Здесь спорить не буду. Бывают такие ситуации, но возникают они далеко не каждый день. И внеплановые митинги, иногда собирать приходится, но до отмены спринта дело еще ни разу не доходило.
А вообще да, согласен, всякое бывает.