Как стать автором
Обновить
@kantocoderread⁠-⁠only

C++ dev, HFT, algorithmic trading

Отправить сообщение
Главное чтобы в команде все необходимые роли были заняты и желательно ещё и продублированы. Ну и чтобы при необходимости человека можно было заменить.

Ну как я пытался объяснить, аджайл хорошо подходит для сверхэксплуатации разработчиков. Не нравится пахать по 12 часов в день? Давай, до свидания. Я же говорю, скорее всего аджайл применяют в потогонках (sweatshop'ах).


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


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

Но это и в водопаде делается, разумная практика. Я нередко вместе с сейлзами ездил к заказчикам.

Смотрите, весь мой корпоративный опыт разработки описывается вот этим:
Waterfall
・Detailed, long-term project plans with single timeline
・Definitive and rigid project management and team roles
・Changes in deliverables are discouraged and costly
・Fully completed product delivered at the end of the timeline
・Contract-based approach to scope and requirements
・Customer is typically involved only at the beginning and end of a project ← тут все же коммуникация с заказчиком была частой.
・Linear-phased approach creates dependencies


В особенности вот это важно: ・Definitive and rigid project management and team roles.
У меня есть начальник, и он мой командир, я подчинен ему по субординации. Т.е. мне понятно под кем я хожу. Поэтому такие вот выкрутасы:
・Flexible, cross-functional team composition
・Collaborative and interactive approach to requirements
мне вообще не понятны, это просто хаос.

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

Вот статья от одного из авторов аджайл о том, что пора бросить аджайл: https://ronjeffries.com/articles/018-01ff/abandon-1/


Вот еще парочка:
https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/#7f6592bd2071
https://techbeacon.com/app-dev-testing/8-reasons-ditch-agile


Вот статья сравнивающая аджайл и водопад: https://www.pmis-consulting.com/agile-versus-waterfall/, там есть pros/cons-табличка для каждого из методов. Вот еще: https://www.pmi.org/learning/library/agile-versus-waterfall-approach-erp-project-6300


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

Что в вашем понимании означает "прогибается"? Это же не так что "изменения направления" делаются за счёт фирмы-исполнителя. Если нужны глобальные изменения, которые сильно отличаются от изначального ТЗ, то это всё обычно делается за дополнительные деньги. Или грубо говоря есть бюджет и если есть изменения, то все они делаются пока бюджет не исчерпан.

Это даже не разработка, это CAM — Computer Aided Masturbation. Но если подходить с тем, что цель — тянуть деньги из клиента, то почему бы и нет? Но я все же надеюсь, что ракеты наши (одна из немногих вещей, которые у нас остались после ликвидации СССР Горбачевым) никогда не будут разрабатываться по аджайл.


Другое дело что для клиента это обычно всё равно выгоднее чем получить в результате "неправильный продукт" из-за неправильного ТЗ.

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

Аджайл в первую очередь то, что написано в его манифесте. А написано вот что, из Манифеста:
Through this work we have come to value:
・Working software over comprehensive documentation
・Responding to change over following a plan
Два первых пункта напрямую приводят к возникновению техдолга.


Далее, из 12-ти принципов:
・Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
・Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Как я уже и писал, аджайл нужен для того, чтобы оттеснить конкурентов через постоянных прогиб перед заказчиком, он для этого и создавался в web индустрии.


・The best architectures, requirements, and designs emerge from self-organizing teams.
Это просто чушь. Лучшие архитектуры, требования, и дизайны возникают из большого опыта разработки, и тщательного, хорошо продуманного планирования.


Я знаю приличное количество фирм которые без особых проблем делают свой продукт и используют аджайл. Так что не сказал бы что ваш вывод так уж и правилен.

Отлично, приведите несколько примеров этих фирм и какой продукт они производят. Мне очень любопытны отзывы о качестве продукта, как и отзывы сотрудников о работе в этих компаниях (хотя последнее вторично).


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

У меня постоянно ощущение, что открыли фабрику по клонированию дураков. Не может быть, чтобы их столько естественным путем народилось.

"Стратегическое планирование" от этого не будет хуже чем в том же водопаде. Зато наоборот есть возможность относительно быстро среагировать если вдруг что-то пошло не так или клиент решит что он хочет идти в другом направлении.

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

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

Нет. Вот их принципы: https://agilemanifesto.org/principles.html, часть из которых просто ложные утверждения, например вот это: "The best architectures, requirements, and designs
emerge from self-organizing teams"

Да и техдолг это не только документация.

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


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


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

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


Про backlog тоже интересное наблюдал: взял сотрудник (не я) задачу из бэклога, поковырял ее, поковырял, не получилось, и он обратно ее в бэклог запихал (он сам на митинге об этом рассказал). У меня от удивления глаза на лоб полезли: Гениального философа… Величайшего программиста современности… И запрячь в тяжеленную машину недоделанную задачу запихать обратно туда откуда взял?! Что за хрень?!?!


Помимо вышеописанного, на мой взгляд система, в которой люди работают не по плану, а по приоритетам, слишком гибкая. Она также плоха для разработчика — четкий список задачь с конкретным дэдлайном хоть и заставляет ответственно относится к работе и уметь оценивать своё время разработки, но он также и защищает от сверхэксплуатации со стороны работодателя. А не так, что "эта фича должна быть сделана еще 3 месяца назад, поэтому ее нужно сделать как можно скорее. Даём тебе 2 дня.".


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

Ну и я на своём личном опыте уже успел почувствовать что происходит когда фирма переходит на скрам и следует правилам. И что происходит когда фирма просто говорит что переходит на скрам и при этом придумывает какие свои "с(к)рамоподобные" правила и процессы.

Не сочтите за труд, расскажите, интересно все-таки

Ну так хорошо, если водопад остается. Вполне работающая методика.

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


Установка была такая: техдолг разгребать сейчас не время, а надо быстро-быстро прилепить еще фичу, чтобы заказчик продолжил финансировать проект. Штука в том, что на разгребание техдолга НИКОГДА нет времени, а потом все либо падает, либо приходит в состояние, в котором дальнейшее развитие просто невозможно.


Думаю, что стартап этот уже мертв — техдолг они врядли преодолели, а деньги их скорее всего уже закончились.


Один из краеугольных камней аджайла это "работающее ПО важнее исчерпывающей документации", т.е. присутствует прямая установка на создание техдолга. Техдолг смертелен для IT бизнеса. Значит, аджайл следует избегать at all cost, если хочешь выжить как компания.

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

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

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

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

Вспомнилось: "драться за дело, которое обречено на провал есть высшая честь офис-самурая."

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность

Специализация

Специалист
Старший
От 500 000 ₽