Предисловие
Данный текст предполагает, что читатель ознакомлен с т.н. agile-манифестом разработки программного обеспечения и его т.н. основополагающими принципами.
В настоящий момент существует огромное количество людей, которые принимают данный "манифест", соглашаются с ним, и даже пытаются применять. Но лично для меня это выглядит как шутка, которая затянулась.
Содержание
- Манифест жёсткого программиста
- Основополагающие принципы манифеста жёсткого программиста
- Комментарии
Манифест жёсткого программиста
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят
То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева.
Основополагающие принципы манифеста жёсткого программиста
Наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста, благодаря продуманному плану и следованию технологии разработки ПО. И, как результат всего этого, удовлетворение от результатов своей работы.
Изменение требований возможно, но новые требования должны пройти те же стадии осмысления, которые прошли и все старые требования. Заказчик должен осознавать, что изменение требований может повлечь переработку продукта.
Продукт следует выпускать только тогда, когда он достигнет необходимого уровня качества. Нет, и быть не может никакой фиксированной периодичности.
Каждый должен разбираться в том, что он делает, и стараться делать это хорошо. Неудачно сделанная работа по продажам или планированию не должна превращаться в бесконечный поток поправок к требованиям или срокам, то есть перекладываться на инженеров.
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Непосредственное общение не должно мешать непосредственной работе. Проводите совещания тогда, когда они необходимы рабочему процессу.
Качественный продукт — основной показатель успеха.
Никто не должен работать "на износ". Работать нужно спокойно, не следуя ничем не обоснованным "ритмам" и "циклам". Переработки недопустимы.
Постоянное внимание к техпроцессу повышает качество, надёжность и гибкость системы.
Самые лучшие требования, архитектурные и технические решения рождаются у команд, которые плотно работают над требованиями, архитектурными и техническими решениями.
Полезно проводить доклады и семинары, чтобы повышать общий профессиональный уровень и степень вовлечённости в общий процесс.
Комментарии к манифесту
Концепция важнее новых требований
Перед началом разработки ПО необходимо сделать две вещи:
- Разработать матмодель ПО;
- Продумать архитектуру ПО.
Если заказчик внезапно прибегает с новыми требованиями, то нужно быть не "готовым к изменениям", а готовым к сопоставлению новых требований со старой концепцией.
Если требования ложатся на существующие матмодель и архитектуру — прекрасно. Ставим задачу в очередь. Если не ложатся, то нужно либо скорректировать или отбросить новые требования, либо изменить матмодель и архитектуру так, чтобы требования на них легли. А это новое планирования, возможное переделывание того, что уже сделано, то есть время и деньги.
Если заказчик этого не понимает, то нужно ему это терпеливо объяснять, а не бросаться по первому зову бежать в направлении, указанном мимолётным мановением его царственной руки. В противном случае вместо ПО выходит куча смердящих отбросов.
Качество важнее скорости
Иначе говоря, техпроцесс важнее сроков.
На стройке ходят в касках. Почему? Потому что этого требует техника безопасности.
Разработчики ПО пишут тесты и документацию. Почему? Потому что такова технология производства ПО.
Многочисленные конторы вываливают тонны неработающего или плохо работающего, кхм, ПО, вместо того, чтобы потратить немного времени, чтобы довести всё это до ума. А потом начинают "фиксить баги".
С пугающей регулярностью поступают сигналы о том, что очередное приложение (или даже целая ОС) после очередного обновления перестаёт работать. А как насчёт еженедельных "технических" обновлений, улучшающих "общую стабильность и надёжность"? Знакомо?
Мы сами создаём этот порочный круг: все торопятся, поэтому мы торопимся, поэтому все торопятся. Пора остановиться и задуматься.
Делать как надо важнее, чем делать как просят
Сидит программист Йцукен. К нему приходит менеджер Ячсмит и говорит, что нужно сделать X к следующему понедельнику. Но Йцукен знает, что для того, чтобы сделать X, нужно пройтись по литературе и статьям, продумать матмодель и архитектуру, написать код, тесты, документацию, и меньше трёх недель на всё это точно не выйдет, потому что A, B и, вероятно, C.
Но Ячсмит — "энергичный" человек с "активной жизненной позицией", поэтому он объясняет Йцукену, что "рынок динамично меняется", и нужно срочно "добежать", чтобы "занять поляну". Йцукен поддаётся, срывает сроки и получает по шапке — от Ячсмита, конечно.
Но Йцукен хочет заниматься любимым делом, и делать его хорошо. Поэтому Йцукен, оценив настоящий срок, должен не бросаться успевать, а объяснить Ячсмиту, что нарушать техпроцесс нельзя, что к следующему понедельнику никак не выйдет, и что на X, согласно техпроцессу, понадобится не менее Y недель, потому что должна быть проделана определённая работа. Ячсмит ведь не будет подгонять хирурга, оперирующего ему сердце, потому что Ячсмит опаздывает на совещание с клиентом своего нанимателя? Или будет?
> К началу
P.S.
Краткие итоги обсуждения.
Два из трёх основных противников этого манифеста стали бы шантажировать увольнением инженера, который говорит, что работа не делается в тот срок, который спущен "сверху".
… если Вы пришли в нашу компанию для того, чтобы получать два месяца зарплату за бесполезную деятельность по написанию кода, который никогда не будет запущен — пожалуйста, напишите заявление по собственному прямо сейчас...
powerman
Следующее действие — увольнение по инициативе работодателя и можете идти с этим в суд. :)
DexterHD
Комментарии (372)
Sinatr
26.11.2018 11:45+1Класс, ваша статья прямо мое жизненное кредо (я программист).
это выглядит как шутка, которая затянулась
Ну почему же. Agile для меня это просто одна из форм организации процесса разработки. Ваш манифест легко вписывается, по крайней мере именно так я и работаю.
Концепция важнее новых требований
Сообственно почему я и присутствую на backlog refinement. У меня спрашивают story points и я чесно говорю, если задача не вписывается, что придется менять для реализации и насколько это сложно. Часто задача сразу же упрощается под существующую архитектуру, откладывается (создается spike — чтобы уточнить сложность) или от задачи вообще отказываются.
Качество важнее скорости
Маленькая предистория. Работал с одним программистом без agile, он делал все быстро и меня не спрашивал. В результате получилось разделение отвественностей: только он знал свой код. Потом он ушел… и грянул гром… там было все плохо… Теперь мы используем agile и code review, любой программист может поддерживать любую часть проекта (нет «черных ящиков» — инкапсулированного кода, не понятного для всех). На этапе ревью код балансируется, чтобы уменьшить технический долг (меньше извините гавнокода). Вроде бы работает, требует больше времени на разработку, зато жизнь после релиза проще.
Делать как надо важнее, чем делать как просят
Моя фирма нанимала программиста, а не обезьянку, которая умеет печатать. Я не дурак (вроде) и могу думать, в том числе решать проблемы. Любая из назначенных задач — это полностью мой выбор как решать. Впрочем есть другой нюанс — у меня свое «узкое» видение решений, которое может быть не совсем оптимальным для конечного пользователя. Тут нужен балланс, «как важнее» — это весьма субьективная трактовка.izvolov Автор
26.11.2018 11:52Теперь мы используем agile и code review, любой программист может поддерживать любую часть проекта...
Аджайл с этим никак не связан. Почти любой программист может поддерживать почти любую часть проекта тогда, когда соблюдается техпроцесс. То есть: обзор кода, тестирование и документирование.
жизнь после релиза проще
Истинно так.
требует больше времени на разработку
А вот это только на ранних этапах. Когда всё встаёт на рельсы, всё только быстрее.
как важнее
Либо я неправильно понял, либо вы неправильно прочитали. У меня не "как важнее", а "как надо".
Sinatr
26.11.2018 12:39Почти любой программист может поддерживать почти любую часть проекта тогда, когда соблюдается техпроцесс
Тут вы прям в точку попали. Документация практически отсутствовала. Тесты — больная тема до сих пор… Я просто хотел сказать, что введение одного лишь code review в процесс разработки существенно улучшило ситуацию с «качеством» кода, хотя и уменьшило скорость.
У меня не «как важнее», а «как надо»
Моя опечатка, врочем смысл не особо меняется. Что значит как надо? Как красивее впишется в архитектуру? Это скорее «как проще» для вас. А пользователю программы это может быть не удобно. И нужно искать балланс, такое решение, которое и впишется в архитектуру, и не будет неудобной кнопкой где-нибудь далеко, до которой еще и добираться через несколько кликов (был случай).
tuxi
26.11.2018 18:54+1Code review это никак не часть agile
Sinatr
27.11.2018 11:12Возможно. До недавнего времени просто вообще ничего не было. А потом пришел scrum master и начались code reviews, появился беклог, спринты и т.д.
Скрум в принципе пропагандирует «быструю» разработку, но пока что не было большой проблемы иногда потратить больше времени на какую-то задачу, чем планировалось. Опять же, нужен баланс, нельзя тупо рвать вперед. Да, в текущем спринте ты будешь молодец, и даже пройдешь ревью, умалчивая о нюансах и, как следствие, о техническом долге. А потом кто-то будет расхлебывать кашу, воюя с твоей нерешенной проблемой.
С другой стороны никто не будет ждать, пока ты пишешь свой «идеальный» код. Потому нужно искать компромис, но все же с упором на качество, не по максимуму, но хотя бы,
чтобы твоя совесть сказала «теперь хорошо, расслабься».tuxi
27.11.2018 12:42+1Я перефразирую, пришел человек который был заинтересован в повышении качества кода (как минимум). scrum то причем? парное программирование и кодревью известны и употребляются повсеместно года этак с 2002..03-го
Sinatr
27.11.2018 13:46Простите, я не пойму что именно вы спрашиваете. Почему я стал говорить о scrum? Потому что мы его сейчас используем. Scrum = agile, статья о догмах разработчика в agile, что не так?
tuxi
27.11.2018 14:42+1Я про то, что на практике, описанные методологии больше заточены под повышение КПД конкретной рабочей единицы в проекте, под возможность более гибкой манипуляцией проектом, но мало заточены под качество кода.
Все основные методологии повышения качества кода, были придуманы задолго до scrum-а и прочего. В том числе и методология коротких итераций в разработке.
Отсюда я делаю вывод, что scrum/agile больше всего преследуют коммерческие интересы конкретной группы лиц в проекте.
И заметьте, я нигде не говорю, что это плохо. Я вообще не сторонник «черно-белой парадигмы». Но то, что эта группа лиц частенько использует эти возможности в целях «замыливания» или скрытия истинного положения дел в проекте — это факт. Отсюда возникают такие публикации как эта.
Aquahawk
26.11.2018 12:04+2А если серьёзно. Я прошёл путь программер -> тимлид -> руководитель проекта -> тимлид и доволен текущим положением дел. Адептом скрама особо не был, пробовали в команде. А вот канбаном мы пользовались долго(около 4х лет, 12 человек, художники, программисты клиента и сервера, сценаристы). Про канбан интересно что сам Дэвид Андерсон говорит не совсем то что говорят многие люди вокруг канбана, он очень хорошо понимает что главная задача делать дело. Я понимаю обе стороны (agile манифест и автора). На текущий момент мне кажется что надо всё-таки понимать что разработка ПО это бизнес. И бизнес нужно понимать, а не гнуть пальцы. Иногда поддержка и маркетинг будут отдуваться за разработчиков, иногда наоборот. Нужно подбирать правильных людей в команду, управлять составом команды, вовремя выводить из неё ненужных людей и нанимать профи. Проверка гипотез — важная часть управления продуктом. И часто можно и нужно наговнякать в коде для проверки гипотезы. НО! Нужно оценить степень говнокодистости и влияния на проект принять решение, либо править, либо нет. Иногда пристройка должна остаться пристройкой. А иногда нужно всё переделать. Я сейчас работаю с проектом которому 7 лет. И там есть места где 6 лет торчит костыль. Он там описан, никому не мешает, вся команда знает что он там есть и работает для одного определённого функционала который за 6 лет прибыльности не потребовал доработки. Я сторонник подхода что при расширении успешного функционала нужно проводить ревизию архитектуры и думать, нужно переделать основание или нет. И делать это надо вне зависимости от того сколько там костылей. Это гигиена, надо улучшать — проверь фундамент. А если что-то есть и не растёт и не мешает, то просто так, по чьей-то прихоти менять код смысла не вижу. Если мешает то конечно надо править. Сейчас я не пользуюсь никакой методологией, мы просто работаем.
xitt
26.11.2018 19:14Аджайл это попытка примирить быстро меняющиеся бизнес-условия и технологический процесс. С моей точки зрения автор не противоречит, а дополняет — он всего лишь говорит что промашки менежмента не должны ложиться на плечи программистов, нельзя всех обезьян вешать на инженера, если на выходе хочешь получить качественный продукт. Хочешь менять требования — пожалуйста, но понимай, что это небесплатно. Извините если я где-то не прав или говорю банальности, но эти банальности на практике частенько забываются за баннером «Аджайл».
izvolov Автор
26.11.2018 20:06… он всего лишь говорит что промашки менежмента не должны ложиться на плечи программистов...
Это я тоже говорю. Но не только.
Vlad_fox
26.11.2018 12:04+3Неудачно сделанная работа по продажам или планированию не должна
и тут навстречу программисту идут со своим манифестом жесткие маркетолог и продажник.
И у них написано в манифесте:
«1. Только продажник может определить удачно или нет сделана работа по продажам.
2. Если кому-то кажется что неудачно — смотри п.1.
3. Продажи превыше всего, в жопу философствующих программистов — их дело — быдлокодить в срок и недорого.»DrunkBear
26.11.2018 12:48А потом приходит околотоп-менеджер и говорит — эта фича нужна сейчас! На проде. Ну и что, что регресс не пройден, я понимаю риски и беру на себя, уже же релизили так.
И тут ломается функционал прода. Тот же топ требует хотфикс, тестеры говорят — у нас регресс займёт 8 часов, мы не успеваем! Им отвечают — фиг с ним, у нас баг на проде, релизим! И релиз хотфикса ломает уже другой функционал, но гораздо больше и критичнее.
После этого начинается свара программистов и тестеров, тимлид рвёт седеющие волосы, всем весело.AstarothAst
26.11.2018 13:53А околотоп, который «взял на себя ответственность» разводит руками, и напоминает, что он не технический специались, и с него взятки гладки…
DrunkBear
26.11.2018 14:02Тестеры не убедили, программисты не сделали как раньше — ведь раньше работало и не крашило.
У программистов виноваты тестеры — сидят, нифига не делают, у тестеров один ответ — а мы предупреждали.
В сухом итоге виноват PM :)glestwid
26.11.2018 14:45+1Главное что околотоп продемонстрировал высший профессионализм в своей области — делегировать ответственность вниз. Ну а денежки — это себе на карман.
powerman
26.11.2018 14:58И тут ломается функционал прода. Тот же топ требует хотфикс, …
… и идёт лесом. Вместо хотфикса делается откат на предыдущую стабильную версию, и работа возвращается в штатное русло. В ответ на любые претензии ответ один: всю ответственность на себя взял вот тот топ, разговаривайте с ним. Претензии от этого топа не принимаются — мы предупредили что "не готово"? Ты не поверил и захотел убедиться? Ты убедился.
Хуже, если подход к разработке не подразумевает возможности быстро откатиться на предыдущую версию. В этом случае алгоритм должен быть такой: прод остаётся поломанным пока хотфикс не будет готов по штатному процессу, с 8-ю часами на регрессию, документирование, и всё остальное, что обычно делается. Если топа это не устраивает — он может снова взять на себя всю ответственность, и мы поломаем прод ещё раз. Дальше алгоритм возвращается в начало.
Если компания, в целом, адекватная — после этого случая мы данного топа больше никогда рядом с разработчиками не увидим. Если нет — уволят всю команду (и это хорошо, чем раньше уволишься из неадекватной компании — тем лучше). :)
marshinov
26.11.2018 18:05Это если вы можете откатиться на предыдущую версию. А бывают такие системы, которые очень-очень-очень много пишут. Постоянно.
Rhombus
26.11.2018 20:13+1Ага, или какие-то внешние регуляторные требования, типа известного GDPR. И попробуй откатись.
fcoder
27.11.2018 21:50Ну отсутствие CI в 2018 году говорит о компании даже больше, чем нетехнический топ, выкатывающий непротестированные релизы
powerman
27.11.2018 22:00Наличие CI/CD ещё не даёт гарантию возможности отката. Чтобы проект можно было спокойно откатывать нужно ещё как минимум реализовать (и тестировать!) автоматизированные миграции БД не только "вперёд", но и "назад".
foal
28.11.2018 01:46Угу, практически нереально, в сложных системах, где идет завязка кода не только на структуру данных, но и на сами данные (да, мы стараемся так не делать, но и 1% достаточно). То есть откатить можно, но безумно сложно :) Бакап перед релизом тоже не спасает — если ошибка не в первые секунды работы, то может накопиться слишком много новых данных, которые в старую структуру не запихаешь. Пичалька…
powerman
28.11.2018 02:30Бэкап обязателен в любом случае — некоторые миграции деструктивны (напр. удаление колонки из SQL-таблицы) и единственный способ их откатить это восстановить бэкап.
Что касается новых данных — не так часто выполняются деструктивные миграции, так что в большинстве случаев новые данные не проблема, а в оставшихся случаях лучше иметь возможность откатиться с потерей последних данных чем не иметь такой возможности в принципе.
transcengopher
28.11.2018 15:02Полезно, думаю, делать деструктивные изменения в базе делать не сразу, а, например, через релиз, по аналогии с удалением чего-то из PublicAPI проекта. То есть, перестали пользоваться полем в релизе A, пометили само поле как Deprecated, но именно удалять его будем только в релизе A+N. Правда, это в разы сложнее отслеживать, но зато откат проводить можно меньшей кровью.
powerman
28.11.2018 15:25Всё верно, но на практике это означает постоянную поддержку в текущей версии приложения двух версий схемы БД. Это банально дорого для большинства проектов.
transcengopher
28.11.2018 16:04Просто нужно определиться, что дороже — потенциальная невозможность откатить изменение схемы, или необходимость конкретное изменение поддерживать в течение некоторого времени, пока не станет ясно, что точно ничего не сломалось.
Разумеется, здесь каждый будет решать по себе, серебряных пуль не завезли.
dimm_ddr
27.11.2018 14:40+1Значит топ должен быть о таком варианте предупрежден и если настаивает, то весь простой — его вина. Я бы, как тестер, в таком случае попросил бы его написать явное распоряжение мне и разработчикам на почту, чтобы потом не было «Я такого не говорил», «меня не так поняли» и т.п. Собственно подобный мысленный эксперимент я проходил на одном из собеседований, которое собственно прошел. Лично, к счастью, именно такого не было. Фича в прод которая все поломает — была. Но менеджер который ее требовал признал что был не прав, все откатили и продолжили работать. Насколько я знаю там даже не менеджера вина была, а клиента, который из госструктуры, но как менеджер потом объяснял почему все поломалось и почему мы не виноваты я уже не знаю и знать не очень хочу.
asv4
28.11.2018 00:09+1если система очень-очень-очень много пишет, ее надо очень-очень-очень регулярно бэкапить.
InOdinWeTrust
27.11.2018 10:574. Программисты должны реализовывать функционал в том виде, в котором его описали продажники, а не придумали сами программисты.
OnelaW
28.11.2018 15:06Позволю с вами не соглашусь, хотя сам продажник. Производство программного продукта глобально не отличается от производства материального товара. Это я к тому, если на «придуманном» хлебозаводе невозможно изготавливать хлебобулочные изделия в виде правильного октаэдра, то ровно такие же ограничения есть при производстве программных продуктов. Если в интерфейсе программы нужно добавить ромбик «цветом бедра испуганной нимфы» в низу экрана, а технологически это невозможно, то как бы продажник не бил копытами, ромбик в низу экрана не появится.
MazayAl
26.11.2018 12:15Автору "+" за буйность!
Хотя вцелом не понравилось. Манифест это же про декларацию конкретных ценностей. Тут скорее какие-то мечты относительно того как достигать ценностей, причем безотносительно каких именно, что уже вцелом провал. «делать как надо» это не ценность (кому надо и что надо?). «качество» это сомнительная ценность, тут отсекаются все сколько-нибудь образованные менеджеры, которые знают про треугольник качество-время-бюджет. И что собраются делать со своим манифестом «жесткие программисты» при отсутствии образованых менеджеров? «концепция» вообще не может быть ценностью для программиста, программа может быть написана только по конкретным требованиям (о чем кстати потом и пишется, но логический переход к ценности некой «концепции» опущен, хотя весьма неочевиден).
Автору хорошо бы почитать хотя бы краткие методички о менеджменте, бизнесе (что-нибудь из бережливого производства для понимания природы изменчивости), инженерии (требования, архитектура, валидация для понимания как сейчас учитывается изменчивость) а потом переработать манифест в соответствии с последними достижениями. Мир уже давно страдает от описанных проблем, но простых решений нет, поэтому и безобразия много — делать «хорошо» нужно учиться.izvolov Автор
26.11.2018 12:17Аджайл-манифест читали? Какие конкретные ценности там декларируются?
DexterHD
26.11.2018 14:33Прочтите теперь хотя бы по одной книге каждого автора Agile манифеста, чтобы хотя бы в кратце понять о чем он. Уверен откроете для себя целую вселенную. Кстати, открою вам страшную тайну, большинство писавших этот манифест, программисты. И писали они его для программистов по большей части :)
izvolov Автор
26.11.2018 14:39… писали они его для программистов...
Неважно, что ты делал, важно, что ты сделал. Они могли хотеть писать его для программистов, но, увы, написали не для них.
DexterHD
26.11.2018 14:52Писали они это для профессиональных программистов. Уровня Senior и выше. Говорю же, прочтите хотя бы по одной книге каждого автора. Вы интерпретируете ценности манифеста по своему искажая реальную его суть. Вы удивитесь сколько там есть вещей «защищающих» разработчиков от менеджмента (если вам это важно), если глубже разберетесь в теме.
izvolov Автор
26.11.2018 14:54А я утверждаю, что это вы не до конца прочувствовали суть происходящего. Один из нас точно неправ.
arilou_camper
26.11.2018 12:37+1Автор, извините, но вы ни-че-го не понимаете во взаимосвязи процесса разработки ПО с другими процессами внутри компании, а также со внешними факторами, влияющими на неё. Ваш «манифест», извините, выглядит как продукт максималистического мышления. Не перехожу на личности, но между строк читается незрелость вас как инженера.
Модель разработки «it’s done when it’s done» подходит крайне ограниченному набору ПО в исключительно редкой ситуации наличия у компании «неограниченных» ресурсов. Во всех остальных случаях определяющую роль играет время вывода на рынок новой функциональности с приемлемым качеством.
Agile-подход как совокупность практик позволяет добиться баланса между скоростью вывода на рынок, качеством продукта и качеством исходного кода. Ваш же манифест вряд ли приведёт к чему-то отличному от «задрачивания на код».izvolov Автор
26.11.2018 13:24… вы ни-че-го не понимаете во взаимосвязи процесса разработки ПО с другими процессами внутри компании, а также со внешними факторами, влияющими на неё.
Я думаю иначе.
Agile-подход как совокупность практик позволяет добиться баланса между скоростью вывода на рынок, качеством продукта и качеством исходного кода.
Аджайл-подход превозносит интересы одного круга лиц над интересами другого круга лиц.
Не перехожу на личности, но между строк читается незрелость вас как инженера.
Незрелость проявляется в том, что я призываю отстаивать свои интересы?
altrus
26.11.2018 13:30+1Незрелость проявляется в том, что я призываю отстаивать свои интересы?
Незрелость проявляется в том, что вы используете придуманные вами термины — «матмодель ПО».
Отсюда сразу же следует, что вы не знаете, что такое математическая модель, и каким образом происходит создание архитектуры программной системы. И фантазируете на ходу, приставляя одно умное слово к другому.
Это неуважение к тем людям, которые знают эти термины.CheatEx
27.11.2018 14:48Ой, а расскажите что они таки значат?
altrus
27.11.2018 14:54-1Они значат, что паясничать на Хабре — моветон.
CheatEx
27.11.2018 15:02+2Простите пожалуйста, редко сюда заглядываю, не в курсе нюансов этикета.
А надувать щёки и рассказывать что точно знаете Правильное Значение Слова а кто не знает тот джун/студент и не имеет права писать — норм?
arilou_camper
26.11.2018 13:35Это какие такие интересы превозносятся? Не дают инженеру играть в песочнице, пока не стемнеет?
Ваш «манифест» — однобокий взгляд, не демонстрирующий понимания, в отличие от авторов agile, которые искали практики, учитывающие интересы и потребности обеих сторон.
// никогда не думал, что буду защищать agile от нападок программиста
А что касается незрелости — я уже написал. Вы — максималист, это даже между строк читать не нужно.
Ничего личного. Просто надо побольше профессионального опыта приобрести, и побывать за пределами уютной IDE-шки.izvolov Автор
26.11.2018 14:44… искали практики, учитывающие интересы и потребности обеих сторон.
Искали, но, увы, не нашли.
Просто надо побольше профессионального опыта приобрести, и побывать за пределами уютной IDE-шки.
Проблема сильно глубже, чем вам кажется.
random1st
27.11.2018 17:45studfiles.net/preview/3801958 Основная мощность системноинженерного подхода именно в разрешении конфликтов.
AstarothAst
27.11.2018 22:16+1Вы знаете, совершенно не собираюсь спорить с тем, что «when it's done» приминим далеко не всегда, но не могу не заметить, что зачастую гонка из-за
определяющую роль играет время вывода на рынок новой функциональности с приемлемым качеством
совершенно не оправданна. Множество раз я наблюдал, как т.н. «бизнес» давит «нужно скорее, быстрее, давайте-давайте, очень все ждут», по итогу выкатывается решение с тем самым «приемлемым качеством», которое по факту обозначает огрехи в проектировании, костыли, говнокод и все прочие падучие, а в ретроспективе оказывается, что этот функционал ждали годами, и никто не умер. И если бы прождали еще месяц, то тоже никто бы не умер. И это был тот самый месяц, которого не хватило что бы выкатить нормальное решение, которое позволит себя расширять и менять. А все пляски с саблями обусловлены единственно тем, что кто-то — мы знаем кто! — пообещал, назвал сроки, завысил ожидания и возбудил аппетит. И как раз аджайл такой подход провоцирует. Поэтому все же иногда бывает разумно упереться рогом, и заявлять, что готово будет тогда, когда будет готово. Естественно этого никто не потерпит, и придется идти на компромисс, но этот компромисс будет уже более компромиссным, чем если бы рогом не упираться, а только кивать головой. В общем иногда баланс можно достичь только будучи не гибким и упертым бараном.arilou_camper
27.11.2018 22:42Бывают плохие команды, не спорю, бывает, не везет с менеджментом.
НО ЭТО НЕ отменяет важность time to market. Да, очень много продуктов имеет красивую обертку, но ужасное подкапотное пространство. Но это реальность большинства проектов. Продукт нужно запускать быстрее, а после запуска и в случае успеха уже от СТО зависит, какое качество будет у кода.izvolov Автор
27.11.2018 22:45Продукт нужно запускать быстрее...
Кому нужно? Почему? Чем это обосновано, кроме "рынка"?
arilou_camper
27.11.2018 22:50Владимир, ответьте на мой вопрос ниже. Ваш манифест решает те потребности бизнеса, которые я там озвучил?
Кому нужно? Почему? Чем это обосновано, кроме «рынка»?
Это нужно бизнесу, потому что ROI и window of opportunity. Это обосновывается исключительно потребностями рынка, потому что, сюрприз, продукты выпускаются с целью зарабатывания денег, и должны решать проблемы рынка.izvolov Автор
26.11.2018 23:01ROI и window of opportunity
Я вас не понимаю. Пожалуйста, вернитесь к нам, простым русским ванькам.
P.S. Я не Владимир. Не понимаю, откуда это взялось.
powerman
26.11.2018 23:08+1Ваня, оба термина без проблем гуглятся, не стесняйтесь пользоваться поисковиками: Окупаемость инвестиций, Window of opportunity.
P.S. Я знаю, как Вас зовут (на гитхабе посмотрел), просто не удержался от стёба в ответ на "простым русским ванькам", простите. :)
izvolov Автор
26.11.2018 23:21Дело не в том, что я могу или не могу что-либо наяндексить, и не в том, что я что-то знаю или не знаю.
Дело в том, что, когда собеседник внезапно начинает сыпать аббревиатурами и иностранными словами, можно смело начинать "ставить диагноз".
arilou_camper
26.11.2018 23:42Дмитрий, вы — хам и тролль. Если вы не понимаете,
— почему эти два термина являются ответом на вопрос, кем, почему и чем обоснована необходимость выпуска достаточно качественных продуктов в определенный срок и бюджет
— зачем нужна методология, которая решает эти проблемы
то вести конструктивный разговор с вами невозможно.izvolov Автор
26.11.2018 23:55Спокойнее. Просто вы привыкли, что вам все верят на слово. Но так вышло, что сегодня это не работает.
Ролевая игра.
Я — программист.
Вы — наниматель.
Пожалуйста, смотивируйте меня броситься соблюдать сроки, если я знаю, что мне требуется на проект три месяца, а "рынок требует" выпустить его через два.
powerman
27.11.2018 00:11Извините, что вмешиваюсь в ваши ролевые игры, но это не сложно:
- Дмитрий, если Вы пришли в нашу компанию для того, чтобы получать два месяца зарплату за бесполезную деятельность по написанию кода, который никогда не будет запущен — пожалуйста, напишите заявление по собственному прямо сейчас, и успехов Вам найти работу в компании, которой надо то же самое, что и Вам.
- Если Вы хотите сделать что-то полезное, то учитывайте, что вне зависимости от качества и функционала продукта он окажется бесполезен, если мы не выпустим его на рынок через два месяца.
- Если Вы уверены, что запланированный функционал с необходимым качеством невозможно выпустить через два месяца — давайте вместе согласуем альтернативу, урезанную по функционалу и/или качеству, которую реально выпустить через два месяца, и которая будет всё ещё достаточно полезной, чтобы у нас был реальный шанс получить достаточно средств для продолжения разработки этого продукта.
- Если Вы не видите возможных альтернатив, и считаете поставленную задачу невыполнимой — пишите заявление по собственному, наша компания либо закроется на два месяца раньше (если никаких вариантов вовремя сделать продукт действительно нет), либо мы наймём другого разработчика, который такие варианты сможет найти.
izvolov Автор
27.11.2018 00:15Это всё сразу, или это варианты?
izvolov Автор
27.11.2018 00:19Вообще, на этом месте игру нужно уже заканчивать, потому что сразу же пошло именно то, ради борьбы с чем мы тут собрались: хамское давление с нарушением ТК.
Следующее действие — звонок в трудовую инспекцию.
DexterHD
27.11.2018 00:41Следующее действие — увольнение по инициативе работодателя и можете идти с этим в суд. :)
izvolov Автор
27.11.2018 00:46Номер статьи? И не сомневайтесь, суд будет выигран, и будет выплачена зарплата за всё время "простоя", а также за нанесение морального вреда. Изучите статистику на этот счёт.
DexterHD
27.11.2018 00:58Уволим вас по сокращению с выплатой вам всех положенных компенсаций. Удачи в суде. Не понятно только за что вы будете судиться? Ведь все ваши права будут соблюдены.
izvolov Автор
27.11.2018 00:49Наконец-то, ну наконец-то вы проявили свою истинную сущность. Менеджерский произвол, о котором тут и идёт речь. Спасибо за наглядную иллюстрацию, Антон.
DexterHD
27.11.2018 00:56+3Только вот незадача, я программист а не менеджер. И да, я не работаю с людьми считающими что они имеют право в рабочее время прокачивать за счет нанимателя свои скиллы.
Вы в общем тоже проявили вполне свою сущность. Вы не заинтересованы работать. Все что вас интересует, это паразитирование на ТК и имитация бурной деятельности за счет работодателя. Это кстати зафиксировано в первом принципе вашего манифеста.
Вам предложили целую кучу вариантов, но вы сразу начали шантаж трудовой инспекцией. Т.е. вас не устроил не один из вариантов. Вы априори считаете что вы всегда правы, а работодатель это такой детский садик, где должны платить деньги просто за то что у вас корочка «программист». О чем можно с вами договариваться?
powerman
27.11.2018 00:36+2Это пошаговый алгоритм ведения диалога — по сути, да, варианты. Если эти варианты Вас не устраивают — не вопрос, предлагайте свои, у меня, как у нанимателя, нет цели ограничить Вас этими конкретными вариантами, моя цель выпустить продукт на рынок через два месяца чтобы заработать денег на продолжение разработки продукта, и любые варианты, ведущие к этой цели, я готов рассмотреть.
А в чём именно нарушение ТК, просто любопытно? Если Вы не можете выполнить ту работу, за которую я готов платить — значит либо это невозможная работа, либо просто для этой работы нужен другой исполнитель. В любом случае, если другой работы конкретно для Вас у меня нет, то Вы — уволены. Или ТК запрещает мне Вас увольнять? Я-ж не говорю "чтоб завтра ноги твоей не было в офисе, и зарплату за предыдущий месяц мы тоже не выплатим" — уволим по ТК, две недели или какие там в России правила, суть ведь вовсе не в этом.
Что до хамского давления — простите??? Где Вы усмотрели хамство? Мне нужно выполнить конкретную работу, я ищу под эту работу исполнителя, готов согласовывать с исполнителем разные варианты как её можно сделать… Если исполнитель не в состоянии сделать эту работу мы просто отказываемся от его услуг и ищем другого исполнителя, либо отказываемся от идеи реализовать именно этот продукт. Что тут можно было найти хамского…
izvolov Автор
27.11.2018 00:46Игра окончена, Алексей. Я "попал" в какую-то быдлоконтору.
Разумеется, хамство — это просить уволиться по собственному. Разумеется, ТК запрещает увольнять сотрудника, обладающего подходящей квалификацией. Единственное, что можно предложить — это увольнение по соглашению сторон с выплатой выходного пособия за три месяца.
Единственно верным был вариант №3, но почему-то он не был главным и единственным. А главным оказался шантаж. Вот, собственно, и иллюстрация к основной теме нашего разговора.
powerman
27.11.2018 02:00Александр. :)
Я же не настоящий
сварщикнаниматель, я не знаю как нужно увольнять по вашему ТК, но, уверяю, увольнение с нарушением закона мной не подразумевалось. Я вообще не уверен, что меня увольняли хоть раз в жизни, вроде бы нет, так что у меня мало опыта в том, как это правильно оформляется.
Вариант №3 не был единственным просто потому, что жизнь штука сложная, и вариантов всегда больше одного. И нет, если Вам показалось, что какие-то из этих вариантов главнее других — то Вам просто показалось.
Шантажа среди вариантов не было вообще, есть работа, и либо Вы можете её сделать, либо нет — у меня нет цели как-то Вас шантажировать, уговаривать или упрашивать, моя цель — получить продукт через 2 месяца, и это единственное, что меня волнует в этот момент. Выберете третий вариант — супер, мне он тоже подходит больше других, потому что остальные подразумевают срочный поиск другого исполнителя, а время поджимает. Выберете не третий — Ваше право, я не могу принуждать Вас делать работу, которой Вы не считаете для себя возможным заниматься, у нас ведь не рабство.
Между прочим, я лично не раз отказывался от работы по четвёртому варианту, и никогда это не было проблемой ни для меня, ни для нанимателя. Просто в моём случае речь идёт о фрилансе, так что формально это не было увольнением, я просто отказывался браться за работу, которой не считал для себя возможным заниматься (и да, это нередко было связано с тем, что заказчику был нужен говнокод, и я даже нередко с ним соглашался, что да, здесь и сейчас ему нужен именно говнокод, просто я не собирался участвовать в его написании — но были и другие варианты, например утилиты для рассылки спама я тоже отказывался писать, из моральных соображений — хотя чисто в техническом плане задача интересная). Более того, мой отказ ещё ни разу не послужил помехой продолжить сотрудничество с теми же заказчиками, как только у них появлялась для меня работа, которой я был готов заниматься.
Ладно, ночь уже, пора заканчивать это развлечение. Я так понимаю, Вы эту ролевую игру слили (придирки к форме оформления увольнения не могут являться осмысленным ответом, или Вам есть что ответить по сути вопроса)?
Ndochp
27.11.2018 09:33Вы не можете уволить работника, чтобы нанять еще одного если он формально подходит. Только через оргштатные с сокращением ставки. А если через 3 дня ставка откроется снова, то уволенный имеет преимущественное право на восстановление.
powerman
27.11.2018 14:50+1Вы как-то упускаете из виду, что в данный момент компании нужен не "разработчик PHP", а "разработчик который может реализовать этот проект за два месяца". Если текущий это сделать не в состоянии — значит его квалификация не соответствует требованиям этой позиции. Опять же, я без понятия как это нужно оформлять юридически, но, очевидно, если компании нужен сеньор, то у неё есть возможность не допустить мидла на эту позицию. Равно как и если ей нужен рок-стар вместо обычного сеньора, то компания сможет убрать из штата позицию "старший разработчик" и заменить её позицией "ведущий разработчик" или ещё как-то, чтобы иметь легальные основания доказать, что текущий разработчик ей действительно сейчас не подходит.
FreeMind2000
27.11.2018 13:42+1Я — программист.
Вы — наниматель.
Вы эту ролевую игру слили
Согласен, позиция izvolov в предложенной им же игре слабее чем у Вас… но, просто он выбрал заранее проигрышный вариант игры, где его же 3й постулат манифеста «Делать как надо важнее, чем делать как просят» — заведомо не выполняется, т.к. наниматель волен ставить перед подчиненным любые задачи и требовать их выполнение в любые сроки, подчиненному остается либо согласиться и пахать в 3 смены, либо уволиться.
Правильная ролевая игра выглядит так:
Я — программист.
Вы — менеджер.
Т.е. тут нет иерархии отношения начальник -> подчиненный, здесь обе стороны равноправны и должны договариваться чтобы согласовать проект.
И тогда нам открывается скрытый пятый вариант:
5. Если Вы как менеджер ставите заведомо не выполнимую задачу (разработать продукт Х за время Т), то я могу дать Вам встречное предложение — отказаться от разработки продукта Х за время Т, а поработать головой и придумать другой продукт Y, который можно разработать за реальное время Т2.
Чувствуете разницу? :)
Это не менеджер заставляет программиста работать (писать плохой код и потом в сверхурочные его править), а программист заставляет работать менеджера (придумывать продукты реализуемые в реальные сроки).
Даже если контора обанкротится через 2 месяца, то виноват будет не программист, который сделал плохой продут, а менеджер, который не придумал тот продукт, который спасет контору.arilou_camper
27.11.2018 14:26+1ну в ситуации эскалации конфликта он все равно дойдет до уровня человека, который имеет право увольнять, и кто-то вполне может быть сокращен.
в нормальной ситуации ваш вариант в целом равнозначен вышеупомянутому варианту №3
Даже если контора обанкротится через 2 месяца, то виноват будет
Виновата будет команда, не сумевшая предложить и реализовать вменяемую альтернативу.FreeMind2000
28.11.2018 13:54в нормальной ситуации ваш вариант в целом равнозначен вышеупомянутому варианту №3
Нет, это как раз альтернативное развитие ситуации в случае отсутствия консенсуса при варианте 3, вместо дальнейшего варианта 4 (увольнение программиста), мы рассматриваем вариант 5 (увольнение менеджера).
Если удается договориться на варианте 3, то это идеальная ситуация, когда и волки сыты и овцы целы, но обычно в 90% случаях так не получается, потому что если новые требования к продукту не требуют кардинальной переделки существующей архитектуры или инструментов, то с реализацией в «нормальном» режиме проблем нет, мы просто ограничиваем ф-ционал, чтобы уложиться в срок, а если требуют – то тут никакое ограничение ф-ционала не возможно, так как нет базового фундамента на котором вообще его строить, а для «правильной» разработки этого фундамента требуется заведомо больше времени чем выделено.
кто-то вполне может быть сокращен.
Именно так.
Если менеджер не соглашается на вариант 5, то у руководителя конторы появляется дилемма, зависящая от его идеологии:
- Либо уволить «жёсткого» программиста (если руководитель адепт AGILE)
- Либо уволить менеджера (если руководитель адепт ANTI-AGILE)
Причина увольнения проста – с точки зрения выбранной идеологии либо тот, либо другой «плохо работает» и третьего не дано.
Виновата будет команда
Групповая ответственность — это отсутствие ответственности. В нашей игре реально плохо работать (некомпетентными) могут быть как программист, так и менеджер, но главный виновник, конечно, это руководитель конторы, который набрал команду и не смог организовать правильно её работу, и возможно, самое главное — выбрал неверную идеологию. А судьей является рынок, на котором будет или не будет получена прибыль.arilou_camper
29.11.2018 13:03Отвечу только на «групповую ответственность». Это распространенное заблуждение — так реагировать на фразу «виновата команда» )
- «Команда» — группа людей, поставленная заниматься конкретной задачей
- «Виновата» — не смогли найти решение, удовлетворяющее поставленным целям
В реальности, невозможность прийти к решению в команде всегда будет эскалирована на уровень выше, и, почти всегда, там будет принято решение, которое команде надо будет имплементировать.
но главный виновник, конечно, это руководитель конторы
Часто вижу такое утверждение. Наверное, это какое-то желание хоть в чем-то иметь возможность обвинить «руководителя конторы». На практике, никакого чувства вины там нет. Есть риск, есть награда. Получилось — отлично, всем хорошо (команде в том числе), не получилось — надо что-то корректировать и предпринимать дальше.
Надеюсь, понятно объяснил.
lingvo
27.11.2018 00:17Извиняюсь, что вмешиваюсь, но мне очень интересно узнать что может быть за программный продукт, который был бы полезен, будучи выпущенным за 2 месяца, но полностью бесполезным, будучи выпущенным за 3?
Честно.powerman
27.11.2018 00:24Откуда берётся такая цифра, и насколько она, на самом деле, оправдана — я уже отвечал ниже.
arilou_camper
27.11.2018 01:35В контексте этого разговора под продуктом может пониматься фича или их группа, которые нужно выпустить на рынок раньше конкурентов.
Dr_Faksov
27.11.2018 08:43Топовый мобильный телефон, анонс которого с точной датой представления был сделан полгода назад. Если вы не сможете показать его на текущей выставке, то к следующей он уже УСТАРЕЕТ а покупать будут почти такой, но у конкурентов.
А вообще разработка ПО для топовых моделей, да под новый процессор — ад. Работа месяцами по 14-16 часов в сутки с одним выходным в неделю- норма. Процессор НИКОГДА не появляется вовремя. Отладка идёт на уровне «абы явно не глючило»Aquahawk
27.11.2018 09:34А сколько софта зависит именно от проца?
cyberly
27.11.2018 10:00Как я понимаю, от проца сильно зависит, например, камера (потому что он содержит специальные блоки для обработки данных с сенсора). А если, скажем, возможности камеры — киллер-фича конкретного телефона, этого должно быть уже достаточно.
CheatEx
27.11.2018 14:59Нескромный вопрос, а зачем? Нормальный пакет акций или зарплата которая позволяет годик пожить на бали?
OnelaW
28.11.2018 15:22Прежде чем маркетологи и прочие продажники анонсируют потенциальным заказчикам о новом решении, в первую очередь продуктовая команда прорабатывает возможность реализации данного решения в заданные сроки. Так называемая дорожная карта. Любое озвученное отклонение от дорожной карты, карается увольнением менеджера допустившего это.
marshinov
27.11.2018 08:56Например ПО для выставки, которая будет проходить в течение трёх дней ровно через два месяца
lingvo
27.11.2018 09:17+1Я понимаю случай с ПО для выставки, когда надо продемонстрировать хоть что-то и это лучше, чем ничего.
Но вот в случае с топовым телефоном не очень согласен. Если считать, что программист прав (agile подразумевает ответственную самоорганизующуюся и квалифицированную комманду)- и нужный софт делается за три месяца, то на рынок выведется очередной говнотелефон с глючным софтом, который повлечет за собой провальные масштабы продаж. Кто это считает?
Ну и вообще с точки зрения общества лучше бы, чтобы таких продуктов поменялось поменьше, но бизнес стремится к другому.
difference
28.11.2018 20:29что это ещё за вброс?
Гипотетический наёмный рабочий, если он квалифицированный профи, он знает себе цену, и на всю эту демагогию не поведётся, Думаю, он мог бы просто ответить такое:
— я работаю на результат, т.е. с толком, но в течении 40 часов в неделю, и беру за это деньги. А задача уложиться в срок — это задача менджмента, а гробить здоровье ради чужих целей, и бизнеса, с которого я не получу процент в любом случае, не собираюсь.
И это всё, скорее всего, было бы сказано достаточно тонко, но со знанием дела.powerman
28.11.2018 20:36Вы где-то между строк вычитали предложение работать сверхурочно? Вам показалось, я ничего такого не подразумевал.
Вариант поработать больше нормы есть всегда, и иногда он действительно может быть одним из решений проблемы со сроками, но это штука стрёмная, с кучей побочных эффектов, и может использоваться только по обоюдному согласию.
powerman
26.11.2018 23:00+3Это обосновано тем, что если выйти на рынок слишком поздно, то продукт окажется никому не нужен (или нужен в недостаточной степени, чтобы доходы позволили продолжать его разработку), бизнес закроется, разработчиков уволят. Я такое наблюдал лично ранее, и наблюдаю прямо сейчас на текущем проекте (собственно, именно по этой причине я треплюсь весь день на хабре вместо того, чтобы работать).
Если Вы имели в виду то, что зачастую менеджеры сильно преувеличивают критичность выхода на рынок именно через два месяца, а не, например, через пол года — то это правда. Они сами зачастую нифига не знают наверняка, паникуют и перестраховываются. Но! Именно они являются экспертами в этой области (бизнеса и рынка) — по крайней мере формально, и других экспертов всё-равно нет. Поэтому разработчикам ничего не остаётся, как принимать их оценку time to market, и исходить из неё, даже если она некорректная. Менеджерам ровно так же приходится принимать мнение разработчиков про разные фреймворки/ЯП/рефакторинг, даже если квалификации разработчиков недостаточно и они несут полную чушь — пока в команде нет других, более квалифицированных, приходится верить этим.
Если Вам кажется, что закрытие бизнеса (из-за срыва time to market) не является проблемой разработчиков, то у меня вопрос: какой смысл без спешки писать качественный код, если этот качественный код будет выброшен вместе с бизнесом ещё до того, как его увидят реальные пользователи? Может кому-то нравится, когда его работу выбрасывают, но мне — не очень. И качество кода важно только тогда, когда этим кодом кто-то пользуется.
DrunkBear
27.11.2018 10:41Думаю, именно с такими мыслями в релиз выпустили последних Heroes of M&M, мир праху этой серии.
При этом, через месяца 2-3 в игру стало можно играть без консоли разработчика, но слишком поздно.ky0
27.11.2018 11:17Подождите-подождите, есть же намного более яркий и свежий пример — Fallout 76 :) Спустя месяц после релиза уже делают скидки чуть не в половину цены, лишь бы купили. Но ТТМ наверняка был на высоте, да.
OnelaW
28.11.2018 16:31Несправедливость какая то)), на инди-песочницы выживалки, которые в раннем доступе и то меньше наезжали.
ky0
28.11.2018 16:45Инди-песочницевыживалки не позиционируют себя, как продолжения одной из лучших серий игр и отношение к ним соответствующее.
Все понемногу привыкли к маразму с платными бета-тестами, называемыми ранним доступом, перезапусками невзлетевшего и прочими прелестями, кстати, довольно похожими на аджайловские «минимально рабочие продукты» и т. д.OnelaW
28.11.2018 17:15Вот это точно подмечено. Пользователи ожидают получить что-то полноценное, законченное и понятное.
А самое главное потребители могут сколь угодно долго сидеть и питаться обещаниями если в конце они получат полноценное, законченное и понятное. Но стоит учитывать что терпение тоже имеет срок(HL3).
lingvo
27.11.2018 18:16Ну так мы имеем классическую диллему проект-менеджмента — либо страдает качество, либо сроки, либо стоимость. Нельзя оптимизировать сразу все три параметра.
И Agile в этом смысле поможет ровно настолько, насколько умна и опытна команда разработчиков. Т.е. жизнь бизнеса начинает зависеть не от менеджмента, а от разработчиков. Попытка переложить ответственность, наверное.
s-kozlov
27.11.2018 16:33+1Чем это обосновано, кроме «рынка»?
Ээ, а зачем искать другие обоснования, когда «рынок» — то, ради чего создается ПО?
AstarothAst
27.11.2018 10:26Вообще-то продукт «нужно запускать быстрее» только тогда, когда это действительно нужно, а TTM не является святым граалем, на который нужно равняться всегда и везде. Думаю, чаще ситуация как раз такова, что конкурента, который дышит в затылок прямо сейчас, нет и в помине, а появится он только тогда, когда продукт будет запущен, и все увидят, что эту грядку можно и нужно пахать. И вот тогда-то начнется гонка — в которой можно будет запросто проиграть, потому что нужно ехать, а у вас костыли. ТТМ бывает разным…
Cyrus
26.11.2018 12:42Подход выглядит как противостояние с менеджером и понимание исполнения задачи как самоцели.
Иногда гибкость разработчика является дополнительной ценностью, которая продается или обменивается на взаимную лояльность.
nicholas_k
26.11.2018 12:45+1Я вижу в этом манифесте много об удовлетворении программиста, но где же в нем про продукт и бизнес?
Устраиваясь на наемную работу за деньги, я ставлю во главу угла деньги, потому что получать удовольствие от программирования я могу и без найма.
А деньги нам дает бизнес. Иногда, чтоб бизнес получил деньги, надо идти на компромиссы, иногда на неприятные. Agile дает нам возможность взаимодействия с теми, кто дает нам деньги и ставит во главу угла продукт, каким он нужен бизнесу. А ваш манифест просто ставит во главу устройство программного обеспечения в том виде, который нравится вам.
Хорошо крутить носом перед работодателем и заказчиком, когда на одно резюме десять вакансий. А если бы было иначе?menstenebris
26.11.2018 13:47А вы никогда не думали что наемный работник всегда будет на одной стороне, а работодатель на другой? Любой человек который любит свою работу будет хотеть делать ее качественно. Просто наемный работник отказывается от результатов своей работы в пользу работодателя, в связи с чем резко падает мотивация к этой самой работе. Именно этот недостаток agile и пытается устранить (помимо остального). Убедить вас в том что ценности работодателя это и ваши ценности тоже (хотя это не так).
nicholas_k
26.11.2018 14:15А вы никогда не думали что наемный работник всегда будет на одной стороне, а работодатель на другой?
Нет, не думал. Ведь наличие денег у работника определяется наличием денег у работодателя. Работнику не очень то выгодно банкротство работодателя, ведь так?
Убедить вас в том что ценности работодателя это и ваши ценности тоже (хотя это не так).
Простите, но разве получение денег не является общей ценностью для всех людей, которые вступают в трудовые отношения? Конечно, наемник хочет себе побольше денег, а работодатель себе. Но ценности то общие.
Просто наемный работник отказывается от результатов своей работы в пользу работодателя, в связи с чем резко падает мотивация к этой самой работе.
Хм, очень спорный момент. Работодатель ведь не просто отнимает результаты труда. Работодатель покупает их. Соответственно если у работника нет мотивации давать результат, то у работодателя нет мотивации платить деньги. Это с вашей точки зрения справедливо?arilou_camper
26.11.2018 14:31Работнику все равно. Ведь вакансии к резюме идут десять к одному.
</сарказм
exehoo
26.11.2018 14:40Ведь наличие денег у работника определяется наличием денег у работодателя. Работнику не очень то выгодно банкротство работодателя, ведь так?
«Стокгольмский синдром»?powerman
26.11.2018 15:08Нет, это из другой оперы: не будь мудаком.
Понятное дело, что наёмный работник не обязан лезть из кожи вон ради развития бизнеса своего работодателя. Но и игнорировать интересы того, кто тебя нанял заниматься вполне определённой работой за деньги, на что ты сам добровольно согласился при найме — это тоже некорректно.
exehoo
26.11.2018 15:38+1«не будь мудаком» ведь в обе стороны работает, не так ли?
Адекватный работодатель отдает себе отчет в том, что работнику, конечно, банкротство не выгодно, но в большинстве случаев не фатально. Если работодатель не дает работнику ощутить удовлетворение от собственного труда, то такой работодатель сам себе злобный буратино — хуже фрустрированного работника только разочарованная жена.powerman
26.11.2018 16:04Я никогда не сталкивался с работодателями, которые бы стремились лишить разработчиков удовлетворения от собственного труда. Никому из работодателей просто не было до этого никакого дела — они нанимают разработчиков для вполне определённых задач, среди которых получение удовлетворения от собственного труда не числится.
Мы сами должны уметь организовать свою работу так, чтобы и задачи работодателя выполнять, и удовлетворение от работы получать. Если не получается — надо либо учится это делать, либо менять работу. Ждать, что работодатель будет бегать вокруг разработчиков с охами и ахами, и каждый день интересоваться, получаем ли мы удовлетворение от работы, и чем он может помочь если мы вдруг его перестали получать — даже не знаю, как это назвать, слово "наивно" как-то слабо смотрится в этом контексте.
Да, работодатель обычно заинтересован в поддержании хорошего психологического климата в коллективе, но не надо совсем уж наглеть, считая что он должен нам сопли подбирать и утешать, если наша игрушка поломалась. В конце концов между работодателем и мамой есть разница — работодатель считает нас взрослыми, и относится соответственно.
izvolov Автор
26.11.2018 16:07Ждать, что работодатель будет бегать вокруг разработчиков с охами и ахами...
О том и публикация, что надо не ждать, а идти и разговаривать. А если понадобится — требовать. Права — они такие. Пока не потребуешь — не отдадут.
powerman
26.11.2018 16:24Добиваться соблюдения своих прав — это одно. Но не надо записывать меня в сторонники этого "манифеста". Есть немало ситуаций, в которых изложенные в нём идеи абсолютно корректны. Немало — это примерно 10-20%. Следованием этим идеям в остальных случаях будет только создавать проблемы, а не решать их.
Стандартный пример — разработка прототипа. Категорически несовместима вообще ни с чем из этого манифеста. Я лично просто стараюсь в разработке прототипов не участвовать вообще, потому что да, конкретно у меня удовлетворение от работы при этом обычно заменяется отвращением. Но если я соглашаюсь писать прототип — я не буду ставить качество превыше скорости, как бы мне этого не хотелось, потому что прототипу качество не требуется, а трата кучи времени на ненужные этому проекту вещи является либо признаком недостаточной квалификации, либо осознанным саботажем.
exehoo
26.11.2018 17:54Стандартный пример — разработка прототипа. Категорически несовместима вообще ни с чем из этого манифеста.
Я вообще-то мимокрокодил, но поясните, пожалуйста, что вы этим хотите сказать? Потому что имхо не просто совместимо, а ну как иначе-то?
Концепция важнее новых требований — да. Если взялись разрабатывать автомобиль, то на выходе должен быть автомобиль, а не летающая субмарина.
Качество важнее скорости — да. Прототип автомобиля должен ездить, и пока он не ездит работа не закончена — жесткие сроки на невозможны.
Делать как надо важнее, чем делать как просят — да. Если заказчик требует установить руль под капотом, то следует игнорировать эти требования.powerman
26.11.2018 18:21+2На всякий случай уточню очевидное: всё нижесказанное подразумевает, что прототип работоспособен, хотя бы в минимально-достаточном объёме.
Концепция важнее новых требований — нет. Мы прототип делаем, а не автомобиль. Разница в том, что когда мы делаем автомобиль — у нас есть концепция, и мы знаем, что хотим получить. А когда мы делаем прототип, мы его делаем как раз потому, что сформировавшейся концепции пока ещё толком нет, и что конкретно мы хотим получить мы ещё сами толком не знаем.
Качество важнее скорости — нет. Понятно, что прототип должен работать, никто не говорит, что его качество не имеет значения вообще. Но оно ни в коем случае не важнее скорости — т.е. выбор между (необязательным, потому что кое-как оно и без этого работает) улучшением качества и (тоже необязательным, потому что при необходимости можно и чуть позже релизнуть) увеличением скорости всегда делается в пользу скорости.
Делать как надо важнее, чем делать как просят — нет. Если заказчик требует установить руль под капотом, то для таких экспериментов прототипы и нужны, мало ли, может он знает какой-то секрет, и такое местоположение руля окажется уникальной киллер-фичей.
exehoo
26.11.2018 19:44+1Спасибо, теперь понятно, в чем мы расходимся.
Я-то всю сознательную трудовую жизнь считаю, что концепция вырабатывается (и объясняется исполнителю!) еще до начала работы руками. Прототип начинают делать после того, как определились с концепцией. Т.е. «автомобиль с рулем под капотом», с учетом вашей поправки, это и есть концепция = условие задачи = «как надо». Если разработчик понимает, что заказчику нужна киллер-фича, то результат будет такой, какой нужен заказчику. А если разработчик не понимает смысла того, что от него требуют, то результата может не быть вовсе (руль будет где просили, но авто ехать перестанет, например).
С другой стороны, сержантский метод руководства («отставить разговорчики и выполнять приказ!») тоже вполне эффективен. Разве что слабо применим, когда от исполнителя требуется думать головой.
И еще одно разночтение: Качество кода важнее скорости его написания. Я всеми руками за то, чтобы разработка велась максимально быстро, но не в ущерб же качеству кода! А то как в анекдоте: «Я печатаю со скоростью 600 знаков в минуту. Тааакая фигня получается!»powerman
26.11.2018 20:47Хорошо, что Вы что-то поняли. Плохо, что я, наоборот, запутался: объясните тогда, пожалуйста, как при Вашем подходе отличается разработка прототипа проекта от разработки самого проекта? Или они у Вас не отличаются никак — для разработки обоих должна быть заранее определена концепция, код пишем одинаково качественно (и, соответственно, с одинаковой скоростью), если новые изменения противоречат архитектуре мы её перепроектируем, сопровождаем код тестами и документацией… всё верно?
exehoo
26.11.2018 23:41Терминология иногда заводит в дебри. Мы не разрабатываем прототип проекта, мы делаем прототип продукта.
Если новые пожелания заказчика противоречат готовой архитектуре, то заказчику следует подробно разъяснить проблему. Хорошо проинформированный заказчик обычно не склонен ломать несущие стены.powerman
27.11.2018 00:19В данном контексте я рассматриваю проект и продукт как синонимы. Прототип проекта/продукта — это нечто, что выглядит похожим на требуемый проект/продукт, но не предназначено для использования реальными пользователями. Прототип разрабатывается для того, чтобы заказчик смог "пощупать" проект/продукт задолго до момента, когда реально выпустить полноценный проект/продукт. И причина, по которой заказчику дают его "пощупать" — чтобы он мог сообщить о необходимости сломать несколько несущих стен на этом, раннем этапе разработки, когда стены полноценного проекта/продукта ещё никто не возводил. Мне действительно необходимо разъяснять что такое прототипы и зачем они нужны, или Вы всё-таки ответите на вопрос?
exehoo
27.11.2018 10:07Так ответ сообщением выше: мы не разрабатываем прототип проекта, мы делаем прототип продукта. Для меня проект и продукт даже близко не синонимы. Проект (со всеми его подготовительными и промежуточными фазами) — это лишь способ решения, а вовсе не ответ на поставленную задачу. Я не вижу смысла разрабатывать проекты ради разработки проектов. Вы — видите.
В этом наше с вами ключевое/концептуальное различие, и именно поэтому лезть дальше в дебри терминологии смысла нет.
xitt
27.11.2018 22:22Простите, всегда считал что прототипы строятся для демонстрации/проверки концепции. А в приложении уже прорабатываются детали. По результатам прототипирования концепция может поменятся. Но не во время построения конкретной версии прототипа. Как-то так.
powerman
27.11.2018 22:43:) А что, по-вашему, происходит, когда прототип накидали, пощупали, и решили что концепцию надо подправить? Эта новая концепция сразу уходит в разработку приложения? (Подсказка: нет.) Мы начинаем писать новый прототип для проверки новой концепции? (Подсказка: не совсем.) Ура! Вы угадали (надеюсь)! Мы быстро-грязно фиксим первый прототип под изменения концепции. И потом ещё не раз повторяем этот цикл. В полном соответствии с заветами не самого приятного варианта аджайла.
На самом деле быстро-грязная итеративная разработка прототипа — это ещё фигня, по сравнению с попыткой затащить прототип в прод, как только он начинает напоминать желаемое. Вот эта тенденция — реально беда, и чтобы этого не допускать иногда приходится прилагать реально героические усилия и даже опускаться до шантажа (мой любимый: "не вопрос, выкатим в прод, но лично я никаких багов/тасков по этому прототипу делать не буду, для меня он уже умер, как и положено хорошему прототипу").
arilou_camper
26.11.2018 16:37Охоспади, какие такие права у вас отобрали?! Ну правда, напишите что-ли уже хоть что-нибудь более конкретное, чем «я дерусь, потому что дерусь».
menstenebris
26.11.2018 14:48+1Нет, не думал. Ведь наличие денег у работника определяется наличием денег у работодателя. Работнику не очень то выгодно банкротство работодателя, ведь так?
Эти вещи совсем слабо связанные. Кому то выгодно чтобы предприятие закрылось. Можно получить компенсацию и найти работу получше. Кому то все равно т.к. работник хочет уйти на другую работу. С другой стороны обратное тоже не верно. Если у работодателя деньги есть он не обязательно ими делится с работником например делая разного рода вычеты (а иногда даже нарушая трудовой договор). Не надо думать что все поголовно сидят и трясутся за свое рабочее место.
Простите, но разве получение денег не является общей ценностью для всех людей, которые вступают в трудовые отношения? Конечно, наемник хочет себе побольше денег, а работодатель себе. Но ценности то общие.
Тоже не совсем верно. Люди вступают в трудовые отношения чтобы обеспечить свое существование. Многие люди при достижении определенного уровня доходов с радостью бы их поменяли на более интересную и общественно значимую работу. Оттуда и разница в ценностях. До уровня базового содержания они у всех одинаковые. А потом начинают расходится.
Хм, очень спорный момент. Работодатель ведь не просто отнимает результаты труда. Работодатель покупает их. Соответственно если у работника нет мотивации давать результат, то у работодателя нет мотивации платить деньги.
У работника есть мотивация давать результат, но только приемлемый результат, а не отличный результат. А так как в областях типа ИТ очень трудно выставить формализованные критерии к качеству результата то проще пытаться замотивировать работника давать отличный результат. Именно про это тимбилдинг, аджайл и прочие мотивационные методики.
Это с вашей точки зрения справедливо?
С моей точки зрения справедлива совсем иная ситуация. но это уже выходит за рамки обсуждения статьи.nicholas_k
26.11.2018 16:41Эти вещи совсем слабо связанные. Кому то выгодно чтобы предприятие закрылось. Можно получить компенсацию и найти работу получше.
А будет ли работа лучше, если у нового работодателя не будет денег? Взгляните на картину целиком, мы ведь говорим концептуально, а не об одном специфическом примере.
Тоже не совсем верно. Люди вступают в трудовые отношения чтобы обеспечить свое существование. Многие люди при достижении определенного уровня доходов с радостью бы их поменяли на более интересную и общественно значимую работу.
У бизнеса ценности тоже могут меняться при достижении определенного уровня. Но прежде чем заявлять, что нечто не является верным — перечитайте еще раз.
Трудовые отношения — это отношения ради денег и никак иначе. Для человека, который вступает в трудовые отношения деньги являются ценностью.
Что станет с ценностями человека, если количество зарабатываемых денег снизится в пять раз? Наверное они снова поднимутся в иерархии ценностей.
С моей точки зрения справедлива совсем иная ситуация. но это уже выходит за рамки обсуждения статьи.
Я подореваю у вас коммунистические взгляды?menstenebris
26.11.2018 20:58А будет ли работа лучше, если у нового работодателя не будет денег? Взгляните на картину целиком, мы ведь говорим концептуально, а не об одном специфическом примере.
А что будет если ни у кого не будет денег чтобы платить зарплату? вот тогда мы все с голоду и умрем.
У бизнеса ценности тоже могут меняться при достижении определенного уровня. Но прежде чем заявлять, что нечто не является верным — перечитайте еще раз.
У бизнеса ценности меняться не могут. Там только одна ценность это зарабатывание денег. Иначе бизнес быстро перестанет быть. Не путайте личность бизнесмена и его бизнес. Да и опять же ценности даже великих изобретателей (без шуток) быстро превращаются в жутко ретроградный луддизм при намёке на то что бизнес может перестать быть
nicholas_k
27.11.2018 18:26А что будет если ни у кого не будет денег чтобы платить зарплату? вот тогда мы все с голоду и умрем.
Да, такое уже бывапо в истории.
У бизнеса ценности меняться не могут. Там только одна ценность это зарабатывание денег. Иначе бизнес быстро перестанет быть. Не путайте личность бизнесмена и его бизнес.
Конечно я имел в виду работодателя, человека.
hexploy
26.11.2018 19:10+1Ведь наличие денег у работника определяется наличием денег у работодателя.
Ох, спасибо, хорошая шутка.
Нет, я не одобряю работу спустя рукава, но наличие денег у работодателя однозначно определяет только наличие денег у работодателя.Bronx
28.11.2018 00:36Вы подменили высказывание и получили ложную дилемму. Сравните:
А: Наличие смеха определяется наличием комической ситуации. (истинно)
Б: Наличие комической ситуации однозначно определяет только наличие комической ситуации. (тоже истинно)
Оба высказывания истинны, но высказывание Б никак не противоречит высказыванию А.
Над чем смеялись-то?
nicholas_k
28.11.2018 14:09+1Гм. Есть такое понятие — условие истинности чего либо.
Условия бывают необходимыми, а бывают достаточными.
Наличие денег у работодателя не является достаточным, зато является необходимым условием наличия денег у работника.
Я все таки настаиваю на том, что программист должен знать логику.
ivzel
28.11.2018 14:11При том, что я не могу не согласиться с вами по поводу классового противоречия (хотя и не думаю, что оно будет существовать всегда), но «качественно», во-первых, не тождественно понятию «идеально», однако практически всегда идёт совместно со словами: "… и в срок". Задача работника — выполнять работу качественно и в срок. А не идеально, и когда получится.
Durimar123
26.11.2018 16:53>Я вижу в этом манифесте много об удовлетворении программиста, но где же в нем про продукт и бизнес?
Как я понял этот манифест указывает своей целью выпуск качественного ПО.
И да манифест явно указывает на известные всем проблемы.
Однако видно, что сам автор явно еще не разобрался, что в 95% случаев программист даже близко не понимает проблемы бизнеса.
Так что мой ему совет, для начала найди работу как постановщик задач, затем как внедренец (хорошо бы еще побывать в роли хозяина/заказчика ПО). И вот тогда у тебя будут знания по всем ролям и после этого манифест будет куда более полным.
DexterHD
26.11.2018 12:56Я бы посоветовал автору просто ознакомится с биографиями и опытом людей которые сформулировали Agile манифест…
menstenebris
26.11.2018 13:41-2«Сперва добейся!...» плохая аргументация чего-либо.
arilou_camper
26.11.2018 13:44Как раз тот случай, когда сначала надо понюхать пороху.
menstenebris
26.11.2018 13:53Безотносительно статьи. Это не отменяет случая с плохой аргументацией. Если есть что сказать надо указывать на конкретные проблемы. А не прикрываться авторитетами. А то так получится что самый умный тот у кого борода до колен.
arilou_camper
26.11.2018 14:09Сорри, но проблема у автора одна — либо недостаток *личного* профессионального опыта работы в хорошей команде, либо неумение свой опыт обобщить, либо общая озлобленность на взаимодействие с бизнес-частью разработки ПО (не повезло с коллегами, тоже бывает).
izvolov Автор
26.11.2018 15:50… недостаток личного профессионального опыта работы в хорошей команде, либо неумение свой опыт обобщить, либо общая озлобленность...
У меня здесь три основных оппонента, каждый из них имеет специфический опыт. Возможно, в чём-то они даже правы. Каждый имеет право на своё мнение. Не так ли? И я тоже могу перечислить набор эпитетов, характеризующих их с моей точки зрения. Но предпочёл бы всё-таки аргументацию.
arilou_camper
26.11.2018 16:33Но предпочёл бы всё-таки аргументацию.
Я вам в своей ветке комментариев всё аргументировал, а вы в каждом ответе отмахиваетесь общими утверждениями.izvolov Автор
26.11.2018 17:10По-моему, я достаточно аргументировал в самой статье. С вашей стороны я вижу только обвинения в "непонимании", "незрелости" и общие слова о пользе бизнесу. В таком ключе не вижу смысла вести дискуссии.
leon_nikitin
27.11.2018 21:25+2Личный опыт показывает, что в большинстве «проектов» — такое дерьмо внутри, что мама не горюй. На качество времени нет, ибо «бизнес же платит, бизнес и танцует». Какой-то фетиш из «бизнеса». Нужно поднимать профессиональный уровень программистов. Нужно у программистов повышать уровень самооценки (с повышением профессионального уровня). Любой мастер своего дела (неважно кто, например, портной), должен уметь сказать заказчику (клиенту, «бизнесу»), «не, я так делать не буду, так делать — себя не уважать и иди ты лесом, если ты требуешь, чтобы я к понедельнику это сделал» (я ведь знаю, что к понедельнику я это качественно сделать не смогу, а если сделаю, то это будет «дерьмо», за которое я себя не буду уважать, как профессионала).
Что-то совсем уже тошнит от «проектов» с которыми последнее (и не последнее) время приходится сталкиваться, как там все внутри…
altrus
26.11.2018 14:15«Давайте спорить о вкусе устриц с теми кто их ел»
Слышали такое выражение?leon_nikitin
27.11.2018 21:28+2Чтобы утверждать, что дерьмо есть не надо, надо обязательно его вкусить?
s-kozlov
27.11.2018 17:01+1Речь же о вкусе, а не о съедобности. Вот вы что можете сказать о вкусе дерьма?
arilou_camper
26.11.2018 14:18Подумал ещё. Иметь право быть «жёстким» программистом надо заслужить десятком средне-крупных проектов, сданными более-менее в срок с удовлетворяющим все стороны качеством. Тогда тебя будут слушать, зная, что ты не дрочишь на код, а реально решаешь проблемы и «знаешь лучше».
Для этого недостаточно задекларировать эти, в общем-то, имеющие право на существование принципы.xitt
26.11.2018 23:26Не согласен. Именно потому что жуниоры привыкают лепить костыли на котылечки, из принципа может прокатит, а если нет то всегда можно сказать «а вы так не хотите — ну тода я переделаю, я думал что надо как быстрее», мы наблюдаем этот горький катаклизм. Каждый жуниор когда нибудь будет имет десяток проектов за плечами, но захочет ли сменить подход — не обязательно. Зачем ему это, когда можно стать продактом, и так же ездить на таких же «мягких программистах»?
arilou_camper
26.11.2018 23:43Я не про джуниоров писал, вообще-то.
xitt
27.11.2018 01:04Ну дык сениоры-то откуда берутся, ими не рождаются, вообще-то.
powerman
27.11.2018 02:30+1Вообще-то… :) есть и такая теория, что да, рождаются. По крайней мере из старших классов школы уже выходят либо сеньорами, либо мидлами. Поясню — для меня разница между ними определяется психикой, а не опытом или зарплатой.
Сеньорам комфортно работать с задачами, которые они не знают, как решать. Они в состоянии, что называется, "решить проблему". Любую. Просто берут на себя ответственность, разбираются в вопросе, и решают. Сеньоры часто не знают или не помнят мелкие детали устройства конкретных фреймворков, но зато они хорошо понимают принципы устройства этих фреймворков и могут быстро найти решение проблемы на незнакомом им фреймворке, которое не в состоянии найти мидл, вроде бы хорошо знающий данный фреймворк. (Вместо "фреймворк" здесь можно подставить что угодно — ЯП, ОС, утилита, сетевой протокол, ….)
Мидлы же предпочитают работать в знакомых условиях, писать типовые задачи на одном и том же, хорошо им знакомом ЯП, с использованием фреймворка, который они детально изучили… и не очень любят переучиваться на использование новых инструментов и подходов — хотя и делают это довольно регулярно, в IT без этого не выживешь.
Так что когда я вижу джуна, то обычно быстро определяю его как джуниор-сеньора или джуниор-мидла — смотря по его психотипу.
Стоит ещё добавить, что я не считаю сеньоров более "крутыми", чем мидлы. Крепкий мидл знает используемые им инструменты намного глубже, чем когда-либо их узнает сеньор. Я не считаю, что зарплата мидла обязательно должна быть ниже зарплаты сеньора — и мидлы и сеньоры бывают очень разные, и пользу проекту приносят тоже разную. Я считаю, что среднему проекту мидлов обычно нужно больше, чем сеньоров. В общем, мидлы для меня не являются разработчиками "второго сорта". Люди разные важны, люди разные нужны — всё зависит от задачи.
Сложившаяся же практика, когда мидл — это синоним менее квалифицированного разработчика, чем сеньор, и для многих просто карьерная ступенька между джуниором и сеньором, вызвана несколькими причинами.
Первая — мидлы менее охотно изучают новое, поэтому медленнее учатся, и, соответственно, их квалификация растёт медленнее.
Вторая — все сеньоры проходят этап, на котором приносимая их неуёмным любопытством изучать новое польза заметно компенсируется наносимым этим же любопытством вредом, и по факту, обучаясь быстрее и охотнее, в этот период они приносят примерно столько же пользы для проекта, сколько и мидл, знающий заметно меньше, но зато применяющий свои знания более уместно (ну, или просто менее разрушительно, это как посмотреть). С точки зрения менеджера, сеньоры на этом этапе мало отличаются от мидлов, поэтому их обычно называют мидлами и платят как мидлам.
Именно вышеописанное, на мой взгляд, объясняет, почему некоторые мидлы "вырастают" в сеньоров, а другие — нет: потому что те, которые вырастают, изначально были сеньорами, просто неопытными.Dr_Faksov
27.11.2018 09:04Вспомнилось из литературы…
Помните что сказал Кристобаль Хозевич Хунта? «Бессмыслица — искать решение, если оно и так есть», в то время как настоящей проблемой будет — «как поступать с задачей, которая решения не имеет».
А прекрасное описание „сеньора“ — Чапаев из „Практикантки“ Каменистого.
powerman
27.11.2018 14:57Не помню, надо бы перечитать. Помнится, когда-то было жаль, что он эту серию не продолжил.
Dr_Faksov
28.11.2018 00:49Как всегда не додумал мысль.
«Сеньорам комфортно работать с задачами, которые они не знают, как решать. Они в состоянии, что называется, „решить проблему“. Любую. Просто берут на себя ответственность, разбираются в вопросе, и решают. » Вот прямо таким Чапаев там и нарисован.
xitt
27.11.2018 18:26Вы сейчас буквально сказали следующее — выживают те, кто имеет к этому способности. Это нормальный закон эволюции, и я с этим не могу спорить, Вы правы. Вопрос же в статье стоит так, нужна ли нам такая среда, чтобы люди выживали с такими способностями — делать быстро, в ущерб качеству, и перетягивая при этом ответственности с бизнеса на себя. Кратковременные выгоды этого подхода перечеркиваются долговременными последствиями как на индивидуальном уровне, так и на уровне проекта, и даже на уровне индустрии в целом, возможно, в чем я не уверен, время покажет.
arilou_camper
27.11.2018 15:09powerman выше хорошо описал.
у нас в компании с легкой руки СТО одно время было понятие «перспективный джуниор». туда относились все кандидаты, которые имели менее 8 лет опыта работы в необходимом для проекта стеке, но показали хорошие знания в фундаментальны вещах из computer science (алгоримты и сложность, структуры данных, многопоточность и параллельная разработка — обуславливалось особенностями проекта, Big Data и highload).
возможно, «перспективный джуниор» звучит обидно, но после нескольких лет работы с командой, где средний стаж составлял 10 летв дополнение
к вышеуказанным требованиям, понимаешь, что вот это — действительно senior.xitt
27.11.2018 18:19Да я согласен. Проблема в том что такой перспективный джуниор, однажды попавший в ситуацию, когда на него кладут всех обезьян, и по срокам, и по стеку, просто лишний раз подумает, а оно мне надо и пойдет не в крепкие мидлы-сеньоры, а куданибудь еще. Буквально вчера говорил с товарищем из Майкрософт, которому осталось до принципал одну ступень. Он говорит — а оно мне надо? Низы уже не хотят, а верхи не могут, знакомая ситуация, да.
DexterHD
26.11.2018 13:57+1Люди написавшие Agile манифест, признанные во всем мире IT профессионалы. Это люди которые сделали огромный вклад в индустрию. Приведенный же автором манифест звучит просто смешно на этом фоне. За Agile манифестом стоят десятилетия опыта совершенно разных людей, в разного размера компаниях, в разные времена и в различных условиях. А что стоит за манифестом автора, кроме юношеского максимализма? Сколько книг написал автор прежде чем сформулировать данный манифест? Сколько успешных проектов запустил? Сколько не успешных похоронил? Сколько написал научных работ? На скольких конференциях выступил?
Уйдите дальше русскоязычного перевода этого манифеста. Почитайте вообще кто эти все люди (https://agilemanifesto.org/authors.html). Потому что доводы описанные выше звучат ну просто смехотворно. В оригинальном манифесте на каждый пункт чуть ли не книга написана, а часто и не одна. И в кучах источников в подробностях раскрыта суть каждой фразы. А тут что? Отсутсвует даже базовое понимание Agile манифеста и практик которые за ним стоят.xitt
27.11.2018 22:27+1Вы, возможно, правы по сути, но это чистой воды Argumentum ad verecundiam. Нельзя говорить что автор не прав, потому что не написал ни одной книги, или о нем никто не знает. Марсельезу тоже не Бетховен написал, знаете ли.
DexterHD
27.11.2018 22:43+1Прежде чем сформулировать манифест, данные люди делали разнообразные продукты, в разнообразных всем известных во всем мире компаниях, изучали компьютерную науку, программировали, писали книги и научные труды.
Только после этого, набравшись опыта, наломавши дров, создавши и убивши не один и не два проекта, они сформулировали этот манифест.
Автор же пришел и просто сказал (даже не удосужившись вникнуть в манифест): Весь ваш опыт — фигня. Все что вы предлагаете — отстой. Вот вам мой манифест.Zombieff
27.11.2018 01:10Какая-то нездорово болезненная реакция на сатирическую статью.
И кстати говоря, я бы на Вашем месте не только не пытался «взывать к авторитету» авторов манифеста Agile, но и не пытался бы переходить от обсуждения идей к обсуждению личностей и засыпать автора статьи уничижительными эпитетами вроде «юношеский максимализм» и «разработчики со стажем большим чем возраст автора». Давайте тогда ещё шутки про мам шутить, чтобы показать свой высокий интеллект.
Если уж так нравится воззвание к авторитету и особенно к возрасту, то с автором имею честь быть знакомым лично, и он будет постарше, чем мой дорогой оппонент. Что, видимо, должно заставить почувствовать жуткую неполноценность, ведь он старше, и пороха, вестимо, больше нюхал!DexterHD
27.11.2018 01:28+1к обсуждению личностей и засыпать автора статьи уничижительными эпитетами вроде «юношеский максимализм» и «разработчики со стажем большим чем возраст автора».
Эти эпитеты у меня родились именно потому, что мнение автора ассоциируется у меня с собирательным образом многих программистов (в основном мало опытных) которых я на своем пути встречал. Личности я не обсуждаю. Я не знаю лично автора, его возраста, его опыта, я сужу исключительно по высказываниям и исходя из личного опыта подобного общения.
Если его это лично задело, да так, что вы как знакомый пришли его поддержать и указать мне на мою некорректность да еще ткнуть меня тем что я по сравнению с ним щегол малолетний.
Приношу искренние извинения автору.
Если уж так нравится воззвание к авторитету и особенно к возрасту, то с автором имею честь быть знакомым лично, и он будет постарше, чем мой дорогой оппонент. Что, видимо, должно заставить почувствовать жуткую неполноценность, ведь он старше, и пороха, вестимо, больше нюхал!
Что касается возраста, я воззываю к опыту и вкладу. Вы отличаете возраст от опыта?
Возраст не имеет ровным счетом ни какого значения. А опыт и вклад в отрасль безусловно имеет.
Какой опыт автор данного манифеста может противопоставить авторам Agile манифеста? Пока что я не увидел ни одного весомого аргумента.
Пусть автор покажет свои статьи, свои книги, свой код, свои научные изыскания. Хоть что нибудь кроме IMHO и откровенного троллинга? Не говорите только что троллинг — это такая высокоинтеллектуальная сатира.
Что, видимо, должно заставить почувствовать жуткую неполноценность, ведь он старше, и пороха, вестимо, больше нюхал!
Готов ознакомится с его достижениями, дайте пожалуйста ссылки. Если автор действительно нюхнул пороха, я готов почувствовать свою неполноценность.
Но пока что, все что я вижу, это то, что у нас с автором просто абсолютно разная система профессиональных ценностей, не смотря на то что и он и я программисты. И если моя система ценностей построена по мимо собственного опыта еще и на опыте индустрии (или как вы говорите «авторитетов»), то на чем построена система ценностей автора, кроме imho я понять пока не могуZombieff
27.11.2018 01:54Я, пожалуй, ещё раз повторюсь, что это настолько очевидная сатира, что для её непонимания нужен, видимо, особый склад ума. И уж как можно было воспринять мой комментарий про порох всерьёз, для меня вообще загадка. Это даже не тонкий сарказм, а открытый предельно простой юмор. А столь бурную реакцию даже не знаю, как объяснить, не может же вся жизнь быть завязана на Agile, на какой-либо другой методологии, да и на работе вообще.
Опять же напирание на авторитет. Мало того, что это шаблонная ошибка аргументации, так ещё и вот о чём стоит задуматься: если авторы этого манифеста занимают высокие управленческие должности, это говорит о них как о хороших управленцах, но ничего не говорит о них как о программистах.
P.S.: Вот это просто пушка, тут всё: и обида на сатиру, и «сперва добейся», и очередное воззвание к авторитету (они же книги писали!), и калька/перевирание моего указания «интеллектуальность» аргументов:
Пусть автор покажет свои статьи, свои книги, свой код, свои научные изыскания. Хоть что нибудь кроме IMHO и откровенного троллинга? Не говорите только что троллинг — это такая высокоинтеллектуальная сатира.
Троллинг — это когда пытаются вызвать такую реакцию, как у Вас. Тут никто не пытался, все хотели по-доброму посмеяться, что и сделало большинство комментаторов. Заодно находя в шутке долю истины. Но нет, кому-то просто жизненно необходимо развести срач. И кто ещё здесь троллит?DexterHD
27.11.2018 02:17Обида, бурная реакция, что то там еще… :D
Вы как мои эмоции прочли? Вы экстрасенс? Мне, как и вам не чем заняться вечером, вот и все. Завтра я проснусь с утра и пойду кататься на горных лыжах, после обеда сяду программировать и забуду про этот ваш манифест и весь этот пост и спор… :) Я абсолютно равнодушен и спокоен, поверьте. Я даже не одного плюсика/минусика не ткнул за всю беседу :)
programming-motherfucker.com — вот к слову более удачная шутка и отличный манифест.… и еще там 6 отличных книг. Сразу видно, автор знает о чем шутит ;)Zombieff
27.11.2018 03:41Ну если обиды не было, тем лучше для всех. Объём ответов удивил (да и содержание частично тоже) и навёл на такую мысль.
leon_nikitin
27.11.2018 06:18Глупости какие-то пишите. Неужели думаете, что автор не согласен с тем, что исполнитель должен делать свою работу? Думаю, тут никто не спорит, что если была достигнута определенная договоренность между заказчиком и исполнителем, то эта договоренность должна соблюдаться.
«Манифест» не про то, что «не буду себя связывать обязательствами, буду делать что хочу, по своему капризу». «Манифест» про другое. Про то, что есть определенные технологические требования (ограничения), которые должны соблюдаться. Что на это надо обратить сугубое внимание, ибо из-за фетиша «БИЗНЕС», часто происходит наоборот. В угоду «удовлетворения капризов 'бизнеса'» часто страдает качество продукта.
И, действительно, не понятны эти «эджайлы». Например, то, что надо на совещаниях не «лить воду», быть конкретными и не затягивать эти совещания, так при чем тут «эджайл»? Это ведь при любом техпроцессе, в любой отрасли, является просто деловой этикой. Зачем тут придумывать «проводить мининги сугубо строго стоя?».
Другая сторона. Вовсе не обязательно рассматривать эту статью, как противопоставление «программисты» <-> «менеджеры». Ее можно рассматривать, против самих «программистов». Только против тех, кто жертвует качеством продукта.
Balthasar
27.11.2018 12:47Я вот тоже знаком с автором лично и специально уточнил у него: «Сатирой это назвать сложно.»
s-kozlov
27.11.2018 17:07А покажете продукты и код, например, Дяди Боба? А то книг-то у него дофига, а реального кода и продуктов в пропорции к ним я как-то маловато нашел.
s-kozlov
27.11.2018 16:54+1Немного не по теме, но вас не смущает, что некоторые из этих разработчиков более известны своими книгами и лекциями, а не программами?
AlePil
27.11.2018 17:05+1извините, что влезаю, но судя по комментариям в статье, тут вообще уже ничего никого не смущает))
DexterHD
27.11.2018 18:30-1Меня не смущает. Я читал их книги, а вы?
Могу с уверенностью сказать, подходы и методы которые в них описаны работают. Принципы которые там высказаны работают. Возьмем те же SOLID принципы (Принципы которые должен знать каждый Junior вышедший из ВУЗа). Вы же не станете утверждать что они глупы и не имеют практического смысла?
Эндрю Танненбаум, Денис Ритчи, Брайан Керниган, Линус Торвальдс в конце концов. Вы серьезно считаете всех этих людей самозванцами или как? Я не могу понять.
Вас не смущает что Хоккинг не летал в космос? Вас не смущает что Братья Райт не построили ни одного аэробуса?
Объясните почему меня должно что-то в этих людях смущать? Если я прочел их труды и использую описанные в них подходы на практике. Причем до некоторых вещей я дошел еще до ознакомления с их трудами.
Что плохого в том, чтобы перенимать опыт лучших представителей отрасли? Если не у них, у кого вы предлагаете учиться? Или может вы предлагаете отбросить все что было сделано или написано до и изобретать все с нуля? И так каждый раз? Во всех областях?
Я вообще посыл автора и его манифеста вижу реально как то вот так:
«Так называемый» Деннис Ритчи, изобрел «так называемый» язык Си. И многие его приняли. Но лично для меня это выглядит как шутка, которая затянулась.
Компьютеры исполняют исключительно машинный код, а все эти ваши Си изобретены самозванцами и они уничижают права одной группы (компьютеров) по отношению к другой группе (людям)s-kozlov
28.11.2018 07:15Меня не смущает. Я читал их книги, а вы?
Странно, что не смущает. Даже если в их книгах есть здравые мысли (а они там есть, я читал), все равно надо держать в уме, что в пропорции к реальному коду и продуктам эти люди больше теоретики, чем практики. И когда человек зарабатывает деньги не кодом, а конференциями, возникают обоснованные сомнения в их, скажем так, близости к реальной разработке.
Эндрю Танненбаум, Денис Ритчи, Брайан Керниган, Линус Торвальдс в конце концов. Вы серьезно считаете всех этих людей самозванцами или как? Я не могу понять.
А при чем тут эти люди? Они создали Agile Manifesto? Они как раз намного больше сделали, чем наговорили, в отличие от.
Вас не смущает что Хоккинг не летал в космос? Вас не смущает что Братья Райт не построили ни одного аэробуса?
Когда Хокинг говорил, как космонавтам вести себя во время полета, на какие кнопки тыкать на панелях и т.п.? Когда братья Райт указывали современным авиаконструкторам, как нужно строить современные самолеты?
Объясните почему меня должно что-то в этих людях смущать?
Потому что сомнение, а не доверие, является признаком разума.
Что плохого в том, чтобы перенимать опыт лучших представителей отрасли?
С чего вы взяли, что они лучшие? Этак можно сказать, что Роберт Кийосаки — лучший бизнесмен.
Если не у них, у кого вы предлагаете учиться?
Так я не предлагаю у них не учиться. Я просто не считаю их гуру, которых надо слушать, разинув рот и капая слюной.
Или может вы предлагаете отбросить все что было сделано или написано до и изобретать все с нуля?
Что они сделали? По сравнению с перечисленными выше Торвальдсом и компанией — ничего.DexterHD
28.11.2018 11:17Даже если в их книгах есть здравые мысли (а они там есть, я читал),
Назовите конкретно, какие книги вы читали, и какие конкретно практики не применимы или приводят к большим проблемам?
И когда человек зарабатывает деньги не кодом, а конференциями, возникают обоснованные сомнения в их, скажем так, близости к реальной разработке.
Это вы решили что они кодом ни когда не зарабатывали? Большинство из них начинали свою карьеру программистов в 70-80-тые. А их пик карьеры как разработчиков приходится на 80-90тые. Или для вас авторитетом является только тот кто всю жизнь на должности миддла просидел?
А при чем тут эти люди? Они создали Agile Manifesto? Они как раз намного больше сделали, чем наговорили, в отличие от.
Вы заблуждаетесь, просто эти люди создавали инструменты для разработчиков. Поэтому их работу вам видно. А те кто сформировал Agile создавали продукты и программы для бизнеса. Но и те и другие являются признанными во всем мире профессионалами. И те и другие сделали огромный вклад в индустрию. Просто в разные ее области. А мы сейчас тут говорим как раз о разработке и бизнесе.
Потому что сомнение, а не доверие, является признаком разума.
Хорошо. По вашей логике: — Я что-то сомневаюсь что вы вообще программист и имеете какой то отношение к IT. Мне кажется вы в своей жизни вообще ни одной программы не написали. Ведь я их нигде не видел. И показать вам нечего.
С чего вы взяли, что они лучшие?
Их вклад в индустрию признается IT сообществом в лице сотен тысяч профессионалов а так же в лице крупных технологических компаний таких как IBM, Intel, Microsoft и т.д.
Что они сделали? По сравнению с перечисленными выше Торвальдсом и компанией — ничего.
Это смешно. Компания людей выше в комментарии, она про технологии. Поэтому их работу видно. Компания из Agile манифеста — про программистов в бизнесе. Это не умоляет ни как того что они сделали для индустрии. Сотни тысяч разработчиков каждый день пользуются архитектурными и другими паттернами которые они сформулировали, пишут тесты в соответсвии с методологиям которые они разработали, проектируют программы в соответсвии с принципами которые они предложили, выпускают успешные продукты в соответсвии с методиками которые они предложили. Причем многие из них об этом даже не подозревают, потому что информацию черпали не из первоисточника а из перепечаток, статей, и т.д. и т.п.s-kozlov
28.11.2018 12:00Вы меня вообще не слышите. Я никогда не говорил, что они плохие программисты. Я никогда не говорил, что их принципы говно. Я говорю, что такие люди зарабатывают на жизнь не программированием, а написанием книг и выступлениями. Стоит хотя бы задуматься: а не оторвались ли эти дяди от реальности, пока ездили по конференциям? Читать эти книги, критически осмысливать их и выносить оттуда что-то полезное — это прекрасно. Считать их по умолчанию непререкаемыми авторитетами на основании того, что какое-то число кого-то там их «признало», они написали кучу книг и бла-бла, до такой степени, что приводить их в дискуссии как ad hominem — это хреново.
DexterHD
28.11.2018 12:59Будьте добры ответить на конкретно поставленные вопросы. Давайте поговорим конкретно, без абстракций и отсылки к умным терминам. Я как минимум 3 конкретных вопроса задал. Вы не ответили не не один.
Считать их по умолчанию непререкаемыми авторитетами на основании того, что какое-то число кого-то там их «признало», они написали кучу книг и бла-бла, до такой степени, что приводить их в дискуссии как ad hominem — это хреново.
Что касается меня лично, то я считаю их авторитетами, потому что я прочел ряд их книг и осмыслил их критически, после чего применил знания на практике. Я убедился в том, что методики этих ребят работают и помогают делать продукты.
Именно поэтому я нахожусь в числе кого-то там кто их «признал». С чего вы взяли что я их признал «по умолчанию», просто потому что их признали остальные я ума не приложу. Вы сами себе выдумали это? Вам не приходит в голову что эти «какое-то число кого-то там», так же читали их книги, критически их осмысливали и применяли подходы на практике? Другие «кто-то там» нанимали их на работу и видели их результаты. И так далее.
Если есть способ сделать как то так чтобы вас начали признавать «по умолчанию», расскажите его пожалуйста?
Я говорю, что такие люди зарабатывают на жизнь не программированием, а написанием книг и выступлениями. Стоит хотя бы задуматься: а не оторвались ли эти дяди от реальности, пока ездили по конференциям?
Откуда такие выводы? Kent Beck например работает сейчас в Facebook… И да, мне вас искренне жаль, если ваш потолок в карьере — рядовой Senior разработчик. Потому что все что выше (в любой ветке развития IT специалиста будь то менеджерская ветвь или техническая) в любом отношении предполагает что 80% времени вы будете отнюдь не код писать. Если верить вашим взглядам, любой разработчик доросший до уровня выше Senior, через пару тройку лет теряет связь с реальностью. Но вот реальность такова, что этим потерянным людям ни чего не мешает создавать и выпускать успешные продукты, в отличие от рядовых программистов которые пишут код ради кода и меняют работу каждые пол года при этом не выростая никуда по карьерной лестнице.powerman
28.11.2018 14:01Ну, вот например я вырос, и уже много лет трачу значительную часть времени не на код, а на общение, обучение и написание документов. Тем не менее, я согласен с тем, что если код не писать, причём минимум 30% времени, то любой крутой архитектор/principal за 4-5 лет превращается в тыкву. Если работать на более менеджерской и менее технической позиции вроде PM/CTO, то без написания кода вполне реально сохранить квалификацию для своей должности, но нормальным разработчиком при этом быть перестаёшь.
DexterHD
28.11.2018 14:11Это называется профессиональный рост. «Нормальный разработчик» один в поле не воин, как бы ему не хотелось этого считать (Максимум ремесленник. Но тогда его потолок вполне известен). Наша индустрия слишком сложная и большая. Все стоящие проекты делаются большими группами людей где у каждого своя роль. Без этого взаимодействия продукт не родится, какой бы рок-звездой не был этот «нормальный разработчик».
Кстати странно получается. Вы сейчас зарабатываете жизнь не программированием, при этом говорите о том, что приведенные выше люди далеки от реальности потому что зарабатывают не программированием? :D Очень логично. Но вы же один из этих людей так или иначе. Из тех зазнавшихся дядек что оторвались от реальности.powerman
28.11.2018 15:21Я зарабатываю тем, что помогаю заказчикам решить их проблему, а вовсе не программированием.
Иногда для этого требуется побыть бизнес-аналитиком и помочь заказчику понять, что проблему нужно решать вообще не разработкой изначально заказанного софта, а как-то иначе. Почти всегда архитектором, спроектировать необходимую систему, разработать API и написать про всё это кучу документов. Почти всегда тимлидом, техлидом или простым сеньором, занимаясь обучением, ревью, или написанием значительной части проекта самостоятельно. Иногда даже немного девопсом, потому что мне для комфортной работы нужен надёжный и быстрый конвейер CI/CD и безопасно настроенные сервера, и не всегда есть кому это поручить. Совсем редко проджект менеджером, как-то раз даже продакт овнером — но это уже не совсем "моё", предпочитаю чтобы этим занимался кто-то другой.
Так что я вижу очень многие этапы разработки лично. И я вижу, как регулярное написание кода помогает сохранять и развивать навыки архитектора. И вижу, как длительное отсутствие написания кода делает разрабатываемые архитектуры оторванными от реальности и создающими проблемы, вместо того, чтобы их решать (меня это тоже касается напрямую, потому что хотя я и пишу постоянно код, я не делаю это на всех ЯП/фреймворках/платформах, которые когда-то знал, и качество проектирования архитектуры под эти, неиспользуемые мной, технологии — с годами падает катастрофически).
Если у Вас мечта вырасти в архитектора или принципала, с надеждой после этого перестать лично писать код — у меня для Вас плохая новость: через несколько лет наслаждения такой жизнью у Вас от высокой квалификации останется только память о ней и неимоверные понты, которые будут сильно мешать найти новую работу, после того, как Вы вылетите со старой.
Более того, беспокоиться об этом Вам нужно лично, потому что нанимателю до этих проблем дела обычно нет, и заполучив крутого архитектора наниматель, как правило, недальновидно предпочитает нагрузить его на 100% работой с архитектурой и документами, не оставляя времени на написание кода — так что если самому не выбивать возможность регулярно писать код, её обычно и не будет.
DexterHD
28.11.2018 15:37Тогда я не понимаю о чем мы спорим? Потому что я занимаюсь ровно тем же что и вы. И делаю ровно все то же самое что вы описали в первых 3-ех абзацах… :D
И Agile подходы, а так же рекомендации тех людей о которых идет речь мне в этом больше помогают, чем мешают. При чем и когда я пишу код и когда работаю с людьми. Не все там идеально, да. Но я и не говорил нигде что Agile идеален.powerman
28.11.2018 15:43Спорили Вы не со мной. Я просто влез прокомментировать что "Если верить вашим взглядам, любой разработчик доросший до уровня выше Senior, через пару тройку лет теряет связь с реальностью." не такая уж и глупость, и нередко такое действительно происходит.
DexterHD
28.11.2018 15:44Не буду отрицать, бывает и такое и очень часто. Тем более если совсем перестает писать код. Но я например лично стараюсь его писать, хоть и после работы по большей части.
powerman
28.11.2018 15:35А! До меня, похоже, дошло, на что Вы так резко отреагировали. На "… но нормальным разработчиком при этом быть перестаёшь", да?
В случае PM/CTO я не вижу в этом ничего плохого, и упомянул это исключительно потому, что многие крутые разработчики действительно любят писать код, но ещё они любят зарплату по-больше и должность по-круче. И им кажется, что они могут быть PM/CTO, и при этом продолжать писать код, поскольку им нравится писать код. Так вот — это им только кажется, на практике это совмещать практически нереально (если не брать мелкий стартап, где 2-3 разработчика и один из них, по совместительству, ещё и CTO — пока стартап мелкий CTO ещё будет писать код, но как только команда вырастет времени на это уже не останется).
DexterHD
28.11.2018 15:43До меня, похоже, дошло, на что Вы так резко отреагировали
До меня только сейчас дошло, что я вас перепутал с s-kozlov, которому мой ответ и предназначался на на который ответили вы вне контекста спора :)
DexterHD
28.11.2018 11:54Даже здесь на Хабре 90% статей по архитектуре ПО, тестировании, разработке enterprise приложений, паттернам — это перепечатки/переводы/интерпретации трудов именно этих людей которые «ничего не сделали». :D
s-kozlov
28.11.2018 12:01Я говорю не про книги и статьи, а код и продукты. И вот первое у них намного виднее, чем последнее. Что и настораживает.
DexterHD
28.11.2018 13:14Код они писали еще до того как многие из нас родились, а многие познакомились с компьютерами. Вас это настораживает?
Продукты в которых они так или иначе поучаствовали вы используете чуть ли не каждый день, потому что их привлекают к работе мировые лидеры IT отрасли. Продуктами этих компаний вы каждый день пользуетесь.
Читайте больше книг IT тематики, а не Википедию и низкопробные статьи в интернете. Там информации куда больше. Если бы вы их читали, вы бы знали в каких компаниях эти люди работали, код каких продуктов писали и т.д.
Иногда складывается ощущение что я веду дискуссию с плоскоземельщиками. Потому что доводы они приводят именно такие «Я не видел что она круглая, а все что описано в официальных источниках — заговор». То что вы чего то не видели говорит только об уровне осведомленности.
Вот эта ваша выборочность она на мой взгляд как раз говорит о том, что вы просто об одних людях «слышали» и приняли на веру их авторитет, а о других не слышали и поэтому ставите их авторитет под сомнение.
А реальность такова, что и те и другие сделали огромный вклад. И работы и тех и других используются повсеместно. Просто об одних вы слышали а о других нет.
Для многих программистов в особенности у нас в СНГ Стив Джобс и Билл Гейтс гениальные программисты :D А о том кто такой Денис Ритчи или Дональд Кнут они вообще не знают… Если они о таких мастодонтах не знают ничего, откуда из знать о Фаулере, Бэке или Мартине (Они все таки более узкие спецы).transcengopher
28.11.2018 15:53Код они писали еще до того как многие из нас родились, а многие познакомились с компьютерами. Вас это настораживает?
Разумеется, настораживает. Во времена их активности именно в качестве кодеров многие современные подходы находились на стадии теоретических изысканий — следовательно, не были применимы к их опыту написания кода.
Некто может как никто другой в мире уметь обрабатывать дерево киянкой и долотом, но обязаны ли мы поэтому считать его непререкаемым авторитетом в современной столярной мастерской? А если учесть что этот мастер в последний раз работал с деревом десять с гаком лет назад, а потом "профессионально вырос" до руководства другими людьми?
DexterHD
28.11.2018 16:49Во времена их активности именно в качестве кодеров многие современные подходы находились на стадии теоретических изысканий — следовательно, не были применимы к их опыту написания кода.
А кто эти современные подходы собственно сформулировал и первым применил на практике? Я вам отвечу. Они и сформулировали, они и применили. А потом формализовали в виде книг и статей, чтобы менее опытные программисты не переизобретали велосипеды…
Каждый профессионал в своей жизни проходит через несколько стадий:
1) Обучение
2) Наработка опыта
3) Передача опыта следующим поколениям
Все эти люди находятся на стадии №3. Вот и все. Вы можете им не доверять, вы можете их отрицать, вы можете переизобретать велосипеды заново. Объективной реальности это не изменит.
Некто может как никто другой в мире уметь обрабатывать дерево киянкой и долотом, но обязаны ли мы поэтому считать его непререкаемым авторитетом в современной столярной мастерской? А если учесть что этот мастер в последний раз работал с деревом десять с гаком лет назад, а потом «профессионально вырос» до руководства другими людьми?
С чего вы взяли что они всю жизнь обрабатывали дерево киянкой и долотом? Они как раз таки изобрели и формализовали ЧПУ станки, и теперь продвигают их в массы попутно осмысливая их и дорабатывая (А киянку и долото они давно положили на полку). Вы в это же время отсекаете весь их опыт и продолжаете обрабатывать дерево киянкой и долотом, которые по дешевке купили на распродаже…
По Agile сформулированному Бобом Мартином работают куча передовых IT компаний среди которых Apple, Google, Intel, IMB, etc.
Паттерны Enterprise приложений Фаулера используют в разработке корпорации и банки по всему миру.
Подходы TDD разработанные Кентом Бэком используют множество компаний где важно качество продукта и его стабильность.
Вы можете называть этих людей самозванцами и ставить под сомнение их подходы сколько угодно, это не отменит объективной реальности, хотите вы в нее верить или нет.
third112
26.11.2018 14:21Разработать матмодель ПО;
А если ПО основано на эвристических алгоритмах? ;)
ValeraUff
26.11.2018 14:32Увы, знаком с некоторыми «жёсткими программистами», которые применяют этот манифест на практике. Это чистой воды саботаж бизнеса, ловко прикрытый потоком технических терминов.
Раньше я думал, что таких людей мотивирует «обучение за счет компании», когда в каждый новый проект вкладывается как можно больше хайповых технологий и методик. Гвозди забиваются микроскопами, бюджеты и сроки раздуваются на порядки, зато в резюме появляются новые строчки изученных технологий. Казалось бы, теперь у тебя отличное резюме, можешь «двигаться дальше», в более крутую компанию. Но нет, «жёсткие программисты» продолжают сидеть на месте и саботировать проект за проектом.
Но самое страшное то, что они выступают с докладами на крупных конференциях и с гордостью рассказывают о своих «достижениях», распространяя хайп.DrunkBear
26.11.2018 14:52+1Вопрос в том, чего хочет бизнес?
Если без ТЗ, вчера и бесплатно — то это проблема бизнеса и «бюджеты и сроки раздуваются на порядки»
Если программисты постоянно не укладываются во вменяемые ТЗ без форс-мажоров и предрелизных правок типа «завтра сдача лифта, сделайте, что он не только вверх-вниз ездил, но и вбок, это же несложно. Ну а ТЗ? возьмите на вертикальный лифт и просто поверните, там одинаково» — меняйте программистов.
PS простите, но ни разу не видел, чтоб на крупных конференциях вставал руководитель компании и говорил «докладчик растяпа и хайпожор, всё сделал плохо, бизнес страдает и его выгнали как кота на улицу. Не верьте его словам»ValeraUff
26.11.2018 16:40В моем примере бизнес относится к разработке очень лояльно, доверие к разработчикам практически безгранично. На мой взгляд, отчасти в этом и проблема. На такой почве «жёсткие программисты» начинают паразитировать, ставя свои личные цели во главу угла совершенно забывая про цели бизнеса.
Описанную вами ситуацию на конференциях тоже не встречал ни разу. Как минимум, потому что она неэтична. Ну и вроде как не принято в IT «выгнонять как кота на улицу». Даже если принято решение расстаться, все равно обычно стараются расстаться миром.
rzerda
26.11.2018 15:24+1Второй говорил Командиру в полёте —
''Я зачитал Руководство до дыр!
Но, чтоб я ни делал, Вы только орёте!''
''Ты делай как надо!''- Сказал Командир…
Горькая правда жизни в том, что подавляющее большинство имеющегося ПО не нужно было даже начинать разрабатывать, не говоря уже о качественной разработке. А около того ПО, что действительно нужно, уже есть регулятор от государства и УК.
Кроме того, адептов Сразу Всё Делать Правильно я видел много и в т.ч. в зеркале, это не работает. Человечество едет на костылях которую тысячу лет совершенно не из-за нехватки манифестов, а из-за нехввтки кадров. Костыли в потребном количестве можем производить, а чуть поинтереснее — люди кончаются.
Поэтому совершенно без издёвки предлагаю Вам заняться важными штуками, где от косяков могут люди погибнуть, и где думать поэтому надо сильно до. Больше хороших штук появляется от запиливания хороших штук, а не от запиливания хороших манифестов.izvolov Автор
26.11.2018 15:26Практически со всем согласен. Однако, призыв тут не "Сразу Всё Делать Правильно", а совсем другой.
tuxi
26.11.2018 19:14Я думаю, что фраза «делать все сразу правильно» подразумевает прежде всего «давайте сразу не делать все неправильно». Если стандарты качества будут постоянно понижаться, в скором будущем они выродятся во что угодно, но не в качество.
А agile тут мог навлечь на себя гнев автора по причине того, что его основные концепции некоторые товарищи используют как проститутку, в угоду своим корыстным целям и/или непрофессионализму.rzerda
26.11.2018 20:26+1Так ведь нет стандартов. На строительство моста с параметрами в широких пределах есть, а на ПО — нет. «Надо писать тесты» это не стандарт, тестами можно очень задорно всё испортить минимум двумя разными путями. Манифест (любой) мне не нравится прежде всего своим «мыши, станьте ёжиками»-стайлом. «Нужно продумать архитектуру», окей. А как понять, что архитектура успешно продумана? Или что матмодель отражает то, что нужно? И всё равно ведь, сколько не продумывай, половину выкинешь, потом выкинешь ещё раз, только потом что-то заработает.
Цирк с понями можно устроить из произвольного манифеста, не только из agile. Agile вообще нормальный, если себя в руках держать, а не буквально понимать, что там написано. Только ведь в таких условиях всё нормальное.tuxi
27.11.2018 21:54Стандарты все же есть, для каждой области свои, но так или иначе есть. Для ракеты пво одни, для космоса другое, для томографа третье, для веба четвертое, для банка пятое.
А вот архитектура, вот ее «хорошесть» — определяется более просто, Архитектура — это субстанция, которая завязана на «бизнес-процессы», которые в свою очередь могут очень быстро меняться, а могут годами быть жестко регламентированными (например законодательством). Поэтому, я считаю, что «хорошая архитектура», это прежде всего та, которая построена на хорошем и глубоком анализе бизнес-процессов.
Помните «метод бумажных карточек ограниченного размера»? Помните «сформулируйте, свои пожелания короткими предложениями не больше 5 слов?» Нудно долго итеративно…
А сейчас ведь как модно, быстро пара совещаний, копи-пасте с другого проекта, 2..3 «фреймоворка-на-слуху» на выбор… коммерческое предложение и вперед шашки наголо, пока бизнес не передумал.
maydjin
26.11.2018 15:53Расскажите этот манифест своим конкурентам, которые начнут продавать свой продукт пока вы делаете мат. модель. А на вырученные деньги потом купят Вас и Вы им уже сделаете как надо.
izvolov Автор
26.11.2018 17:59-1В описанной гипотетической ситуации инженер как работал, так и продолжает работать. Ничего не изменилось.
Кто-то сверху кого-то купил. Но откуда следует, что нужно бороться именно за этого конкретного нанимателя? Может, тот, который перекупит, будет лучше?
maydjin
26.11.2018 18:17Ну, тогда, глупо сравнивать сей манифест с гибким. Ибо agile таки про то, как сделать хорошо типовому бизнесу а не Вам лично или какому-то гипотетическому инженеру в вакууме.
Кто будет нанимать такие команды, которые призывает творить вышеупомянутый манифест? Такие клиенты есть и сейчас(оружие массового поражения, космос, ядерная энергетика, некоторые научные изыскания), когда итеративная модель не подходит, все всё сразу делают хорошо ибо ошибка в проде стоит ощутимо дороже промедления. И за хорошие деньги. Почему лично Вы или Я не попали в ряды таких инженеров, это явно не вопрос разработки каких-то манифестов.
izvolov Автор
26.11.2018 18:22-1Кто будет нанимать такие команды
Кто будет нанимать работника, который, видите ли, требует соблюдения ТК? Никому такой не нужен. Лентяй неблагодарный.
maydjin
27.11.2018 11:29Даже не знаю как можно ответить на такое передёргивание. Аналогия как минимум странная.
Вместо этого, попробую ещё раз раскрыть свою мысль, хотя, я был бы рад ошибаться.
Есть вещи которые нужно сделать быстро и можно улучшить потом. Это повысит их ценность. 90% разработки ПО крутится вокруг таких вещей. Это просто факт, кто вторым вышел на рынок — проигрывает в большинстве случаев. А 9 женщин не родят ребёнка за месяц©.
Именно по-этому вводятся понятия минимального жизнеспособного продукта и итеративных подходов к разработке.
Kroid
26.11.2018 18:24-1Это называется саботаж. Можно еще пару пунктов в такой манифест добавить. Например, «завязывайте процессы на себя, пишите запутанный код, будьте незаменимым, чтобы вас не смогли уволить».
izvolov Автор
26.11.2018 18:26+1Если внимательно прочитать статью, то будет видно, что соблюдение технологии ставится на первый план. А соблюдение технологии — это простой и понятный код, полное тестирование и развёрнутая документация.
Kroid
27.11.2018 12:27+3Технология для строительства АЭС, загородного дома и деревенского туалета — это три разных технологии. В вашем манифесте я вижу идею «Накрутим по максимуму, как если бы мы строили космический корабль. А то, что бизнесу требуется всего лишь простой воздушный змей — это проблема бизнеса».
lingvo
27.11.2018 18:23Технология для строительства АЭС, загородного дома и деревенского туалета — это три разных технологии.
С точки зрения манифеста не очень согласен. Эти технологии, как и технология проведения аудита или сдачи бухгалтерской отчетности, имеют очень много общего — у них есть известные этапы работ, продолжительность и очередность которых может быть определена достаточно точно еще на этапе планирования проекта. Грубо говоря — фундамент, стены, крыша, а не сначала крыша, потом фундамент, потом стены.
А вот этапы разработки планировать гораздо сложнее. Зачастую изначально очень трудно оценить не только продолжительность каждого этапа, а вообще какие этапы нужны, чтобы разработать тот или иной продукт.
А все потому, что АЭС, дома и туалеты человечество строило не раз и имеет достаточно большой опыт, а вот разработка — она всегда новая.Kroid
28.11.2018 20:37Я думаю, вы неправы.
Какой процент софта разрабатывается реально с нуля? Особенно, как вы говорите, «человечеством», так-то для студента каждая программа — что-то новое. Давайте возьмем как пример самую распространенную область — веб приложения и корпоративное ПО. Что там нового? Взял фреймворк, написал поверх него бизнес логику, протестировал, задеплоил на продакшен. Бизнес логика разная? Ну так и один и тот же дом, в зависимости от местоположения, будет различаться — где-то утеплить сильнее, где-то фундамент изменить и тд.DexterHD
28.11.2018 20:55Бизнес-логика ведь разная везде. Кому то нужен дом, кому то автомобиль, а кому то космолет. Бизнес-логика это же ключевая часть приложения. Именно из-за нее растет сложность и валятся сроки и недовольны программисты и не вырисовывается архитектура. Все остальное просто I/O обертка вокруг бизнес-логики.
kotovsky_art
26.11.2018 16:04А я поддерживаю ) Наличие манифеста и следование ему не сделает тяп-ляпную эджайл разработку на 100% идеальной, но как отличный противовес менеджерскому разгулу — то, что нужно.
johnfound
26.11.2018 16:35Понравилось. Как то напоминает этот манифест: http://programming-motherfucker.com/
jevius
26.11.2018 17:44+2«Sounds good, doesn't work».
В некоторых ситуациях ваши правила только помешают. В том что вы называете мат. моделью в первую очередь надо определить срок эксплуатации ПО, выгоду от оптимизации с помощью него, потери от усилий на разработку. Нет смысла пилить с заделами на будущее то, что уже не пригодится через три месяца. Учитывать «технические» моменты реальной жизни надо, если короче. Бюрократия в государстве ведь тоже оборотная сторона принципов, направленных на лучшее. Но в итоге всех бесит и раздражаетizvolov Автор
26.11.2018 18:02"Мои правила" никак сказанному вами не противоречат. Более того, с основной мыслью я согласен.
random1st
26.11.2018 17:51Как бы против Agile у меня есть убийственный аргумент — «Вы бы хотели чтобы АЭС неподалеку от Вас строилась по Agile?»
DexterHD
26.11.2018 18:04+2Не знаю как на счет АЭС, но NASA например, как бы использует Agile если что и достаточно долго. И ничего, ракеты летают, марсоходы ездят :) Agile — это не про х**як х**як и в produciton. Это типичное заблуждение. В гибких методологиях тоже есть фазы планирования. Есть фазы когда нельзя просто прийти поменять требования и т.д. и т.п.
random1st
26.11.2018 18:07Пруф, где хоть один спутник запущенный в космос в рамках проекта, разработанного по принципам Agile. Там где они софт пишут, возможно, но не там, где занимаются инженерной работой.
DexterHD
26.11.2018 18:14Ну например вот один из документов NASA Agile: From Software to Mission System
Углубитесь в историю. Этот манифест был сформирован людьми которые работали в отрасли во время ее зарождения. Этот манифест не подходит для команд с низкой квалификацией.
Модель водопада как раз таки была изобретена в ответ на появление огромного кол-ва молодых программистов на рынке, которые понятия не имеют как делать проекты и которыми отрасли пришлось учится как то управлять.
Agile модель работает только тогда, когда в команде большинство составляют уже сложившиеся профессионалыrandom1st
26.11.2018 18:19Я об этом и говорил — Agile работает там, где низкая цена ошибки и есть возможность многократных итераций — например, в разработке софта. Попробуйте запустить ракету в космос по Agile — сколько раз вам придется ее уронить, чтобы она в конце концов полетела?
DexterHD
26.11.2018 18:31Ни разу не нужно ее ронять по Agile чтобы она полетела. Еще раз. Agile не отменяет планирования, проектирования, тестирования, фиксации требований, контроля качества и т.д.
Bronx
28.11.2018 09:49+1SpaceX, например, чем вам не agile? Прототипы, минимальный продукт, итерации — всё на месте.
Dr_Faksov
28.11.2018 01:01Вот как раз в космических пусках приоритет окончания в срок наиважнейший. То есть буквально — если не запустим хоть как-то через месяц, то потом спешить уже не надо, несколько лет, до следующего пускового окна, у нас будет, если проэкт не закроют.
Kroid
26.11.2018 18:13-3Действительно убийственный аргумент — он убивает желание с вами дальше общаться.
gdshebanov
27.11.2018 21:25В agile есть понятие доменов. Всего 4 домена, при этом agile применим только в одном из них — «хаосе». АЭС не строится а режиме «хаоса», соответственно, по agile строго не рекомендуется строить такие проекты. Разумеется, ни в Nasa, ни в пентагоне никто не применяет agile.
DexterHD
27.11.2018 21:28+1В NASA говорят что применяют. И даже делают положительные выводы. Смотрите выше ссылку на сайт NASA
ton_1
27.11.2018 11:25Несмотря на то, что в фактах вы ошибаетесь, мыслите вы в очень верном направлении.
Вы говорите о фреймворке Cynefin, а не об agile, а непосредственно agile применим, как правило, в «запутанном» домене, не в «хаосе».
Но применение этого фреймворка для определения методологии разработки и решении о применении agile (замечательного, но не универсального подхода) весьма полезно. Возможно с пропуска этого шага зачастую и начинается внедрение неподходящего к ситуации agile-а, вызывающего, в дальнейшем, бурю негодования у разработчиков.
en.wikipedia.org/wiki/Cynefin_framework
s-kozlov
27.11.2018 17:14Я бы точно не хотел, чтобы АЭС строили люди, которые с серьезным выражением лица применяют принципы строительства АЭС к строительству сортиров. Просто потому, что таких неадекватов нельзя допускать до строительства чего бы то ни было.
dimoff66
26.11.2018 19:55Подписываюсь под каждой строчкой. Взвешенный разумный манифест в противовес agile-овскому детсаду.
yorgo
26.11.2018 20:00+1Многие программисты порой забывают за что их ценит бизнес (подсказка: не за совершенный код).
lingvo
26.11.2018 21:13В принципе описан обычный манифест программиста для встраиваемых систем. Так что хотите заделаться жестким программистом — идите в embedded.
DexterHD
27.11.2018 21:36+1«Внезапно» один из авторов Agile манифеста (Stephen J. Mellor), как раз в свое время специализировался на по embedded и realtime системах, и работал в том числе в CERN. А сейчас является CTO в Industrial Internet Consortium который был создан копаниями AT&T, Cisco, General Electric, IBM и Intel
?\_(?)_/?arilou_camper
27.11.2018 21:38Удивительно, что нас в этом обсуждении мало кто понимает.
random1st
27.11.2018 21:41Может, причина в основном, что вся Ваша аргументация — это отсылка к авторитетам и источникам? Мол, так все работает и нечего туда лезть? Хотя вот например системноинженерный подход работает ни разу не хуже, хоть и затратнее, чем этот ваш Agile. Пруфов насовать? Или статью пришьете за оскорбление чувств «свидетелей Agile»?
DexterHD
27.11.2018 21:50+1Насуйте пруфов где Agile противоречит инженерному подходу. Agile это и есть инженерный подход, сформулированный квалифицированными инженерами, работающими в отрасли с того времени когда многих из нас еще в проекте не было.
Еще раз повторюсь, Agile не отменяет ни проектирования, ни фиксации требований, ни управления рисками ни контроля качества.
И да, то что у нас в России продают под видом Agile, им не является.
Здесь обсуждают манифест, знание о котором у людей сложилось исключительно из основных тезисов манифеста и додумывания всего остального, а так же опираясь исключителньно на свой негативный опыт взаимодействия с менеджерами и заказчиками.
При этом вообще не углубляясь в суть манифеста, в то, почему он был сформулирован, для каких целей, когда, зачем, и так далее.
Agile был сформулирован IT ИНЖЕНЕРАМИ и УЧЕНЫМИ в области CS.
Мол, так все работает и нечего туда лезть?
Нет, отсылка следующая: — Сперва разберитесь в вопросе, после давайте обсудим.
arilou_camper
27.11.2018 21:57Где я отсылаю к авторитетам? Я вообще не отношусь к категории «свидетелей Иего^W Agile». Я как раз являюсь адептом подхода «наймите хороших специалистов и не мешайте им работать».
В этом обсуждении я оставил несколько аргументированных комментариев, и несколько эмоциональных, поддавшись на троллинг автора.
1. Не вижу критики Agile. Как предложенный «манифест» решает проблему сдачи качественного продукта за предсказуемый срок и бюджет? Если он не решает, то он не нужен, или нужен, но не в такой форме подачи.
2. Какие конкретно предложения из «манифеста» предназначены для решения проблемы предсказуемости выхода обновлений продуктов? Если никакие, то он не нужен или нужен, но не в такой форме подачи.
Вот и всё)izvolov Автор
27.11.2018 22:08Где я отсылаю к авторитетам?
Очевидно, имелся в виду ваш "соратник".
Как предложенный «манифест» решает проблему сдачи качественного продукта за предсказуемый срок и бюджет? Если он не решает, то он не нужен, или нужен, но не в такой форме подачи.
Как agile-«манифест» решает проблему сдачи качественного продукта за предсказуемый срок и бюджет? Если он не решает, то он не нужен, или нужен, но не в такой форме подачи.
Какие конкретно предложения из «манифеста» предназначены для решения проблемы предсказуемости выхода обновлений продуктов? Если никакие, то он не нужен или нужен, но не в такой форме подачи.
Какие конкретно предложения из agile-«манифеста» предназначены для решения проблемы предсказуемости выхода обновлений продуктов? Если никакие, то он не нужен или нужен, но не в такой форме подачи.
Вот и всё)
arilou_camper
27.11.2018 22:30А он и не решает. А ваш?
izvolov Автор
27.11.2018 22:35А он и не решает.
Так, значит, он не нужен?
arilou_camper
27.11.2018 22:36Может вы наконец ответите хотя бы на один вопрос, вам заданный?
izvolov Автор
27.11.2018 22:50Может вы наконец ответите хотя бы на один вопрос, вам заданный?
Да как-то не привык отвечать на риторические вопросы.
Разумеется, "мой" манифест не решает проблему сдачи качественного продукта.
arilou_camper
27.11.2018 22:53А какую проблему он тогда решает?
izvolov Автор
26.11.2018 23:02А какую проблему решает agile-манифест?
По-моему, это бессмысленный разговор.
arilou_camper
26.11.2018 23:08Мне реально интересно, какую проблему решает ваш манифест. Вы же зачем-то выложили его на Хабр?
izvolov Автор
26.11.2018 23:22Ну так а какую проблему решает аджайл-манифест? Его же зачем-то выложили в интернет.
DexterHD
26.11.2018 23:28+1Вот некоторые из проблем которые эта философия решает:
1) Регулярная и ранняя поставка ценного программного обеспечения.
2) Обеспечение заказчику конкурентного преимущества
3) Выпуск продукта с периодичностью от пары недель до пары месяцев.
4) Налаживание устойчивого процесса разработки.
5) Повышение гибкости проекта.izvolov Автор
26.11.2018 23:32Ничего из перечисленного манифест не решает. Это решает только правильно поставленный конкретный техпроцесс в конкретной команде.
DexterHD
26.11.2018 23:38+1Ничего из перечисленного манифест не решает.
Решает, с помощью 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) Scrumbanizvolov Автор
26.11.2018 23:39Во-первых, не всё, что здесь перечислено, является полноценным техпроцессом.
Во-вторых, речь шла про манифест. Не нужно соскакивать с темы.
DexterHD
26.11.2018 23:41+1Методологии являются развитием ценностей сформулированных манифесте. Ни кто с темы не соскакивает. Странно что для вас это не очевидно. Они не на пустом месте родились эти методологии. Они все разделают общую философию.
izvolov Автор
26.11.2018 23:51Внимание. В данной ветке мы говорим о манифесте.
Обсуждать "производные" от него объекты — это отдельное удовольствие.
altrus
27.11.2018 12:50Проблему внутренней удовлетворенности программиста
Иногда это намного важней всяких продуктов и сроковLex-is
27.11.2018 18:01Несомненно. Так никто и не мешает программисту внутренне удовлетворятся за свой счет. А заказчики и руководители проектов, странные люди, отчего то хотят деньги получить а не уйти, по результатам разработки прекрасного кода, на несколько миллионов убытка. Никто же не мешает программисту самостоятельно привлекать средства, писать прекрасный код, получая от этого глубокое удовлетворение, и продавать его зарабатывая много денег.
DexterHD
27.11.2018 22:32Я не отсылаю вас к авторитетам.
Я вам предлагаю сперва разобраться в вопросе. Потому что на мой взгляд вы обсуждаете манифест не имея ни малейшего представления о том, какие на самом деле идеи в нем заложены. Если вы хотите реально конкретных ответов на поставленные вопросы, откройте книги авторов манифеста и почитайте их.
В них написано и как решить проблемы сдачи качественного продукта в установленный срок и как решить проблему предсказуемости выхода обновлений и даже о том, как разрабатывать архитектуру приложений которые стабильно работают и адаптируются к изменениям требований. Все эти книги и их авторов легко найти в интернете.
Приведу простой пример. Я думаю вам точно известны SOLID принципы. Так вот их сформулировал один из авторов и главных вдохновителей Agile манифеста. Вы же не станете утверждать теперь, что SOLID — чушь и не работает?izvolov Автор
27.11.2018 22:40Я не отсылаю вас к авторитетам.
Позвольте! У меня все ходы записаны:
Я бы посоветовал автору просто ознакомится с биографиями и опытом людей которые сформулировали Agile манифест…
https://habr.com/post/431064/#comment_19415788
Потому что на мой взгляд вы обсуждаете манифест не имея ни малейшего представления о том, какие на самом деле идеи в нем заложены.
Но вы ведь тоже обсуждаете "мой" манифест не имея ни малейшего представления о том, какие на самом деле идеи в нём заложены.
Обсуждайте. Только в рамках приличия, пожалуйста.
Все эти книги и их авторов легко найти в интернете.
Я даже читал некоторые из них, и даже со многим согласен. Значит ли это, что я должен соглашаться со всем, что будут говорить эти авторы в будущем?
Вы же не станете утверждать теперь, что SOLID — чушь и не работает?
Нет, не стану. См. выше.
DexterHD
26.11.2018 23:02+1Позвольте! У меня все ходы записаны:
Уделали… Мой посыл отсылки к «авторитетам» как раз в том что мне кажется вы не совсем правильно поняли данный манифест (А может и не хотели понять).
Просто Agile как раз таки решает некоторые из тех проблем которые вы затронули в своем манифесте.
Ваш манифест больше похож на манифест разработчика которого достали «эффективные менеджеры».
Но проблема в том что Agile тут не при чем. И эти менеджеры понятия не имеют что такое Agile и не следуют тем методологиям которые наследуют данную философию.izvolov Автор
26.11.2018 23:15По-видимому, это разговор бесконечен, потому что не существует никаких исследований на тему того, что аджайл либо "улучшает", либо "ухуджает" разработку ПО.
Многие люди считают, что аджайл (обобщённый) работает, потому что лично у них всё получилось. Но тут как с гомеопатией. Многие утверждают, что лично им помогло, но механизма воздействия предъявить не могут.
Ваш манифест больше похож на манифест разработчика которого достали «эффективные менеджеры».
Не допускаете мысль, что, наоборот, просто вам сильно повезло, вопреки аджайлу?
И эти менеджеры понятия не имеют что такое Agile и не следуют тем методологиям которые наследуют данную философию.
О том и речь, что эта "философия", независимо от того, какие цели изначально преследовали или не преследовали авторы, направлена на перекос в сторону интересов одной из сторон. А внедряет эту "философию" именно та стороны, в чью сторону идёт перекос. Хорошо ли это? А вот здесь, видимо, у разных сторон ответ свой.
DexterHD
26.11.2018 23:26По-видимому, это разговор бесконечен, потому что не существует никаких исследований на тему того, что аджайл либо «улучшает», либо «ухуджает» разработку ПО.
Вообще то существуют. Не про обобщенную философию кончено, но про конкретные методики. И как правило с цифрами и метриками.
Не допускаете мысль, что, наоборот, просто вам сильно повезло, вопреки аджайлу?
А почему мне повезло? Потому что я не работаю с эффективными менеджерами?
О том и речь, что эта «философия», независимо от того, какие цели изначально преследовали или не преследовали авторы, направлена на перекос в сторону интересов одной из сторон. А внедряет эту «философию» именно та стороны, в чью сторону идёт перекос. Хорошо ли это? А вот здесь, видимо, у разных сторон ответ свой.
Да, здесь есть проблема, потому что внедрять ее должны разработчики, которые понимают о чем она, а не менеджеры которые вообще ни чего не понимают в разработке ПО.
И нет в ней нет перекоса, даже если это не очевидно. Более того, чтобы избежать заблуждения о том что существует перекос, Agile был дополнен создателями другим манифестом.
Вот он:
manifesto.softwarecraftsmanship.org
random1st
27.11.2018 22:11Я про предложенный манифест и не говорю. Он наивен до невозможности. Но и Agile я могу критиковать до бесконечности.
Individuals and interactions over processes and tools — нам вообще неинтересно как вы это сделаете, пожалуйста, говорите это вслух, а то мы ничего не понимаем в вашей тарабарщине.
Working software over comprehensive documentation — работает, и ладно. Документация нам зачем?
Customer collaboration over contract negotiation — мы сами не знаем чего хотим. Давайте выяснять в процесссе.
Responding to change over following a plan — когда вы все закончите, мы резко захотим все переделать.arilou_camper
27.11.2018 22:35хоспади, зачем я в это всё ввязался-то?)
Working software over comprehensive documentation
К.О.: потому что бизнесу нужно именно working software.
Customer collaboration over contract negotiation
К.О.: потому что согласование контракта с ТЗ со всеми мелочами может занять больше времени, чем есть на вывод продукта на рынок.
Responding to change over following a plan
То есть, если рынок изменился, и план больше не актуален, вы предлагаете все равно продолжать его придерживаться? )lingvo
26.11.2018 23:21Другими словами — давайте сделаем грязно, но быстро или чисто, но долго. В продуктах, чей жизненный цикл не превышает пару лет, допустимо первое. Продукты, чей жизненный цикл от 5 лет и более, требует второе. Вот поэтому в Software agile и любят.
mentatxx
27.11.2018 12:50А мы согласуем контракт на разработку продукта, или продажу разработчиков по time&materials?
Если первое — и не согласовать что конкретно мы должны сделать, сколько у заказчика есть итераций на согласование дизайна, сколько у заказчика есть время на приемку каждой фичи/итерации, и не включить в контракт что именно мы должны по нему выполнить, то можно встрять на конкретные деньги. Сколько раз уже видел примеры до чего доводит принцип «лишь бы продать».
А вот если просто продать гребцов на конкретный срок — то тут уже заказчик может хоть десять пивотов устроить за свой счет, на здоровье. Но заказчик тоже не дурак — он посмотрит конечно на накаченные бицепсы и хорошие зубы разработчиков, но ему то нужен выполненный продукт. Потому продавать живой товар обычно сложней.arilou_camper
27.11.2018 14:22А мы согласуем контракт на разработку продукта, или продажу разработчиков по time&materials?
Мне кажется, вы путаете теплое с мягким. Я этот принцип понимаю так: чем тратить время на согласование ТЗ, детальной оценки трудозатрат, сроков и стоимости, и существенных, да и несущественных условий контракта, лучше взять гибкий контракт (T&M — хороший пример) и начать работу, разибраясь в деталях по мере продвижения.mentatxx
27.11.2018 15:07Почему путаем? Вся эта философия в отрыве от реальности не имеет смысла, потому проецируем на обычный кейс. Например, мы обычная галера и хотим продать заказчику наши услуги.
У заказчика обычно ограниченный бюджет, потому продать ему гибкий контракт намного сложней. В этом случае риски также уходят на заказчика, к чему заказчики готовы еще меньше.
Customer collaboration over contract negotiation — это хорошо для крупных американских корпоративных клиентов, где услуги поддержки/разработки проданы на год вперед, и дальше уже делаем максимально хорошо заказчику на выданный бюджет. В условиях же большинства проектов маленьких галер это только доставляет проблемы как заказчику, так и исполнителюarilou_camper
27.11.2018 15:13безусловно, есть нюансы, не везде подходит. НО это не «философия», это вполне рабочая модель. я считаю, что перенос рисков заказчика на разработчика — это порочная практика.
// не называйте место своей работы галерой. слава б-гу, сейчас нигде нет рабства, и вы вольны встать и уйти в любой момент.mentatxx
27.11.2018 15:38Считаю себя свободным галерщиком. Для меня понятие «галеры» не связано с рабством, а с необходимостью грести вместе с командой. Чтобы проникнуться атмосферой, рекомендую исторические фильмы
random1st
27.11.2018 17:23Типичная ошибка инженера. Бизнесу пофиг ваш софт, бизнесу нужна возможность, которую тот реализует. Не факт, что ему вообще надо что-то писать («сделайте мне Яндекс, только как Гугл»). Софт — это всего-лишь модель, описание системы.
arilou_camper
27.11.2018 17:26это мне ответ? спасибо, я в курсе про «возможность»; на уровне технической команды бизнесу нужно именно working software.
lingvo
26.11.2018 23:12«Внезапно» один из авторов Agile манифеста (Stephen J. Mellor), как раз в свое время специализировался на по embedded и realtime системах, и работал в том числе в CERN. А сейчас является CTO в Industrial Internet Consortium который был создан копаниями AT&T, Cisco, General Electric, IBM и Intel
«Внезапно» Но он же не придумывал Agile для embedded и real-time? Причем здесь его предыдущая специализация?
DexterHD
26.11.2018 23:17Agile это про software в целом а не про отдельные направления. Это в первую очередь философия, система ценностей.
lingvo
26.11.2018 23:24… которая почти нахрен не нужна в embedded или real-time. А вот философия и ценности, описанные в данном манифесте, в принципе, вполне к ним относятся. Поэтому я и предлагаю автору переквалифицироваться.
iehrlich
27.11.2018 22:46На стройке ходят в касках. Почему? Потому что этого требует техника безопасности.
Почему?izvolov Автор
27.11.2018 22:47Что-то мне подсказывает, что для того, чтобы снизить травматичность на производстве.
xitt
26.11.2018 23:28Как вариант — Потому что страховку не выплатят?
s-kozlov
27.11.2018 18:14А почему страховые компании не хотят выплачивать людям, которые ходят без касок?
xitt
27.11.2018 18:40Потому что компаниям выгодно получать взносы и не платить страховки?
s-kozlov
28.11.2018 12:05Вот мы и пришли к тому, что страховые компании, которые умеют считать деньги и поэтому разбираются в статистике страховых случаев, считают, что в касках безопаснее.
xitt
28.11.2018 18:09Страховые компании полагают по статистике, что выплат получается меньше в касках, чем без касок, а то что ходить в каске безопаснее. Это немного разные вещи. Например, мой случай — при выезде задом с парковки в меня вьезжают, хотя я стоял на месте под 45 градусов и готов был трогаться вперед. Моя страховая выплачивает тому кто вьехал, не потому что я нарушил технику безопасности, а потому что закон штата говорит, что в данном случае виноват я. Если коротко, я понимаю вашу мысль, но количество выплат и соблюдение техники безопасности это разные вещи, хотя и находятся в корелляции.
elCreator
27.11.2018 22:51Проекты разные, описан очень частный случай, когда это может сработать: если на старте команде известно, чего будут все еще хотеть заказчики через год-два, когда продукт будет готов и оттестирован. Например, если инвестор верит в гениальность идеи и способность убедить пользователей, что продукт — именно то, что им нужно (именно убедить, а не методом проб и ошибок понять).
horror_x
26.11.2018 23:01Я как-то пытался продвигать на работе свои идеалы, но быстро выгорел. Основная проблема тут социальная — нужно ещё как-то убедить и других программистов, зачем делать «лучше» и дольше, если можно удовлетворительно и быстро. А тут и характеры у людей разные, и понимание процесса у всех разное.
Ещё и доказывать надо, что «лучше» — действительно лучше. С этим у меня всегда были проблемы, т.к. не особо красноречив и впадаю в ступор при необходимости объяснять очевидные вещи. При чём немалая часть людей всё понимает, но им просто всё равно или банально лень.
А потом, когда натыкаемся на очередные грабли и самое время сказать «а я же говорил!» и прочитать лекцию про технический долг — никто уже и не помнит как так получилось. Такие проблемы воспринимаются как данность, об их причинах никто не думает — некогда.powerman
26.11.2018 23:15+2К сожалению, единственный способ решить эту проблему — качать софт-скилы. Чтобы писать хорошо код вполне можно обойтись техническими навыками, но вот объяснить коллеге почему код нужно писать именно так — это уже работа с людьми (и не смотрите что вроде он тоже программист, это не поможет), и она требует совсем других навыков, не технических. Хорошая новость в том, что софт-скилы всё-равно пригодятся, без них сложно стать действительно хорошим сеньором, и тем более тимлидом, архитектором или CTO.
izvolov Автор
26.11.2018 23:24-1Зачем кому-то из программиста становиться станцией технического обслуживания?!
ardentum
26.11.2018 23:49+1Погодите, так это была не ирония? Я, наверное, по аджайлу быстренько прочитал вступление, и дальше думал, что вы так изящно троллите неповоротливых программистов.
sotnikdv
27.11.2018 07:47-1Наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста, благодаря продуманному плану и следованию технологии разработки ПО. И, как результат всего этого, удовлетворение от результатов своей работы.
Отлично, Вы молодец,я дам вам парабеллум.
А вот денег вам не дадут-с, деньги-с платят не за ваше удовлетворение, а за решение проблем бизнеса.
Enrey
27.11.2018 08:14На самом деле описанные в статье проблемы признаются мировым сообществом, в т.ч. самими авторами 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 :)
izvolov Автор
27.11.2018 08:24Краткие итоги обсуждения.
Два из трёх основных противников этого манифеста стали бы шантажировать увольнением инженера, который говорит, что работа не делается в тот срок, который спущен "сверху". Третий же, судя по комментариям, с ними солидарен.
… если Вы пришли в нашу компанию для того, чтобы получать два месяца зарплату за бесполезную деятельность по написанию кода, который никогда не будет запущен — пожалуйста, напишите заявление по собственному прямо сейчас...
powerman
Следующее действие — увольнение по инициативе работодателя и можете идти с этим в суд. :)
DexterHD
Что и требовалось доказать.
le1ic
27.11.2018 09:13Действительно, на работе нужно работать
KTG
27.11.2018 10:41Это из разряда «как отучить людей воровать».
Сработает только если все люди одновременно перестанут воровать, будут крайне осуждать или да же серьезно наказывать вплоть до смерти, Потом вообще запретят об этом говорить, что бы искоренить само понятие и так же нарушивших выпиливать из общества. И уже тогда через несколько поколений воровства не будет.
Призыв делать качественно и продуманно в разрез быстро и как придется не несет ничего плохого. Утопичен, но порицать тут не за что.
Это то же будет работа, только другое отношение к ней.Milein
27.11.2018 13:32+1Наёмные работники нужны не для того чтобы делать работу, а для того чтобы сделать работу. Любые манифесты, у которых во главе угла поставлена другая цель это действительно саботаж. Это естественно я не про ТБ (и прочие нормы), они по умолчанию идут первыми и не обсуждаются.
Зачем вам тесто для булочки сделанное по высшим понятием пекаря, если булочки никогда не будет? Это не отменяет того что булочку надо сделать вкусной. Но для этого сначала её нужно сделать.
le1ic
27.11.2018 16:11В нормальной здоровой компании это роль СТО и/или VP of engineering компенсировать неудержимые хотелки продавцов. Его ответственность балансировать между сроками, качеством, себестоимостью. Естественно как с фидбэком от архитекторов/разработчиков, так и от бизнеса. К сожалению, часто при проектной организации работы, равномощного противовеса ПМ обычно нет. И вот такие низовые манифесты рядовых разработчиков для бизнеса действительно близки к саботажу.
izvolov Автор
27.11.2018 10:04Перепутал местами ссылки. Первая ведёт на вторую цитату, а вторая — на первую.
DexterHD
27.11.2018 11:09Два из трёх основных противников этого манифеста стали бы шантажировать увольнением инженера, который говорит, что работа не делается в тот срок, который спущен «сверху».
Наглая ложь и подмена понятий. Я нигде не утверждал, что я бы уволил кого-то из-за срыва сроков спущенных «сверху». Я лично на работе ни когда не говорю «Да», срокам спущенным сверху, если они противоречат моей экспертной оценке. При этом, мне это не мешает работать по Agile и сдавать продукт в срок. А вам мешает. Мы сразу бежите в трудовую инспекцию и проставлять минусы в комменты :Dizvolov Автор
27.11.2018 11:10-1Глупо обвинять меня во лжи, когда весь текст перед глазами.
DexterHD
27.11.2018 11:12Глупо обижаться на всех вокруг, когда у кого то получается а у вас нет :)
altrus
27.11.2018 12:46-1Чисто для статистики, можно узнать насколько уменьшилась ваша карма на этом топике?
DexterHD
27.11.2018 14:52-1На 5.5 единиц. Я например вообще не минусую ни кого как правило, и уж тем более не трогаю карму. Увы но сообщество на Хабре давно уже не то, что было раньше…
altrus
27.11.2018 15:09-2Ну, не надо так категорично
Из 5-10 тысяч читателей вас личным врагом признали всего 6 человек. Всего одно промилле.
К тому же страдать за правду сам Бог велел. И Джордано Бруно.
powerman
27.11.2018 15:18+1Наглая ложь и подмена понятий. Я нигде не утверждал, что я бы уволил кого-то из-за срыва сроков спущенных «сверху». Я лично на работе ни когда не говорю «Да», срокам спущенным сверху, если они противоречат моей экспертной оценке. При этом, мне это не мешает работать по Agile и сдавать продукт в срок.
Полностью согласен, у меня ровно так же.
Я никогда не соглашаюсь писать говнокод, и редко когда соглашаюсь участвовать в разработке проекта, сроки которого не позволяют сделать его достаточно качественно (по моим личным меркам).
Но я не вижу ничего некорректного в том, чтобы наниматель, которому нужны такие проекты, поручил их не мне, а тем разработчикам, которые готовы делать то, что нужно нанимателю. Мне кажется странным принуждать нанимателя платить мне за то, что я буду делать не то, что ему нужно, а то, что я считаю правильным. Зачем создавать этот конфликт на пустом месте, если всем будет только лучше, если я просто уйду на тот проект, в котором потребности нанимателя и мои личные не содержат принципиальных противоречий?
le1ic
27.11.2018 09:30Общий комментарий. Последнее время в среде программистов стали набирать популярность левацкие идеи. Речь не только об этой статье, и не только о Хабре. И с исторической точки зрения и взгляда из космоса это кажется нелишенным смысла. И если представить программную компанию, как фабрику по производству ботинок со средними по рынку зарплатами, то идеи получать деньги за прохождения собеседования, добиваться долгого и детализированного изменения каждого требования и т.д. выглядят защитой интересов программистов как класса в марксистском смысле.
Однако софтверная индустрия уникальна последние 20 лет. Здесь крутятся одни из самых больших денежных объемов, которые не зависят от наличия природных ресурсов, влиятельных лоббистов в правительстве, даже границ государств. Выигрывает тот, кто умнее, работоспособнее, упорнее, ну и удачливее конечно. И пока часть программистов будет добровольно приравнивать себя к мелким наемным рабочим и заниматься борьбой в этом болоте, другая часть будет в… бошивать по полной, по 80 часов в неделю, без отпусков и менять этот мир.
Я за последние 10-15 лет работал в трех компаниях, которые можно назвать стартапами, одной русской, и двух американских. Одной не очень удачной в целом, но не без отдельных удачных проектов, одной весьма удачной с очень хорошим выходом, и одной пока в процессе. И никогда успех не приходил просто так, при работе по графику и утвержденному плану. Успех всегда приходил, когда все силы бросались в небольшую форточку возможностей, когда ты знаешь что есть несколько конкурентов, которые точно также сидят за работой в 11 часов вечера. И побеждает более настойчивый, более компетентный, более собранный, более заряженный на победу.
«The Extra Mile Is Never Crowded»DD174
27.11.2018 11:21Все верно, но если программист наемный работник, то он относится к классу пролетариата.
Осознания себя как части рабочего класса, ни как не может мешать выкладываться по 80 часов :)
mentatxx
27.11.2018 12:58Ради любопытства, при удаче стартапа вам давали какие либо бонусы? Успех компании компенсировал ваши overtime'ы?
le1ic
27.11.2018 16:02+1Я не боялся овертаймов, даже когда работал меньше чем за $200 в месяц без всяких бонусов в начале карьеры. Нужно выбирать интересные, перспективные проекты и команды, и тогда придет успех и удовлетворение от жизни. А если выбирать плюшевый офис с фуагра на завтрак, то как бы вы ни были круты изначально, все равно закончите болотом.
Ответ на ваш вопрос очевиден, он буквально из каждого утюга. Есть десятки и сотни тысяч программистов, ставших очень обеспеченными людьми. Даже в России в Яндексе таких множество. Есть, конечно, огромное число провалившихся стартапов, но если только вы не CEO, обманывавший инвесторов, то даже провал вам очень много даст.
PS. «бонусы» дают не при удаче. Бонусы — опционы выдают сразу на старте, ничего не обещая, сколько это может стоить. В некоторых компаниях даже предлагают самому выбрать из пары вариантов баланса между зарплатой и опционами, в зависимости от вашей текущей финансовой потребности и веры в компанию.
ArgentMind
27.11.2018 10:02+1Подобные манифесты очень круто смотрятся и даже могут использоваться в маркетинге, но при одном единственном условии: каждый ваш продукт, если вас не трогать и дать работать как надо, будет уровнем и потенциалом равен фейсбуку, амазону и иже с ними, а не очередным «ну мне пофиг на пользователей, мне так удобно и так правильно по архитектуре» =)
Есть сайты, которые делают SEOшники — они в топе, но их нереально читать. Есть сайты, которые делают дизайнеры: они красивые, но не функциональные и на дне выдачи. И есть сайты которые делают программеры. Как правило, для программеров.
Если вы не спец с мировым уровнем разработки, то не стоит использовать данный манифест — лучше станьте отшельником или создайте общину, делающую проекты для себя.
KTG
27.11.2018 10:11Здесь крутятся одни из самых больших денежных объемов, которые не зависят от наличия природных ресурсов, влиятельных лоббистов в правительстве, даже границ государств.
Фармакология и еще с десяток направлений имеющих больший объем денежного оборота.
В целом — да, пока ты вспоминаешь где ширинка, другой уводит девушку к себе.
Все зависит от поставленных задач.
Твердо и уверенно можно вести только личные проекты, хотя основательного и логичного подхода не хватает.
Видел 2 конторы которые торопясь сами себя закопали: тут костыль, тут как быстрее, а не как лучше, и тут «времянка». А потом все это как снежный ком обрастает и в один момент разваливается.KTG
27.11.2018 10:49дополню что в одной из них крутилась тикет-система с проставленным таймингом задач, по которой потом считали KPI.
И люди боролись за количество отработанных задач.
Каково вам например увидеть в коде запрос к базе из 5 связанных таблиц, но в котором тем не менее 2 десятка полей вызываются отдельным подзапросом?
А все потому что так добавить вывод поля мелким подзапросом занимает 5 минут, а построить запрос что бы учитывал необходимость добавления доп. полей и условий — 30 минут. Ну так что бы и логика прослеживалась, и связь, и ресурсов много не жрал.
В итоге, утрированно, 2 цифры в отчет выводятся 15 минут…
9zloy
27.11.2018 10:521. Создают продукты те, кто работает над ними
2. Не создают продукты те, кто над ними не работает
3. Работайте над продуктами
JackKatch
27.11.2018 11:05Полностью согласен с автором! Из-за таких agile-манифестов нет нормального работоспособного ПО. Куда не посмотри, всё глючит, падает и т.д. Видел как женщина вносила в терминал крупную сумму, терминал сказал ей:- Извините, ошибка. И перегрузился. Справедливости ради надо сказать, что противостоять agile-манифесту трудно т.к. некоторый резон, диктуемый рынком, в нём есть. Но с этим надо бороться.
9zloy
27.11.2018 11:08У меня очень много вопросов к этому манифесту. Так как izvolov активен в комментариях, я смиренно надеюсь, что он найдет время ответить на 11 простых вопросов, которые, вне всякого сомнения, прояснят глубину его мысли и дальность её полета.
- Почему концепция важнее новых требований? Откуда это следует? Создавая систему, мы постоянно ставим эксперименты, которые влияют на концепцию. И что такое концепция вообще в вашем определении?
- Почему качество важнее скорости?
- Делать как надо? Это как именно? Полагаясь на что? На интуицию? На звезды? На физику параллельной вселенной?
- Почему наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста? А как же пользователи с их проблемами? Программист работает для себя или для пользователей?
- Какой уровень качества необходим? Кто это решает? Как именно?
- Как быть начинающим разработчикам? Они еще не профессионалы, как им работать вообще?
- Что такое качественный продукт?
- Для какого софта можно разработать матмодель? Что такое матмодель для игры Packman? Что такое матмодель для движка Habr?
- Почему мы должны ориентироваться на каски строителей и хирургов?
- Что такое хороший техпроцесс?
- КОНТРОЛЬНЫЙ: Что такое качество?
KTG
27.11.2018 11:37-1Не автор поста, но часть вопросов абсурдны.
Да и скорей это относиться к корпоративному ПО или крупным проектам.
Прототип стартапа хоть на коленке делай.
1. Потому что да же мелкие проекты должны иметь ТЗ. Если нет ТЗ — получается каша, и не видно конечной цели. Если проект чуть крупнее и есть сроки -то потом с тебя же и спросят почему проект не закончен, и попробуй объяснить что ты отклонялся от ТЗ из-за вдохновения Васи-Пети и их новых идей.
2. Узнаешь когда заведешь себе девушку. Может шутка грубовата.
Но суть в исключении ошибок по невнимательности и выбора неверных подходов, которые повлияют на стоимость дальнейшей разработки. Например отсутствие масштабируемости.
3. На технологии и нормы. Без костылей.
6. Тщательней готовится, читать документацию. Разбивать этапы разработки на подзадачи и изучать способы их реализаций.
9. Потому что это аналогия.
10. Когда предусмотрел всё или почти всё и любой этап от идеи до релиза идет по отлаженным рельсам. А сход с них — форс-мажор, а не правило.
В целом, если критично относиться к данной мысли изложенной автором, то 70% статей хабра можно удалять за ненадобностью, т.к. они как раз и расписывают как надо или как стоит делать, и как будет лучше/качественней/продуктивней/производительней.
А то получается на «говнокод» мы плюемся, а не плодить его отказываемся.9zloy
27.11.2018 11:42Я ждал автора, но что же. Эти ответы совершенно неудовлетворительные.
1. Даже с ТЗ подавляющее большинство проектов получается с задержками по времени, с большим количеством багов и с 0 пользой для клиентов. ТЗ не является ответом
2. У меня жена и двое детей. Иногда надо быстро, пока дети не проснулись.
3. Что такое норма? Что такое технология? Что такое костыль? Пожалуйста, эти абстрактные ответы оставляйте при себе. Нормы не существует.
9. Аналогии не всегда работают, не так ли?
10. Это бывает только никогда. Вернее, только при разработке очень простых и понятных система. Например, сайта для индивидуального предпринимателя Иванова.
Рекомендую начать углубляться в детали и понизить градус абстракции.KTG
27.11.2018 12:091. является. все вышеперечисленное ошибки на других этапах.
2. в вашем случае расценивайте «быстрее быстрого. Дети спали до утра, а вы закончили через 2 минуты.» Выбор неверных подходов, которые повлияют на стоимость дальнейшей разработки. — Позовите «тещу» посидеть с детьми.
3. Костыль — временное решение. Но ничего нет более постоянного чем временного. Я думаю все понимают что это, но на примере:
Это когда в 1С в отчетности ты в макете прописываешь подписантов, потому что надо вот сейчас, и забиваешь на реализацию механизма вывода подписантов из справочников ответственных лиц.
Нормы — это парадигмы в том же ООП, паттерны в проектировании. Понимание сущностей, явное объявление переменных и корректное комментирование кода, это все то же норма. Общепринятая практика устоявшаяся на многолетнем опыте.
9. Не всегда, но применимы в общих чертах и имеют место быть. Все зависит от подхода.
10. Если подобные процессы налажены то и сложные системы становятся простыми и понятными как сайт для ИП Иванова. Сейчас инструментов для ведения этих процессов предостаточно.
ZakharP
27.11.2018 11:40+1Концепция предлагает создание основного ориентира для разработки ПО, основывается на проблеме клиента, которую необходимо решить.
Насчёт качества это как с ездой на самолёте если вести правильно то избегает катастрофы, при погоне за скоростью перенагружаешь элементы и теряешь много ресурсов и качества.
Делать зависит от выбора способа решения этот манифест лишь создаёт набор рекомендаций для упрощения разработки и только указывать какие способы работы лучше выбрать.
На этапе выбора концепции создаётся основа решения проблемы и этот манифест принуждает к лучшему исследовании проблемы клиента путем переговоров про необходимость различных функций и для правильности подбирают концепцию для современного и качественного решения по принципу sancta simplicity, уберая фантазии клиента.
И как следствие при высокой эффективности разработки находиться правильное решение проблемы.
Разумеется нет идеального манифеста.
В связке с концепцией можно создать систему оценки качества и выполнения, и тогда учитываются особенности предметной области проекта.
Начинающие как и всегда будут по разному пытается применять разные методологии, эти манифесты подсказывают принципы разран при этом давая часть опыта для избежания проблем.
Качественный продукт -тот который определил клиент и команда, методология лишь указывает принцип того что работа должна быть выполнена правильно и качественно.
Матмодель позволяет без реализации проверить реальность работы ПО, то есть экономит время отладки, а также даёт ПО лучшую возможность анализа. Но в некоторых приложениях необходимо лишь сделать обычную UML модель и проанализировать матметодами (мое мнение весьма не компетентно)
Перегрузка лубого рабочего уменьшает его эффективность, а в результате увеличивает критическую цепь проекта.
Хороший техпроцесс это эффективность, качество и интуитивное понимание выполнения проекта, но тут интуитивное заменяется система оценивания
Качество определяется концепцией и эффективностью решения9zloy
27.11.2018 11:50Отвечу то же самое, что и предыдущему оратору. Рекомендую начать углубляться в детали и понизить градус абстракции. По вашим ответам невозможно создать процесс разработки. По манифесту выше это хотя бы возможно, но к сожалению процесс получится совершенно неудовлетворительным с самых разных точек зрения, потому что он будет подходить только для узкого круга задач.
Автор упускает довольно много важных деталей разработки ПО:
1 — высокую неопределенность
2 — психологию пользователей, которые редко знают, чего хотят
3 — сложность создания систем (особенно в группе, особенно в большой группе)
4 — невозможность формализации системы. ТЕМ БОЛЕЕ на уровне матмодели.
5 — экспериментальный характер процесса разработки.
Основная задача — увеличить скорость накопления знаний. Это следует делать увеличением количества экспериментов, ускорением экспериментов и постоянным взаимодействием с пользователями системы. Agile хотя бы делает к этому шаг, автор текущей статьи отпрыгивает назад шагов на 15
KTG
27.11.2018 12:168. Математическая модель видимо Вам представляется одними цифрами.
Но для того же хабра часть этой модели будет например расчет рейтинга комментариев и постов, условия привязки этих самых постов к авторам, проверки на валидность той же почты при регистрации. Количество постов в «Что обсуждают» и расчет периодов.
В отношении сайтов это редко, практически никогда не рассчитывают заранее. Хотя может предполагаемую нагрузку для выбора хостинга, объемы информации для выбора хранилища. Затраты, объемы рекламы. Может не точный, но приблизительный расчет ведется.
А Пакман… в геймдеве сплошь и рядом математические модели — баланс, подсчет очков, условия возникновения событий и т.д.9zloy
27.11.2018 13:21Ладно, если математику 9 класса считать матмоделью софта, то я рад за вас. Ваша жизнь удалась.
KTG
27.11.2018 11:53Самое интересное что тут нет противопоставления.
Если разбирать Аджаил принципы то там вполне себе кроется основательный подход на стадии проектирования, иначе никак.
Релиз ПО с ошибками — это не работающее ПО и там и там.
Пересмотр архитектуры под новые требования — это не отказ от внесения изменений.
Анализ, самоорганизация, минимизация лишней работы — все то же самое что у автора поста.
Только другими словами.
tuxi
27.11.2018 13:10+1Я с большим удовольствием прочитал обсуждение, все таки это правильно, иногда всколыхнуть болото-трясину.
На ум пришла одна аналогия, объясняющая как мне кажется, причины таких бурных споров. Вот возьмем большое производство. Там обязательно есть НИОКР (в том или ином виде), назовем его отделом «перспективных исследований», есть конвейер где монотонно согласно строгому ТЗ собирается из деталей готовый продукт, есть худо-бедно собственное производство таких деталей, где ТЗ меняются, редко но всеж меняются.
В отделе «перспективных и не очень» исследований большая свобода, есть время поизучать и поставить эксперименты.
В отделе производства деталей работают высококлассные токари и мастера инструментальщики, которые могут сами придумать (или технолог поможет) и изготовить оправку/приблуду для сборки изделия на конвейере, могут выточить нужные детали с точностью, большей чем можно купить у поставщика.
На конвейере… ну кароче обычные «галеры» этот конвейер.
Вот в случае с программированием, во всех этих отделах, работает как правило один и тот же человек. Отсюда такие разнополярные мнения и возникают.
vovansystems
27.11.2018 13:27кстати, очень интересная методология подхода к работе описана у дизайн-бюро Горбунова и называется ФФФ bureau.ru/about/fff
Аббревиатура ФФФ означает fix time, fix budget, flex scope. Мы работаем с фиксированными сроками и бюджетом, а функциональность оставляем гибкой (по согласованию с заказчиком)
lingvo
27.11.2018 18:32Из этой методологии выводятся другие две.
Fix time, fix scope, flex Budget
Fix Scope, Fix Budget, flex Time.
Это не новая методология, а частный выбор из стандартного треугольника проект-менеджмента
vovansystems
28.11.2018 00:32да, безусловно. я просто наткнулся на описание ффф и разъяснения как именно такой подход помогает в разработке сайтов ещё в те времена, когда в русскоязычном сегменте сети ещё не говорили про эджайлы и мне это очень понравилось, потому что на тот момент было принято ругать заказчиков за плохо составленное ТЗ и изменения навязываемые в процессе :)
вполне возможно, что и автору статьи и некоторым другим пользователям может быть интересна и такая интерпретация, которая может подойти для частных случаев или простых проектов. а то мне кажется странным совет комрада DexterHD — прочитать по одной книге основных автором манифеста Agile — это большая трата ресурсов, а тут таки одна страничка и куча ответов на конкретные вопросы по работе с заказчиками.
наверное, мне самому это чтение было интересно в первую очередь потому, что тут есть понимание интересов бизнеса и идёт поиск новых (на то время) подходов, чтобы их учитывать — ход мыслей и логика описаны хорошо, возможно это поможет кому-то ещё разобраться в том зачем в принципе могут быть нужны всякие эджайлы.
дисклеймер: я сам не разработчик, а больше системный администратор, но и с разработчиками сталкиваюсь регулярно. то есть уровень про который со мной предметно можно разговаривать — это небольшие команды и проекты :)
Serge3leo
27.11.2018 13:56Какое прекраснодушие, «… чтобы довести всё это до ума. А потом начинают «фиксить баги»....»
К гадалке не ходи, отдел тестирования и пользователи всё так же будут выявлять ошибки. Программисты, работающие по сему манифесту, будут их вкладывать в мат. модель и исправлять, ну или корректировать мат. модель и исправлять. А служба поддержки всё так же будет еженедельно собирать готовые и оттестированые, на данный момент, исправления и отсылать пользователям.izvolov Автор
27.11.2018 14:01
arilou_camper
27.11.2018 14:32izvolov Дмитрий, я бы все же хотел попросить вас ответить на два моих вопроса, которые вы проигнорировали.
1. Какие именно интересы одного круга лиц agile превозносит над интересами другого, да и о каких конкретно кругах тут идет речь?
2. Какие ваши права как программиста ущемляются agile-манифестом (и/или вытекающими из него методологиями)?
lotse8
27.11.2018 16:44Такой подход хорош в конторе с неограниченным финансированием из госбюджета, типа «Роснано». Когда финансы ограничены, эта идиллия может закончится раньше готовности продукта по причине отсутствия финансов.
Qwoter
27.11.2018 16:46Комментарии это конфликт интересов в чистом виде.
Чем дальше от сердца бизнеса тем более солидарны с идеей манифеста.
По ходу движения к руководителям начинается настоящая истерика, у некоторых полное отрицание.
Я бы согласился со второй группой людей но… Напоминает людей которые завели свой маленький бизнес на рекламе в интернете после чего стали апостолами удаления адблока из своей жизни и жизни других людей только потому что это им выгодно по их мнению.
Мое мнение что инженерный ум не совместим с продажным но «целое больше, чем сумма его частей» и те кто найдут компромис не потеряв себя как программиста, маркетолога и тд пойдут дальше в бизнесе основанном на технологическом продукте.
AlePil
27.11.2018 16:55Спасибо автору, комментарии к статье-манифесту доставили огромное удовольствие.
mskotyn
27.11.2018 17:59Все это становится реальностю когда реальностью, когда пишешь код или для авиации или для атомной энергетики или для космоса. И наверно с использованием языка Ada.
evgenWebm
27.11.2018 17:59Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят
Проблема в том, что клиент вертел этот манифест. Как для утопии еще годится.
abar
27.11.2018 18:54+1Вкачусь со взглядом со своей колокольни. Я работал 4 года в Германии, и сейчас в балтийском банке, с трудовыми практиками России не знаком, так что не судите строго.
Выше по ветке читал обсуждение про ТК из которого могу сделать вывод что ситуация в РФ гораздо мягче к девелоперам. Если бы я на любой из своих работ попробовал подойти к начальству и потребовать выполнения манифеста именно такими словами, то меня бы уволили к херам за то, что порчу коллективу мир розовых поней. В смысле, за несоблюдение трудовой этики. Или для улучшения диверсити внутри команды. Или просто дали бы доработать год до истечения контракта после чего выяснилось бы что продлить его совершенно случайно не могут. В общем, способов бортануть борзого сотрудника тут гораздо больше чем с ТК РФ. Но это так, прискаска.
На первой работе, несмотря на декларируемый эджайл (практикам которого мы практически не следовали), работали мы практически по этому манифесту. Наша команда сперва пилила набор утилит для тестирования, потом перенесли это в один фреймворк, который кое-как внедрили на всей фирме, и под конец наш синьёр с менеджером загорались мыслью выпустить этакий универсальный фреймворк для совсем крутой автоматизации тестов в мире CI/CD с использованием всех лучших практик, что бы он стал этаким стандартом вроде Netflix OSS для облачных решений. И вот тут-то всё и стухло.
Я был студентом-разработчиком, который по меркам немецких уровней имеет даже более низкий ранг чем джуниор с улицы. Пока два синьёра то по-одиночке, то парно разрабатывали ключевые принципы своей платформы, писали и внедряли этажи в своем фундаменте да оборачивали всё в тесты, а менеджер генерировал доклады того «как всё будет», на меня повесили всё остальное, что было не так интересно главным программистам — поддержка старой версии фреймворка и попытка внедрения новых фич, которые нужны уже сейчас конкретным командам. Поскольку мне не особо доверяли трогать бэкенд, то новые фичи создавались системами костылей на фронтенде. Изредка мне доверяли написать какой-то прототип, посмотрев на который синьеры говорили: «отлично, только не так и неправильно, но всё равно спасибо, пойдем внедрять это у себя и теперь уже правильно». Как же именно правильно мне так и не показывали. Осознавая ненужность своей работы я сидел с жутким выгоранием и работал только последний день перед еженедельном митингом чтоб отчитаться «прикрутил костыль, на остальное нужно больше времени». Самое смешное, что по результату мой труд никак не отличался от труда опытных синьёров которые из раза в раз докладывали «по прежнему пишем тесты!». Пару раз в это пытался вмешаться старший менеджер поверх нашего, стараясь напомнить комманде что вообще-то мы должны прибыль фирме приносить и как же так, где результаты, на что старший программист просто отрезал что-то вроде «Качество!» с чем никто никак не мог спорить. Ирония в том, что это самое качество финального продукта, гарантировать которое и было изначальной задачей нашего отдела (и про которое под конец уже все забыли за проектированием своего внутреннего продукта), стало под конец сильно падать, что повлекло изменения внутри команды. Но это уже другая история, которая связана не только с нами.
А вот уйдя с прошлой работы я после долгих колебаний пошел в работать банк. Боялся, что тут будет нечего делать, что технологии старые, что я не смогу, как мечтал на прошлой работе, пилить распределенные облачные сервисы на самых новых языках программирования в самых современных фреймворках. В банке же почти весь первый месяц занимался тем, что получал права доступа к базам данных и слушал обязательные тренинги, на которых нам вдалбливали, что банк работал 200 лет до твоего рождения (большую часть — вообще без всяких компьютеров) и собирается проработать ещё столько же задолго после того как ты умрешь. Единственный смысл банка — приносить прибыль, и платить тебе твою зарплату — это непостредственный убыток, так что будь добр — отработай так, чтоб прибыли было больше чем расходов.
Работа идет по самым жестким agile методикам, но при этом я понимаю, что такой свободы на прошлой фирме у меня никогда не было. Ежедневные стендапы, работа исключительно на бизнес-клиентов, и еженедельные отчеты от стэйкхолдеров позволяют не потерять перспективу того, что и для кого ты делаешь. И при этом дает вполне себе защищенность от от неадекватных запросов на переделки — если ты можешь аргументированно объяснить что и почему могут ухудшить/поломать изменившиеся запросы, то требования завернут, так ещё и благодарность тебе выпишут за бдительность. В начале работы я сумел убедительно доказать, что именно и как мы можем улучшить, к моим словам прислушились и мне дали зеленый свет. Это и есть то самое качество во главе, которое задекларировал автор этого манифеста, которое мы вполне себе нормально получаем при agile методологии.
TL; DR: На своем опыте я убедился, что следование ценностям, задекларированным в этом манифесте не гарантирует ни качественных продуктов, ни адекватной рабочей атмосферы, если коллектив состоит из программистов разных уровней. К тому же он по определению дистанцирует и противопоставляет заказчиков/руководство программистам, что не способствует здоровой атмосфере. В то же время правильно поставленный agile решает, в том числе, и те проблемы, которыми был озабочен автор этого манифеста.
Ещё одна мысль. На прошлой работе в один момент старшие программисты заинтересовались прикрутить машинное обучение к одному из основных компонентов (fuzzy тестирование с production данными) своего фреймворка. Поскольку задача была слишком большой для обычного прототипа, мне её поручили сделать как бакалаврскую в университете. Для сбора данных мне потребовался тот самый компонент, а поскольку закрытый коммерческий код выносить с предприятия было нельзя, я, с разрешения работодателя, сделал свой open source аналог. Что бы повторить главную киллер-фичу фреймворка (над которым на тот момент работали уже почти год) мне потребовались сутки. Ещё пара дней ушла бы на то, чтоб переписать работу с сокетами на С — просто для скорости, и возможно потребовалась бы неделя чтоб прикрутить слив данных с распределенных инстанцев в одну базу что бы поддерживать параллелизирование. Таким образом за месяц я мог бы выкатить кривую и косую (я совершенно не обманываю себя о том, какого качества код я произвожу относительно опытных senior developer-ов), но рабочую версию, дающую тот же функционал, что и продукт, который разрабатывается уже полтора года но так ещё и не был никуда выпущен. Разумеется, я не собираюсь этого делать, но информация о фреймворке выкладывалась в открытую сеть в виде презентаций (которые я и пересказал тут, что бы гарантировать, что я не не ломать NDA) и если бы продукт представлял реальную выгоду — у потенциальных конкурентов было бы более чем достаточно времени что бы выпустить свою версию, захватить и поделить рынок, пока команда спецов делает всё «правильно».
CheatEx
28.11.2018 01:17> Концепция важнее новых требований
Пойдёт.
> Качество важнее скорости
Надо развернуть, в чём измеряется качество и в чём скорость? Без внятных определений очередная философская херня натянутая на инженерную дисциплину.
> Делать как надо важнее, чем делать как просят
Как надо кому? Просят кто?
DrPaster
28.11.2018 10:18-1Программист — художник, созидатель, одиночка, самодостаточный профессионал.
Программисту не нужна шелуха, якоря и балласт в виде — общества, коллектива, помощников, коуч-тренеров, офисов.
Для программирования нет ни чего хуже — графиков работы, сроков, режимов, собраний, листочков на досках, пустых встреч, общения с заказчиком.
Идеальный заказчик — это: а) программист, б) внимательный к деталям и уравновешенный человек, личность в первую очередь (не пройдоха, хапуга, экономщик, быстро-быстро, стартапер и прочая требуха)
altrus
Даже для идеального мира не тянет.
У качества и скорости есть свои весовые коэффициенты — вот вам первый артефакт вашей матмодели
Кстати, что это за зверь — матмодель ПО?
«Делать как надо» — кому надо? кто сказал, что так надо?
Понятно, что в чем-то по сути вы правы, но вы безапелляционно вводите это в абсолют.
izvolov Автор
Всё здесь написанное нужно читать на контрасте с т.н. аджайл-манифестом, на который дана ссылка в предисловии.
altrus
Эджайл-манифест имеет право на жизнь. Ваш — нет (в смысле, не приложим к реальной жизни). Как отдельные абстрактные принципы — да, как манифест — нет.
Можно назвать манифестом оборзевшего разработчика ))
(признаю, что иногда использую подобные принципы, чтобы приструнить наглеющих заказчиков)
izvolov Автор
И вы. Но кто же прав?
altrus
Что «и вы»?
Я ничего не ввожу. Использую то, что удобней и правильней, при этом оценка «правильности» и мера использования проходит по множеству факторов, а не просто безапелляционно «Качество важнее скорости»
izvolov Автор
Откройте уже первую ссылку из этой публикации, и читайте обе страницы параллельно.
altrus
Если вы хотели сделать отражение эджайл манифеста — это ваше право.
Высказать в комментах мнение, что оно абсолютно не приложимо к реальной жизни — мое право.
izvolov Автор
?\_(?)_/?rfq
Экой вы, право, брутальный. Не все с вами согласны — www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/Michael-O-Church?share=1
izvolov Автор
Это вы точно мне хотели ответить? Если да, то я не понял.
Первая строка — цитата моего оппонента, если что.
rfq
да, ошибся дверью, прошу прощения. Надо было адресовать ответ вашему оппоненту.
Paskin
С таким же успехом статью можно назвать «почему разработчики считают дедлайны или менеджеров нонсенсом». Программирование перестает быть искусством и превращается в ремесло — сродни тому как когда-то мастера запирались в кузнице и ковали меч с неизвестным наперед результатом — а сегодня оружие делают на станках с ЧПУ.
StarTrinity_CEO
Почему не имеет? Я поддержу автора, у меня в компании на практике — близко к тому, о чем пишет автор
solver
Что «это» и где именно вы увидели возведение «этого» в абсолют?
Я вот ничего подобного не заметил. Все описано ровно также как и в аджайл манифесте и его концепциях.
И точно так же, как в аджайле, есть здравое зерно, но не все сходится с реальностью…
altrus
Я не пользуюсь эджайл и «за» дизайн и архитектуру ПО, но здравое зерно в эджайле примерно на порядок крупнее того, что здесь.
Попробуйте сунуться с этими принципами к следующему вашему заказчику/работодателю.
Попробуйте просто их применить для своего личного проекта.
Не будет этого, кроме как на простых школьных работах.
Никогда не сможет разработчик все просчитать на стадии дизайна, даже если требования не будут изменяться. Всё равно нужна подвижность и динамика.
solver
Либо вы читаете между строк, либо ваши каменты не от этого топика…
Я вот нигде не увидел фраз «все просчитать на стадии дизайна».
Черным по белому написано, что при изменении тербований просто запускается полный цикл продумывания изменений.
И именно так я всегда старался и делать.
altrus
Я ожидаю от вас или от автора статьи описания, как вы следующий свой проект сделали в полном соответствии с данным манифестом, чтобы не балаболить.
solver
Ох уж эти интернет воины))
Вы серьезно этого ждете? Вот прямо серьезно серьезно?
altrus
Нет, уже не жду
Можете продолжать балаболить.
solver
Парень, балаболишь здесь только ты))
Манифест, это не жесткие правила. Не догмы.
Это идеи которыми люди руководствуются при работе над проектами.
В аджайле есть несколько разных фреймворков, типа скрама и канбана, которые не одно и то же, но тем не менее руководствуются манифестом.
Так и этот манифест в разных ситуациях может выливаться в разные действия.
Если ты этого не понимаешь, то земля тебе пухом)
exception13x
А чем это тогда отличается от аджайла?
foal
Да, это нормально — продумывать изменения, просто очень многие делают из этого «слона», а ведь зачастую это просто мелочь. Концепция важна, но это не догма. И заказчик должен видеть, что вы готовы обсудить изменения и поменять её за его деньги. К сожалению, довольно часто сталкиваюсь с тем, что даже за деньги концепцию меняют очень неохотно. Важна та самая золотая середина. Аджайл идет к ней со стороны заказчика/менеджеров, автор со стороны исполнителя/программистов.
leon_nikitin
Профессионалу, тому у кого есть «профессиональный вкус» — понятно
lvn_alchevsk
Согласен — программа пишется для бизнеса прежде всего, а не для удовлетворения внутреннего эго программистов. Поэтому «как надо» = «как надо бизнесу» и никак иначе в первую очередь..
wing_pin
Самое главное не путать «как надо бизнесу» и «как менеджеру, чтобы получить премию». Слишком многие почему-то забывают, что это совершенно разные вещи.
lvn_alchevsk
И вот здесь мы плавно переходим к теме «манифеста жесткого менеджера» :)