Людям свойственно со временем забывать откуда все пошло, поэтому нужно вспоминать. Публикация навеяна статьей «Почему Scrum не надо применять там, где не надо — ограничения и допущения фреймворка«.
Конечно, это моя интерпретация, но она основана на огромном количестве времени обучения, самообучения и опыта в индустрии.
Понятно, что тут только про разработку ПО. И разработку длительную (в коротких проектах есть много возможностей где-то срезать углы).
Идейная основа Agile-манифеста (ака честный и понятный Agile-манифест):
-
PMBoK и остальные классические методы управления проектами не дают достаточный результат. В топку их.
-
Пока что у человечества нет способа успешно завершать проекты. Поэтому мы рассчитываем на то, что и не будем (придется что-то двигать в пирамидке время, функционал, стоимость и качество).
-
Мы считаем, что в пирамидке имеет смысл двигать только функционал. Другими словами мы не гарантируем то, что успеем сделать, а все остальное гарантируем.
-
Делаем сначала самый критичный функционал, затем менее критичный. Функционал делаем так, чтобы все необязательные вещи отложить на потом, так чтобы быстрее прийти к ситуации минимально рабочего продукта (и уже от этого этапа заниматься улучшениями). Т.о., в любой момент будет выдана максимальная ценность на затраты.
-
Мы гарантируем, что будем максимально активно работать. Для этого мы обеспечиваем максимальную прозрачность для заказчика.
-
Мы гарантируем, что приложим усилия по постоянному анализу и улучшению того как мы работаем.
-
Ма гарантируем, что будем поставлять небольшими итерациями, чтобы иметь возможность быстро адаптироваться.
-
Мы всячески поддерживаем изменение ТЗ, чтобы сделать именно то, что нужно, а не то, что было понятно до начала проекта.
-
Мы ожидаем сильную вовлеченность заказчика в процесс разработки, т.к. это одна из общих черт успешных проектов.
Почему они сразу не написали что-то подобное? Видимо, не было цели сделать его простым и понятным. Или просто написали то, что и как успели. Все-таки согласовать что-то среди 17 человек (и у каждого огромный опыт) весьма сложно.
Другими словами: нет способов -> и не будет от нас -> что успеем функционал -> компенсации за такой подход.
Эти 9 пунктов соответствуют 4м пунктам манифеста. 12-ти основополагающим принципам не соответствует в одном пункте («Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.»). Точнее этот пункт вынесен за скобки: его можно было бы сделать десятым, но у меня сильные сомнения в нем — не знаю данных по нашей стране (а голословно не хотелось бы утверждать) и не видел на практике как эффективно строить подобные команды (не хотелось бы делать нереализуемые требования — типа пишите код без ошибок и проблем не будет).
Обычно самые дискуссионные пункты 2 и 3. Давайте их рассмотрим подробнее.
Опытные заказчики прекрасно представляют, что проекты обычно проваливаются. Но это не значит, что все из них готовы на Agile-подход. Так же весьма распространен подход, когда сама разработка в итоге убыточна для подрядчика, а прибыль делается за счет завышенной цены поддержки. Бывает, что заказчик вполне сознательно разоряет подрядчика, просто потому что тот неопытный новичок. Тут нет какого-то особого рецепта, но в большинстве внутренних проектов в итоге приходят либо к Agile-подходу, либо просто смотрят сквозь пальцы на постоянные провалы проектов («это жизнь», при этом без компенсационных пунктов из Agile). Для заказных проектов есть еще такой подход: глубокая специализация исполнителя, тогда в очередном проекте он не делает для себя ничего нового и может адекватно оценить проект.
Другой вопрос: почему только функционал, а не 3 других характеристики? Давайте рассмотрим:
-
Стоимость. Обычно есть некоторое бюджетирование и крайне неприятно его превышать. Например, чтобы в середине проекта увеличить команду в 2 раза — не так уж это и будет эффективно.
-
Время. Обычно время довольно сильно связано со стоимостью. И часто есть какие-то связи с другими подразделениями, которые ожидают продукт к какому-то числу. Поэтому достаточно редко получается двигать время.
-
Качество. Сложная материя. Можно разделить на 2 аспекта: качество для пользователя и качество для дальнейшей разработки. Если играем в долгую, то стараются задать необходимую планку качества и дальше ее придерживаться. Ухудшать качество, чтобы успеть с проектом, приводит к большим проблемам дальше.
-
Функционал. Функционал крайне гибкая вещь в ПО. Его можно довольно сильно дробить, выделять быстрые и важные вещи, выделять медленные и не такие уж важные вещи, приоритизировать все это дело. Можно даже добиваться высокоуровневых целей проекта без каких-то удобных и важных, но некритичных вещей. Другими словами: в этом пункте огромный потенциал, который мы и хотим использовать.
Еще не все понимают, что «что успели функционал» фактически может означать увеличение времени и стоимости, если заказчик заапрувит дополнительный бюджет. При этом мы в любом случае поставляем что-то, что уже может быть использовано, просто может быть еще не так эффективно как хотелось бы.
Что же про Скрам? Это одна из реализаций Agile-манифеста. Получила высокую популярность за краткость и понятность артефактов/мероприятий.
При этом крайне часто Скрам внедряется без Скрама. Как так получилось? Внедряется весь основной процесс, но без скрам-мастера. Да, это тоже может быть и даже будет соответствовать Agile. Просто это нужно называть как-то не Скрамом.
Скрам-мастер — это переговорщик без ИТ-знаний. Для внутренних команд он может быть среднего уровня (и получать заметно меньше менеджеров проектов, начальников отделов, тимлидов и тп — в этом и один из смыслов). Основная задача: наладить взаимодействие всех на проекте (и внутри команды, и внешние связи). Нет права принимать никаких решений (и тут так же полезно отсутствие ИТ-знаний). Скрам-мероприятия используются как одна из стартовых точек регулярного общения.
Почему обычно не внедряется Скрам? Даже во внутренних командах многие руководители требуют персональную ответственность кого-то за результат команды и не хотят особо смотреть на прогресс команды в промежуточных стадиях. Нужны отчеты руководству выше, а скрам-мастер их писать не умеет (если это нормальный скрам-мастер ака выпускник факультета психологии). Поэтому вместо скрам-мастеров берут достаточно дорогих руководителей проекта, которые в итоге не дают результат, но дают много бумаги почему то, что получилось — это успех.
Отдельная проблема Скрама — это Скрам-альянс и многочисленные коучи. Хотя, может именно из-за них Скрам и приобрел такую узнаваемость (даже при том, что мало кто его по настоящему внедряет).
ссылка на оригинал статьи https://habr.com/ru/articles/691800/
Добавить комментарий