В дебрях водопада

[vit_r]

SCRUM is great: you don't have to measure quality and the Product Owner is a scapegoat for all epic failures.

Написал в одном нехорошем месте. Перенесу сюда, чтоб было.

Программисты, воспевающие скрам напоминают проституток, агитирующих за свой образ жизни.

Первым делом, scram - это не agile. Это процесс, практически религиозный культ, а про процессы написано в первой строчке Agile Manifesto (той, что сразу после введения).

Scrum - это Эффективный Менеджмент™ во всей своей красе. Вместе с полным незнанием предмета, полным непониманием накопленного человечеством опыта, высосанными из пальца доказательствами и совершенно неправильным использованием слов.

Любая скрам-команда, если этот бардак не прекратить, достаточно быстро выходит на безотходный цикл. То есть, они производят баги и идиотизмы со скоростью большей, чем потребна для их исправления. (В это время менеджер начинает кричать, что народ зашивается и проект горит, если ему не купят ещё десяток-другой душ. Ему их дают. Потом дают ещё. А потом он идёт на повышение.)

Как же насчёт удивительных побед, выполненых по этой методологии?

Чудес я не исключаю, но в них не верю. Помнится, как-то в фирме с красивыми сертификатами ISO, CMMI и кучей всяких других выяснил, что то, что у них спецификацией называется, на самом деле куча мусора, который никто не использует, а вся информация идёт по мейлу. Но на бумаге всё красиво.

Также и со scrum-победами: Немного поскребёшь позолоту и выясняется, что внутри или совсем не scrum, или совсем не успех.

Ещё интересно, что при всей управляемости scrum-проекты невозможно планировать. То есть, пообещать релиз софтостроители смогут, но вот, что в него попадёт на самом деле, это уже никто предсказать не в состоянии. Не в смысле очередной итерации, а в глобоальном смысле приближения к безбаговому софту, выполняющему нужные клиенту функции.

В нормальной системе, даже та, которая agile (правда, не первого уровня, а третьего) всё вовремя просчитывается и вместо «Вот релиз - жрите» у клиента и менеджмента есть достаточно точная система, предсказывающая, когда что получится, и что нужно сделать, чтобы сделать быстрее или качественнее.

Если немного отойти от мест с вебом и Эффективным Менеджментом™, в таких условиях даже можно поработать.

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

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

Ещё проповедники scrum любят «доказывать» правильность своей религии сравнением со спортом, рассказывая о командах, заменимости игроков на поле, и приводя в примеры звёзд высшей лиги.

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

Впрочем, Эффективный Менеджмент™ в это не верит и дальше изыскивает способы заменить специалистов на толпы посудомоек или обезьянок.

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

Дело не в том, что работа совершенно не интеллектуальная. Гораздо интереснее для рассмотрения то, что результат всегда в конечном итоге бесполезен. Лежит мячик в воротах или не лежит, от этого банк не разорится и поезд с рельс не сойдёт. Вся беготня по полю даёт в результате только фиктивные очки в виртуальном мире. Короче, чистый выпендрёжь.

Программисты создают новую реальность. Что создают футболисты? Даже цифры на табло за них другие люди переставляют.

Но, даже, в этом случае scrum - это не командная работа. Потому я и упомянул дружный коллектив борделя. (Вот где работа чисто по скраму, маман за Product Owner, а вышибалы за Scrum Master, ну и так далее, только менее формально. Надо, впрочем, спросить у специалистов. )

Команда - это совсем другое.

Взять хотя-бы этот несчастный футбол. "Собрались - погоняли мяч" - это уровень дворовой компании. Всё, что чуть серьёзнее работает по другим принципам.

Во-первых, тренер, имеющий практически диктаторские полномочия, разрабатывающий СТРАТЕГИЮ, выясняющий слабые стороны противников, планирующий как это использовать и составляющий для футболистов план тренировок.

Во-вторых, футболистам платят не за то, чтобы они раз в квартал мячик попинали. Их работа - это каждодневные изматывающие тренировки. Они работают над собой, до автоматизма заучивая необходимые навыки. Выполняют программу, заданную тренером. Даже с питанием руководствуются чёткими рекомендациями.

И отрабатывают приёмы командной работы.

"Дал пас - передал дальше - ударил и забил" - это не подарок свыше, как учат нас проповедники сказочных методов. Это результат стратегической разработки тренера, доведение этой стратегии до каждого исполнителя, полное осознание своих задач и действий партнёров, плюс методическое заучивание всех элементов вплоть до системы сигналов, способных работать в стрессовых условиях реального матча.

В каком месте то, что называется scrum похоже на такую командную работу?

Comments

[raydac.livejournal.com]

ну если учесть что "фантазии за деньги", то проститутки, как и все наемники кто за бабло

[vit-r.livejournal.com]

Обычные наёмные работники продают результаты своего (творческого) труда, а не время использования своего тела.

[raydac.livejournal.com]

врядли проституток нанимают не для получения результата их творческого труда, творческих проституток вообще народ любит

[cross-join.livejournal.com]

Нехорошее место - это хабр? :)

[vit-r.livejournal.com]

Нет, просто местный форум. Причём, это был диалог, так что ещё видны места склеек.

Но идея с хабром интересная. Может быть, туда тоже закину.

[cross-join.livejournal.com]

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

[vit-r.livejournal.com]

Карма и подобные игры меня абсолютно не волнуют.

[cross-join.livejournal.com]

Начиная с некоторого уровня. И получается, что нужного уровня беседы на сайтах с кармой и минусованием найти проблематично. "Узок круг, далеки от народа"

[rdia.livejournal.com]

> Карма и подобные игры меня абсолютно не волнуют.

Там вроде бы движок такой, что это отражается на чём-то.

[vit-r.livejournal.com]

Это проблемы движка.

[joysana.livejournal.com]

интересный разбор, да.

[vit-r.livejournal.com]

Это как-бы всем давно известные истины, о которых просто никто не говорит.

[white-bars.livejournal.com]

У нас скрам и планирование разнесены, и все работает ничего себе так. Я работаю с клиентом и отвечаю за стратегию, у меня есть архитектор, я с ним работаю по технологиям. Во время спринтов мы собираем скелет и убеждается, что он правильно шевелитсяшевелится (не шевелится - убиваем). Дальше - обычная работа: люди сидят, пишут код. Все видят, кто и что делает, все друг другу помогают (не совсем pair programming, но что-то такого типа). На стэндапах у нас неплохая оперативная координация. Есть скрам оф скрамс - там у нас то же самое, но раз в неделю и на другом уровне. Процесс нацелен на качество продукта и уменьшение отходов. На выходе получаются востребованные системы (число клиентов растёт лавинообразно), качественный код (время, затрачиваемое на отработку запросов на исправление багов за год у нас снизилась раза в три) и удовлетворенные клиенты (уровень счастья измеряется).
По большому счёту скрам мне видится как попытка девелоперов выйти из подчинения ПМов, и это само по себе неплохо :) Но недостаточно: разработчики действительно не очень умеют планировать, определять стратегию и достигать успеха. Это все поправимо, но решение находится за пределами скрама.
Я соглашусь, что сам по себе скрам мало чего значит: "борделей" я тоже насмотрелся. Но я видел два случая, когда реализация была успешной. В обоих случаях создавалась система взаимоотношений и правил, частью которой был скрам. В одном случае скрам пришлось очень сильно покорежить, чтобы он работал для создания комплексной системы (девелоперы роптали, но результат был изумительным).
Соглашусь и с тем, что в скраме есть проблема карьерного роста (не профессионального, а типа "как выйти на качественно иной уровень, если для этого есть предпосылки"). Но тут должен начальник как-то свой хлеб отрабатывать, и давать людям возможность проявить себя.
В общем, все сложно, но не безнадёжно, я считаю :)

[vit-r.livejournal.com]

... не совсем pair programming, но что-то такого типа
... то же самое, но раз в неделю и на другом уровне
... решение находится за пределами скрама
... скрам пришлось очень сильно покорежить

Если у бабушки есть яйца, то это, скорее всего, дедушка.

Создатели этой религии не придумали ничего нового, просто взяли давно известные вещи и немного завернули в другую упаковку. Странно бы было бы, если бы "элементы скрама" не работали.

По большому счёту скрам мне видится как попытка девелоперов выйти из подчинения ПМов

В Agile Manifesto написано, что люди важнее процессов.

Я уже писал, что создатели Скрама сказали, что манифест замечательный, но люди не важны, а про процессы там ничего нет. Отсюда следует, что необходимо создать процесс.

Кому необходимо? Явно не программистам. Целевая аудитория религии процессов - менеджеры.

[rdia.livejournal.com]

Как вам статеечка - http://habrahabr.ru/post/229963/ ?

[rdia.livejournal.com]

Вообще, такое ощущение, что компиляторы усложняют язык Цэ. Скажем, ну что без оптимизаций может случится жуткого от считывания пост-последнего элемента статически выделенного массива? Да ничего - ну чушь считается, но программа не упадёт, т.к. стек велик есть. А тут фигак - и без объявления войны цикл вырезается к чертям.

[vit-r.livejournal.com]

В принципе, ограничения компиляторов люди должны знать. Всё-таки, работа идёт не с математическими абстракциями, а с железом, имеющим разрядность и прочие характеристики.

Там, где это важно, люди выставляют ключи компиляции и проверяют все сообщения об ошибках.

Другое дело, если один маленький баг убивает программу, то это плохая программа.

[rdia.livejournal.com]

> Там, где это важно, люди выставляют ключи компиляции и проверяют все сообщения об ошибках.

Так GCC зачастую ничего не расскажет про UB, а просто убьёт код.

Всё-таки, понятно, что "стандарт языка Цэ" не вполне описывает то, что компилятор может делать. Скажем, хотя по стандарту при возникновении UB программа может делать всё, что хочется, компилятор явно не должен вставлять туда вызов "rm -rf $HOME", да и вызов nethack'а недопустим.

Т.е. есть некоторые плохо формализуемые правила разработки компиляторов.

> Другое дело, если один маленький баг убивает программу, то это плохая программа.

Какая программа имеется ввиду? Компилятор или обрабатываемая?

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

[vit-r.livejournal.com]

Так GCC зачастую ничего не расскажет про UB, а просто убьёт код.


Есть сертифицированные версии GCC. Есть специальные компиляторы. Там, где надо, всё это стоит и никаких побочных эффектов нет. Оптимизацию обычно отключают.

Оптимизация - это уже игра с возможными неожиданностями.