Рецензия на заметку про SCRUM

Получил осуждающую рецензию на свою заметку про SCRUM.

Приводить сплошным текстом не буду.  Буду отвечать на каждый тезис поэтапно.

--> Проектную документацию заменяет носитель информации, сиречь Владелец продукта. 

Владелец продукта заменяет Владельца продукта и никого более. Главная (но далеко не единственная) его задача и предназначение — наладить тесный контакт с заказчиком и поддерживать его (контакт) на протяжении всего проекта.
Все первично добытые знания  Владелец продукта оформляет в виде бэклога (PBI по-аглицки), которые тщательно заносит в формализованные рабочие элементы проекта (PBI workitems). Каждый такой элемент может (и в идеале — должен) быть сопровожден помимо краткого описания детальной информацией (отдельное поле, вложенные файлы с описанием, скриншоты, схемы и пр.). Кроме того в процессе приближения к спринту каждый рабочий элемент прикрепляется к связанными рабочим элементам других типов. Например, с тестовыми случаями, планами тестирования, ошибками и с детальными задачами (на которые разбивается каждый PBI-элемент на старте спринта).
Т.е.  все необходимое вполне себе нормально фиксируется за пределами светлой головы Владельца продукта. 

--> Остальную документацию заменяют заставленные стаканами листочки, в которые местами заворачивали селедку. 

Как нетрудно догадаться, засаленные листочки — это была всего лишь фигура речи, для оживления повествования и придания колорита. Ты попался на ловкую провокацию, Паша!

Повторюсь, детальное описание рабочих элементов и пользовательских историй проектов никак не отрицается. Кроме того, подробно прописанные сценарии и планы тестирования — это не детский лепет, а вполне четкие инструкции. Далее, предполагается, что код пишется максимально  качественно и в соответствии со стандартами и лучшим практиками, Т.е. он (код) среди прочего качественно документируется/комментируется. Во благо будущих поколений.

--> Планы заменяют летучки.

Каждый новый спринт предваряется достаточно серьезным плановым мероприятием. На котором в обязательном порядке присутствуют все участники команды.
В результате определяется состав очередного спринта. Выбранные элементы бэклога продукта попадают в бэклог спринта. Расставляются четкие приоритеты, какие элементы и в какой последовательности будут реализованы. Сначала выполняется  верхнеуровневая оценка каждого выбранного PBI-элемента. Затем каждый элемент разбивается на детальные задачи (аналог классических и понятных нам задач в рамках наших проектов). Каждая задача подробно обсуждается, при необходимости делаются уточняющие запросы к бизнесу. В результате по всем задачам определяется максимально точный срок реализации.
Все эти телодвижения фиксируются в соответствующих рабочих элементах. Все задачи привязываются к родительским PBI-элементам.

Никакой «замены летучками» не предполагается. Все достаточно серьезно и профессионально. При этом каждый участник проекта в курсе, кто чем будет заниматься, для чего все это деалется и каковы общие цели предстоящего спринта.

Как по мне — это очень большой бонус подхода SCRUM. Вот этого понимания общей картины и осознания общей цели и видения проекта нам катастрофически и регулярно не хватает. И это вовсе не голое теоретизирование, а суровая реальность  всех наших проектов. И это то, что реально эти проекты тормозит и портит.

--> Вот выпущен такой продукт за минимальные сроки, безо всякого формализму.

Так точно, хотя что понимать по формализмом? Просто у скрума —  подход, позволяющий этот формализм максимально распараллелить и растянуть по дистанции. Без ущерба качеству.

-> Успешно эксплуатируется достаточное время. И вдруг выпускает ЦБ новое постановление. Продукт нужно модифицировать.
     Владелец продукта — ау, где ты? Ты еще не уволился? Помнишь то, что знал два года назад? Помнишь, но у тебя уже другой проект?
     И засаленные листочки использованы по назначению... :(

Как уже было сказано выше, все ходы четко и максимально тщательно фиксируются. Более того, все элементы между собой взаимосвязаны, как по струтктуре (в виде привязки родитель-дочь/сын) так и во времени. Что позволяет четко отслеживать текущее состоянии проекта, его темп и возможность выполнять анализировать в ретроспективе. Хоть через два, хоть через десять лет.

-->Как закономерный итог: проще собрать новую ура-команду и переписать продукт заново, чем его переделывать.

Можно новую, можно старую, можно смешанную. Никаких препятствий, как и при классической методологии. Если бабла не жалко — можно и заново переписать.
    
-->Фишка в этом, или я чего-то не понимаю?

Фишка в том, что долгие танцы с бубнами (особенно на старте проекта)  отменяются. Функционал начинает поставляться быстрее и чаще. При этом достигается максимальное вовлечение заказчика на всех этапах проекта. Как следствие обеспечивается постоянная обратная связь с будущими пользователями и возможность вовремя отследить, что проект движется не туда. 

-->Мы сейчас сопровождаем ряд продуктов, документации к которым нет и никогда не было (Счета фактур, Benefit, Внебаланс, итд).

Это печально, но методология скрум, как бы дерзко это не звучало с моей стороны, тут совершенно не при чем:)

-->Огромное количество времени уходит на реинжиниринг программного кода.

Если внимательно посмотреть Agile-манифест, то там предъявляются максимально жесткие требования к качеству кода. Стандартная методология даже как-то уходит в тень в этом плане.

-->Для нас, эти самые BRD и FSD — это шанс на нормальный процесс работы по специальности...

Дык про ценность BRD и FSD никто и не спорит. Особенно их ценность возрастает когда код пишется кривыми руками:) С надеждой на то, что пусть потом наследники разбираются по BRD и FSD.

--> Описанная технология заточена на быстрейший выпуск продукта, 

Да, это одна из неиллюзорных фишек методологии!

-->а на тех, кто будет этот продукт программно сопровождать, — ну, вы понимаете...
    Продукт развивается неформально, меняется ежечасно. Кто эти изменения будет фиксировать? Видимо, какой-то неупомянутый чемпион по запоминанию.  
      Может быть, селенит из «Первые люди на Луне» Уэллса.

Про фиксацию и документирование постарался подробно описать выше. Что касается «ежечасного изменения», то это из разряда мифов и предрассудков.

В SCRUM четко прописано: вся работа, запланированная в спринте, должна быть выполнена без изменений. Если посреди спринта к вам врывается с шашкой наголо заказчик и требует срочно все сделать по-другому, то он будет безальтернативно послан куда подальше. Нет, не туда, куда вы подумали, а Владельцу продукта. Владелец даст заказчику излить душу и качественно его утешит. Подробно запишет все новые хотелки и замечания и аккуратно все занесет ... в самый конец бэклога продукта.

Затем, когда эмоции схлынут, процентов 90 будет успешно выкинуто на свалку, и команда разработчиков об этом даже никогда не узнает. Оставшуюся часть Владелец продукта задокументирует, выставит приоритеты и включит в планы на один из следующих спринтов. А команда разработчиков спокойно закончит текущий спринт. Так что рассказы о непрерывных изменениях продукта — мимо кассы.Адаптивность не значит бардак.

--> А сопровождать продукт придется именно SCRUM'у, грубо говоря, вот нам.

Да, сопровождают (как и разрабатывают) всегда люди. Прискорбно это осознавать:)

-->  Нам, скрумным людям, на собственных скрумных шкурках приходится ощущать все прелести продуктов, неформально и (яуверен) в кратчайшие сроки разработанных
такими вот гибкими методами и неформальными командами.

На своей шкуре мы обычно ощущаем прелести чьих-то кривых рук. Как показывает мой личный опыт, даже самая лютая методология не обеспечивает качества кода, если у разработчика серьезные проблемы с головой, и если он предоставляется сам себе.

--> Реэюме:
      в наше время, это называлось не Agile. Вообще-то, это называется методом и психологией шабашников. :)
      Расхлебывать как всегда, будет SCRUM. :)

Лично я видел (не вру, честно-четно) офигительно классный, эффективный и удобочитаемый  код, написанный по методологиям XP и Agile. И совершенно невменяемый код, сбацанный под крылом классической методологии. Видел и обратное.
 
Повторюсь, методология Agile (как и XP кстати) предъявляет жесточайшие требования к качеству кода и процессу рефакторинга.

--> Просто потому, что данная технология — продукт мыслительной деятельности менеджеров.
     Менеджер — это самое главное и необходимое звено в наше время. Разработчики являются допустимым, но не обязательным компонентом.

Если внимательно ознакомиться с историей создания этой методологии, то выяснится, что она создавалась по инициативе «снизу». Именно как ответ на дебилизм менеджеров. 

P.S.

В заключение хочется вспомнить, с каким скрипом в свое время продвигались так называемые n-tier архитектуры. Сначала клиент-сервер, потом 2+n-звенки.

Сколько было высказано уничижительных замечаний и выпущено уничтожающих стрел. А вот, не прошло и десяти-двенадцати лет, а мы уже спокойно настраиваем апликейшен серверы, сервера СУБД, сервера управления очередями асинхронных сообщений и много чего еще. И нормально, не пыхтим.

Не нужно относиться к Agile, MSF, RUP  как к религиям. Принципы адаптивной разработки нормально живут рядом с MSF и RUP. А иногда — могут успешно сочетаться. Нужно смотреть на это рационально, а не в молитвенном экстазе.

    Предыдущие статьи из категории: Есть мнение

  • Боевые ахтунги в атаке
  • ...А далее следуют призывы. Комик Стивен Фрай, утончённый интеллектуал и любимец образованных москвичей, утончённо призывает премьер-министра Великобритании Кэмерона бойкотировать Олимпиаду-2014, […]

  • Рассуждения неравнодушного американца
  • Братья, простите за эту немножко хаосную статью. Иммиграция и демография — огромные темы, но я могу сказать, что, пока я […]

  • «Чудо узнавания»
  • «Главная их страсть – это похоть и веселость... Не нежность вкуса, но изобилие в пище и хмель напитков их прельщает. […]

  • О смысле жизни
  • Так вот сижу я на кухне, пью чай, читаю бумажную книгу. И понимаю, что это одно из лучших занятий, которое […]

  • Сделать знание силой
  • Ахтунг. Много непонятных буков. Девочкам с плеером не читать. Ключевая идея предлагаемой стратегии развития заключается в опережающем становлении базисных производств […]

Вы можете оставить комментарий, или Трекбэк с вашего сайта.

Оставить комментарий

Вы должны Войти, чтобы оставить комментарий.