Rose debug info
---------------

Адель Шигабутдинов

Сеньор помидор. Бложек ведущего разработчика и тимлида, трансформировавшегося в менеджера проектов :-)

Автомобиль не начинается со скейтборда

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

Здесь две проблемы:

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

Мы всегда идем от автомобиля. Он должен быть самым простым, хоть как повозка на колесах, но это всегда автомобиль, на каждом шаге.
Вот правильная картинка про Agile:

Reference: Allen Houb

Переболевшим Agile

Наткнулся на блестящий комментарий к видео с беседой о проблемах скрам и том почему аджайл все-таки не работает. Если нет времени смотреть все 1.5 ч интервью:

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

О монолитах

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

Пара статей по этому поводу, не теряющих актуальность на сегодняшний день
https://m.signalvnoise.com/the-majestic-monolith/ от 2016г
https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/ и от 2020

Анти-аджайл манифест

Что, если перевернуть аджайл манифест и 12 принципов гибкой разработки ПО?

В некоторых местах не смешно :-)

Анти-аджайл манифест

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

Процессы и инструменты важнее людей и их взаимодействия

Исчерпывающая документация важнее работающего продукта

Согласование условий контракта важнее сотрудничества с заказчиком

Следование плану важнее готовности к изменениям

Хотя и можно (под давлением) признать что то, что справа имеет какую-то ценность, мы на самом деле считаем важным только то, что слева.

12 принципов анти-гибкой разработки программного обеспечения

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

Ссылки
Перевел с: https://agilecheetah.com/the-anti-agile-manifesto/

Соответствует требованиям

Программисты любят говорить «требования». Реализую требования, спустили требования, код соответствует требованиям.

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

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

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

Короче, думать своей головой и договариваться надо, а оправдывать плохо сделанную работу требованиями — нет.
https://t.me/nikitonsky_pub/326

Slime mold

Презентация о том, почему даже в хорошо слаженных организациях с компетентными и ориентированными на сотрудничество людьми случаются штормы

https://komoroske.com/slime-mold/

Ранее Ctrl + ↓