Манифест жёсткого программиста


    Предисловие


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


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



    Содержание


    1. Манифест жёсткого программиста
    2. Основополагающие принципы манифеста жёсткого программиста
    3. Комментарии


    Манифест жёсткого программиста


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


    Концепция важнее новых требований
    Качество важнее скорости
    Делать как надо важнее, чем делать как просят


    То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева.



    Основополагающие принципы манифеста жёсткого программиста


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


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


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


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


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


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


    Качественный продукт — основной показатель успеха.


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


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


    Самые лучшие требования, архитектурные и технические решения рождаются у команд, которые плотно работают над требованиями, архитектурными и техническими решениями.


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



    Комментарии к манифесту


    Концепция важнее новых требований


    Перед началом разработки ПО необходимо сделать две вещи:


    1. Разработать матмодель ПО;
    2. Продумать архитектуру ПО.

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


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


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


    Качество важнее скорости


    Иначе говоря, техпроцесс важнее сроков.


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


    Многочисленные конторы вываливают тонны неработающего или плохо работающего, кхм, ПО, вместо того, чтобы потратить немного времени, чтобы довести всё это до ума. А потом начинают "фиксить баги".


    С пугающей регулярностью поступают сигналы о том, что очередное приложение (или даже целая ОС) после очередного обновления перестаёт работать. А как насчёт еженедельных "технических" обновлений, улучшающих "общую стабильность и надёжность"? Знакомо?


    Мы сами создаём этот порочный круг: все торопятся, поэтому мы торопимся, поэтому все торопятся. Пора остановиться и задуматься.


    Делать как надо важнее, чем делать как просят


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


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


    Но Йцукен хочет заниматься любимым делом, и делать его хорошо. Поэтому Йцукен, оценив настоящий срок, должен не бросаться успевать, а объяснить Ячсмиту, что нарушать техпроцесс нельзя, что к следующему понедельнику никак не выйдет, и что на X, согласно техпроцессу, понадобится не менее Y недель, потому что должна быть проделана определённая работа. Ячсмит ведь не будет подгонять хирурга, оперирующего ему сердце, потому что Ячсмит опаздывает на совещание с клиентом своего нанимателя? Или будет?


    К началу




    P.S.


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


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




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

    powerman



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

    DexterHD
    Share post

    Comments 389

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

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

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

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

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

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

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

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

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

                    ¯\_(ツ)_/¯

                      0
                        +2

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


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

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

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

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


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

                        Истинно так.


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

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


                        как важнее

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

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

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

                          +3

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

                            0
                            Возможно. До недавнего времени просто вообще ничего не было. А потом пришел scrum master и начались code reviews, появился беклог, спринты и т.д.

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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


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

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

                                                          –6
                                                          Не кажется.
                                                            0
                                                            studfiles.net/preview/3801958 Основная мощность системноинженерного подхода именно в разрешении конфликтов.
                                                        +8
                                                        Вы знаете, совершенно не собираюсь спорить с тем, что «when it's done» приминим далеко не всегда, но не могу не заметить, что зачастую гонка из-за
                                                        определяющую роль играет время вывода на рынок новой функциональности с приемлемым качеством

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

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

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

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

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

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


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

                                                                  +1
                                                                  Сорри, Дмитрий.

                                                                  1. ROI

                                                                  2. Window of opportunity
                                                                    +2

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


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

                                                                      –3

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


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

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

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

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

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


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


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


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

                                                                            +3

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


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

                                                                              Это всё сразу, или это варианты?

                                                                                +3

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


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

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

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

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

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

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

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

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

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


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


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

                                                                                      –2

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


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


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

                                                                                        0

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


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


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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                          0

                                                                                          Откуда берётся такая цифра, и насколько она, на самом деле, оправдана — я уже отвечал ниже.

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

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

                                                                                                      +2

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

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

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


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

                                                                                          +5

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


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


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

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

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

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

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

                                                                                              +1
                                                                                              Чем это обосновано, кроме «рынка»?

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

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

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

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

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


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

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


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

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


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

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

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

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


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

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

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


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


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

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

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

                                                                                                                +1

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


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

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

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

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


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


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


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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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

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


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

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


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

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

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

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


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

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

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

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

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


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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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


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

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

                                                                                                                                              0

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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