SCRUM или шабаш ведьм

Весна, никто не застрахован от обострений психиатрической клиники, даже К.О. Далее будет о скраме, и что оно из себя представляет на практике.

UPD:: По непосредственной просьбе заинтересованых лиц все явки и пароли были изменены, хотя срок NDA уже протух. Но все же.

В далеком 10-м году, в городе-герое Киеве работал я в небольшой софтоконторке под гордым названием [censored]. Эта конторка, в свою очередь, контрактила мелкий провинциальный инвестбанк [censored] из швейцарской деревушки Цюрих. И вот в какой-то момент времени кому-то из “там” пришла мысль - а давайте весело проебем бабла возьмем конь суль тантов помоднее (например Craig Larman) и замутим тут Эджайл Команды!

Сказано-сделано. На самое начало процесса я не сильно успел, но “как там все” застал. Здесь нужно немного про [censored]. Особенность этого заведения в том, что оно действительно ниибаццо большое. [censored]

Айти в нем тоже состоит из сильно дохера народу, реально тысячи программистов по всему миру, начиная от Нуёрка и заканчивая Бангалором (через всякие там Лондоны, Цюрихи и прочие рыбные места).

Наличие в перечне Бангалора уже определяет качество продукта, который там, унутре, ну где неонка. И, воодушевленные лозунгами навроде “Товарищи! Любая кухарка может управлять государством!” - ребята решили, что мол щас будет СКРАМ и все резко-резко станет заебись.

Теперь, собссно, что же такоэ СКРАМ. Первое, что я увидел - это скрамдоска, на которую принято дрочить на бёрндаун вешать стикеры. Классическая скрамдоска состоит из секций типа

  • запланировано
  • в работе
  • сделано иногда, по вкусу, добавляют “протестировано” - но это на любителя (мы же эджайл, помните? эта мантра везде).

На соседней доске обычно рисуют диаграммку, которая зовется “burndown”, и она как бы показывает команде, как бездарно круто мы проебываем перформим в этот спринт.

Спринт, есличо - это такая себе итерация (масло масляное, да), когда за N дней нужно сделать чего-то там. Чего-то там - это, обычно, одна или несколько суровых галлюцинаций задач, котрые придумал так называемый product-owner (в просторечии - чувак, который не смог отмазаться от этой должности, и которому вообще обычно похуй на это все - у него есть своей работы) для того чтобы Все Пошли В Светлое Будущее Строем.

Все эти задачи висят в так называемом бэклоге, который суть список этих самых задач, они же user-stories, отсортированные по приоритетам. Которые приоритеты могут меняться хоть каждый день - мы же эджайл, помните?

Самое главное! Эти задачи оценены в story point! Если спросить у адепта скрама - что ж такое сторипойнты - он скорее всего задвинет умные слова про то, как задачи могут быть разными, но мы не знаем насколько они разные потому что мы их никогда не делали, и чтобы оценить то что мы не знаем - мы вводим интуитивные метрики, когда одна задача считается в два раза сложнее другой, и потом они так опа - и сортируются. Сторипойнты берутся из чисел фибоначчи (ну там 1-2-3-5-8-13-21…), где за 1 принимается “да ваще ничего”. Если человеческим языком - то пальцем в небо. Дальше будет еще веселее.

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

Чувствуете величие мысли? Оценим неизвестный объем работ в относительных попугаях, оценим как команда сможет сделать этот неизвестный объем работ в этих же попугаях - и таким образом предположим, что команда может взять например историю A и B.

Будет ли это работать? Сразу нет. Но! Мы же эджайл! Плюс, это банк - а в банках бабло не считают. (на самом деле, считают, купить лицензию на ту же IntelliJ IDEA или например JRebel - целое дело, и нам их так и не купили. Вот такой парадокс.). Поэтому ребята-консультанты подсуетились и сказали - это все временно и оно самонастроится!

Соответственно, новая команда гарантированно проебет заандерперформит спринтов 5-10 - и это считается ок. С учетом времени спринта в 2 недели - от 1 до 3 месяцев команда не будет успевать сделать то, что заявлено на спринт.

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

Теперь про burndown. Нужно понимать, что классический SCRUM с часами дела не имеет. Потому что какие там нафиг часы, в условиях оценки задач в попугаях? С другой стороны, софтостроительный консалтинг биллит заказчика именно что за часы. Теперь следите за руками.

На спринт, например, взяли сделать что-то A и B. Это все в сумме дает например 5+8 = 13 поинтов на спринт. Далее истории A и B в начале спринта распиливаются на задачи (ну там сделать класс такой-то, с таким-то интерфейсом, узнать как там все интегрируется, допилить в базу что-то). Эти задачи распиливаются коллективно. И затем им коллективно же дается оценка, но уже … в часах работы. Причем если один человек говорит 2 часа, а другой - 8 - то выясняется, почему так - может тот, кто говорит 2 - знает что-то, чего не знают другие. Ну или чувак с 8 часами видит какие-то подводные грабли. Путем долгих обсуждений и мордобоя все приходят к какой-то единой оценке. Причем есть негласное правило - задачи больше 6 часов быть не могут, их надо распиливать дальше.

Ну собссно после того как все задачи распланированы и собраны в кучку - рисуется burndown, на котором есть две линии - одна - это теоретический перформанс команды (N человек умножить на M часов продуктивности в день, где M <=8). А вторая - это линия фактически того, что взяли в этот спринт.

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

В идеале все должно сходится в 0.

Далее, В скраме есть еще такое понятие как стендап-камеди, когда утром все собираются и читают молитвы Шваберу рассказывают, чего было вчера и что планируется сделать сегодня, какие тяготы и лишения были преодолены, а какие - созданы, и затем преодолены. Это обычно отнимает от 15 минут до получаса времени.

Дальше идет один или несколько митингов с продактоунером. Ну чтобы уточнить, что пока мы тут планировали военные действия - они там у себя не поменяли ландшафт местности вручную. Это около 1-2 часов в среднем.

В скраме так же декларируется отсутствие менеджмента, типа “team decides”, что в теории означает что команда может вообще отменить спринт, если на каком-то митинге случился полный когнитивный диссонанс.

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

Что из всего вышеизлитого можно почерпнуть для себя?

Вывод 1. Команда, которая состоит из грамотных профессионалов, которые знают предметную область - в скраме не нуждается.

Вывод 2. В скраме можно фасилитировать различные процессы, как-то - назначать митинги, проводить обсуждения, коммуницировать с заказчиком и пить кофе в курилке. Причем если в команде таких товарищей больше одного - то ничего уже сделать будет нельзя. Одного товарища команда может выгнать из себя к хуям, двух - уже нет.

Вывод 3. Для консалтерской работы скрам пригоден только тогда, когда заказчику задурили моск коучеры и он согласный оплачивать вот все эти митинги и прочий карго-культ. Для боевой разработки скрам скорее вреден, чем полезен.

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


UPD

В комментариях обратили внимание на отсутствие описания процесса получения задач из беклога. В идеальном мире в беклоге содержится ровно то, что нужно для решения задачи. В реальном же мире беклог представляет из себя задачи навроде:

  • добавить в список counterparty идентификаторы стоков маркета в APAC. 13 pts.
  • изменить формат сообщения от маркета, добавить поле NeedReconciliation, обновить правила в Drools. 8 Pts.

Соответственно, любая из этих задач не содержит в себе никакой информации для программистов. Вообще. Более того, часто даже product owner не знает, что это такое. Но поскольку команда уже в прошлом спринте запилила поинтов на 20 штук - то можно взять обе эти задачи. Потому что team capacity позволяет.

После планирования команда судорожно начнет выяснять - а что такое этот самый список и где его брать. А какие бывают стоки. А что с ними можно делать. При этом про список стоков знает Ellie, но она в Нуёрке и еще спит. А про список знает Ramjesh, но он в Бангалоре и уже ушел поклоняться Кришне. А потом, когда завтра вы выцепите Ellie, окажется что она вовсе и не знает нихера, это вас продактоунер дезинформировал. А кто знает - она не знает, но может быть Мария. Которая в отпуске до следующей недели. И Рамжеш - это вовсе не тот Рамжеш, а тот который знает - умер уволился в 2005-м году. Полнейший коллапс и отсутствие нужной информации.

У нас как-то была ситуация, когда аццкий говнокод на жабе был написан в 2004 году, на него не было тестов, никто не знал и не понимал как он работает - потому как описания протоколов общения с внутренними системами уже давно не было. И эта задача шла на 5 поинтов.

Поэтому в 8 случаях из 10 все те задачи, которые были взяты в спринт - это вообще не те задачи. Совы не те, чем кажутся (Ц) Twin Peaks. И неделя времени всей команды теряется на то, чтобы выяснить - а что же собственно надо сделать, и как.

В лучшем случае окажется достаточным поменять две буквы в CSV файле, который менялся 7 лет назад последний раз. И то когда его впервые засунули в SVN. В худшем - будет как с моей задачей на 2 поинта, которую мне выдали на второй неделе. Я её нашел на доске в work in progress, когда как-то зашел в гости в [censored] через три года после того, как я оттудова уволился.