Comments 389
Даже для идеального мира не тянет.
У качества и скорости есть свои весовые коэффициенты — вот вам первый артефакт вашей матмодели
Кстати, что это за зверь — матмодель ПО?

«Делать как надо» — кому надо? кто сказал, что так надо?

Понятно, что в чем-то по сути вы правы, но вы безапелляционно вводите это в абсолют.

Всё здесь написанное нужно читать на контрасте с т.н. аджайл-манифестом, на который дана ссылка в предисловии.

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

Откройте уже первую ссылку из этой публикации, и читайте обе страницы параллельно.

Если вы хотели сделать отражение эджайл манифеста — это ваше право.
Высказать в комментах мнение, что оно абсолютно не приложимо к реальной жизни — мое право.

Это вы точно мне хотели ответить? Если да, то я не понял.


Первая строка — цитата моего оппонента, если что.

да, ошибся дверью, прошу прощения. Надо было адресовать ответ вашему оппоненту.
С таким же успехом статью можно назвать «почему разработчики считают дедлайны или менеджеров нонсенсом». Программирование перестает быть искусством и превращается в ремесло — сродни тому как когда-то мастера запирались в кузнице и ковали меч с неизвестным наперед результатом — а сегодня оружие делают на станках с ЧПУ.
Почему не имеет? Я поддержу автора, у меня в компании на практике — близко к тому, о чем пишет автор
но вы безапелляционно вводите это в абсолют

Что «это» и где именно вы увидели возведение «этого» в абсолют?
Я вот ничего подобного не заметил. Все описано ровно также как и в аджайл манифесте и его концепциях.
И точно так же, как в аджайле, есть здравое зерно, но не все сходится с реальностью…
Я не пользуюсь эджайл и «за» дизайн и архитектуру ПО, но здравое зерно в эджайле примерно на порядок крупнее того, что здесь.
Попробуйте сунуться с этими принципами к следующему вашему заказчику/работодателю.
Попробуйте просто их применить для своего личного проекта.
Не будет этого, кроме как на простых школьных работах.
Никогда не сможет разработчик все просчитать на стадии дизайна, даже если требования не будут изменяться. Всё равно нужна подвижность и динамика.
Либо вы читаете между строк, либо ваши каменты не от этого топика…
Я вот нигде не увидел фраз «все просчитать на стадии дизайна».
Черным по белому написано, что при изменении тербований просто запускается полный цикл продумывания изменений.
И именно так я всегда старался и делать.
Я ожидаю от вас или от автора статьи описания, как вы следующий свой проект сделали в полном соответствии с данным манифестом, чтобы не балаболить.
Ох уж эти интернет воины))
Вы серьезно этого ждете? Вот прямо серьезно серьезно?
Парень, балаболишь здесь только ты))
Манифест, это не жесткие правила. Не догмы.
Это идеи которыми люди руководствуются при работе над проектами.
В аджайле есть несколько разных фреймворков, типа скрама и канбана, которые не одно и то же, но тем не менее руководствуются манифестом.
Так и этот манифест в разных ситуациях может выливаться в разные действия.
Если ты этого не понимаешь, то земля тебе пухом)
Да, это нормально — продумывать изменения, просто очень многие делают из этого «слона», а ведь зачастую это просто мелочь. Концепция важна, но это не догма. И заказчик должен видеть, что вы готовы обсудить изменения и поменять её за его деньги. К сожалению, довольно часто сталкиваюсь с тем, что даже за деньги концепцию меняют очень неохотно. Важна та самая золотая середина. Аджайл идет к ней со стороны заказчика/менеджеров, автор со стороны исполнителя/программистов.
Согласен — программа пишется для бизнеса прежде всего, а не для удовлетворения внутреннего эго программистов. Поэтому «как надо» = «как надо бизнесу» и никак иначе в первую очередь..
Самое главное не путать «как надо бизнесу» и «как менеджеру, чтобы получить премию». Слишком многие почему-то забывают, что это совершенно разные вещи.
Класс, ваша статья прямо мое жизненное кредо (я программист).
это выглядит как шутка, которая затянулась
Ну почему же. Agile для меня это просто одна из форм организации процесса разработки. Ваш манифест легко вписывается, по крайней мере именно так я и работаю.
Концепция важнее новых требований
Сообственно почему я и присутствую на backlog refinement. У меня спрашивают story points и я чесно говорю, если задача не вписывается, что придется менять для реализации и насколько это сложно. Часто задача сразу же упрощается под существующую архитектуру, откладывается (создается spike — чтобы уточнить сложность) или от задачи вообще отказываются.
Качество важнее скорости
Маленькая предистория. Работал с одним программистом без agile, он делал все быстро и меня не спрашивал. В результате получилось разделение отвественностей: только он знал свой код. Потом он ушел… и грянул гром… там было все плохо… Теперь мы используем agile и code review, любой программист может поддерживать любую часть проекта (нет «черных ящиков» — инкапсулированного кода, не понятного для всех). На этапе ревью код балансируется, чтобы уменьшить технический долг (меньше извините гавнокода). Вроде бы работает, требует больше времени на разработку, зато жизнь после релиза проще.
Делать как надо важнее, чем делать как просят
Моя фирма нанимала программиста, а не обезьянку, которая умеет печатать. Я не дурак (вроде) и могу думать, в том числе решать проблемы. Любая из назначенных задач — это полностью мой выбор как решать. Впрочем есть другой нюанс — у меня свое «узкое» видение решений, которое может быть не совсем оптимальным для конечного пользователя. Тут нужен балланс, «как важнее» — это весьма субьективная трактовка.
Теперь мы используем agile и code review, любой программист может поддерживать любую часть проекта...

Аджайл с этим никак не связан. Почти любой программист может поддерживать почти любую часть проекта тогда, когда соблюдается техпроцесс. То есть: обзор кода, тестирование и документирование.


жизнь после релиза проще

Истинно так.


требует больше времени на разработку

А вот это только на ранних этапах. Когда всё встаёт на рельсы, всё только быстрее.


как важнее

Либо я неправильно понял, либо вы неправильно прочитали. У меня не "как важнее", а "как надо".

Почти любой программист может поддерживать почти любую часть проекта тогда, когда соблюдается техпроцесс
Тут вы прям в точку попали. Документация практически отсутствовала. Тесты — больная тема до сих пор… Я просто хотел сказать, что введение одного лишь code review в процесс разработки существенно улучшило ситуацию с «качеством» кода, хотя и уменьшило скорость.
У меня не «как важнее», а «как надо»
Моя опечатка, врочем смысл не особо меняется. Что значит как надо? Как красивее впишется в архитектуру? Это скорее «как проще» для вас. А пользователю программы это может быть не удобно. И нужно искать балланс, такое решение, которое и впишется в архитектуру, и не будет неудобной кнопкой где-нибудь далеко, до которой еще и добираться через несколько кликов (был случай).
Возможно. До недавнего времени просто вообще ничего не было. А потом пришел scrum master и начались code reviews, появился беклог, спринты и т.д.

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

С другой стороны никто не будет ждать, пока ты пишешь свой «идеальный» код. Потому нужно искать компромис, но все же с упором на качество, не по максимуму, но хотя бы,
чтобы твоя совесть сказала «теперь хорошо, расслабься».
Я перефразирую, пришел человек который был заинтересован в повышении качества кода (как минимум). scrum то причем? парное программирование и кодревью известны и употребляются повсеместно года этак с 2002..03-го
Простите, я не пойму что именно вы спрашиваете. Почему я стал говорить о scrum? Потому что мы его сейчас используем. Scrum = agile, статья о догмах разработчика в agile, что не так?
Я про то, что на практике, описанные методологии больше заточены под повышение КПД конкретной рабочей единицы в проекте, под возможность более гибкой манипуляцией проектом, но мало заточены под качество кода.

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

Отсюда я делаю вывод, что scrum/agile больше всего преследуют коммерческие интересы конкретной группы лиц в проекте.

И заметьте, я нигде не говорю, что это плохо. Я вообще не сторонник «черно-белой парадигмы». Но то, что эта группа лиц частенько использует эти возможности в целях «замыливания» или скрытия истинного положения дел в проекте — это факт. Отсюда возникают такие публикации как эта.
А если серьёзно. Я прошёл путь программер -> тимлид -> руководитель проекта -> тимлид и доволен текущим положением дел. Адептом скрама особо не был, пробовали в команде. А вот канбаном мы пользовались долго(около 4х лет, 12 человек, художники, программисты клиента и сервера, сценаристы). Про канбан интересно что сам Дэвид Андерсон говорит не совсем то что говорят многие люди вокруг канбана, он очень хорошо понимает что главная задача делать дело. Я понимаю обе стороны (agile манифест и автора). На текущий момент мне кажется что надо всё-таки понимать что разработка ПО это бизнес. И бизнес нужно понимать, а не гнуть пальцы. Иногда поддержка и маркетинг будут отдуваться за разработчиков, иногда наоборот. Нужно подбирать правильных людей в команду, управлять составом команды, вовремя выводить из неё ненужных людей и нанимать профи. Проверка гипотез — важная часть управления продуктом. И часто можно и нужно наговнякать в коде для проверки гипотезы. НО! Нужно оценить степень говнокодистости и влияния на проект принять решение, либо править, либо нет. Иногда пристройка должна остаться пристройкой. А иногда нужно всё переделать. Я сейчас работаю с проектом которому 7 лет. И там есть места где 6 лет торчит костыль. Он там описан, никому не мешает, вся команда знает что он там есть и работает для одного определённого функционала который за 6 лет прибыльности не потребовал доработки. Я сторонник подхода что при расширении успешного функционала нужно проводить ревизию архитектуры и думать, нужно переделать основание или нет. И делать это надо вне зависимости от того сколько там костылей. Это гигиена, надо улучшать — проверь фундамент. А если что-то есть и не растёт и не мешает, то просто так, по чьей-то прихоти менять код смысла не вижу. Если мешает то конечно надо править. Сейчас я не пользуюсь никакой методологией, мы просто работаем.
Аджайл это попытка примирить быстро меняющиеся бизнес-условия и технологический процесс. С моей точки зрения автор не противоречит, а дополняет — он всего лишь говорит что промашки менежмента не должны ложиться на плечи программистов, нельзя всех обезьян вешать на инженера, если на выходе хочешь получить качественный продукт. Хочешь менять требования — пожалуйста, но понимай, что это небесплатно. Извините если я где-то не прав или говорю банальности, но эти банальности на практике частенько забываются за баннером «Аджайл».
… он всего лишь говорит что промашки менежмента не должны ложиться на плечи программистов...

Это я тоже говорю. Но не только.

Неудачно сделанная работа по продажам или планированию не должна

и тут навстречу программисту идут со своим манифестом жесткие маркетолог и продажник.
И у них написано в манифесте:
«1. Только продажник может определить удачно или нет сделана работа по продажам.
2. Если кому-то кажется что неудачно — смотри п.1.
3. Продажи превыше всего, в жопу философствующих программистов — их дело — быдлокодить в срок и недорого.»
А потом приходит околотоп-менеджер и говорит — эта фича нужна сейчас! На проде. Ну и что, что регресс не пройден, я понимаю риски и беру на себя, уже же релизили так.
И тут ломается функционал прода. Тот же топ требует хотфикс, тестеры говорят — у нас регресс займёт 8 часов, мы не успеваем! Им отвечают — фиг с ним, у нас баг на проде, релизим! И релиз хотфикса ломает уже другой функционал, но гораздо больше и критичнее.
После этого начинается свара программистов и тестеров, тимлид рвёт седеющие волосы, всем весело.
А околотоп, который «взял на себя ответственность» разводит руками, и напоминает, что он не технический специались, и с него взятки гладки…
Тестеры не убедили, программисты не сделали как раньше — ведь раньше работало и не крашило.
У программистов виноваты тестеры — сидят, нифига не делают, у тестеров один ответ — а мы предупреждали.
В сухом итоге виноват PM :)
Главное что околотоп продемонстрировал высший профессионализм в своей области — делегировать ответственность вниз. Ну а денежки — это себе на карман.
И тут ломается функционал прода. Тот же топ требует хотфикс, …

… и идёт лесом. Вместо хотфикса делается откат на предыдущую стабильную версию, и работа возвращается в штатное русло. В ответ на любые претензии ответ один: всю ответственность на себя взял вот тот топ, разговаривайте с ним. Претензии от этого топа не принимаются — мы предупредили что "не готово"? Ты не поверил и захотел убедиться? Ты убедился.


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


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

Это если вы можете откатиться на предыдущую версию. А бывают такие системы, которые очень-очень-очень много пишут. Постоянно.
Ага, или какие-то внешние регуляторные требования, типа известного GDPR. И попробуй откатись.
Ну отсутствие CI в 2018 году говорит о компании даже больше, чем нетехнический топ, выкатывающий непротестированные релизы

Наличие CI/CD ещё не даёт гарантию возможности отката. Чтобы проект можно было спокойно откатывать нужно ещё как минимум реализовать (и тестировать!) автоматизированные миграции БД не только "вперёд", но и "назад".

Угу, практически нереально, в сложных системах, где идет завязка кода не только на структуру данных, но и на сами данные (да, мы стараемся так не делать, но и 1% достаточно). То есть откатить можно, но безумно сложно :) Бакап перед релизом тоже не спасает — если ошибка не в первые секунды работы, то может накопиться слишком много новых данных, которые в старую структуру не запихаешь. Пичалька…

Бэкап обязателен в любом случае — некоторые миграции деструктивны (напр. удаление колонки из SQL-таблицы) и единственный способ их откатить это восстановить бэкап.


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

Полезно, думаю, делать деструктивные изменения в базе делать не сразу, а, например, через релиз, по аналогии с удалением чего-то из PublicAPI проекта. То есть, перестали пользоваться полем в релизе A, пометили само поле как Deprecated, но именно удалять его будем только в релизе A+N. Правда, это в разы сложнее отслеживать, но зато откат проводить можно меньшей кровью.

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

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

Разумеется, здесь каждый будет решать по себе, серебряных пуль не завезли.
Значит топ должен быть о таком варианте предупрежден и если настаивает, то весь простой — его вина. Я бы, как тестер, в таком случае попросил бы его написать явное распоряжение мне и разработчикам на почту, чтобы потом не было «Я такого не говорил», «меня не так поняли» и т.п. Собственно подобный мысленный эксперимент я проходил на одном из собеседований, которое собственно прошел. Лично, к счастью, именно такого не было. Фича в прод которая все поломает — была. Но менеджер который ее требовал признал что был не прав, все откатили и продолжили работать. Насколько я знаю там даже не менеджера вина была, а клиента, который из госструктуры, но как менеджер потом объяснял почему все поломалось и почему мы не виноваты я уже не знаю и знать не очень хочу.
если система очень-очень-очень много пишет, ее надо очень-очень-очень регулярно бэкапить.
Тут беда в том, что откат может быть проблематичен не только из-за «подхода», а потому что там появились пользовательские данные и просто откат на бэкап невозможен. То есть даже откат на стабильную версию может не быть однозначно безопасным и успешным. Просто представьте себе подобные движения туда-сюда в, к примеру, GMail, где у кучи народа почтовые архивы. В остальном — да, баг висит в проде, пока хотфикс не оттестируют. Я в таких проектах работал и подобные ситуации видел. И рад, что не был в тот момент менеджером. Правда, летом работал в проекте, где был единственным разработчиком, заказчики не дали всех сведений сразу, а перезапустить проект уже было нельзя, потому что часть данных ушла в печать и была вклеена в официальные документы (QR-коды со ссылками вклеивались в дипломы, чтобы можно было подтвердить, что диплом не распечатан на цветном принтере).
4. Программисты должны реализовывать функционал в том виде, в котором его описали продажники, а не придумали сами программисты.
Позволю с вами не соглашусь, хотя сам продажник. Производство программного продукта глобально не отличается от производства материального товара. Это я к тому, если на «придуманном» хлебозаводе невозможно изготавливать хлебобулочные изделия в виде правильного октаэдра, то ровно такие же ограничения есть при производстве программных продуктов. Если в интерфейсе программы нужно добавить ромбик «цветом бедра испуганной нимфы» в низу экрана, а технологически это невозможно, то как бы продажник не бил копытами, ромбик в низу экрана не появится.
Автору "+" за буйность!

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

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

Аджайл-манифест читали? Какие конкретные ценности там декларируются?

Прочтите теперь хотя бы по одной книге каждого автора Agile манифеста, чтобы хотя бы в кратце понять о чем он. Уверен откроете для себя целую вселенную. Кстати, открою вам страшную тайну, большинство писавших этот манифест, программисты. И писали они его для программистов по большей части :)
… писали они его для программистов...

Неважно, что ты делал, важно, что ты сделал. Они могли хотеть писать его для программистов, но, увы, написали не для них.

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

А я утверждаю, что это вы не до конца прочувствовали суть происходящего. Один из нас точно неправ.

Вообще Agile неплохо так защищает кодеров от произвола менеджмента — так как он призван быть гибким — и гибкость эта раскрывается в умении адаптации процесса разработки под требования бизнеса И команды. Если вам не повезло работать в командах, которые просто бездумно выполняют ритуалы и не вовлечены в улучшение процесса разработки — это не проблема Agile =)) Во всех гибких командах, где бы мне не довелось работать в РФ и в Европе мы всегда выстраивали свой процесс и оптимизировали его. И так же радели за качество продукта и архитектурные изыскания и процесс ввода фич из беклога в спринты/канбан доску. Да! Agile работает не для всех продуктов, есть продукты где лучше работает водопад, но такова жизнь. Agile — не волшебная палочка для решения проблем — единственную проблему, которую вижу я сейчас с этим вопросом — это то, что его как и любой «модный инструмент» подают под соусом «мазь для решения всех ваших проблем с разработкой ПО». Да и всегда следует помнить, что рабочие места организует бизнес, не будет бизнеса не будет и программистов =) А последнее время и вы и другие коллеги все чаще подают такую мысль: «Я — программист, я — основа этого бизнеса, без меня его не будет — следовательно, я хочу диктовать свою волю бизнесу», но это не так работает =)) Обучить кодера — это полгода — еще за год сверху он станет крепким мидлом, поверьте заменить человека сложно, но на рынке уже есть подготовленные кадры, поэтому свою волю бизнесу навязывать ультиматумами — глупо. Что сделать спросите Вы? Я отвечу — все очень просто — меняйте бизнес-процессы изнутри, если в ваших предложениях есть измеримая, хотя бы косвенно прибыль — то сознательный бизнес мало того, что пойдет на встречу, но и выделит вас, может сделает техническим управленцем даже =)) А если бизнес не хочет вести диалог на своем языке — то и нафиг там работать(мы же программисты-здвёздочки — найти новую работу ведь легко =)))
Обучить кодера — это полгода — еще за год сверху он станет крепким мидлом

Тут традиционная ошибка в эстимейте — примерно в π раз.

Извините, много работы было.

Вы вот про это я так понимаю:
1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану

Да, это гораздо более конкретно, люди попытались вычленить то, что по их мнению приносит пользу конечному заказчику и минимизирует работу производственной системы.
Успех этого манифеста заключается в том, что он весьма неплохо мапится на конкретные объекты и процессы реального мира, например многим знакомо, что после фиксации требований и начала работы, заказчика могут послать лесом и в результате выкатить продукт который ему уже не нужен, а оплачивать надо. Присутствуют нужные объекты, субъекты, контекст некоторой бизнес ситуации.

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

Модель разработки «it’s done when it’s done» подходит крайне ограниченному набору ПО в исключительно редкой ситуации наличия у компании «неограниченных» ресурсов. Во всех остальных случаях определяющую роль играет время вывода на рынок новой функциональности с приемлемым качеством.

Agile-подход как совокупность практик позволяет добиться баланса между скоростью вывода на рынок, качеством продукта и качеством исходного кода. Ваш же манифест вряд ли приведёт к чему-то отличному от «задрачивания на код».
… вы ни-че-го не понимаете во взаимосвязи процесса разработки ПО с другими процессами внутри компании, а также со внешними факторами, влияющими на неё.

Я думаю иначе.


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

Аджайл-подход превозносит интересы одного круга лиц над интересами другого круга лиц.


Не перехожу на личности, но между строк читается незрелость вас как инженера.

Незрелость проявляется в том, что я призываю отстаивать свои интересы?

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

А надувать щёки и рассказывать что точно знаете Правильное Значение Слова а кто не знает тот джун/студент и не имеет права писать — норм?
Это какие такие интересы превозносятся? Не дают инженеру играть в песочнице, пока не стемнеет?

Ваш «манифест» — однобокий взгляд, не демонстрирующий понимания, в отличие от авторов agile, которые искали практики, учитывающие интересы и потребности обеих сторон.

// никогда не думал, что буду защищать agile от нападок программиста

А что касается незрелости — я уже написал. Вы — максималист, это даже между строк читать не нужно.

Ничего личного. Просто надо побольше профессионального опыта приобрести, и побывать за пределами уютной IDE-шки.
… искали практики, учитывающие интересы и потребности обеих сторон.

Искали, но, увы, не нашли.


Просто надо побольше профессионального опыта приобрести, и побывать за пределами уютной IDE-шки.

Проблема сильно глубже, чем вам кажется.

Вы знаете, совершенно не собираюсь спорить с тем, что «when it's done» приминим далеко не всегда, но не могу не заметить, что зачастую гонка из-за
определяющую роль играет время вывода на рынок новой функциональности с приемлемым качеством

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

НО ЭТО НЕ отменяет важность time to market. Да, очень много продуктов имеет красивую обертку, но ужасное подкапотное пространство. Но это реальность большинства проектов. Продукт нужно запускать быстрее, а после запуска и в случае успеха уже от СТО зависит, какое качество будет у кода.
Продукт нужно запускать быстрее...

Кому нужно? Почему? Чем это обосновано, кроме "рынка"?

Владимир, ответьте на мой вопрос ниже. Ваш манифест решает те потребности бизнеса, которые я там озвучил?
Кому нужно? Почему? Чем это обосновано, кроме «рынка»?

Это нужно бизнесу, потому что ROI и window of opportunity. Это обосновывается исключительно потребностями рынка, потому что, сюрприз, продукты выпускаются с целью зарабатывания денег, и должны решать проблемы рынка.
ROI и window of opportunity

Я вас не понимаю. Пожалуйста, вернитесь к нам, простым русским ванькам.


P.S. Я не Владимир. Не понимаю, откуда это взялось.

Ваня, оба термина без проблем гуглятся, не стесняйтесь пользоваться поисковиками: Окупаемость инвестиций, Window of opportunity.


P.S. Я знаю, как Вас зовут (на гитхабе посмотрел), просто не удержался от стёба в ответ на "простым русским ванькам", простите. :)

Дело не в том, что я могу или не могу что-либо наяндексить, и не в том, что я что-то знаю или не знаю.


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

Дмитрий, вы — хам и тролль. Если вы не понимаете,

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

то вести конструктивный разговор с вами невозможно.

Спокойнее. Просто вы привыкли, что вам все верят на слово. Но так вышло, что сегодня это не работает.


Ролевая игра.


Я — программист.
Вы — наниматель.


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

Извините, что вмешиваюсь в ваши ролевые игры, но это не сложно:


  1. Дмитрий, если Вы пришли в нашу компанию для того, чтобы получать два месяца зарплату за бесполезную деятельность по написанию кода, который никогда не будет запущен — пожалуйста, напишите заявление по собственному прямо сейчас, и успехов Вам найти работу в компании, которой надо то же самое, что и Вам.
  2. Если Вы хотите сделать что-то полезное, то учитывайте, что вне зависимости от качества и функционала продукта он окажется бесполезен, если мы не выпустим его на рынок через два месяца.
  3. Если Вы уверены, что запланированный функционал с необходимым качеством невозможно выпустить через два месяца — давайте вместе согласуем альтернативу, урезанную по функционалу и/или качеству, которую реально выпустить через два месяца, и которая будет всё ещё достаточно полезной, чтобы у нас был реальный шанс получить достаточно средств для продолжения разработки этого продукта.
  4. Если Вы не видите возможных альтернатив, и считаете поставленную задачу невыполнимой — пишите заявление по собственному, наша компания либо закроется на два месяца раньше (если никаких вариантов вовремя сделать продукт действительно нет), либо мы наймём другого разработчика, который такие варианты сможет найти.

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


Следующее действие — звонок в трудовую инспекцию.

Следующее действие — увольнение по инициативе работодателя и можете идти с этим в суд. :)

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

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

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

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

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

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

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


А в чём именно нарушение ТК, просто любопытно? Если Вы не можете выполнить ту работу, за которую я готов платить — значит либо это невозможная работа, либо просто для этой работы нужен другой исполнитель. В любом случае, если другой работы конкретно для Вас у меня нет, то Вы — уволены. Или ТК запрещает мне Вас увольнять? Я-ж не говорю "чтоб завтра ноги твоей не было в офисе, и зарплату за предыдущий месяц мы тоже не выплатим" — уволим по ТК, две недели или какие там в России правила, суть ведь вовсе не в этом.


Что до хамского давления — простите??? Где Вы усмотрели хамство? Мне нужно выполнить конкретную работу, я ищу под эту работу исполнителя, готов согласовывать с исполнителем разные варианты как её можно сделать… Если исполнитель не в состоянии сделать эту работу мы просто отказываемся от его услуг и ищем другого исполнителя, либо отказываемся от идеи реализовать именно этот продукт. Что тут можно было найти хамского…

Игра окончена, Алексей. Я "попал" в какую-то быдлоконтору.


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


Единственно верным был вариант №3, но почему-то он не был главным и единственным. А главным оказался шантаж. Вот, собственно, и иллюстрация к основной теме нашего разговора.

Александр. :)


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


Вариант №3 не был единственным просто потому, что жизнь штука сложная, и вариантов всегда больше одного. И нет, если Вам показалось, что какие-то из этих вариантов главнее других — то Вам просто показалось.


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


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


Ладно, ночь уже, пора заканчивать это развлечение. Я так понимаю, Вы эту ролевую игру слили (придирки к форме оформления увольнения не могут являться осмысленным ответом, или Вам есть что ответить по сути вопроса)?

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

Вы как-то упускаете из виду, что в данный момент компании нужен не "разработчик PHP", а "разработчик который может реализовать этот проект за два месяца". Если текущий это сделать не в состоянии — значит его квалификация не соответствует требованиям этой позиции. Опять же, я без понятия как это нужно оформлять юридически, но, очевидно, если компании нужен сеньор, то у неё есть возможность не допустить мидла на эту позицию. Равно как и если ей нужен рок-стар вместо обычного сеньора, то компания сможет убрать из штата позицию "старший разработчик" и заменить её позицией "ведущий разработчик" или ещё как-то, чтобы иметь легальные основания доказать, что текущий разработчик ей действительно сейчас не подходит.

Я — программист.
Вы — наниматель.

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

Правильная ролевая игра выглядит так:
Я — программист.
Вы — менеджер.

Т.е. тут нет иерархии отношения начальник -> подчиненный, здесь обе стороны равноправны и должны договариваться чтобы согласовать проект.
И тогда нам открывается скрытый пятый вариант:
5. Если Вы как менеджер ставите заведомо не выполнимую задачу (разработать продукт Х за время Т), то я могу дать Вам встречное предложение — отказаться от разработки продукта Х за время Т, а поработать головой и придумать другой продукт Y, который можно разработать за реальное время Т2.

Чувствуете разницу? :)
Это не менеджер заставляет программиста работать (писать плохой код и потом в сверхурочные его править), а программист заставляет работать менеджера (придумывать продукты реализуемые в реальные сроки).

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

в нормальной ситуации ваш вариант в целом равнозначен вышеупомянутому варианту №3
Даже если контора обанкротится через 2 месяца, то виноват будет
Виновата будет команда, не сумевшая предложить и реализовать вменяемую альтернативу.
в нормальной ситуации ваш вариант в целом равнозначен вышеупомянутому варианту №3
Нет, это как раз альтернативное развитие ситуации в случае отсутствия консенсуса при варианте 3, вместо дальнейшего варианта 4 (увольнение программиста), мы рассматриваем вариант 5 (увольнение менеджера).
Если удается договориться на варианте 3, то это идеальная ситуация, когда и волки сыты и овцы целы, но обычно в 90% случаях так не получается, потому что если новые требования к продукту не требуют кардинальной переделки существующей архитектуры или инструментов, то с реализацией в «нормальном» режиме проблем нет, мы просто ограничиваем ф-ционал, чтобы уложиться в срок, а если требуют – то тут никакое ограничение ф-ционала не возможно, так как нет базового фундамента на котором вообще его строить, а для «правильной» разработки этого фундамента требуется заведомо больше времени чем выделено.

кто-то вполне может быть сокращен.
Именно так.
Если менеджер не соглашается на вариант 5, то у руководителя конторы появляется дилемма, зависящая от его идеологии:
  • Либо уволить «жёсткого» программиста (если руководитель адепт AGILE)
  • Либо уволить менеджера (если руководитель адепт ANTI-AGILE)

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

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

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

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

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

Часто вижу такое утверждение. Наверное, это какое-то желание хоть в чем-то иметь возможность обвинить «руководителя конторы». На практике, никакого чувства вины там нет.
Ну, по себе людей не судят… Я когда писал «главный виновник, конечно, это руководитель конторы» имел в виду, что именно он является главной причиной того, что контора не получит прибыли/обонкротится и объяснил почему это именно так, про чувство вины у руководителя конторы — это вы уже нафантазировали, не знаю из каких соображений )
А вы путаете причину и следствие, определяя «виновата» — как «не смогли найти решение». Виновата — это значит, команда стала причиной, того что решение не найдено.

Команду поставили на задачу, дали ответственность и полномочия, а она не справилась. Задача не сделана, «виновата» команда — в случае сферического проекта в вакууме.

В целом, вы пишете про ответственность руководителя команды — с этим я не спорю. Но командная работа — на то она и командная. Вместе боролись, вместе прое^W не справились.
  1. При увольнении по соглашению сторон нет обязательных выплат. Предложить можно соглашение и без выходных пособий. Практика с выплатой выходного пособия сложилась, скорее, как альтернатива сокращению.
  2. В крупной организации могут не уволить, а поставить в разработку второстепенного (не mission-critical) продукта, скорее всего "приговоренного в декомиссу" в течение 3-5 лет. Особо нагружать не будут, повышать не будут, поощрять не будут, развития не будет. Всё по ТК. Если хватит глупости досидеть до end-of-life продукта, то дадут такой же, хм, перспективный. BTW, иногда (очень иногда) у упёртых жёстких одиночек (за счет недогруза задачами и от скуки) хватает сил переработать архитектуру такого legacy до весьма неплохого уровня. Это как бы почти win-win, но реально win для конторы и потраченные годы жизни на тупиковый проект, выгорание и ЗП ниже рынка.
  3. В небольших организациях такой опции нет, но зато могут себе позволить тщательнее отбирать новичков. Ну или придётся страдать.
  4. В стартапах часто на входе сразу говорят, что либо мы делаем продукт, который можно продать "к исходу сентября", либо бабло тупо кончается. И, да, за оставшиеся N месяцев, скорее всего, придётся 3 раза переписать продукт, потому что всплывают внезапные изменения.

Извиняюсь, что вмешиваюсь, но мне очень интересно узнать что может быть за программный продукт, который был бы полезен, будучи выпущенным за 2 месяца, но полностью бесполезным, будучи выпущенным за 3?
Честно.

В контексте этого разговора под продуктом может пониматься фича или их группа, которые нужно выпустить на рынок раньше конкурентов.
Топовый мобильный телефон, анонс которого с точной датой представления был сделан полгода назад. Если вы не сможете показать его на текущей выставке, то к следующей он уже УСТАРЕЕТ а покупать будут почти такой, но у конкурентов.
А вообще разработка ПО для топовых моделей, да под новый процессор — ад. Работа месяцами по 14-16 часов в сутки с одним выходным в неделю- норма. Процессор НИКОГДА не появляется вовремя. Отладка идёт на уровне «абы явно не глючило»
Как я понимаю, от проца сильно зависит, например, камера (потому что он содержит специальные блоки для обработки данных с сенсора). А если, скажем, возможности камеры — киллер-фича конкретного телефона, этого должно быть уже достаточно.
Нескромный вопрос, а зачем? Нормальный пакет акций или зарплата которая позволяет годик пожить на бали?
Зарплата, которая позволяет жить в своём доме, иметь 2 машины и содержать жену и 2х детей.
Прежде чем маркетологи и прочие продажники анонсируют потенциальным заказчикам о новом решении, в первую очередь продуктовая команда прорабатывает возможность реализации данного решения в заданные сроки. Так называемая дорожная карта. Любое озвученное отклонение от дорожной карты, карается увольнением менеджера допустившего это.

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

Я понимаю случай с ПО для выставки, когда надо продемонстрировать хоть что-то и это лучше, чем ничего.
Но вот в случае с топовым телефоном не очень согласен. Если считать, что программист прав (agile подразумевает ответственную самоорганизующуюся и квалифицированную комманду)- и нужный софт делается за три месяца, то на рынок выведется очередной говнотелефон с глючным софтом, который повлечет за собой провальные масштабы продаж. Кто это считает?
Ну и вообще с точки зрения общества лучше бы, чтобы таких продуктов поменялось поменьше, но бизнес стремится к другому.

  1. В играх: новогодние, хеллоуиновые и прочие события. Специальный квест по поиску Санты нафиг не нужен в марте.
  2. В финансовой сфере: вся регуляторная часть. И прямо (к дате X должны быть внедрены фичи A и B) и косвенно (декларации НДФЛ интересны только с января по март). Похожая ситуация, когда внешний крупный вендор сообщил об изменении протоколов или снятии с поддержки текущего решения: тоже есть дедлайн на который повлиять невозможно.
  3. В рознице с сезонными пиками (Milfgard же писал): если автоматизация склада/логистики/розницы не сделана, то считай, что торопились зря и на этих праздниках попали и на оплату разработки и на разгребание без автоматизации. Может быть фатально.
  4. При заказанной и оплаченной рекламной кампании: если заказанная доработка критична для пропускной способности бизнеса. Реклама пойдёт, клиенты придут и… Ой.
  5. На самом деле похоже работают многие зависимости разработки от внешних контрактов: достроят завод, запустят в серию прибор и т.д. и т.п.
  6. Образование: Если не успеть разработать курс/продукт к началу учебного года, то придётся отложить как минимум на семестр.
  7. Безопасность: если есть архитектурная дыра и договоренности с white hat на 3 месяца до full disclosure.
UFO landed and left these words here

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


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

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


Если Вы имели в виду то, что зачастую менеджеры сильно преувеличивают критичность выхода на рынок именно через два месяца, а не, например, через пол года — то это правда. Они сами зачастую нифига не знают наверняка, паникуют и перестраховываются. Но! Именно они являются экспертами в этой области (бизнеса и рынка) — по крайней мере формально, и других экспертов всё-равно нет. Поэтому разработчикам ничего не остаётся, как принимать их оценку time to market, и исходить из неё, даже если она некорректная. Менеджерам ровно так же приходится принимать мнение разработчиков про разные фреймворки/ЯП/рефакторинг, даже если квалификации разработчиков недостаточно и они несут полную чушь — пока в команде нет других, более квалифицированных, приходится верить этим.


Если Вам кажется, что закрытие бизнеса (из-за срыва time to market) не является проблемой разработчиков, то у меня вопрос: какой смысл без спешки писать качественный код, если этот качественный код будет выброшен вместе с бизнесом ещё до того, как его увидят реальные пользователи? Может кому-то нравится, когда его работу выбрасывают, но мне — не очень. И качество кода важно только тогда, когда этим кодом кто-то пользуется.

Думаю, именно с такими мыслями в релиз выпустили последних Heroes of M&M, мир праху этой серии.
При этом, через месяца 2-3 в игру стало можно играть без консоли разработчика, но слишком поздно.
Подождите-подождите, есть же намного более яркий и свежий пример — Fallout 76 :) Спустя месяц после релиза уже делают скидки чуть не в половину цены, лишь бы купили. Но ТТМ наверняка был на высоте, да.
Несправедливость какая то)), на инди-песочницы выживалки, которые в раннем доступе и то меньше наезжали.
Инди-песочницевыживалки не позиционируют себя, как продолжения одной из лучших серий игр и отношение к ним соответствующее.

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

А самое главное потребители могут сколь угодно долго сидеть и питаться обещаниями если в конце они получат полноценное, законченное и понятное. Но стоит учитывать что терпение тоже имеет срок(HL3).

Ну так мы имеем классическую диллему проект-менеджмента — либо страдает качество, либо сроки, либо стоимость. Нельзя оптимизировать сразу все три параметра.
И Agile в этом смысле поможет ровно настолько, насколько умна и опытна команда разработчиков. Т.е. жизнь бизнеса начинает зависеть не от менеджмента, а от разработчиков. Попытка переложить ответственность, наверное.

UFO landed and left these words here
Вообще-то продукт «нужно запускать быстрее» только тогда, когда это действительно нужно, а TTM не является святым граалем, на который нужно равняться всегда и везде. Думаю, чаще ситуация как раз такова, что конкурента, который дышит в затылок прямо сейчас, нет и в помине, а появится он только тогда, когда продукт будет запущен, и все увидят, что эту грядку можно и нужно пахать. И вот тогда-то начнется гонка — в которой можно будет запросто проиграть, потому что нужно ехать, а у вас костыли. ТТМ бывает разным…
Прошу прощения, а чем Agile провоцирует «назвал сроки, завысил ожидания и возбудил аппетит.»? Если мне не изменяет память оценки complexity, ретроспективы, планирование спринтов, как раз и призваны сказать, какой будет срок от фичи до релиза с учетом capacity команды. Возможно я не так понимаю agile разработку?
Подход выглядит как противостояние с менеджером и понимание исполнения задачи как самоцели.

Иногда гибкость разработчика является дополнительной ценностью, которая продается или обменивается на взаимную лояльность.
Я вижу в этом манифесте много об удовлетворении программиста, но где же в нем про продукт и бизнес?

Устраиваясь на наемную работу за деньги, я ставлю во главу угла деньги, потому что получать удовольствие от программирования я могу и без найма.

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

Хорошо крутить носом перед работодателем и заказчиком, когда на одно резюме десять вакансий. А если бы было иначе?
А вы никогда не думали что наемный работник всегда будет на одной стороне, а работодатель на другой? Любой человек который любит свою работу будет хотеть делать ее качественно. Просто наемный работник отказывается от результатов своей работы в пользу работодателя, в связи с чем резко падает мотивация к этой самой работе. Именно этот недостаток agile и пытается устранить (помимо остального). Убедить вас в том что ценности работодателя это и ваши ценности тоже (хотя это не так).
А вы никогда не думали что наемный работник всегда будет на одной стороне, а работодатель на другой?


Нет, не думал. Ведь наличие денег у работника определяется наличием денег у работодателя. Работнику не очень то выгодно банкротство работодателя, ведь так?

Убедить вас в том что ценности работодателя это и ваши ценности тоже (хотя это не так).


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

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


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

</сарказм
Ведь наличие денег у работника определяется наличием денег у работодателя. Работнику не очень то выгодно банкротство работодателя, ведь так?

«Стокгольмский синдром»?

Нет, это из другой оперы: не будь мудаком.


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

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

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


Мы сами должны уметь организовать свою работу так, чтобы и задачи работодателя выполнять, и удовлетворение от работы получать. Если не получается — надо либо учится это делать, либо менять работу. Ждать, что работодатель будет бегать вокруг разработчиков с охами и ахами, и каждый день интересоваться, получаем ли мы удовлетворение от работы, и чем он может помочь если мы вдруг его перестали получать — даже не знаю, как это назвать, слово "наивно" как-то слабо смотрится в этом контексте.


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

Ждать, что работодатель будет бегать вокруг разработчиков с охами и ахами...

О том и публикация, что надо не ждать, а идти и разговаривать. А если понадобится — требовать. Права — они такие. Пока не потребуешь — не отдадут.

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


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

Стандартный пример — разработка прототипа. Категорически несовместима вообще ни с чем из этого манифеста.

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

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


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


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


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

Спасибо, теперь понятно, в чем мы расходимся.
Я-то всю сознательную трудовую жизнь считаю, что концепция вырабатывается (и объясняется исполнителю!) еще до начала работы руками. Прототип начинают делать после того, как определились с концепцией. Т.е. «автомобиль с рулем под капотом», с учетом вашей поправки, это и есть концепция = условие задачи = «как надо». Если разработчик понимает, что заказчику нужна киллер-фича, то результат будет такой, какой нужен заказчику. А если разработчик не понимает смысла того, что от него требуют, то результата может не быть вовсе (руль будет где просили, но авто ехать перестанет, например).

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

И еще одно разночтение: Качество кода важнее скорости его написания. Я всеми руками за то, чтобы разработка велась максимально быстро, но не в ущерб же качеству кода! А то как в анекдоте: «Я печатаю со скоростью 600 знаков в минуту. Тааакая фигня получается!»

Хорошо, что Вы что-то поняли. Плохо, что я, наоборот, запутался: объясните тогда, пожалуйста, как при Вашем подходе отличается разработка прототипа проекта от разработки самого проекта? Или они у Вас не отличаются никак — для разработки обоих должна быть заранее определена концепция, код пишем одинаково качественно (и, соответственно, с одинаковой скоростью), если новые изменения противоречат архитектуре мы её перепроектируем, сопровождаем код тестами и документацией… всё верно?

Терминология иногда заводит в дебри. Мы не разрабатываем прототип проекта, мы делаем прототип продукта.
Если новые пожелания заказчика противоречат готовой архитектуре, то заказчику следует подробно разъяснить проблему. Хорошо проинформированный заказчик обычно не склонен ломать несущие стены.

В данном контексте я рассматриваю проект и продукт как синонимы. Прототип проекта/продукта — это нечто, что выглядит похожим на требуемый проект/продукт, но не предназначено для использования реальными пользователями. Прототип разрабатывается для того, чтобы заказчик смог "пощупать" проект/продукт задолго до момента, когда реально выпустить полноценный проект/продукт. И причина, по которой заказчику дают его "пощупать" — чтобы он мог сообщить о необходимости сломать несколько несущих стен на этом, раннем этапе разработки, когда стены полноценного проекта/продукта ещё никто не возводил. Мне действительно необходимо разъяснять что такое прототипы и зачем они нужны, или Вы всё-таки ответите на вопрос?

Так ответ сообщением выше: мы не разрабатываем прототип проекта, мы делаем прототип продукта. Для меня проект и продукт даже близко не синонимы. Проект (со всеми его подготовительными и промежуточными фазами) — это лишь способ решения, а вовсе не ответ на поставленную задачу. Я не вижу смысла разрабатывать проекты ради разработки проектов. Вы — видите.
В этом наше с вами ключевое/концептуальное различие, и именно поэтому лезть дальше в дебри терминологии смысла нет.
Если вам надо проверить красящую ленту на износостойкость а механизм машинки на ресурс — 600 знаков самое то!
UFO landed and left these words here
Простите, всегда считал что прототипы строятся для демонстрации/проверки концепции. А в приложении уже прорабатываются детали. По результатам прототипирования концепция может поменятся. Но не во время построения конкретной версии прототипа. Как-то так.

:) А что, по-вашему, происходит, когда прототип накидали, пощупали, и решили что концепцию надо подправить? Эта новая концепция сразу уходит в разработку приложения? (Подсказка: нет.) Мы начинаем писать новый прототип для проверки новой концепции? (Подсказка: не совсем.) Ура! Вы угадали (надеюсь)! Мы быстро-грязно фиксим первый прототип под изменения концепции. И потом ещё не раз повторяем этот цикл. В полном соответствии с заветами не самого приятного варианта аджайла.


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

Охоспади, какие такие права у вас отобрали?! Ну правда, напишите что-ли уже хоть что-нибудь более конкретное, чем «я дерусь, потому что дерусь».
Нет, не думал. Ведь наличие денег у работника определяется наличием денег у работодателя. Работнику не очень то выгодно банкротство работодателя, ведь так?


Эти вещи совсем слабо связанные. Кому то выгодно чтобы предприятие закрылось. Можно получить компенсацию и найти работу получше. Кому то все равно т.к. работник хочет уйти на другую работу. С другой стороны обратное тоже не верно. Если у работодателя деньги есть он не обязательно ими делится с работником например делая разного рода вычеты (а иногда даже нарушая трудовой договор). Не надо думать что все поголовно сидят и трясутся за свое рабочее место.

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


Тоже не совсем верно. Люди вступают в трудовые отношения чтобы обеспечить свое существование. Многие люди при достижении определенного уровня доходов с радостью бы их поменяли на более интересную и общественно значимую работу. Оттуда и разница в ценностях. До уровня базового содержания они у всех одинаковые. А потом начинают расходится.

Хм, очень спорный момент. Работодатель ведь не просто отнимает результаты труда. Работодатель покупает их. Соответственно если у работника нет мотивации давать результат, то у работодателя нет мотивации платить деньги.


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

Это с вашей точки зрения справедливо?

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


А будет ли работа лучше, если у нового работодателя не будет денег? Взгляните на картину целиком, мы ведь говорим концептуально, а не об одном специфическом примере.

Тоже не совсем верно. Люди вступают в трудовые отношения чтобы обеспечить свое существование. Многие люди при достижении определенного уровня доходов с радостью бы их поменяли на более интересную и общественно значимую работу.


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

Трудовые отношения — это отношения ради денег и никак иначе. Для человека, который вступает в трудовые отношения деньги являются ценностью.

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

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


Я подореваю у вас коммунистические взгляды?
А будет ли работа лучше, если у нового работодателя не будет денег? Взгляните на картину целиком, мы ведь говорим концептуально, а не об одном специфическом примере.

А что будет если ни у кого не будет денег чтобы платить зарплату? вот тогда мы все с голоду и умрем.

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

У бизнеса ценности меняться не могут. Там только одна ценность это зарабатывание денег. Иначе бизнес быстро перестанет быть. Не путайте личность бизнесмена и его бизнес. Да и опять же ценности даже великих изобретателей (без шуток) быстро превращаются в жутко ретроградный луддизм при намёке на то что бизнес может перестать быть

А что будет если ни у кого не будет денег чтобы платить зарплату? вот тогда мы все с голоду и умрем.


Да, такое уже бывапо в истории.

У бизнеса ценности меняться не могут. Там только одна ценность это зарабатывание денег. Иначе бизнес быстро перестанет быть. Не путайте личность бизнесмена и его бизнес.


Конечно я имел в виду работодателя, человека.
Ведь наличие денег у работника определяется наличием денег у работодателя.


Ох, спасибо, хорошая шутка.
Нет, я не одобряю работу спустя рукава, но наличие денег у работодателя однозначно определяет только наличие денег у работодателя.
Вы подменили высказывание и получили ложную дилемму. Сравните:
А: Наличие смеха определяется наличием комической ситуации. (истинно)
Б: Наличие комической ситуации однозначно определяет только наличие комической ситуации. (тоже истинно)
Оба высказывания истинны, но высказывание Б никак не противоречит высказыванию А.
Над чем смеялись-то?
Гм. Есть такое понятие — условие истинности чего либо.
Условия бывают необходимыми, а бывают достаточными.

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

Я все таки настаиваю на том, что программист должен знать логику.
При том, что я не могу не согласиться с вами по поводу классового противоречия (хотя и не думаю, что оно будет существовать всегда), но «качественно», во-первых, не тождественно понятию «идеально», однако практически всегда идёт совместно со словами: "… и в срок". Задача работника — выполнять работу качественно и в срок. А не идеально, и когда получится.
(хотя и не думаю, что оно будет существовать всегда)

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

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

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

Как я понял этот манифест указывает своей целью выпуск качественного ПО.

И да манифест явно указывает на известные всем проблемы.
Однако видно, что сам автор явно еще не разобрался, что в 95% случаев программист даже близко не понимает проблемы бизнеса.

Так что мой ему совет, для начала найди работу как постановщик задач, затем как внедренец (хорошо бы еще побывать в роли хозяина/заказчика ПО). И вот тогда у тебя будут знания по всем ролям и после этого манифест будет куда более полным.
Я бы посоветовал автору просто ознакомится с биографиями и опытом людей которые сформулировали Agile манифест…

Спойлер
… Я уверен, там внезапно могут оказаться разработчики со стажем большим чем возраст автора.
Безотносительно статьи. Это не отменяет случая с плохой аргументацией. Если есть что сказать надо указывать на конкретные проблемы. А не прикрываться авторитетами. А то так получится что самый умный тот у кого борода до колен.
Сорри, но проблема у автора одна — либо недостаток *личного* профессионального опыта работы в хорошей команде, либо неумение свой опыт обобщить, либо общая озлобленность на взаимодействие с бизнес-частью разработки ПО (не повезло с коллегами, тоже бывает).
… недостаток личного профессионального опыта работы в хорошей команде, либо неумение свой опыт обобщить, либо общая озлобленность...

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

Но предпочёл бы всё-таки аргументацию.

Я вам в своей ветке комментариев всё аргументировал, а вы в каждом ответе отмахиваетесь общими утверждениями.

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

Личный опыт показывает, что в большинстве «проектов» — такое дерьмо внутри, что мама не горюй. На качество времени нет, ибо «бизнес же платит, бизнес и танцует». Какой-то фетиш из «бизнеса». Нужно поднимать профессиональный уровень программистов. Нужно у программистов повышать уровень самооценки (с повышением профессионального уровня). Любой мастер своего дела (неважно кто, например, портной), должен уметь сказать заказчику (клиенту, «бизнесу»), «не, я так делать не буду, так делать — себя не уважать и иди ты лесом, если ты требуешь, чтобы я к понедельнику это сделал» (я ведь знаю, что к понедельнику я это качественно сделать не смогу, а если сделаю, то это будет «дерьмо», за которое я себя не буду уважать, как профессионала).
Что-то совсем уже тошнит от «проектов» с которыми последнее (и не последнее) время приходится сталкиваться, как там все внутри…
«Давайте спорить о вкусе устриц с теми кто их ел»
Слышали такое выражение?
Чтобы утверждать, что дерьмо есть не надо, надо обязательно его вкусить?
UFO landed and left these words here
Подумал ещё. Иметь право быть «жёстким» программистом надо заслужить десятком средне-крупных проектов, сданными более-менее в срок с удовлетворяющим все стороны качеством. Тогда тебя будут слушать, зная, что ты не дрочишь на код, а реально решаешь проблемы и «знаешь лучше».

Для этого недостаточно задекларировать эти, в общем-то, имеющие право на существование принципы.
Не согласен. Именно потому что жуниоры привыкают лепить костыли на котылечки, из принципа может прокатит, а если нет то всегда можно сказать «а вы так не хотите — ну тода я переделаю, я думал что надо как быстрее», мы наблюдаем этот горький катаклизм. Каждый жуниор когда нибудь будет имет десяток проектов за плечами, но захочет ли сменить подход — не обязательно. Зачем ему это, когда можно стать продактом, и так же ездить на таких же «мягких программистах»?
Ну дык сениоры-то откуда берутся, ими не рождаются, вообще-то.

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


Сеньорам комфортно работать с задачами, которые они не знают, как решать. Они в состоянии, что называется, "решить проблему". Любую. Просто берут на себя ответственность, разбираются в вопросе, и решают. Сеньоры часто не знают или не помнят мелкие детали устройства конкретных фреймворков, но зато они хорошо понимают принципы устройства этих фреймворков и могут быстро найти решение проблемы на незнакомом им фреймворке, которое не в состоянии найти мидл, вроде бы хорошо знающий данный фреймворк. (Вместо "фреймворк" здесь можно подставить что угодно — ЯП, ОС, утилита, сетевой протокол, ….)


Мидлы же предпочитают работать в знакомых условиях, писать типовые задачи на одном и том же, хорошо им знакомом ЯП, с использованием фреймворка, который они детально изучили… и не очень любят переучиваться на использование новых инструментов и подходов — хотя и делают это довольно регулярно, в IT без этого не выживешь.


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


Стоит ещё добавить, что я не считаю сеньоров более "крутыми", чем мидлы. Крепкий мидл знает используемые им инструменты намного глубже, чем когда-либо их узнает сеньор. Я не считаю, что зарплата мидла обязательно должна быть ниже зарплаты сеньора — и мидлы и сеньоры бывают очень разные, и пользу проекту приносят тоже разную. Я считаю, что среднему проекту мидлов обычно нужно больше, чем сеньоров. В общем, мидлы для меня не являются разработчиками "второго сорта". Люди разные важны, люди разные нужны — всё зависит от задачи.


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

Вспомнилось из литературы…
Помните что сказал Кристобаль Хозевич Хунта? «Бессмыслица — искать решение, если оно и так есть», в то время как настоящей проблемой будет — «как поступать с задачей, которая решения не имеет».
А прекрасное описание „сеньора“ — Чапаев из „Практикантки“ Каменистого.

Не помню, надо бы перечитать. Помнится, когда-то было жаль, что он эту серию не продолжил.

Как всегда не додумал мысль.
«Сеньорам комфортно работать с задачами, которые они не знают, как решать. Они в состоянии, что называется, „решить проблему“. Любую. Просто берут на себя ответственность, разбираются в вопросе, и решают. » Вот прямо таким Чапаев там и нарисован.
Вы сейчас буквально сказали следующее — выживают те, кто имеет к этому способности. Это нормальный закон эволюции, и я с этим не могу спорить, Вы правы. Вопрос же в статье стоит так, нужна ли нам такая среда, чтобы люди выживали с такими способностями — делать быстро, в ущерб качеству, и перетягивая при этом ответственности с бизнеса на себя. Кратковременные выгоды этого подхода перечеркиваются долговременными последствиями как на индивидуальном уровне, так и на уровне проекта, и даже на уровне индустрии в целом, возможно, в чем я не уверен, время покажет.
powerman выше хорошо описал.

у нас в компании с легкой руки СТО одно время было понятие «перспективный джуниор». туда относились все кандидаты, которые имели менее 8 лет опыта работы в необходимом для проекта стеке, но показали хорошие знания в фундаментальны вещах из computer science (алгоримты и сложность, структуры данных, многопоточность и параллельная разработка — обуславливалось особенностями проекта, Big Data и highload).

возможно, «перспективный джуниор» звучит обидно, но после нескольких лет работы с командой, где средний стаж составлял 10 лет
в дополнение
к вышеуказанным требованиям, понимаешь, что вот это — действительно senior.
Да я согласен. Проблема в том что такой перспективный джуниор, однажды попавший в ситуацию, когда на него кладут всех обезьян, и по срокам, и по стеку, просто лишний раз подумает, а оно мне надо и пойдет не в крепкие мидлы-сеньоры, а куданибудь еще. Буквально вчера говорил с товарищем из Майкрософт, которому осталось до принципал одну ступень. Он говорит — а оно мне надо? Низы уже не хотят, а верхи не могут, знакомая ситуация, да.
Люди написавшие Agile манифест, признанные во всем мире IT профессионалы. Это люди которые сделали огромный вклад в индустрию. Приведенный же автором манифест звучит просто смешно на этом фоне. За Agile манифестом стоят десятилетия опыта совершенно разных людей, в разного размера компаниях, в разные времена и в различных условиях. А что стоит за манифестом автора, кроме юношеского максимализма? Сколько книг написал автор прежде чем сформулировать данный манифест? Сколько успешных проектов запустил? Сколько не успешных похоронил? Сколько написал научных работ? На скольких конференциях выступил?

Уйдите дальше русскоязычного перевода этого манифеста. Почитайте вообще кто эти все люди (https://agilemanifesto.org/authors.html). Потому что доводы описанные выше звучат ну просто смехотворно. В оригинальном манифесте на каждый пункт чуть ли не книга написана, а часто и не одна. И в кучах источников в подробностях раскрыта суть каждой фразы. А тут что? Отсутсвует даже базовое понимание Agile манифеста и практик которые за ним стоят.
Вы, возможно, правы по сути, но это чистой воды Argumentum ad verecundiam. Нельзя говорить что автор не прав, потому что не написал ни одной книги, или о нем никто не знает. Марсельезу тоже не Бетховен написал, знаете ли.
Прежде чем сформулировать манифест, данные люди делали разнообразные продукты, в разнообразных всем известных во всем мире компаниях, изучали компьютерную науку, программировали, писали книги и научные труды.

Только после этого, набравшись опыта, наломавши дров, создавши и убивши не один и не два проекта, они сформулировали этот манифест.

Автор же пришел и просто сказал (даже не удосужившись вникнуть в манифест): Весь ваш опыт — фигня. Все что вы предлагаете — отстой. Вот вам мой манифест.
Какая-то нездорово болезненная реакция на сатирическую статью.

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

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

Эти эпитеты у меня родились именно потому, что мнение автора ассоциируется у меня с собирательным образом многих программистов (в основном мало опытных) которых я на своем пути встречал. Личности я не обсуждаю. Я не знаю лично автора, его возраста, его опыта, я сужу исключительно по высказываниям и исходя из личного опыта подобного общения.

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

Приношу искренние извинения автору.

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


Что касается возраста, я воззываю к опыту и вкладу. Вы отличаете возраст от опыта?
Возраст не имеет ровным счетом ни какого значения. А опыт и вклад в отрасль безусловно имеет.

Какой опыт автор данного манифеста может противопоставить авторам Agile манифеста? Пока что я не увидел ни одного весомого аргумента.
Пусть автор покажет свои статьи, свои книги, свой код, свои научные изыскания. Хоть что нибудь кроме IMHO и откровенного троллинга? Не говорите только что троллинг — это такая высокоинтеллектуальная сатира.

Что, видимо, должно заставить почувствовать жуткую неполноценность, ведь он старше, и пороха, вестимо, больше нюхал!

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

Но пока что, все что я вижу, это то, что у нас с автором просто абсолютно разная система профессиональных ценностей, не смотря на то что и он и я программисты. И если моя система ценностей построена по мимо собственного опыта еще и на опыте индустрии (или как вы говорите «авторитетов»), то на чем построена система ценностей автора, кроме imho я понять пока не могу
Я, пожалуй, ещё раз повторюсь, что это настолько очевидная сатира, что для её непонимания нужен, видимо, особый склад ума. И уж как можно было воспринять мой комментарий про порох всерьёз, для меня вообще загадка. Это даже не тонкий сарказм, а открытый предельно простой юмор. А столь бурную реакцию даже не знаю, как объяснить, не может же вся жизнь быть завязана на Agile, на какой-либо другой методологии, да и на работе вообще.

Опять же напирание на авторитет. Мало того, что это шаблонная ошибка аргументации, так ещё и вот о чём стоит задуматься: если авторы этого манифеста занимают высокие управленческие должности, это говорит о них как о хороших управленцах, но ничего не говорит о них как о программистах.

P.S.: Вот это просто пушка, тут всё: и обида на сатиру, и «сперва добейся», и очередное воззвание к авторитету (они же книги писали!), и калька/перевирание моего указания на «интеллектуальность» аргументов:
Пусть автор покажет свои статьи, свои книги, свой код, свои научные изыскания. Хоть что нибудь кроме IMHO и откровенного троллинга? Не говорите только что троллинг — это такая высокоинтеллектуальная сатира.

Троллинг — это когда пытаются вызвать такую реакцию, как у Вас. Тут никто не пытался, все хотели по-доброму посмеяться, что и сделало большинство комментаторов. Заодно находя в шутке долю истины. Но нет, кому-то просто жизненно необходимо развести срач. И кто ещё здесь троллит?
Обида, бурная реакция, что то там еще… :D
Вы как мои эмоции прочли? Вы экстрасенс? Мне, как и вам не чем заняться вечером, вот и все. Завтра я проснусь с утра и пойду кататься на горных лыжах, после обеда сяду программировать и забуду про этот ваш манифест и весь этот пост и спор… :) Я абсолютно равнодушен и спокоен, поверьте. Я даже не одного плюсика/минусика не ткнул за всю беседу :)

programming-motherfucker.com — вот к слову более удачная шутка и отличный манифест.… и еще там 6 отличных книг. Сразу видно, автор знает о чем шутит ;)
Ну если обиды не было, тем лучше для всех. Объём ответов удивил (да и содержание частично тоже) и навёл на такую мысль.
Глупости какие-то пишите. Неужели думаете, что автор не согласен с тем, что исполнитель должен делать свою работу? Думаю, тут никто не спорит, что если была достигнута определенная договоренность между заказчиком и исполнителем, то эта договоренность должна соблюдаться.
«Манифест» не про то, что «не буду себя связывать обязательствами, буду делать что хочу, по своему капризу». «Манифест» про другое. Про то, что есть определенные технологические требования (ограничения), которые должны соблюдаться. Что на это надо обратить сугубое внимание, ибо из-за фетиша «БИЗНЕС», часто происходит наоборот. В угоду «удовлетворения капризов 'бизнеса'» часто страдает качество продукта.

И, действительно, не понятны эти «эджайлы». Например, то, что надо на совещаниях не «лить воду», быть конкретными и не затягивать эти совещания, так при чем тут «эджайл»? Это ведь при любом техпроцессе, в любой отрасли, является просто деловой этикой. Зачем тут придумывать «проводить мининги сугубо строго стоя?».

Другая сторона. Вовсе не обязательно рассматривать эту статью, как противопоставление «программисты» <-> «менеджеры». Ее можно рассматривать, против самих «программистов». Только против тех, кто жертвует качеством продукта.
Я вот тоже знаком с автором лично и специально уточнил у него: «Сатирой это назвать сложно.»
UFO landed and left these words here
UFO landed and left these words here
извините, что влезаю, но судя по комментариям в статье, тут вообще уже ничего никого не смущает))
Меня не смущает. Я читал их книги, а вы?

Могу с уверенностью сказать, подходы и методы которые в них описаны работают. Принципы которые там высказаны работают. Возьмем те же SOLID принципы (Принципы которые должен знать каждый Junior вышедший из ВУЗа). Вы же не станете утверждать что они глупы и не имеют практического смысла?

Эндрю Танненбаум, Денис Ритчи, Брайан Керниган, Линус Торвальдс в конце концов. Вы серьезно считаете всех этих людей самозванцами или как? Я не могу понять.

Вас не смущает что Хоккинг не летал в космос? Вас не смущает что Братья Райт не построили ни одного аэробуса?

Объясните почему меня должно что-то в этих людях смущать? Если я прочел их труды и использую описанные в них подходы на практике. Причем до некоторых вещей я дошел еще до ознакомления с их трудами.

Что плохого в том, чтобы перенимать опыт лучших представителей отрасли? Если не у них, у кого вы предлагаете учиться? Или может вы предлагаете отбросить все что было сделано или написано до и изобретать все с нуля? И так каждый раз? Во всех областях?

Я вообще посыл автора и его манифеста вижу реально как то вот так:
«Так называемый» Деннис Ритчи, изобрел «так называемый» язык Си. И многие его приняли. Но лично для меня это выглядит как шутка, которая затянулась.

Компьютеры исполняют исключительно машинный код, а все эти ваши Си изобретены самозванцами и они уничижают права одной группы (компьютеров) по отношению к другой группе (людям)
UFO landed and left these words here
Даже если в их книгах есть здравые мысли (а они там есть, я читал),

Назовите конкретно, какие книги вы читали, и какие конкретно практики не применимы или приводят к большим проблемам?

И когда человек зарабатывает деньги не кодом, а конференциями, возникают обоснованные сомнения в их, скажем так, близости к реальной разработке.

Это вы решили что они кодом ни когда не зарабатывали? Большинство из них начинали свою карьеру программистов в 70-80-тые. А их пик карьеры как разработчиков приходится на 80-90тые. Или для вас авторитетом является только тот кто всю жизнь на должности миддла просидел?

А при чем тут эти люди? Они создали Agile Manifesto? Они как раз намного больше сделали, чем наговорили, в отличие от.

Вы заблуждаетесь, просто эти люди создавали инструменты для разработчиков. Поэтому их работу вам видно. А те кто сформировал Agile создавали продукты и программы для бизнеса. Но и те и другие являются признанными во всем мире профессионалами. И те и другие сделали огромный вклад в индустрию. Просто в разные ее области. А мы сейчас тут говорим как раз о разработке и бизнесе.

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

Хорошо. По вашей логике: — Я что-то сомневаюсь что вы вообще программист и имеете какой то отношение к IT. Мне кажется вы в своей жизни вообще ни одной программы не написали. Ведь я их нигде не видел. И показать вам нечего.

С чего вы взяли, что они лучшие?

Их вклад в индустрию признается IT сообществом в лице сотен тысяч профессионалов а так же в лице крупных технологических компаний таких как IBM, Intel, Microsoft и т.д.

Что они сделали? По сравнению с перечисленными выше Торвальдсом и компанией — ничего.

Это смешно. Компания людей выше в комментарии, она про технологии. Поэтому их работу видно. Компания из Agile манифеста — про программистов в бизнесе. Это не умоляет ни как того что они сделали для индустрии. Сотни тысяч разработчиков каждый день пользуются архитектурными и другими паттернами которые они сформулировали, пишут тесты в соответсвии с методологиям которые они разработали, проектируют программы в соответсвии с принципами которые они предложили, выпускают успешные продукты в соответсвии с методиками которые они предложили. Причем многие из них об этом даже не подозревают, потому что информацию черпали не из первоисточника а из перепечаток, статей, и т.д. и т.п.
UFO landed and left these words here
Будьте добры ответить на конкретно поставленные вопросы. Давайте поговорим конкретно, без абстракций и отсылки к умным терминам. Я как минимум 3 конкретных вопроса задал. Вы не ответили не не один.

Считать их по умолчанию непререкаемыми авторитетами на основании того, что какое-то число кого-то там их «признало», они написали кучу книг и бла-бла, до такой степени, что приводить их в дискуссии как ad hominem — это хреново.

Что касается меня лично, то я считаю их авторитетами, потому что я прочел ряд их книг и осмыслил их критически, после чего применил знания на практике. Я убедился в том, что методики этих ребят работают и помогают делать продукты.
Именно поэтому я нахожусь в числе кого-то там кто их «признал». С чего вы взяли что я их признал «по умолчанию», просто потому что их признали остальные я ума не приложу. Вы сами себе выдумали это? Вам не приходит в голову что эти «какое-то число кого-то там», так же читали их книги, критически их осмысливали и применяли подходы на практике? Другие «кто-то там» нанимали их на работу и видели их результаты. И так далее.

Если есть способ сделать как то так чтобы вас начали признавать «по умолчанию», расскажите его пожалуйста?

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

Откуда такие выводы? Kent Beck например работает сейчас в Facebook… И да, мне вас искренне жаль, если ваш потолок в карьере — рядовой Senior разработчик. Потому что все что выше (в любой ветке развития IT специалиста будь то менеджерская ветвь или техническая) в любом отношении предполагает что 80% времени вы будете отнюдь не код писать. Если верить вашим взглядам, любой разработчик доросший до уровня выше Senior, через пару тройку лет теряет связь с реальностью. Но вот реальность такова, что этим потерянным людям ни чего не мешает создавать и выпускать успешные продукты, в отличие от рядовых программистов которые пишут код ради кода и меняют работу каждые пол года при этом не выростая никуда по карьерной лестнице.

Ну, вот например я вырос, и уже много лет трачу значительную часть времени не на код, а на общение, обучение и написание документов. Тем не менее, я согласен с тем, что если код не писать, причём минимум 30% времени, то любой крутой архитектор/principal за 4-5 лет превращается в тыкву. Если работать на более менеджерской и менее технической позиции вроде PM/CTO, то без написания кода вполне реально сохранить квалификацию для своей должности, но нормальным разработчиком при этом быть перестаёшь.

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

Кстати странно получается. Вы сейчас зарабатываете жизнь не программированием, при этом говорите о том, что приведенные выше люди далеки от реальности потому что зарабатывают не программированием? :D Очень логично. Но вы же один из этих людей так или иначе. Из тех зазнавшихся дядек что оторвались от реальности.

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


Иногда для этого требуется побыть бизнес-аналитиком и помочь заказчику понять, что проблему нужно решать вообще не разработкой изначально заказанного софта, а как-то иначе. Почти всегда архитектором, спроектировать необходимую систему, разработать API и написать про всё это кучу документов. Почти всегда тимлидом, техлидом или простым сеньором, занимаясь обучением, ревью, или написанием значительной части проекта самостоятельно. Иногда даже немного девопсом, потому что мне для комфортной работы нужен надёжный и быстрый конвейер CI/CD и безопасно настроенные сервера, и не всегда есть кому это поручить. Совсем редко проджект менеджером, как-то раз даже продакт овнером — но это уже не совсем "моё", предпочитаю чтобы этим занимался кто-то другой.


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


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


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

Тогда я не понимаю о чем мы спорим? Потому что я занимаюсь ровно тем же что и вы. И делаю ровно все то же самое что вы описали в первых 3-ех абзацах… :D
И Agile подходы, а так же рекомендации тех людей о которых идет речь мне в этом больше помогают, чем мешают. При чем и когда я пишу код и когда работаю с людьми. Не все там идеально, да. Но я и не говорил нигде что Agile идеален.

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

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

А! До меня, похоже, дошло, на что Вы так резко отреагировали. На "… но нормальным разработчиком при этом быть перестаёшь", да?


В случае PM/CTO я не вижу в этом ничего плохого, и упомянул это исключительно потому, что многие крутые разработчики действительно любят писать код, но ещё они любят зарплату по-больше и должность по-круче. И им кажется, что они могут быть PM/CTO, и при этом продолжать писать код, поскольку им нравится писать код. Так вот — это им только кажется, на практике это совмещать практически нереально (если не брать мелкий стартап, где 2-3 разработчика и один из них, по совместительству, ещё и CTO — пока стартап мелкий CTO ещё будет писать код, но как только команда вырастет времени на это уже не останется).

До меня, похоже, дошло, на что Вы так резко отреагировали

До меня только сейчас дошло, что я вас перепутал с s-kozlov, которому мой ответ и предназначался на на который ответили вы вне контекста спора :)
Даже здесь на Хабре 90% статей по архитектуре ПО, тестировании, разработке enterprise приложений, паттернам — это перепечатки/переводы/интерпретации трудов именно этих людей которые «ничего не сделали». :D
UFO landed and left these words here
Код они писали еще до того как многие из нас родились, а многие познакомились с компьютерами. Вас это настораживает?
Продукты в которых они так или иначе поучаствовали вы используете чуть ли не каждый день, потому что их привлекают к работе мировые лидеры IT отрасли. Продуктами этих компаний вы каждый день пользуетесь.
Читайте больше книг IT тематики, а не Википедию и низкопробные статьи в интернете. Там информации куда больше. Если бы вы их читали, вы бы знали в каких компаниях эти люди работали, код каких продуктов писали и т.д.

Иногда складывается ощущение что я веду дискуссию с плоскоземельщиками. Потому что доводы они приводят именно такие «Я не видел что она круглая, а все что описано в официальных источниках — заговор». То что вы чего то не видели говорит только об уровне осведомленности.

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

Для многих программистов в особенности у нас в СНГ Стив Джобс и Билл Гейтс гениальные программисты :D А о том кто такой Денис Ритчи или Дональд Кнут они вообще не знают… Если они о таких мастодонтах не знают ничего, откуда из знать о Фаулере, Бэке или Мартине (Они все таки более узкие спецы).
Код они писали еще до того как многие из нас родились, а многие познакомились с компьютерами. Вас это настораживает?

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


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

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

А кто эти современные подходы собственно сформулировал и первым применил на практике? Я вам отвечу. Они и сформулировали, они и применили. А потом формализовали в виде книг и статей, чтобы менее опытные программисты не переизобретали велосипеды…

Каждый профессионал в своей жизни проходит через несколько стадий:
1) Обучение
2) Наработка опыта
3) Передача опыта следующим поколениям

Все эти люди находятся на стадии №3. Вот и все. Вы можете им не доверять, вы можете их отрицать, вы можете переизобретать велосипеды заново. Объективной реальности это не изменит.

Некто может как никто другой в мире уметь обрабатывать дерево киянкой и долотом, но обязаны ли мы поэтому считать его непререкаемым авторитетом в современной столярной мастерской? А если учесть что этот мастер в последний раз работал с деревом десять с гаком лет назад, а потом «профессионально вырос» до руководства другими людьми?


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

По Agile сформулированному Бобом Мартином работают куча передовых IT компаний среди которых Apple, Google, Intel, IMB, etc.
Паттерны Enterprise приложений Фаулера используют в разработке корпорации и банки по всему миру.
Подходы TDD разработанные Кентом Бэком используют множество компаний где важно качество продукта и его стабильность.

Вы можете называть этих людей самозванцами и ставить под сомнение их подходы сколько угодно, это не отменит объективной реальности, хотите вы в нее верить или нет.
Разработать матмодель ПО;
А если ПО основано на эвристических алгоритмах? ;)
Увы, знаком с некоторыми «жёсткими программистами», которые применяют этот манифест на практике. Это чистой воды саботаж бизнеса, ловко прикрытый потоком технических терминов.

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

Но самое страшное то, что они выступают с докладами на крупных конференциях и с гордостью рассказывают о своих «достижениях», распространяя хайп.
Вопрос в том, чего хочет бизнес?
Если без ТЗ, вчера и бесплатно — то это проблема бизнеса и «бюджеты и сроки раздуваются на порядки»
Если программисты постоянно не укладываются во вменяемые ТЗ без форс-мажоров и предрелизных правок типа «завтра сдача лифта, сделайте, что он не только вверх-вниз ездил, но и вбок, это же несложно. Ну а ТЗ? возьмите на вертикальный лифт и просто поверните, там одинаково» — меняйте программистов.
PS простите, но ни разу не видел, чтоб на крупных конференциях вставал руководитель компании и говорил «докладчик растяпа и хайпожор, всё сделал плохо, бизнес страдает и его выгнали как кота на улицу. Не верьте его словам»
В моем примере бизнес относится к разработке очень лояльно, доверие к разработчикам практически безгранично. На мой взгляд, отчасти в этом и проблема. На такой почве «жёсткие программисты» начинают паразитировать, ставя свои личные цели во главу угла совершенно забывая про цели бизнеса.
Описанную вами ситуацию на конференциях тоже не встречал ни разу. Как минимум, потому что она неэтична. Ну и вроде как не принято в IT «выгнонять как кота на улицу». Даже если принято решение расстаться, все равно обычно стараются расстаться миром.
Второй говорил Командиру в полёте —
''Я зачитал Руководство до дыр!
Но, чтоб я ни делал, Вы только орёте!''
''Ты делай как надо!''- Сказал Командир…

Горькая правда жизни в том, что подавляющее большинство имеющегося ПО не нужно было даже начинать разрабатывать, не говоря уже о качественной разработке. А около того ПО, что действительно нужно, уже есть регулятор от государства и УК.

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

Поэтому совершенно без издёвки предлагаю Вам заняться важными штуками, где от косяков могут люди погибнуть, и где думать поэтому надо сильно до. Больше хороших штук появляется от запиливания хороших штук, а не от запиливания хороших манифестов.

Практически со всем согласен. Однако, призыв тут не "Сразу Всё Делать Правильно", а совсем другой.

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

Цирк с понями можно устроить из произвольного манифеста, не только из agile. Agile вообще нормальный, если себя в руках держать, а не буквально понимать, что там написано. Только ведь в таких условиях всё нормальное.
Стандарты все же есть, для каждой области свои, но так или иначе есть. Для ракеты пво одни, для космоса другое, для томографа третье, для веба четвертое, для банка пятое.
А вот архитектура, вот ее «хорошесть» — определяется более просто, Архитектура — это субстанция, которая завязана на «бизнес-процессы», которые в свою очередь могут очень быстро меняться, а могут годами быть жестко регламентированными (например законодательством). Поэтому, я считаю, что «хорошая архитектура», это прежде всего та, которая построена на хорошем и глубоком анализе бизнес-процессов.

Помните «метод бумажных карточек ограниченного размера»? Помните «сформулируйте, свои пожелания короткими предложениями не больше 5 слов?» Нудно долго итеративно…

А сейчас ведь как модно, быстро пара совещаний, копи-пасте с другого проекта, 2..3 «фреймоворка-на-слуху» на выбор… коммерческое предложение и вперед шашки наголо, пока бизнес не передумал.

Расскажите этот манифест своим конкурентам, которые начнут продавать свой продукт пока вы делаете мат. модель. А на вырученные деньги потом купят Вас и Вы им уже сделаете как надо.

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


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

Ну, тогда, глупо сравнивать сей манифест с гибким. Ибо agile таки про то, как сделать хорошо типовому бизнесу а не Вам лично или какому-то гипотетическому инженеру в вакууме.


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

Кто будет нанимать такие команды

Кто будет нанимать работника, который, видите ли, требует соблюдения ТК? Никому такой не нужен. Лентяй неблагодарный.

Даже не знаю как можно ответить на такое передёргивание. Аналогия как минимум странная.


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


Есть вещи которые нужно сделать быстро и можно улучшить потом. Это повысит их ценность. 90% разработки ПО крутится вокруг таких вещей. Это просто факт, кто вторым вышел на рынок — проигрывает в большинстве случаев. А 9 женщин не родят ребёнка за месяц©.


Именно по-этому вводятся понятия минимального жизнеспособного продукта и итеративных подходов к разработке.

Снова спор идёт не со мной, а со своим воображением.


С вашим комментарием я согласен.

Ну хоть с кем то нужно спорить… Не самый плохой способ познания;)

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

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

Технология для строительства АЭС, загородного дома и деревенского туалета — это три разных технологии. В вашем манифесте я вижу идею «Накрутим по максимуму, как если бы мы строили космический корабль. А то, что бизнесу требуется всего лишь простой воздушный змей — это проблема бизнеса».
Технология для строительства АЭС, загородного дома и деревенского туалета — это три разных технологии.

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


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

Я думаю, вы неправы.

Какой процент софта разрабатывается реально с нуля? Особенно, как вы говорите, «человечеством», так-то для студента каждая программа — что-то новое. Давайте возьмем как пример самую распространенную область — веб приложения и корпоративное ПО. Что там нового? Взял фреймворк, написал поверх него бизнес логику, протестировал, задеплоил на продакшен. Бизнес логика разная? Ну так и один и тот же дом, в зависимости от местоположения, будет различаться — где-то утеплить сильнее, где-то фундамент изменить и тд.
Бизнес-логика ведь разная везде. Кому то нужен дом, кому то автомобиль, а кому то космолет. Бизнес-логика это же ключевая часть приложения. Именно из-за нее растет сложность и валятся сроки и недовольны программисты и не вырисовывается архитектура. Все остальное просто I/O обертка вокруг бизнес-логики.
А я поддерживаю ) Наличие манифеста и следование ему не сделает тяп-ляпную эджайл разработку на 100% идеальной, но как отличный противовес менеджерскому разгулу — то, что нужно.
«Sounds good, doesn't work».

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

"Мои правила" никак сказанному вами не противоречат. Более того, с основной мыслью я согласен.

Как бы против Agile у меня есть убийственный аргумент — «Вы бы хотели чтобы АЭС неподалеку от Вас строилась по Agile?»
Не знаю как на счет АЭС, но NASA например, как бы использует Agile если что и достаточно долго. И ничего, ракеты летают, марсоходы ездят :) Agile — это не про х**як х**як и в produciton. Это типичное заблуждение. В гибких методологиях тоже есть фазы планирования. Есть фазы когда нельзя просто прийти поменять требования и т.д. и т.п.
Пруф, где хоть один спутник запущенный в космос в рамках проекта, разработанного по принципам Agile. Там где они софт пишут, возможно, но не там, где занимаются инженерной работой.
Ну например вот один из документов NASA Agile: From Software to Mission System

Углубитесь в историю. Этот манифест был сформирован людьми которые работали в отрасли во время ее зарождения. Этот манифест не подходит для команд с низкой квалификацией.
Модель водопада как раз таки была изобретена в ответ на появление огромного кол-ва молодых программистов на рынке, которые понятия не имеют как делать проекты и которыми отрасли пришлось учится как то управлять.
Agile модель работает только тогда, когда в команде большинство составляют уже сложившиеся профессионалы
Я об этом и говорил — Agile работает там, где низкая цена ошибки и есть возможность многократных итераций — например, в разработке софта. Попробуйте запустить ракету в космос по Agile — сколько раз вам придется ее уронить, чтобы она в конце концов полетела?
Ни разу не нужно ее ронять по Agile чтобы она полетела. Еще раз. Agile не отменяет планирования, проектирования, тестирования, фиксации требований, контроля качества и т.д.
SpaceX, например, чем вам не agile? Прототипы, минимальный продукт, итерации — всё на месте.

Agile там закончился с появлением Falcon 9 FT. Точно также не видно Agile с капсулами Dragon.

Закончился, потому что закончился сам Falcon. Теперь будет agile для BFR.

Я думаю, что нет. Смысл Agile для Falcon был в том, что Маску срочно нужен был продукт, на котором он мог бы запускать спутники, чтобы зарабатывать деньги на дальнейшую разработку. Поэтому и летали ракеты с полезными нагрузками, хотя это были фактически недоделки.
А с BFR уже так торопиться нет смысла — рабочая лошадка есть, летает и приносит деньги. Поэтому вряд-ли мы увидим BFR 1.0, 1.1 и т.д.

Вот как раз в космических пусках приоритет окончания в срок наиважнейший. То есть буквально — если не запустим хоть как-то через месяц, то потом спешить уже не надо, несколько лет, до следующего пускового окна, у нас будет, если проэкт не закроют.
Действительно убийственный аргумент — он убивает желание с вами дальше общаться.
В agile есть понятие доменов. Всего 4 домена, при этом agile применим только в одном из них — «хаосе». АЭС не строится а режиме «хаоса», соответственно, по agile строго не рекомендуется строить такие проекты. Разумеется, ни в Nasa, ни в пентагоне никто не применяет agile.
В NASA говорят что применяют. И даже делают положительные выводы. Смотрите выше ссылку на сайт NASA
Несмотря на то, что в фактах вы ошибаетесь, мыслите вы в очень верном направлении.

Вы говорите о фреймворке Cynefin, а не об agile, а непосредственно agile применим, как правило, в «запутанном» домене, не в «хаосе».

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

en.wikipedia.org/wiki/Cynefin_framework
UFO landed and left these words here
Подписываюсь под каждой строчкой. Взвешенный разумный манифест в противовес agile-овскому детсаду.

Многие программисты порой забывают за что их ценит бизнес (подсказка: не за совершенный код).

В принципе описан обычный манифест программиста для встраиваемых систем. Так что хотите заделаться жестким программистом — идите в embedded.

«Внезапно» один из авторов Agile манифеста (Stephen J. Mellor), как раз в свое время специализировался на по embedded и realtime системах, и работал в том числе в CERN. А сейчас является CTO в Industrial Internet Consortium который был создан копаниями AT&T, Cisco, General Electric, IBM и Intel

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

Еще раз повторюсь, Agile не отменяет ни проектирования, ни фиксации требований, ни управления рисками ни контроля качества.

И да, то что у нас в России продают под видом Agile, им не является.

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

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

Agile был сформулирован IT ИНЖЕНЕРАМИ и УЧЕНЫМИ в области CS.

Мол, так все работает и нечего туда лезть?

Нет, отсылка следующая: — Сперва разберитесь в вопросе, после давайте обсудим.
Где я отсылаю к авторитетам? Я вообще не отношусь к категории «свидетелей Иего^W Agile». Я как раз являюсь адептом подхода «наймите хороших специалистов и не мешайте им работать».

В этом обсуждении я оставил несколько аргументированных комментариев, и несколько эмоциональных, поддавшись на троллинг автора.

1. Не вижу критики Agile. Как предложенный «манифест» решает проблему сдачи качественного продукта за предсказуемый срок и бюджет? Если он не решает, то он не нужен, или нужен, но не в такой форме подачи.

2. Какие конкретно предложения из «манифеста» предназначены для решения проблемы предсказуемости выхода обновлений продуктов? Если никакие, то он не нужен или нужен, но не в такой форме подачи.

Вот и всё)
Где я отсылаю к авторитетам?

Очевидно, имелся в виду ваш "соратник".


Как предложенный «манифест» решает проблему сдачи качественного продукта за предсказуемый срок и бюджет? Если он не решает, то он не нужен, или нужен, но не в такой форме подачи.

Как agile-«манифест» решает проблему сдачи качественного продукта за предсказуемый срок и бюджет? Если он не решает, то он не нужен, или нужен, но не в такой форме подачи.


Какие конкретно предложения из «манифеста» предназначены для решения проблемы предсказуемости выхода обновлений продуктов? Если никакие, то он не нужен или нужен, но не в такой форме подачи.

Какие конкретно предложения из agile-«манифеста» предназначены для решения проблемы предсказуемости выхода обновлений продуктов? Если никакие, то он не нужен или нужен, но не в такой форме подачи.


Вот и всё)
Может вы наконец ответите хотя бы на один вопрос, вам заданный?

Да как-то не привык отвечать на риторические вопросы.


Разумеется, "мой" манифест не решает проблему сдачи качественного продукта.

А какую проблему решает agile-манифест?


По-моему, это бессмысленный разговор.

Мне реально интересно, какую проблему решает ваш манифест. Вы же зачем-то выложили его на Хабр?

Ну так а какую проблему решает аджайл-манифест? Его же зачем-то выложили в интернет.

Вот некоторые из проблем которые эта философия решает:

1) Регулярная и ранняя поставка ценного программного обеспечения.
2) Обеспечение заказчику конкурентного преимущества
3) Выпуск продукта с периодичностью от пары недель до пары месяцев.
4) Налаживание устойчивого процесса разработки.
5) Повышение гибкости проекта.

Ничего из перечисленного манифест не решает. Это решает только правильно поставленный конкретный техпроцесс в конкретной команде.

Ничего из перечисленного манифест не решает.

Решает, с помощью Agile методологий и…
Это решает только правильно поставленный конкретный техпроцесс в конкретной команде.

И вот список некоторых из них...:

1) Adaptive software development (ASD)
2) Agile modeling
3) Agile unified process (AUP)
4) Disciplined agile delivery
5) Dynamic systems development method (DSDM)
6) Extreme programming (XP)
7) Feature-driven development (FDD)
8) Lean software development
9) Kanban
10) Rapid application development (RAD)
11) Scrum
12) Scrumban

Во-первых, не всё, что здесь перечислено, является полноценным техпроцессом.


Во-вторых, речь шла про манифест. Не нужно соскакивать с темы.

Методологии являются развитием ценностей сформулированных манифесте. Ни кто с темы не соскакивает. Странно что для вас это не очевидно. Они не на пустом месте родились эти методологии. Они все разделают общую философию.

Внимание. В данной ветке мы говорим о манифесте.


Обсуждать "производные" от него объекты — это отдельное удовольствие.

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

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

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

Приведу простой пример. Я думаю вам точно известны SOLID принципы. Так вот их сформулировал один из авторов и главных вдохновителей Agile манифеста. Вы же не станете утверждать теперь, что SOLID — чушь и не работает?
Я не отсылаю вас к авторитетам.

Позвольте! У меня все ходы записаны:




Я бы посоветовал автору просто ознакомится с биографиями и опытом людей которые сформулировали Agile манифест…
https://habr.com/post/431064/#comment_19415788



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

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


Обсуждайте. Только в рамках приличия, пожалуйста.


Все эти книги и их авторов легко найти в интернете.

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


Вы же не станете утверждать теперь, что SOLID — чушь и не работает?

Нет, не стану. См. выше.

Позвольте! У меня все ходы записаны:

Уделали… Мой посыл отсылки к «авторитетам» как раз в том что мне кажется вы не совсем правильно поняли данный манифест (А может и не хотели понять).

Просто Agile как раз таки решает некоторые из тех проблем которые вы затронули в своем манифесте.

Ваш манифест больше похож на манифест разработчика которого достали «эффективные менеджеры».

Но проблема в том что Agile тут не при чем. И эти менеджеры понятия не имеют что такое Agile и не следуют тем методологиям которые наследуют данную философию.

По-видимому, это разговор бесконечен, потому что не существует никаких исследований на тему того, что аджайл либо "улучшает", либо "ухуджает" разработку ПО.


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


Ваш манифест больше похож на манифест разработчика которого достали «эффективные менеджеры».

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


И эти менеджеры понятия не имеют что такое Agile и не следуют тем методологиям которые наследуют данную философию.

О том и речь, что эта "философия", независимо от того, какие цели изначально преследовали или не преследовали авторы, направлена на перекос в сторону интересов одной из сторон. А внедряет эту "философию" именно та стороны, в чью сторону идёт перекос. Хорошо ли это? А вот здесь, видимо, у разных сторон ответ свой.

По-видимому, это разговор бесконечен, потому что не существует никаких исследований на тему того, что аджайл либо «улучшает», либо «ухуджает» разработку ПО.

Вообще то существуют. Не про обобщенную философию кончено, но про конкретные методики. И как правило с цифрами и метриками.

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

А почему мне повезло? Потому что я не работаю с эффективными менеджерами?

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


Да, здесь есть проблема, потому что внедрять ее должны разработчики, которые понимают о чем она, а не менеджеры которые вообще ни чего не понимают в разработке ПО.
И нет в ней нет перекоса, даже если это не очевидно. Более того, чтобы избежать заблуждения о том что существует перекос, Agile был дополнен создателями другим манифестом.

Вот он:
manifesto.softwarecraftsmanship.org
Вообще то существуют.

Прям настоящие? Научные? Ссылки в студию!


manifesto.softwarecraftsmanship.org

Это ещё более водянисто и бессмысленно, чем аджайл.

Я про предложенный манифест и не говорю. Он наивен до невозможности. Но и Agile я могу критиковать до бесконечности.
Individuals and interactions over processes and tools — нам вообще неинтересно как вы это сделаете, пожалуйста, говорите это вслух, а то мы ничего не понимаем в вашей тарабарщине.

Working software over comprehensive documentation — работает, и ладно. Документация нам зачем?
Customer collaboration over contract negotiation — мы сами не знаем чего хотим. Давайте выяснять в процесссе.
Responding to change over following a plan — когда вы все закончите, мы резко захотим все переделать.
хоспади, зачем я в это всё ввязался-то?)
Working software over comprehensive documentation

К.О.: потому что бизнесу нужно именно working software.
Customer collaboration over contract negotiation

К.О.: потому что согласование контракта с ТЗ со всеми мелочами может занять больше времени, чем есть на вывод продукта на рынок.
Responding to change over following a plan

То есть, если рынок изменился, и план больше не актуален, вы предлагаете все равно продолжать его придерживаться? )

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

А мы согласуем контракт на разработку продукта, или продажу разработчиков по time&materials?
Если первое — и не согласовать что конкретно мы должны сделать, сколько у заказчика есть итераций на согласование дизайна, сколько у заказчика есть время на приемку каждой фичи/итерации, и не включить в контракт что именно мы должны по нему выполнить, то можно встрять на конкретные деньги. Сколько раз уже видел примеры до чего доводит принцип «лишь бы продать».
А вот если просто продать гребцов на конкретный срок — то тут уже заказчик может хоть десять пивотов устроить за свой счет, на здоровье. Но заказчик тоже не дурак — он посмотрит конечно на накаченные бицепсы и хорошие зубы разработчиков, но ему то нужен выполненный продукт. Потому продавать живой товар обычно сложней.
А мы согласуем контракт на разработку продукта, или продажу разработчиков по time&materials?
Мне кажется, вы путаете теплое с мягким. Я этот принцип понимаю так: чем тратить время на согласование ТЗ, детальной оценки трудозатрат, сроков и стоимости, и существенных, да и несущественных условий контракта, лучше взять гибкий контракт (T&M — хороший пример) и начать работу, разибраясь в деталях по мере продвижения.