Вопрос очень спорный, и лично я не нашел простого и очевидного ответа на него, хотя искал достаточно долго, и ищу до сих пор (до сих пор верю, что найду способ использовать на аутсорс-проекте чистую эссенцию скрама и ничего кроме). Тем не менее, сам по себе фреймворк дает много ништяков, пользу которых отрицать трудно, если не невозможно. И все же в вопросе, которым озаглавлена статья, между строк читается реальная проблема. Разрешите озвучить.
Скрам — это эджайл фреймворк, он предполагает гибкую разработку. Гибкая разработка предполагает гибкие сроки и аналогичный бюджет. Аутсорс-разработка, в свою очередь, в 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. У меня это ГМС — генно модифицированный скрам.
