Pull to refresh

Comments 73

Программист, который может держать код в голове и отличается скорострельностью — отличный профессионал.

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

Говорю без шуток, ибо стоимость сопровождения определяется тем, сколько код сопровождать. Бывает код, который вообще не сопровождается (написан, работает и ладно). В этих условиях мы имеем минимальную стоимость разработки при максимальной скорости.

Разумеется, это не очень хороший подход для постоянно развиваемого кода, но есть масса областей, где надо «написать и забыть». И там такой подход даст большую эффективность, чем любые системы управления хаосом.
Я очень очень надеюсь на отрицательный ответ — подход «написать и забыть» надеюсь не практикуется в Селектеле? :)
В том числе практикуется. Например, на позапрошлом спринте была задача — написать прототип утилиты для манипуляции объектом, который бы проверял правильность реализации всех остальных компонент.

Я на момент планирования на 100% знал, что этот код не будет обслуживаться. Его задача — увидеть, как оно всё работает, найти неочевидные баги в соглашениях между компонентами и т.д.

Нафига мне там мега-девелопмент, когда его надо просто пойти и накодить?

Более того, я вот только что аналогичным образом накодил себе шелловый «однострочник» примерно в 4 кб размером, который делает головоломную выборку из нескольких баз, обрабатывает их и выдаёт на выходе умные циферки, над которыми я буду думать.

Аналогично — код есть, сопровождения нет.

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

Заметим, это никаким образом не относится к тому коду, который мы сопровождаем. Там у нас во-первых двухуровневое code review, во вторых каждый epic имеет подробную документацию с мотивационной частью, шагами реализации и описанием вносимых изменений, причём написанный до того, как расписаны все issue.

Но нужно понимать, что если в центральный сервер биллинга мы готовы инвестировать scrum, code review, рефакторинг технического долга и т.д., то это вовсе не значит, что подобный подход должен применяться всюду.
Мы практикуем решение таких задач в отдельных бранчах с указанием, что этот код был «просто написан», чтобы потом к нему не было доверия на том же уровне как к остальному коду. Тогда для разовых задач или прототипов это вполне приемлемый подход. Не так давно обсуждали это в другой ветке.
Вам не кажется, что
который может держать код в голове
и
написать и забыть
немного противоречивые вещи?
Нет. Человек держит в голове предметную область и помнит, как он это написал. Если, вдруг, в «накоженное» нужно будет чуток внести изменения, то это будет легче сделать через того, кто накодил.
>>такой подход даст большую эффективность
Совершенно верно, именно по эффективности и стоит выбирать методику.

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

Короче, нет серебрянной пули, надо выбирать по обстоятельствам. Иногда говнокодинг — это то, что нужно, но не так часто, как это пытаются преподнести
Вы много видели апологетов говнокодинга? Большинство либо молчит, либо говорит «ура» юнит-тестам и прочим играм. При этом многие из тех, кто согласен, продолжают говнокодить.
Видел много, да.
При этом отдаю себе отчёт, что «другого народа у меня для вас нет» — в смысле, предпочитаю максимально полезно использовать то, что у меня есть. Как и вы, думаю
Апологетов или тихих сторонников? Апологетов (которые бы это в виде стратегии разработки объявляли вслух) я не видел.

А вот ползуче-неосозанное — это да, часто.
Увы, да, это очень часто. Code review спасает, хотя есть и свои трудности.

Про ползуче-неосознанно есть ещё момент в том, что на масштабах команды 20 и больше начинаешь воспринимать разработчиков как абстрактно-средних… Даже если в команде есть один-другой с перегибами в обе стороны, это сильно дела не меняет (хотя и улучшает). Начинается управление разработкой по закону больших чисел. А абстрактный разработчик пишет далеко не самый лучший код
Лучше стабильно средний, чем эпизодически хороший. Честно, что будет в команде из 20 человек — не знаю, это очень много. Тут явно нужны доп. уровни структурирования, ибо если каждый человек за неделю делает 10 issue с средним размером 2 sp, то это 400 issue в неделю, столько один человек написать и организовать не сможет.
Я не видел ни одной задачи в стиле «нам нужно гавнокод». Ну разве что — если Вы хотите создать тестовое задание для программиста (как выяснилось в ходе обсуждения одной из статьи на хабре — и это спорно). Так может быть всё же гавнокод — НИКОГДА не нужен? Может быть хватит оправдывать себя «я пишу быстро — значит плохо»? Посмотрите на спортсменов — быстрые движения — не значит плохие.
Не могу понять, где я написал про оправдывать.

А я не видел ни одной задачи «надо написать JIT-компилятор» или «надо сделать рефакторинг». Заказчику не нужна дрель, ему нужны дырки. При этом как вы их сделаете — его не сильно волнует. Если дырок надо немного, и на этом ваше сотрудничество прекращается — то можно и коловоротом накрутить.
>>Иногда говнокодинг — это то, что нужно
Не ваши ли это слова?

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

Когда Вы даёте себе индульгенцию на гавнокод (это быстрый фикс к релизу, это просто прототип, надо сделать быстро чтоб показать заказчику, потом переделаю) — Вы понижаете свой стиль. Знаете, в единоборствах одно из главных правил — выполнять техники правильно. Можно медленно. Но правильно. Потому что привыкнув делать неправильно (обычно это случается, когда пытаешься делать быстро) — потом очень тяжело переучиться. И результаты получаются плачевными.

И последнее — в каждом большом проекте, где я работал, я нахожу огромное колличество меток ToDo — значит кто-то понимал, что код плох, но всё равно его оставил…
Золотые слова.

Вы тут везде упоминаете «хороший код», вкладывая некоторое понимание. Я же в своих комментариях говорю, что код должен быть «достаточно хорошим», а не просто «хорошим». Потому что под «хорошим» разные люди понимают разное, и тут главное — не перегибать в обе стороны.
Да вы это и так понимаете
>> все паттерны, архитектурные изыски, стандарты кодинга и так далее придуманны с одной единственной целью — писать код более быстро

Знаете, я не раз и не два встречался с ситуацией на проекте, где они _не_ помогали писать быстрее. Зачем их использовали — дань традициям, сила авторитета, чтобы было, архитектурная мастурбация, перфекционизм — это другой вопрос.

Если вам юнит-тесты не помогают повысить эффективность в оговоренном периоде — не надо их использовать.

Я только два тула знаю, которые следует использовать всегда, независимо от периода и эффективности — код-ревью и continuos integration+грамотный сорс-контрол.

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

И я надеюсь, никто эти слова не воспримет как указание отказаться от своих полезных практик :)
>>Решения на будущее — архитектурные решения, которые принимаются на проекте, должны быть как можно больше адаптированы к изменениям. Нужно полностью планировать, какой компонент каким функционалом может обладать в будущем. Например, если это календарь (см. выше), то нужно расширить ядро таким образом, чтобы «в один клик» изменить формат вывода с 10-тичной на любую другую систему счисления, а также сменить грегорианский календарь на календарь в произвольной форме, описывающийся структурой в XML-файле, для которого также следует написать специальный парсер, который также следует адаптировать к генерации произвольных форматов XML не только для календарей, но и рецептов, вдруг у вас на сайте появятся рецепты?..

Я думаю отсюда все проблемы растут. Очень часто, начинают делать проект и:
— А что мы будем делать когда у нас будет 1М пользователей в день?! (пока ент ни одного)
— А если мы переползём на Oracle?
— Систему лучше изначально делать распределённой! (ни одного пользователя по прежнему нет)
— Нам надо так, что сегодня у нас одна концепция построяния каталога — а завтра мы ррраз, и поменяли всё (ни товаров, ни пользователей, ни поставщиков и в помине ещё нет)
CI без фунционального тестирования — бомба замедленного действия. И когда-нибудь она взорвётся.
У нас функциональное тестирование каждой собранной версии + выделенное на тестовом контуре совместно с людьми от заказчика
Я не могу оправдывать «себя», потому что я не программист. (И да, я знаю, что я пишу очень плохо, потому я предпочитаю писать очень мало и не лезу в крупные проекты). Я работаю lead'ом (он же менеджер проекта, он же product owner). То есть я о программистах рассуждаю по стороны, имея возможность отключиться от личного «я крутой программист» или «тут всё надо переписать во имя великой справедливости».

Так вот, я точно знаю, что у меня есть моменты, когда мне нужен говнокод. Который just do it. В конкретных условиях с конкретным уровнем сложности входных данных и т.д. И если вместо говнокода мне выдают DSL с красивой моделью, юнит-тестами и т.д. — я ругаюсь, ибо время потратили зря.

А бывает наоборот. И тогда я ругаюсь на говнокод. Точнее, на сам код я практически не смотрю, это разруливается code review, а я поддерживаю недовольных некрасивостью написанного.
Скажите, если Вы не программист — то как Вы можете судить, что DSL с красивой моделью, юнит-тестами и т.д. — лишние?

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

У руководителей есть одна плохая болезнь — они считают, что большинство архитектурных изысков — это причуды программистов. «Не парь мозги, просто СДЕЛАЙ чтоб работало». Поэтому, если Вы не разбераетесь в программировании — поставте одного из хороших разработчиков тех. лидом, и позвольте ему решать, какой код хорош в данном случае, а какой — нет. Программисты ОЧЕНЬ не любят слушать упрёки от людей, которые не разбераются в программировании.
Все-таки «разбираетесь» и «разбираются»…
>> ни считают, что большинство архитектурных изысков — это причуды программистов.

Добавлю свои 5 копеек. Вы тут почему-то полагаете, что программисты работают в своё удовольствие. Нет, это не так. Не в своё удовольствие, и не для таких же гиков-программистов, как они, а для свободных людей.
Программисты не высшая каста. Программы не самоценны, не надо делать программу, если ей никто не пользуется. Программисты это обслуга — такие же, как официант, дворник, или там сапожник.

И как у любой обслуги, у них есть мера эффективности.

А вот как им их работу делать внутри — это их собственное дело. Я не говорю, как дворнику держать лопату; но если один держит её так, что двор убирается в 10 раз медленнее, чем мог бы, а объясняет это тем, что так написано в книге «Паттерны уборки двора», а второй уже который день договаривается о выделении трактора, чтобы почистить сразу всё много, это негодные дворники
Не стоит привносить мерки индустриальной эпохи в постиндустриальную.

Программисты — не низшая каста, и не обслуга. Так же как не являются «обслугой» режисёры и актёры в фильмах, так же как не являются «обслугой» врачи.

Степень влияния человека на внутреннее качество кода не стоит недооценивать. peer review — лучшая сила в медицине, науке и программировании. При этом решаются бизнес-задачи, но превращение программиста в кодера режима офисного планктона лишает компанию второго из ресурсов, которые предоставляет программист за свою зарплату.

Ресурсов два: время и энтузиазм.

И scrum решает проблему времени. А вот вопрос энтузиазма решает атмосфера проекта и возможность самовыражения.

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

А вот как раз «нефиг парится с архитектурой, сгамнякайте хоть чтонибудь» — приводит к очень плачевным результатам. К текучке например. Почитайте Демарко PeopleWare — он об этом гараздо лучше меня пишет.
Не, я тут не при чём. Вы мне зачем-то чужие слова приписываете. Моя позиция — не такая, как вы описали «нефиг париться с архитектурой», а вы зачем-то с голосами в голове спорите. Или я не знаю, с кем.

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

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

К сожалению, «хорошие» программисты (в общечеловеческом понимании этого слова) часто ставят перед собой чучело идеальной архитектуры и молятся на него; что там надо бизнесу, их волнует редко. И очень часто всё приходит в состояние «всё было красиво спроектировано, но вот бизнес туда не очень ложится». Вовремя понять, что иногда и говнокоду есть место, ибо это объективное отражение того беспорядка, что творится в бизнесе — это очень важно.

Если программист это не хочет принять, то выше mid developer его ставить не стоит, увы. Если ему не нравится хаос бизнеса — пусть начинает переделывать бизнес-процессы; потому что недельные рефакторинги не окупаются совершенно.
А я и не лезу в красоту кода, я оперирую с другими понятиями. Никакие бюрократические стандарты не заменят peer review, именно на него мы и полагаемся при оценке качества кода (с точки зрения программиста). С моей же точки зрения (как Product Owner) меня интересует во-первых возможность продолжать развитие без постоянного нудёжа «всё переписывать надо», а во-вторых сроки реализации payload (то есть полезной части проекта).

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

Я не могу сказать, что я «не разбираюсь в программировании» (хотя да, всякие игры в семигрупоиды и template haskell — это выше моего уровня компетенции). Я вполне свободно пишу на Си, питоне и т.д., не говоря уже про прикладные шелловые скрипты, так что первое приближение обсуждаемой идее я дать могу. А тонкости (вроде того, какую библиотеку в Хаскеле использовать для работы с postgres, и как именно декларируются типы в datamodel) — это уже к программистам. Впрочем, в дискуссии нужно ли тип делать Maybe я обычно всё-таки участвую, т.к. источники данных в БД — это моя вотчина.

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

Надо понимать, что у программистов есть определённые деформации сознания — для них код и есть программа, а главным её достоинством является удобство её дописывания. С точки зрения же бизнеса главным достоинством программы является мнение о ней клиентов и генерируемая revenue. Я нахожусь по середине, то есть могу и программистов «обломать» с чрезмерным увлечением метапрограммированием и ткнуть в необходимость вести легаси, и на совещании возражать против изменений, которые «вот тут побыстрому доделать».

Причём второе — это особое искусство, т.к. говорить нужно на языке, термины которого описывают бизнес. То есть никого не интересует чистота кода или архитектурное совершенство. А вот цена сопровождения и предсказуемые сроки реализации годового плана — вполне волнуют и понятны.
А, да, знал такого. Правда максимальное кол-во посетителей на сайте — было 1 (потом сайт умирал), смотреть на несовсем новых компьютерах карту было нереально, а при фиксе одной фичи — отпадала другая. А специалист — классный, да. И работал быстро.
Отличное наблюдение! В некоторых банках этот замечательный подход работает на ура. С ужасом вспоминаю клиент-банк, реализованный на почтовых ящиках, систему бюджетирования максимум на 75 клиентов и папку на 300 батничков с именами asasas.bat. Всё работает, к программистам приходишь — сидят смотрят фильмы, а ближайшие две недели выделены на таск «рефакторинг кода». И все при деле.
Ну а когда код перестанет умещаться в голове, как, по-вашему, он будет работать? Могу сразу сказать — плохо, плюс начнутся потуги переписать все начисто, потому что старый код перестал быть прозрачным, а тестов нет. Знаю, в том числе, и по себе.
Если код «перестаёт укладывается в голову» и его хочется сопровождать — то это не тот случай, про который я говорю. Ценность кода надо уметь измерять.
А тот случай, про который вы говорите — это не разработка, это просто кодирование, не надо приплетать тут технологии для разработки ПО, которые ориентированы на полный цикл кодирование-тестирование-поддержка, плюс работу в команде.
Если разработчик стреляет из пушки по воробьям, это явно ошибка. И не факт что его. Многие заказчики говорят, что это лишь на один раз, а в итоге «одноразовый» код потом годами пьет кровь тех, кто его поддерживает.
Я про это и говорю. Но дело в том, что деление «сопровождаемый проект»/«одноразовый код» не бинарное. Классификация больше/меньше — удел PO. И его же обязанность решить, что делать с одноразовым кодом, который начал перерастать в крупный проект.
Ну, раз «это его обязанность», значит это и его дело — как организовать процесс, на день или на неделю ;)
Да, я про это и говорю. PO должен контролировать степень формальности в работе над проектом. Чем важнее проект, тем больше ресурсов должно быть потрачено на то, чтобы проект не оказался в состоянии «легаси, всё переписывать надо».
Да и не мелкие, собственно, тоже.
В целом, достаточно разумный подход :)

Можно легко все перевернуть с ног на голову и написать «Programming for Programming Sake Driven Development» (или PPSDD).

Планирование — планирование задач должно быть как можно более долгим. Каждую деталь нужно решить и документировать заранее, все UML-диаграммы должны быть сертифицированы по ISO и подписаны Ведущим Разработчиком, Зам. Ведущего Разработчика и Ведущим Инженером по Подписыванию Диаграмм. Созвоны и чаты запрещены, все изменения документируются исключительно через тикеты в Системе Контроля Изменения Спецификаций (СКИС).

Рефакторинг — самая главная задача заключается в понятности кода, а не в решении бизнес-задач! Поэтому как только решение начинает работать, разработчик должен ставить специальную задачу по рефакторингу и тут же приниматься за нее. Каждый рефакторинг также можно пропустить через дополнительный рефакторинг рефакторинга, и желательны code review как кода после первого рефакторинга, так и после 2 и 3. Закрывать задачу по рефакторингу можно только после того, как все члены команды сдадут экзамен на понимание каждой строчки кода. Конечно, до выкладки этого в production.

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

Решения на будущее — архитектурные решения, которые принимаются на проекте, должны быть как можно больше адаптированы к изменениям. Нужно полностью планировать, какой компонент каким функционалом может обладать в будущем. Например, если это календарь (см. выше), то нужно расширить ядро таким образом, чтобы «в один клик» изменить формат вывода с 10-тичной на любую другую систему счисления, а также сменить грегорианский календарь на календарь в произвольной форме, описывающийся структурой в XML-файле, для которого также следует написать специальный парсер, который также следует адаптировать к генерации произвольных форматов XML не только для календарей, но и рецептов, вдруг у вас на сайте появятся рецепты?..

Полное тестирование кода — каждый разработчик знает, что тестировать код намного важнее, чем все остальное. В рамках «решений на будущее» также следует предусмотреть максимум возможных use case и написать для них соответствующие тесты. Так как тесты подвержены эволюции, то их сами тоже нужно тестировать. Также необходимо тестировать саму систему запуска тестов, и систему отображения результатов тестов. Желательно также тестировать каждого разработчика с утра перед выходом на работу.

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

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

Отсутствие спешки — код вечен, а бизнес скоротечен. Не давайте коллегам увлечь вас вихрем рынка, ведь ваш код все это переживет, он будет полностью покрыт тестами и готов к переходу в 23-й век, а бизнес уже давно закроется или переориентируется. Код — это главное. Бизнес ничто.
Красиво получилось! Да, антипрактики есть по обе стороны баррикад.
И как же быть теперь. :) Мне, к примеру, за почти 15 лет практики разного программирования, *чаще всего* приходится встречаться с мусорным кодом. Не в смысле, что он плохой, а в смысле, что его нужно выбрасывать. В него вложили деньги, силы, труд, но он просто больше не нужен. Есть вещи «на века», но их намного меньше, особенно в веб-разработке. Конечно, если у вас софтовая компания, или вы делаете какие-то generic вещи, как Oracle или Microsoft, то вы можете вкладываться в качество кода. В вебе, особенно в продажах, общий успех зачастую зависит от качества системы в целом — проектирования бизнес-процессов, маркетинга, бэк-офиса, HR и др. И в мире наблюдается четкая тенденция к перевешиванию этой сугубо материальной и бизнес-составляющей в т.ч. и в софтовых продуктах.
Забыли добавить вывод, описывающий, в чем же профит для программиста:
«Выбирайте только те системы, фреймворки и библиотеки, которые также разрабатываются по принципам PPSDD — например, Android, Yii и Drupal. Подобные системы также постоянно рефакторятся без оглядки на совместимость с предыдущими версиями. А так как вы делегировали им всю реальную работу, при выходе очередного еженедельного обновления никто кроме вас не сможет запустить вашу программу. Это железобетонная гарантия, что вас не уволят».
Отлично! Я именно так и стараюсь работать. Кому он нужен, этот бизнес :)
Это вы еще забыли про Систему Централизованного Управления Клиентскими Обращениями :-)
Хочу поделиться своим грустным опытом в Agile.

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

Прошел год такой разработки. Все дедлайны были провалены, часть людей ушла из проекта, часть добавилась. Я стал тимлидом. Один из менеджеров решил, что для повышения эффективности команды ей стоит работать, придерживаясь Scrum`а. Он был введен. И вот, после 10 спринтов, вся команда начала понимать, что велкикий и могучий Скрам не помогает нам работать. Потому что нет костяка(читай ТЗ), который можно было бы гибко менять в заисимости от отклика юзеров. Овнер(он же менеджер, предложивший Скрам) продолжает требовать от команды новых костылей и не хочет обращать внимания на глобальные проблемы модели приложения, команда продолжает пилить гири костыли. Каждый день я жду новых падений модели-инвалида и пытаюсь убедить Овнера, что нужно приостановиться и обновить модель.

Мораль сей басни такова: гибкая разработка — это круто, но каждому необходимо понимать, когда ней можно начинать пользоваться, а когда еще рано.
«Скрам говно, потому что архитектура приложения плохая»?
Я не говорю, что скрам говно. Я говорю, что нужно вовремя ним пользоваться, иначе этот инструмент больше вредит, чем помогает. В данный момент я знаю, что арзитектура говно, знаю почему, есть предложения по исправлению, но в ответ меня настоятельно просят ближайший спринт посвятить багфиксингу, а рефакторинг будет позже. Вот только это позже не обозримо.
Ну, спринт-второй багфиксинга — хорошая возможность отрефакторить хотя бы ключевые участки кода, а ПМ даже ничего и не узнает.
Багфиксинг касается интерфейса в основном. А для основных участков кода требуетсяс недели 2-3 рефакаторинга, при чем проект загажен настолько, что сделать эти правки паралельно с текущим работающим кодом просто нереально. Все завалится к черту. Код сильносвязан и малейшие колебания в одном месте наочно демонстрируют теорию хаоса.
Учитесь делать латентные эпики. Это такие epic'и, которые выполняются по 1-2 issue (на 1-2 story point) в неделю.

У меня, например, есть вяло ползущий эпик, который тянется уже больше года. Выполнен на 60%. При этом мне бы никто такое количество программисто-недель в эксклюзив не дал бы. А вот мягко и неторопливо делать сложные изменения — самое то.

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

Худший вид рефакторинга — это когда «новая крутая модель» просто не совместима со старой и требует внимания к себе, а не к совместимости. Условно говоря, сломали, пишут, будет офигенно, а вот всякие мелкие вещи, которые и есть бизнес-логика, оставляются на потом, да ещё часть и выкидывают, ибо «не совместимо с новой моделью».

Отсюда мораль — должен быть человек, который ведёт проект. Не в смысле сакральных знаний, а в смысле «чувства правильного».
Вот тут как раз и вся беда.

Три менеджера, у каждого из которых бывают свои взгляды на то, как должно быть.

По поводу «новой крутой модели» хохма в том, что она как раз нужна для реализации бизнес логики, которую на текущей модели реализовать просто нереально, она не заложена в модель. Вот так и живем. Мобильное приложение, которое занимает в данный момент 240 Мб в памяти, выполнять можето только 2/3 из бизнес задач, но рюшики важнее.
Проблемы организационной сферы. Надо найти язык, на котором объяснить проблему. Обычный язык в таком случае — перевод на деньги.

Время сотрудников = деньги. Повышение эффективности = снижение затрат.

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

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

Иными словами, нужно не просто просить ресурсы на переписывание, но и возвращать инвестиции.
Agile не спасет проект, в котором не было требований ни в каком более-менее адекватном виде. Так же как и проект-калеку на костылях. Это миф, который многие (а именно адепты Scrum, но далеко не все) пытаются успешно продавать.

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

1) Скрам и дедлайн несовместимы. В скраме фича готова, когда команда говорит, что фича готова. Для этого команда работает столько сколько нужно. Если это не так, то у вас не скрам, а бардак.

2) Планирование фичи должно заключаться в проработке User Story. Для Story должны быть как минимум определены сценарии и критерии приемки. Набор сторей и будет ваше ТЗ. Если такого нет, то это не скрам, а бардак.

3) В скраме нужно планировать релизы. Одна итерация перед релизом обычно уделяется на «вылизывание» продукта: устранение дефектов с прошлого релиза, устранение некритичных багов (фичи с критичными багами просто не включаются в релиз) итд. Если такого нет, то это не скрам, а бардак.

4) Если в скраме не удается уложиться в план (итерации, релиза), то всегда жертвуются фичи. Если к релизу недостаточно фич, то надо просто признать фейл, перенести релиз, пересчитать velocity, учесть при планировании следующего релиза и продолжать работать в том же темпе. Никакого форсирования работ не допускается. Если такого нет… ну вы поняли.

Основной фокус скрама — ритмичные релизы, более стабильное получение фидбека и включение его в разработку, создание продукта, максимально удовлетворяющего клиента. Это достигается фактически снижением темпа выпуска фич и закрытия багов.

Если смотреть на треугольник полезность-качество-скорость, то скрам торгует скорость на полезность.
Что за паранойя?

1. Дедлайны всегда есть, просто в скраме под них подгоняется скоуп (сколько успеем сделать к дате дедлайна). Есть альтернативный подход с датами дедлайна в зависимости от времени на фиксированный скоуп. Но без дедлайнов разработка практически возможна только в теории. «Команда работает сколько нужно» — идеализированный подход для сверхкоманды, да и то на нее будет действовать закон Паркинсона.

2. Тут я с вами согласен по поводу необходимости требований и формат User Story мне тоже нравится. Но в скраме он не предписывается в качестве обязательного. Знаю много команд, в которых замечательно работают в скраме другие процессы управления требованиями.

3. При таком подходе вы все дальше от Continuous Delivery. Вы же сами в первом пункте сказали, что стори готова когда команда сказала «ГОТОВО». Так о каких доработках и фиксах идет речь? Это в простонародье называется стабилизационной итерацией и многие считают это антипаттерном.

4. Тут я снова с вами соглашусь. Есть соблазн «немного поднажать», но он может привести к плохим последствиям.

А вот по поводу снижения темпа я с вами категорически не согласен. Тут речь не только о стабильности, но и о скорости разработки. На протяжение итерации команду не отвлекают разной ерундой, на планировании и в ходе разработки дают все необходимое, не давят по срокам, все прозрачно и контролируемо. Поэтому при правильном применении скрама скорость разработки не падает.
1. Дедлайн означает что к сроку нужно сдать работу в полном объеме. В скраме нет такого. В скраме есть release plan, про это пункты 3-4 предыдущего коммента.
3. В книжном описании скрама есть недостаток. Там считается что все баги устраняются в ходе разработки. Acceptance тесты не ловят всех багов, тестеры тоже люди, допускают ошибки. Поэтому перед релизом продукта таки надо тратить время на вылизывание. Чтобы это уложить в скрам и делается вылизывательная итерация, иначе будет попытка увеличить темп разработки, что скажется на качестве.

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

Да, практика показывает что правильное применение скрама делает работу более равномерной, и в среднем продуктивность растет из-за отсутствия переключений между задачами, персонального commitment_а разработчиков и раннего устранения дефектов. Но изначально все это достигается снижением темпа разработки, а преимущества появляются не сразу и только если менеджмент не мешает.
Ага, а теперь вопрос: если начинает падать velocity, то мы снижаем и снижаем? А народ мирно ковыряется в коде, жертвуя фичами. Ну-ну…
Если начинает падать velocity, то надо разобраться почему. Чаще всего velocity падает из-за того что есть working to deadline и нету достаточно тестирования в итерации, от этого появляется много багов, которые отъедают часть работы в следующей итерации.
Надо снижать темп в таком случае.
То есть вариант «кто-то начал халтурить» не рассматривается в принципе? В этом и печаль agile, он говорит «у нас команда энтузиастов и не мешайте ей работать максимально продуктивно, а только помогайте». А если нет? Если кто-то просто ленится или ему что-то не нравится?

Любая попытка подпнуть разрабочика на тему «пиши быстрее» воспринимается как покушение на принципы agile.

Безусловно, бывает, что задача рассчитана неправильно. Но бывает — что просто ленится. Вот я сейчас поеду на митинг и буду вопрошать человека, почему он за весь недельный спринт сделал только три issue на пять сторипоинтов. Причём для одного из них он поменял оценку с «1» до 3 (ок, ок), но это совсем не отвечает на вопрос, чем он занимался всё остальное время.
Кто-то это кто? Ведь очень легко отслеживается по истории задач кто сколько работы сделал по истории итерации. Задачи кстати оцениваются в часах, так что низкая продуктивность одного человека будет видна сразу же. Но пока проблем нет (velocity не падает), оценивать индивидуальные метрики нельзя. Это кстати не в скраме написано, а в TSP.

Естественно если есть проблемы надо разбираться в причинах, а не просто «пиши быстрее», иначе качество упадет. Я вот в своей жизни ни разу не видел чтобы человек работал хорошо, а потом внезапно начал работать плохо. Скорее всего для этого есть очень явные причины.
… Например, человек вылетел из графика, всё время хочет спать и вообще, не до (этого нелюбимого) проекта.
Что значит «вылетел из графика» откуда у него график? Velocity падает? Если нет, то не надо заниматься микро-менеджментом.
Такая ситуация была изначально? Или «внезапно» появилась?

Если изначально, то почему это не было видно на daily scrum? Если человек постоянно не укладывается в сроки задач, то это сразу видно — банально нечего сказать на daily scrum… Значит надо его учить\мотивировать\исключать из проекта.

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

Не зная причины предпринимать любые действия неэффективно, можно нарваться на противоположное действие.
Бороться с такой ленью достаточно просто — надо работать в паре на таких задачах. Но это в предположении, что не вся команда одновременно ленится. На ежедневном митинге, если видно что человек не укладывается в командную оценку, то он объясняет какие есть сложности. Если у техлида или кого-то другого есть подозрение на лень, то он может просто предложить доделать задачу в паре. А а в паре лениться гораздо сложнее.
Вы упускаете важную вещь — технический долг. И это задача тимлида донести до владельцев необходимость реализации технического долга. Лучше всего это делать монотонным зачитыванием issue с техническим долгом и расписыванием последствий проблем от оных.

Заметим, обратное, программистов нужно принуждать к написанию issue про технический долг. А это трудно, ибо человек должен (фактически) признать «я тут написал какую-то неведомую херню, но теперь я знаю, как это написать чуть лучше и мне на это надо в три раза больше времени».
С техническим долгом могут помочь также статические анализаторы. Помимо отлавливания общих проблем в коде и агрегации результатов, они могут также обрабатывать архитектурные проблемы в виде todo специального типа. Но это предполагает, что все честные и, вставляя костыль, добавляют todo с описанием проблемы и рисков с ней связанных. Тогда статический анализатор сводит все воедино и некоторые даже считают технический долг по заданным параметрам, переводя его в человеко-часы и деньги.
У нас недавно было принято, что после code review, если есть мнение, что это «таки работает», но есть ощущение, что халтура, то это оформляется как технический долг и распределяется на равне с остальными issue (это было сделано в рамках борьбы с бесконечным пин-понгом при code review, который де-факто — рефакторинг до победного конца).

Я не знаю, будут ли у этого решения долгосрочные проблемы, но после явной формализации понятия «технический долг» и выделения на него некоторого числа ресурсов, мы получили более steady flow, то есть предсказуемую скорость разработки. При этом PO/lead может оценивать степень важности рефакторинга и решать объём того, сколько на какую компоненту выделяется времени. Это позволяет задвинуть вниз всё не важное (в т.ч. и его рефакторинг), при этом поддерживать важное на должном уровне.

Но, эта штука пока у нас работает несколько недель, точнее будет понятно через месяца два-три.
Это открывает врата соблазна всю халтуру списывать на технический долг, а соответственно разрешает делать халтуру в принципе. Если за этим не углядеть, то может быть пичалька…
Угу. Зато «халтура» начинает работать прямо сейчас, а после её эксплуатации может оказаться, что рефакторенное решение выглядит совсем не так, как его хотели сделать.
О, наконец-то нашёлся кто-то, кто оперирует понятием технический долг, и взвешивает задачи с учётом бизнес-эффективности! Ура, коллега. Держите пять
Не будем забегать впереди паровоза. Будущее покажет. Если будет хорошо, попробую согласовать рассказ о том, как у нас устроен процесс разработки.
Мораль сей басни такова: гибкая разработка — это круто, но каждому необходимо понимать, когда ней можно начинать пользоваться, а когда еще рано.

Только в вашем случае — «когда уже поздно». Если уж вы завели проект в такое болото, глупо пенять на скрам, что он вас по волшебству оттуда не вытащил.
Sign up to leave a comment.

Articles