Как стать автором
Обновить

Комментарии 389

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

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

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

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

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

И вы. Но кто же прав?

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

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

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

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


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

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

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

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


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

Истинно так.


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

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


как важнее

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

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

По-моему, у нас нет спора :) .

Code review это никак не часть agile

Возможно. До недавнего времени просто вообще ничего не было. А потом пришел 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.
НЛО прилетело и опубликовало эту надпись здесь

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


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

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


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


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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

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

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


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

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

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


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


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

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

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

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


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

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

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

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


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


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


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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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

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


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

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


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

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

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

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


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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

Компьютеры исполняют исключительно машинный код, а все эти ваши Си изобретены самозванцами и они уничижают права одной группы (компьютеров) по отношению к другой группе (людям)
НЛО прилетело и опубликовало эту надпись здесь
Даже если в их книгах есть здравые мысли (а они там есть, я читал),

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

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

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

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

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

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

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

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

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

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

Это смешно. Компания людей выше в комментарии, она про технологии. Поэтому их работу видно. Компания из Agile манифеста — про программистов в бизнесе. Это не умоляет ни как того что они сделали для индустрии. Сотни тысяч разработчиков каждый день пользуются архитектурными и другими паттернами которые они сформулировали, пишут тесты в соответсвии с методологиям которые они разработали, проектируют программы в соответсвии с принципами которые они предложили, выпускают успешные продукты в соответсвии с методиками которые они предложили. Причем многие из них об этом даже не подозревают, потому что информацию черпали не из первоисточника а из перепечаток, статей, и т.д. и т.п.
НЛО прилетело и опубликовало эту надпись здесь
Будьте добры ответить на конкретно поставленные вопросы. Давайте поговорим конкретно, без абстракций и отсылки к умным терминам. Я как минимум 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
НЛО прилетело и опубликовало эту надпись здесь
Код они писали еще до того как многие из нас родились, а многие познакомились с компьютерами. Вас это настораживает?
Продукты в которых они так или иначе поучаствовали вы используете чуть ли не каждый день, потому что их привлекают к работе мировые лидеры 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».

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

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

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

Углубитесь в историю. Этот манифест был сформирован людьми которые работали в отрасли во время ее зарождения. Этот манифест не подходит для команд с низкой квалификацией.
Модель водопада как раз таки была изобретена в ответ на появление огромного кол-ва молодых программистов на рынке, которые понятия не имеют как делать проекты и которыми отрасли пришлось учится как то управлять.
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
НЛО прилетело и опубликовало эту надпись здесь
мне понравились теги

Спасибо. Всю душу в них вложил.

Подписываюсь под каждой строчкой. Взвешенный разумный манифест в противовес 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 был сформулирован 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

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


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

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

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


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

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

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

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

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

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




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



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

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


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


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

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


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

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

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

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

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

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

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

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


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


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

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


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

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

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

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

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

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

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


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

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

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


manifesto.softwarecraftsmanship.org

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

Гугл в помощь
НЛО прилетело и опубликовало эту надпись здесь
хоспади, зачем я в это всё ввязался-то?)
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 — хороший пример) и начать работу, разибраясь в деталях по мере продвижения.
Почему путаем? Вся эта философия в отрыве от реальности не имеет смысла, потому проецируем на обычный кейс. Например, мы обычная галера и хотим продать заказчику наши услуги.

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

Customer collaboration over contract negotiation — это хорошо для крупных американских корпоративных клиентов, где услуги поддержки/разработки проданы на год вперед, и дальше уже делаем максимально хорошо заказчику на выданный бюджет. В условиях же большинства проектов маленьких галер это только доставляет проблемы как заказчику, так и исполнителю
безусловно, есть нюансы, не везде подходит. НО это не «философия», это вполне рабочая модель. я считаю, что перенос рисков заказчика на разработчика — это порочная практика.

// не называйте место своей работы галерой. слава б-гу, сейчас нигде нет рабства, и вы вольны встать и уйти в любой момент.
Считаю себя свободным галерщиком. Для меня понятие «галеры» не связано с рабством, а с необходимостью грести вместе с командой. Чтобы проникнуться атмосферой, рекомендую исторические фильмы
Спасибо за разъяснение
НЛО прилетело и опубликовало эту надпись здесь
это мне ответ? спасибо, я в курсе про «возможность»; на уровне технической команды бизнесу нужно именно working software.
«Внезапно» один из авторов Agile манифеста (Stephen J. Mellor), как раз в свое время специализировался на по embedded и realtime системах, и работал в том числе в CERN. А сейчас является CTO в Industrial Internet Consortium который был создан копаниями AT&T, Cisco, General Electric, IBM и Intel

«Внезапно» Но он же не придумывал Agile для embedded и real-time? Причем здесь его предыдущая специализация?

Agile это про software в целом а не про отдельные направления. Это в первую очередь философия, система ценностей.

… которая почти нахрен не нужна в embedded или real-time. А вот философия и ценности, описанные в данном манифесте, в принципе, вполне к ним относятся. Поэтому я и предлагаю автору переквалифицироваться.

На стройке ходят в касках. Почему? Потому что этого требует техника безопасности.

Почему?

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

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

Ещё и доказывать надо, что «лучше» — действительно лучше. С этим у меня всегда были проблемы, т.к. не особо красноречив и впадаю в ступор при необходимости объяснять очевидные вещи. При чём немалая часть людей всё понимает, но им просто всё равно или банально лень.

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

К сожалению, единственный способ решить эту проблему — качать софт-скилы. Чтобы писать хорошо код вполне можно обойтись техническими навыками, но вот объяснить коллеге почему код нужно писать именно так — это уже работа с людьми (и не смотрите что вроде он тоже программист, это не поможет), и она требует совсем других навыков, не технических. Хорошая новость в том, что софт-скилы всё-равно пригодятся, без них сложно стать действительно хорошим сеньором, и тем более тимлидом, архитектором или CTO.

Зачем кому-то из программиста становиться станцией технического обслуживания?!

Опять английский термин не понравился? По-моему, Вы придираетесь. :)
Ладно, скажу по-русски: тех.директором.

Спасибо :) .


На самом деле, в этой ветке, опять же, спора нет.

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

НЛО прилетело и опубликовало эту надпись здесь
На самом деле описанные в статье проблемы признаются мировым сообществом, в т.ч. самими авторами Agile Manifesto.

Вот Мартин Фаулер про «Agile 2018», очень интересное выступление, где он обозначает текущие проблемы Agile, которые авторы оригинального agile манифеста «даже не представляли» (problems that we original manifesto authors didn't imagine) и ставит следующие цели:

1. Борьба с псевдо-agile (dealing with faux-agile)
2. Важность технической стороны (the lack of recognition of the importance of technical excellence)
3. Продуктовый, а не проектный подход (get rid of software projects and use a product-oriented view)

martinfowler.com/articles/agile-aus-2018.html

Вот Роберт Мартин и куча подписавшихся людей с Craftsmanship Manifesto:

1. Well-crafted software
2. Steadily adding value
3. A community of professionals
4. Productive partnerships

manifesto.softwarecraftsmanship.org

Это я к тому, что текущая статья не противоречит Agile :)

Краткие итоги обсуждения.


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




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

powerman



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

DexterHD



Что и требовалось доказать.

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

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

Перепутал местами ссылки. Первая ведёт на вторую цитату, а вторая — на первую.

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

Наглая ложь и подмена понятий. Я нигде не утверждал, что я бы уволил кого-то из-за срыва сроков спущенных «сверху». Я лично на работе ни когда не говорю «Да», срокам спущенным сверху, если они противоречат моей экспертной оценке. При этом, мне это не мешает работать по Agile и сдавать продукт в срок. А вам мешает. Мы сразу бежите в трудовую инспекцию и проставлять минусы в комменты :D

Глупо обвинять меня во лжи, когда весь текст перед глазами.

Глупо обижаться на всех вокруг, когда у кого то получается а у вас нет :)
Чисто для статистики, можно узнать насколько уменьшилась ваша карма на этом топике?
На 5.5 единиц. Я например вообще не минусую ни кого как правило, и уж тем более не трогаю карму. Увы но сообщество на Хабре давно уже не то, что было раньше…
Ну, не надо так категорично
Из 5-10 тысяч читателей вас личным врагом признали всего 6 человек. Всего одно промилле.
К тому же страдать за правду сам Бог велел. И Джордано Бруно.
Наглая ложь и подмена понятий. Я нигде не утверждал, что я бы уволил кого-то из-за срыва сроков спущенных «сверху». Я лично на работе ни когда не говорю «Да», срокам спущенным сверху, если они противоречат моей экспертной оценке. При этом, мне это не мешает работать по Agile и сдавать продукт в срок.

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


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


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

НЛО прилетело и опубликовало эту надпись здесь
Все верно, но если программист наемный работник, то он относится к классу пролетариата.
Осознания себя как части рабочего класса, ни как не может мешать выкладываться по 80 часов :)
Ради любопытства, при удаче стартапа вам давали какие либо бонусы? Успех компании компенсировал ваши overtime'ы?
НЛО прилетело и опубликовало эту надпись здесь
Подобные манифесты очень круто смотрятся и даже могут использоваться в маркетинге, но при одном единственном условии: каждый ваш продукт, если вас не трогать и дать работать как надо, будет уровнем и потенциалом равен фейсбуку, амазону и иже с ними, а не очередным «ну мне пофиг на пользователей, мне так удобно и так правильно по архитектуре» =)

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

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

Фармакология и еще с десяток направлений имеющих больший объем денежного оборота.

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

Твердо и уверенно можно вести только личные проекты, хотя основательного и логичного подхода не хватает.
Видел 2 конторы которые торопясь сами себя закопали: тут костыль, тут как быстрее, а не как лучше, и тут «времянка». А потом все это как снежный ком обрастает и в один момент разваливается.
дополню что в одной из них крутилась тикет-система с проставленным таймингом задач, по которой потом считали KPI.
И люди боролись за количество отработанных задач.
Каково вам например увидеть в коде запрос к базе из 5 связанных таблиц, но в котором тем не менее 2 десятка полей вызываются отдельным подзапросом?
А все потому что так добавить вывод поля мелким подзапросом занимает 5 минут, а построить запрос что бы учитывал необходимость добавления доп. полей и условий — 30 минут. Ну так что бы и логика прослеживалась, и связь, и ресурсов много не жрал.
В итоге, утрированно, 2 цифры в отчет выводятся 15 минут…
1. Создают продукты те, кто работает над ними
2. Не создают продукты те, кто над ними не работает
3. Работайте над продуктами
Полностью согласен с автором! Из-за таких agile-манифестов нет нормального работоспособного ПО. Куда не посмотри, всё глючит, падает и т.д. Видел как женщина вносила в терминал крупную сумму, терминал сказал ей:- Извините, ошибка. И перегрузился. Справедливости ради надо сказать, что противостоять agile-манифесту трудно т.к. некоторый резон, диктуемый рынком, в нём есть. Но с этим надо бороться.
У меня очень много вопросов к этому манифесту. Так как izvolov активен в комментариях, я смиренно надеюсь, что он найдет время ответить на 11 простых вопросов, которые, вне всякого сомнения, прояснят глубину его мысли и дальность её полета.

  1. Почему концепция важнее новых требований? Откуда это следует? Создавая систему, мы постоянно ставим эксперименты, которые влияют на концепцию. И что такое концепция вообще в вашем определении?
  2. Почему качество важнее скорости?
  3. Делать как надо? Это как именно? Полагаясь на что? На интуицию? На звезды? На физику параллельной вселенной?
  4. Почему наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста? А как же пользователи с их проблемами? Программист работает для себя или для пользователей?
  5. Какой уровень качества необходим? Кто это решает? Как именно?
  6. Как быть начинающим разработчикам? Они еще не профессионалы, как им работать вообще?
  7. Что такое качественный продукт?
  8. Для какого софта можно разработать матмодель? Что такое матмодель для игры Packman? Что такое матмодель для движка Habr?
  9. Почему мы должны ориентироваться на каски строителей и хирургов?
  10. Что такое хороший техпроцесс?
  11. КОНТРОЛЬНЫЙ: Что такое качество?


Не автор поста, но часть вопросов абсурдны.
Да и скорей это относиться к корпоративному ПО или крупным проектам.
Прототип стартапа хоть на коленке делай.
1. Потому что да же мелкие проекты должны иметь ТЗ. Если нет ТЗ — получается каша, и не видно конечной цели. Если проект чуть крупнее и есть сроки -то потом с тебя же и спросят почему проект не закончен, и попробуй объяснить что ты отклонялся от ТЗ из-за вдохновения Васи-Пети и их новых идей.
2. Узнаешь когда заведешь себе девушку. Может шутка грубовата.
Но суть в исключении ошибок по невнимательности и выбора неверных подходов, которые повлияют на стоимость дальнейшей разработки. Например отсутствие масштабируемости.
3. На технологии и нормы. Без костылей.
6. Тщательней готовится, читать документацию. Разбивать этапы разработки на подзадачи и изучать способы их реализаций.
9. Потому что это аналогия.
10. Когда предусмотрел всё или почти всё и любой этап от идеи до релиза идет по отлаженным рельсам. А сход с них — форс-мажор, а не правило.

В целом, если критично относиться к данной мысли изложенной автором, то 70% статей хабра можно удалять за ненадобностью, т.к. они как раз и расписывают как надо или как стоит делать, и как будет лучше/качественней/продуктивней/производительней.
А то получается на «говнокод» мы плюемся, а не плодить его отказываемся.
Я ждал автора, но что же. Эти ответы совершенно неудовлетворительные.
1. Даже с ТЗ подавляющее большинство проектов получается с задержками по времени, с большим количеством багов и с 0 пользой для клиентов. ТЗ не является ответом
2. У меня жена и двое детей. Иногда надо быстро, пока дети не проснулись.
3. Что такое норма? Что такое технология? Что такое костыль? Пожалуйста, эти абстрактные ответы оставляйте при себе. Нормы не существует.
9. Аналогии не всегда работают, не так ли?
10. Это бывает только никогда. Вернее, только при разработке очень простых и понятных система. Например, сайта для индивидуального предпринимателя Иванова.

Рекомендую начать углубляться в детали и понизить градус абстракции.
1. является. все вышеперечисленное ошибки на других этапах.
2. в вашем случае расценивайте «быстрее быстрого. Дети спали до утра, а вы закончили через 2 минуты.» Выбор неверных подходов, которые повлияют на стоимость дальнейшей разработки. — Позовите «тещу» посидеть с детьми.
3. Костыль — временное решение. Но ничего нет более постоянного чем временного. Я думаю все понимают что это, но на примере:
Это когда в 1С в отчетности ты в макете прописываешь подписантов, потому что надо вот сейчас, и забиваешь на реализацию механизма вывода подписантов из справочников ответственных лиц.
Нормы — это парадигмы в том же ООП, паттерны в проектировании. Понимание сущностей, явное объявление переменных и корректное комментирование кода, это все то же норма. Общепринятая практика устоявшаяся на многолетнем опыте.
9. Не всегда, но применимы в общих чертах и имеют место быть. Все зависит от подхода.
10. Если подобные процессы налажены то и сложные системы становятся простыми и понятными как сайт для ИП Иванова. Сейчас инструментов для ведения этих процессов предостаточно.
Для того чтобы предусмотреть ВСЁ нужно быть специалистом во ВСЁМ.
Концепция предлагает создание основного ориентира для разработки ПО, основывается на проблеме клиента, которую необходимо решить.
Насчёт качества это как с ездой на самолёте если вести правильно то избегает катастрофы, при погоне за скоростью перенагружаешь элементы и теряешь много ресурсов и качества.
Делать зависит от выбора способа решения этот манифест лишь создаёт набор рекомендаций для упрощения разработки и только указывать какие способы работы лучше выбрать.
На этапе выбора концепции создаётся основа решения проблемы и этот манифест принуждает к лучшему исследовании проблемы клиента путем переговоров про необходимость различных функций и для правильности подбирают концепцию для современного и качественного решения по принципу sancta simplicity, уберая фантазии клиента.
И как следствие при высокой эффективности разработки находиться правильное решение проблемы.
Разумеется нет идеального манифеста.
В связке с концепцией можно создать систему оценки качества и выполнения, и тогда учитываются особенности предметной области проекта.
Начинающие как и всегда будут по разному пытается применять разные методологии, эти манифесты подсказывают принципы разран при этом давая часть опыта для избежания проблем.
Качественный продукт -тот который определил клиент и команда, методология лишь указывает принцип того что работа должна быть выполнена правильно и качественно.
Матмодель позволяет без реализации проверить реальность работы ПО, то есть экономит время отладки, а также даёт ПО лучшую возможность анализа. Но в некоторых приложениях необходимо лишь сделать обычную UML модель и проанализировать матметодами (мое мнение весьма не компетентно)
Перегрузка лубого рабочего уменьшает его эффективность, а в результате увеличивает критическую цепь проекта.
Хороший техпроцесс это эффективность, качество и интуитивное понимание выполнения проекта, но тут интуитивное заменяется система оценивания
Качество определяется концепцией и эффективностью решения
Отвечу то же самое, что и предыдущему оратору. Рекомендую начать углубляться в детали и понизить градус абстракции. По вашим ответам невозможно создать процесс разработки. По манифесту выше это хотя бы возможно, но к сожалению процесс получится совершенно неудовлетворительным с самых разных точек зрения, потому что он будет подходить только для узкого круга задач.

Автор упускает довольно много важных деталей разработки ПО:
1 — высокую неопределенность
2 — психологию пользователей, которые редко знают, чего хотят
3 — сложность создания систем (особенно в группе, особенно в большой группе)
4 — невозможность формализации системы. ТЕМ БОЛЕЕ на уровне матмодели.
5 — экспериментальный характер процесса разработки.

Основная задача — увеличить скорость накопления знаний. Это следует делать увеличением количества экспериментов, ускорением экспериментов и постоянным взаимодействием с пользователями системы. Agile хотя бы делает к этому шаг, автор текущей статьи отпрыгивает назад шагов на 15
8. Математическая модель видимо Вам представляется одними цифрами.
Но для того же хабра часть этой модели будет например расчет рейтинга комментариев и постов, условия привязки этих самых постов к авторам, проверки на валидность той же почты при регистрации. Количество постов в «Что обсуждают» и расчет периодов.

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

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

На ум пришла одна аналогия, объясняющая как мне кажется, причины таких бурных споров. Вот возьмем большое производство. Там обязательно есть НИОКР (в том или ином виде), назовем его отделом «перспективных исследований», есть конвейер где монотонно согласно строгому ТЗ собирается из деталей готовый продукт, есть худо-бедно собственное производство таких деталей, где ТЗ меняются, редко но всеж меняются.

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

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

На конвейере… ну кароче обычные «галеры» этот конвейер.

Вот в случае с программированием, во всех этих отделах, работает как правило один и тот же человек. Отсюда такие разнополярные мнения и возникают.
кстати, очень интересная методология подхода к работе описана у дизайн-бюро Горбунова и называется ФФФ bureau.ru/about/fff

Аббревиатура ФФФ означает fix time, fix budget, flex scope. Мы работаем с фиксированными сроками и бюджетом, а функциональность оставляем гибкой (по согласованию с заказчиком)

Из этой методологии выводятся другие две.
Fix time, fix scope, flex Budget
Fix Scope, Fix Budget, flex Time.


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

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

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

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

дисклеймер: я сам не разработчик, а больше системный администратор, но и с разработчиками сталкиваюсь регулярно. то есть уровень про который со мной предметно можно разговаривать — это небольшие команды и проекты :)
Какое прекраснодушие, «… чтобы довести всё это до ума. А потом начинают «фиксить баги»....»

К гадалке не ходи, отдел тестирования и пользователи всё так же будут выявлять ошибки. Программисты, работающие по сему манифесту, будут их вкладывать в мат. модель и исправлять, ну или корректировать мат. модель и исправлять. А служба поддержки всё так же будет еженедельно собирать готовые и оттестированые, на данный момент, исправления и отсылать пользователям.
izvolov Дмитрий, я бы все же хотел попросить вас ответить на два моих вопроса, которые вы проигнорировали.

1. Какие именно интересы одного круга лиц agile превозносит над интересами другого, да и о каких конкретно кругах тут идет речь?

2. Какие ваши права как программиста ущемляются agile-манифестом (и/или вытекающими из него методологиями)?
На мои 11 тоже не ответил. Что уж тут 2…
Такой подход хорош в конторе с неограниченным финансированием из госбюджета, типа «Роснано». Когда финансы ограничены, эта идиллия может закончится раньше готовности продукта по причине отсутствия финансов.
Комментарии это конфликт интересов в чистом виде.
Чем дальше от сердца бизнеса тем более солидарны с идеей манифеста.

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

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

Мое мнение что инженерный ум не совместим с продажным но «целое больше, чем сумма его частей» и те кто найдут компромис не потеряв себя как программиста, маркетолога и тд пойдут дальше в бизнесе основанном на технологическом продукте.
НЛО прилетело и опубликовало эту надпись здесь
Все это становится реальностю когда реальностью, когда пишешь код или для авиации или для атомной энергетики или для космоса. И наверно с использованием языка Ada.
НЛО прилетело и опубликовало эту надпись здесь
Вкачусь со взглядом со своей колокольни. Я работал 4 года в Германии, и сейчас в балтийском банке, с трудовыми практиками России не знаком, так что не судите строго.

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

На первой работе, несмотря на декларируемый эджайл (практикам которого мы практически не следовали), работали мы практически по этому манифесту. Наша команда сперва пилила набор утилит для тестирования, потом перенесли это в один фреймворк, который кое-как внедрили на всей фирме, и под конец наш синьёр с менеджером загорались мыслью выпустить этакий универсальный фреймворк для совсем крутой автоматизации тестов в мире CI/CD с использованием всех лучших практик, что бы он стал этаким стандартом вроде Netflix OSS для облачных решений. И вот тут-то всё и стухло.

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

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

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

TL; DR: На своем опыте я убедился, что следование ценностям, задекларированным в этом манифесте не гарантирует ни качественных продуктов, ни адекватной рабочей атмосферы, если коллектив состоит из программистов разных уровней. К тому же он по определению дистанцирует и противопоставляет заказчиков/руководство программистам, что не способствует здоровой атмосфере. В то же время правильно поставленный agile решает, в том числе, и те проблемы, которыми был озабочен автор этого манифеста.

Ещё одна мысль. На прошлой работе в один момент старшие программисты заинтересовались прикрутить машинное обучение к одному из основных компонентов (fuzzy тестирование с production данными) своего фреймворка. Поскольку задача была слишком большой для обычного прототипа, мне её поручили сделать как бакалаврскую в университете. Для сбора данных мне потребовался тот самый компонент, а поскольку закрытый коммерческий код выносить с предприятия было нельзя, я, с разрешения работодателя, сделал свой open source аналог. Что бы повторить главную киллер-фичу фреймворка (над которым на тот момент работали уже почти год) мне потребовались сутки. Ещё пара дней ушла бы на то, чтоб переписать работу с сокетами на С — просто для скорости, и возможно потребовалась бы неделя чтоб прикрутить слив данных с распределенных инстанцев в одну базу что бы поддерживать параллелизирование. Таким образом за месяц я мог бы выкатить кривую и косую (я совершенно не обманываю себя о том, какого качества код я произвожу относительно опытных senior developer-ов), но рабочую версию, дающую тот же функционал, что и продукт, который разрабатывается уже полтора года но так ещё и не был никуда выпущен. Разумеется, я не собираюсь этого делать, но информация о фреймворке выкладывалась в открытую сеть в виде презентаций (которые я и пересказал тут, что бы гарантировать, что я не не ломать NDA) и если бы продукт представлял реальную выгоду — у потенциальных конкурентов было бы более чем достаточно времени что бы выпустить свою версию, захватить и поделить рынок, пока команда спецов делает всё «правильно».
«манифест программиста, не понимающего, кто и за что ему платит.»
> Концепция важнее новых требований
Пойдёт.

> Качество важнее скорости
Надо развернуть, в чём измеряется качество и в чём скорость? Без внятных определений очередная философская херня натянутая на инженерную дисциплину.

> Делать как надо важнее, чем делать как просят
Как надо кому? Просят кто?

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


Программисту не нужна шелуха, якоря и балласт в виде — общества, коллектива, помощников, коуч-тренеров, офисов.


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


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

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

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

Публикации

Истории