Вопрос очень спорный, и я лично не нашел на него простого и очевидного ответа, хотя искал довольно долго, и ищу до сих пор (по-прежнему верю, что найду способ использовать чистый суть Scrum и ничего более в аутсорсинговом проекте).
Однако сам фреймворк предоставляет массу плюсов, преимущества которых сложно, а то и невозможно отрицать.
И все же в вопросе, вынесенном в заголовок статьи, есть реальная проблема, которую нужно читать между строк.
Позвольте мне озвучить это.
Проблема
Scrum — это гибкая структура, которая предполагает гибкую разработку.Гибкая разработка предполагает гибкие сроки и аналогичный бюджет. Аутсорсинговая разработка, в свою очередь, в 95% случаев (за исключением дедкидинга) предполагает сжатые сроки и ограниченный бюджет. Условно: «сделайте мне корпоративный портал за 3 месяца, бюджет 3 миллиона.
Я плачу вам за результат».
И заказчик прав, он хочет видеть результат. И менеджер должен привести команду к этому результату.
Но как это сделать с помощью Scrum? Эта основа предполагает неопределенность как в отношении сроков, так и бюджета.
То есть уже на начальном этапе проекта сам Scrum говорит вам: «Подожди, я не могу сюда прийти, есть четкие сроки и реальный бюджет, нужно искать критический путь, планировать все заранее, ищи что-нибудь водопад».
Решение
Шаг 1. Начните с водопада, чтобы продавать свои услуги
С детства папа учил меня: «Не бывает черного и белого, везде ищи плюсы и минусы».Да, водопад устарел и не очень подходит для гибкой разработки, но он дает понимание и позволяет просчитать критический путь с учетом всех рисков.
Скорее всего, критический путь не будет точным и даже пессимистическая оценка окажется очень оптимистичной (если вы понимаете, о чем я), но этот шаг даст примерное представление об объеме работы для вас и вашего заказчика.
Вам придется потратить немало времени на оценку проекта вместе с разработчиками.
Для обсуждения особенностей.
И это время, которое жалко терять, ведь фичи потом все равно придется переоценивать, а пока без этого никак: иначе проект не продастся и гончая аутсорс-разработки не сломается рыхлый, в погоне за следующей косточкой не будет. (!) Этот шаг не говорит о прямых продажах, речь идет лишь об определении условных «от» и «до» в денежном и терминальном плане.
Шаг 2. Ура! Взяли проект, начинаем работать по Scrum (по его образу и подобию)
Проект принят. Вроде бы все сроки соблюдены.Задача ясна, что ж, поехали делать.
Тревога! Не спешите.
Скорее всего, многое изменилось с тех пор, как вы впервые оценили проект. Например, мог появиться дизайн или поступили новые пожелания от заказчика.
У меня есть предложение.
Попробуйте Скрам.
В журнале невыполненных работ по продукту выберите журнал невыполненных работ по спринту и выполните очистку.
Тщательно спланируйте спринт и посмотрите, как справится команда.
Проводите ежедневные скрамы в формате «Что разработчик делал вчера/Что он делает сегодня».
И ретро в конце спринта, чтобы подвести итоги прогресса каждого и успеха команды в целом.
Вы быстро заметите, как от спринта к спринту увеличивается KPI каждого разработчика, как уменьшается количество возвратов от QA и как уменьшается бэклог продукта.
P.S. Не спешите отказываться от новых пожеланий клиента.
Может быть, они имеют смысл и их можно безболезненно добавить в бэклог продукта вместо какого-то другого функционала, который оказался уже не нужен бизнесу вашего заказчика (и, соответственно, самому заказчику).
Шаг 2.1. Добавьте владельца продукта в проект
Чаще всего компании, занимающиеся аутсорсинговой разработкой, имеют только одного менеджера проекта.Не разделяя на Scrum Masters и Product Owners, но это не такая большая проблема, как кажется на первый взгляд. Например, у меня на проекте есть крутой тестировщик, которому я делегировал 90% обязанностей Product Owner (остальные 10% — это то, что приходит ко мне от заказчика, и я уже передаю это коллеге).
Помимо тестирования (и с этим он справляется превосходно), он еще поддерживает и расширяет бэклог, пишет в документ, строит флоу и таблицы сущностей: он отлично справляется (не в ущерб своей основной работе), что я просто на это нет времени, так как занят другими проектами.
У этого подхода есть еще одно огромное преимущество.
Для опытного тестировщика (а только такому человеку можно доверить владение продуктом) это отличный шанс не заскучать и получить удовольствие от новых задач + почувствовать свою значимость.
Не забывайте проявлять доверие к членам своей команды, хотя бы потому, что так вы еще и повысите свой авторитет. P.S. Сейчас я не на всех своих проектах работаю по этой модели.
В некоторых местах Scrum просто не нужен, потому что он усложняет ситуацию.
В основном это небольшие проекты продолжительностью один месяц или меньше.
Шаг 2.2. Конвертируйте рейтинг в часах в баллы истории
Не самый важный шаг, без него можно обойтись, но это сложнее.Дело в том, что когда вы оцениваете задачи в часах, то часы у всех разные, у кого-то на создание доменной сущности (условной задачи) уйдет 6 часов, у кого-то 7, у кого-то 8. В стори-пойнтах у всех будет то же = 8. Используя Story Points, будет удобнее рассчитать KPI каждого разработчика, составить обзор эффективности и отслеживать успешность проекта в целом.
Договаривайтесь с разработчиками за 8 (5 МБ для джуниоров) стори-пойнтов в день, планируйте исходя из этого и смотрите, как выполняются задания и завершается проект. Если разработчик вдруг за 4 часа закроет 8 сторипойнтов (5 сторипойнтов по числам Фибоначчи), не нагружайте его новыми задачами.
Цените ваши договоренности, уважайте его труд. Часть оставшегося «свободного» времени все равно будет тратить на изучение очередной особенности и подготовку к завтрашнему дню, а часть на саморазвитие или даже досуг.
Хороший досуг также мотивирует вас хорошо работать.
Шаг 3: Работайте усердно
Не делайте все так, как написано в руководствах по Scrum или других стандартизаторах PM. Принимайте решения гибко и учитывайте ситуацию.Тщательно выбирайте инструменты, предлагаемые различными фреймворками, и не стесняйтесь пробовать что-то новое.
Вам не обязательно работать с Waterfall или Scrum, чтобы успешно управлять проектами.
Вам нужно много работать.
Вот и все.
Заключение
Вы можете использовать Scrum, и это будет очень полезно: отличный фреймворк, предлагающий кучу крутых инструментов для того, чтобы постоянно быть в курсе событий, развивать себя и давать рост команде, следить за ходом проекта и подсчитывать KPI вашей команды.члены.
Однако Scrum — не панацея, и сказать, например, заказчику, что мы изначально не знаем, сколько вам будет стоить проект и сколько времени он займет в условиях аутсорсинговой разработки, скорее всего, не получится.
Без элементов водопада здесь все равно не обойтись.
Смело комбинируйте фреймворки и используйте те инструменты, которые нравятся вам и вашей команде, даже если они не предложены Scrum. Сделать так, чтобы было удобно работать, ведь это основная цель каждого фреймворка.
Как вы это назовете, решать вам.
P.S. У меня есть этот GMS - генетически модифицированный скрам.
Теги: #Управление разработкой #Управление продуктом #agile #scrum #управление проектами #agile разработка #аутсорсинг
-
Советы По Установке Удаленного Доступа К Пк
19 Oct, 24 -
Ddr4 Поступит В Продажу В Следующем Месяце
19 Oct, 24 -
Книга Про Тотал Коммандер
19 Oct, 24 -
Наличие В Магазинах
19 Oct, 24 -
Карма – Это Приглашение На Вечеринку
19 Oct, 24
