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

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

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

Стандартный цикл разработки в СНГ

Утащил из комментариев на Пикабу (!) Бьется с некоторым моим опытом.

Почему так происходит? Присуще ли это именно нашей ментальности, описанной в Русской модели управления?

Шаг 1. РП (руководитель проекта): спросить заказчика, что он хочет, и понять, что тот сам ничего не понимает и хочет, чтобы РП ему сам дал его мнение.

Шаг 2. РП: придумать всё за заказчика, показать ему и получить в ответ что-то типа: «ну, ок, похоже на правду».

Шаг 3. РП: спросить технического лидера (ТЛ), сколько займёт ресурсов.

Шаг 4. ТЛ: обалдеть от размытости ТЗ, переспросить требования у РП и получить в ответ что-то типа: «ну, вот такие требования заказчика, ничё не поделать».

Шаг 5. ТЛ: додумать за РП особенности бизнес-логики, допридумывать отдельные моменты, показать РП и получить в ответ: «ну... что-то типа того»; назвать примерно реальные сроки работы и получить в ответ, что это слишком долго, и надо уложиться в срок вдвое короче.

Шаг 6: магия, за время которой разработчики создают «что-то типа того продукта, о котором мечтает заказчик, по ТЗ, которое похоже на правду».

Шаг 7. ТЛ: сдать проект; а РП: на предварительные смотры пригласить лиц, которым пофиг, и получить ответ «ну, в принципе норм».

Шаг 8. РП: выпустить проект на опытную эксплуатацию для конечных пользователей.

Шаг 9. Заказчик: услышать нытьё сотрудников, наорать на них, что это они тупые, ждать до почти конца опытной эксплуатации без комментариев в сторону РП.

Шаг 10. Заказчик: внезапно осознать, что это ему нужен рабочий продукт, а не всем вокруг, собрать со служащих «перечень недоработок» и выкатить его на РП.

Шаг 11. РП: обалдеть от четырёхсот-страничного файла excel с абы как составленными претензиями, сидеть и, не разбираясь в сути (времени уже нет), ставить проблемы в план решения со статусом «невероятно важно» на ТЛ.

Шаг 12. ТЛ: обалдеть от вороха критически важных задач в календаре, начать их разгребать, понимая, что часть из них затрагивают принципиальные и глубинные слои проекта, которые не понятно, что лучше: исправить или переписать с нуля; попутно отмахиваясь от ПР, которому «ну, что так долго?»

Шаг 13: магия, при которой разработчики зашиваются и перерабатывают, накидывают костылей, мешая и путая друг друга.

Шаг 14. Все: ожидание люлей, поиск виноватых и прикрытие собственной жопы.

Шаг 15. Дедлайн: время, о котором договорились РП и заказчик, игнорируя оценку ТЛ из пункта 5. Получение люлей всеми сторонами друг от друга и от руководителей всех участников.

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

Шаг 17. РП: понять, что текущий продукт абсолютно не соответствует хотелкам заказчика, но, поскольку бюджета и времени уже нет, доказывать заказчику, что часть важных хотелок заказчика ему не нужна, а текущая реализация лучше. Что не получилось отбить, спустить на ТЛ.

Шаг 18. ТЛ: повторно обалдеть от требований, которые ему пришли, понять, что переделка продукта в должном качестве займёт больше времени, чем написание с нуля. Кое-что отбить у РП, а остальное распределить в работу.

Шаг 19. Повторный марафон переработок в целях закостылять ненавистный уже всеми проект. Очередной просранный дедлайн с разбрасыванием говна, кому попадёт.

Шаг 20. Релиз. Продукт, работающий медленно, на костылях, говне и палках, отдаётся в эксплуатацию. Пользователи жалуются на неудобство, тормоза, недостаток функционала. Их затыкает заказчик, так как решение уже просто должно быть принято в работу. РП: передать проект в поддержку (ТП).

Шаг 21. ТП: получить продукт без документации, а на вопрос, где она, получить что-то типа «вот она» (пара листов из ТЗ), или «скоро будет» (нет), а лучше «там всё интуитивно понятно» (ну-ну).

Шаг 22. Получить тонну жалоб от пользователей со статусом «ничего не делал, всё не работает». Зашиваться, пытаясь ответить пользователям, папаллельно разбираясь, кто дурак: пользователи, разработчики или они сами.

Шаг 23. Заказчик: все хотелки, которые ранее не вошли в ТЗ на этапе 17, выкатить в сторону ТП как баги, которые «выползли вот только что и ломают работу».

Шаг 24. ТП: не вникая (да и откуда им знать?) в историю создания продукта, пробросить проблемы в сторону ТЛ, как проблемы по договору технической поддержки.

Шаг 25. ТЛ: узнать тот же ворох претензий от заказчика, что был раньше, но под другим соусом, чертыхнуться и отправиться к РП, чтобы совместно придумать, как послать Заказчика так, чтобы тот не обиделся, но пошёл. В результате получить фигу с маслом, так как проект закрыт, а поддержка — это уже другое. Пойти к ТП и там пробовать показать и рассказать. Результат тот же: баги есть, договор о поддержке тоже. Пойти самому нахер и отложить все эти задачи в долгий ящик.

Шаг 26: магия, когда задачи из технического долга лежат без решения и превращаются из багов в фичи.

Шаг 27: Заказчик: через несколько лет вспомнить про задачи и параллельно захотеть доработку (переработку) проекта. Стартуем с пункта 1.

Источник:
https://pikabu.ru/story/i_eshche_deploit_v_pyatnitsu_9617515#comments

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

Эта хайповая картинка хотя и пытается рассказать о том, что 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 + ↓