Красной таблетки не существует

    О чем это


    Я долгое время был адептом идей о равенстве, свободе и братстве том, что существует красная таблетка.

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

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

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



    Проектирования нет


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

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

    Но это не работает. У людей не уживается в голове одна простая мысль: идеального не существует. Любой дизайнер, программист, специалист, глядя на свои работы годичной давности, найдет много ошибок — ибо вырос профессионально. Значит, всегда можно улучшить любой результат. Однако те же самые люди будут с пеной у рта убеждать вас, что вот сегодня они познали дзен и сделают сразу правильно.

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

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

    Об эволюционном проектировании (и о мертвом традиционном) серьезно рассуждал даже Мартин Фаулер

    Методологии нет


    Здесь я буду краток. Мы попробовали фиксированные итерации, пробуем канбан. Так как я программист, помимо PM — могу подтвердить, что все методологии действительно сводятся к пиши-код-блять.рф.

    И чем меньше лишних действий вносится в процесс — тем лучше. Ежедневные обязательные разговоры — минус (мы общаемся вечером и все чаще on-demand). Плэнинг покер — нафиг: как правило, в моих проектах очень много сложных зависимостей, и смоделировать их и точно представить нельзя; а значит, оценки будут только отнимать время и довлеть, когда ты их на себя взял. Вместо этого — простые прикидки: сделать сразу, сделать за час, за день, и тд, то есть порядок.

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

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

    В общем, пока я не видел универсальной методологии. Когда учился в вузе и был курс управления проектами, нам сватали RUP. Потом изучал Agile. На практике первое просто для IT, быстроменяющегося рынка и отрасли, просто мертво. А второе — секрет полишинеля. Все рассказывают, что уж они-то точно знают все секреты и могут поставить разработку. Но все чаще на рынок выходят говнопроекты, и делается все очень медленно. Зато конторы по консультациям процветают. Удивительно, да? Вместо того, чтобы самим делать проекты, они делают бабки на тренерской работе.

    Кроме единиц, как некоторые, кто там 5-10 лет в Гугле или IBM рулил разработкой, в основном эти ребята ИМХО даже близко не должны подходить к консультациям, если только в портфолио нет реально крутых своих проектов.

    А что есть?


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

    Есть только люди. По мнению доктора биологических наук Сергея Савельева, которое он изложил в книге «Изменчивость и гениальность», мозги у людей отличаются в разы (отдельные структуры до 40 раз). Грубо говоря, у всех мозг уникален. И вся задача состоит только в том, чтобы отобрать к вам на работу самых гениальных, заточенных именно для нужной работы. Потому что определенные большие структуры в мозге будут тянуть человека делать то, к чему у него дар. Поэтому у лучших людей всегда кайф от работы — но не потому, что они выбрали такую работу, а потому, что изначально были созданы для нее и всего лишь правильно угадали.

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

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

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

    Кто хочет тратить деньги, время и свои усилия на красные таблетки в виде Agile, или думает, что щас умные программисты все спроектируют, а дизайнеры нарисуют — ок, вперед! Можно проектировать до третьего пришествия, и пытаться до четвертого выстроить идеальный burndown chart, в то время как 10 хостов бесятся от неверно выбранных user stories на вашем проекте.

    Желаю вам не тратить время на фигню, а скорее сфокусироваться на поиске и удержании лучших из лучших!

    Эпилог


    Пост посвящается тем самым единицам, тем программистам, менеджерам проектов и дизайнерам, и всем специалистам, которые трудятся на совесть и делают реальную работу, а не ИБД, как многие их коллеги. Такие, как вы — это элита IT и движущая сила мира. О вас хорошо сказал Айзек Азимов в своем рассказе «Профессия».

    [...], и тот, кто не желает смириться с этим, и есть человек, которого мы ищем. Быть может, это жестокий метод, но он себя оправдывает. Нельзя же сказать человеку: «Ты можешь творить. Так давай, твори». Гораздо вернее подождать, пока он сам не скажет: «Я могу творить, и я буду творить, хотите вы этого или нет». Есть около десяти тысяч людей, подобных тебе, Джордж, и от них зависит технический прогресс полутора тысяч миров. Мы не можем позволить себе потерять хотя бы одного из них или тратить усилия на того, кто не вполне отвечает необходимым требованиям.
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 347
    • +60
      Вот! Вот, наконец, статья от нормального программиста.

      И эпилог шикарный. Я буду творить, и мне насрать на тех, кто учит меня, как это делать правильно. Вспомним знаменитую притчу про Моцарта и симфонии, кстати.
      • +3
        А расскажите притчу?
        • +32
          Я нашел сходу две, если что

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

          Отсюда: pritchi.omkara.ru/pritcha816.htm

          Вторая
          Однажды молодой композитор пришел к Моцарту. Он хотел знать, как развить свой талант.

          — Думаю, нужно начать с простых композиций, — посоветовал Моцарт. — Песен, например.

          — Но вы ведь сочиняли симфонии еще будучи ребенком! — запротестовал молодой человек.

          — Да, это так. Но я ведь не ходил к кому-либо за советом о том, как развить свой талант.

          Отсюда: krendelek.ru/content/doc/parable/anthony-de-mello/page4
          • +6
            Шикарно, особенно вторая притча, и жизненно спустя N веков!
            • +9
              Один иудей обратился к ребе с вопросом — надо ли брить бороду? Ребе ответил, что надо. Иудей поблагодарил, и ушел, но по дороге задумался.
              — Как же так? Ребе сказал, что надо брить бороду, но у него самого она не сбрита. Весь в непонимании он вернулся к ребе с вопросом.
              -Ты сказал мне, что надо брить бороду, но у тебя самого она не сбрита. В чем тут дело?".
              Ребе ухмыльнулся.
              -А я не у кого не спрашивал, брить мне ее, или нет.
              • +2
                Я имел в виду вторую, правда читал ее чуть в других словах:

                «Какой-то юноша спросил Моцарта, как писать симфонию.
                — Вы еще слишком молоды. Почему бы вам не начать с баллад? -сказал Моцарт.
                Юноша возразил:
                — Но ведь вы начали писать симфонии, когда вам не было еще и десяти.
                — Да, — ответил Моцарт, — но я ведь ни у кого не спрашивал, как их нужно писать.»
          • +2
            Сильно
            • +6
              Особенно нравится это:
              • +3
                Мне ещё вот это нравится.
                • +2
                  У меня карма отрицательная, парсер съел теги.
                  • +2
                    Да я понимаю, что парсер. Просто не смог удержаться)
              • +2
                О тренингах — напоминает книги о том, как заработать. Чего ж эти бараны сами не воспользуются знаниями?

                А вот насчет разницы в сорок раз структур мозга — совсем не понятно. Разве структура не может отличаться на проценты? Куда уж выше 100% (т.е. полностью)?
                • 0
                  У мозга много структур, 40 по 100% получается 4000 % :)
                  • 0
                    Что-то тут не так… но доходы, действительно, раз в 40 отличаются.
                  • +2
                    Они и зарабатывают. На тех, кто покупает книги.
                    • 0
                      1 мм против 5 см, к примеру.

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

                      • 0
                        Я не верю в это (до конца). Сам учился в музыкальной школе. До нее — даже петь не выходило. После хора и вокала научился (вроде). :)
                        • 0
                          способности могут быть в зачатке.

                          но если их __физически__ нет, то развить нельзя
                          • 0
                            Я не раз слышал (в том числе и от уважаемых мной музыкантов), что петь можно научить кого угодно (хотя лучше это делать всё-таки в детстве). Людей совсем без слуха не существует — чтоб человек пел, надо лишь развить то, что и так есть.
                            • 0
                              Вопрос в том как. Имхо, гены и среда до начала любого обучения оказывают воздействие на то, каких высот можно достигнуть. Проще говоря, у людей неравные стартовые возможности в любом начинании и при одинаковом вложении труда у кого-то результат будет всё равно лучше.
                  • +2
                    Всё правильно кроме вот этого:

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

                    тема раскрыта в «Peopleware».

                    Если те самые гениальные разработчики, которые в 10 раз продуктивнее среднего говорят вам такое, их тоже не нужно «слушаться»?
                    • 0
                      > И если вы послушаетесь их бесконтрольно

                      это значит, что пустите дело на самотек, не будете применять никаких Метрик и т.д.

                      я только это имел в виду.
                      • 0
                        Добавлю, что я выделяю от недели до нескольких месяцев на рефакторинг. Но все обычно по определенному вектору
                        • +5
                          Как вам точка зрения о том, что рефакторинг необходим только как часть решения очередной задачи, не чтобы все исправить, а исправить только части имеющие отношение к конкретной задаче. Задача может относиться как к багу, так и к новой фиче.
                          Я давненько забросил заниматься рефакторингом ради рефакторинга. Т.о. и рефакторинг как бы есть, и месяцы на него тратить не нужно.
                          • +1
                            Вроде небольшая (для заказчика :) ) фича может потребовать либо переделки всего с нуля, либо нагромождения костылей во всех слоях.
                            • 0
                              Заказчик — вообще основной источник рисков для проекта. Было такое на последней работе. «Field in form should be calculated and editable» — как-то пропустили. А поле вычислялось по сумме по БД. Пришлось для «editable» сумм городить отдельные таблицы.
                              • 0
                                Ну, тут явно ваш фэйл, заказчик не в конце разработки же вставил «and editable» :)
                                • 0
                                  Фэйл был нашего ПМ, который трахал моск всякой левой фигнёй, что нервировало и отвлекало от дела… Но всё равно — ставить задачу по системе, использующей БД, не используя ни одного термина из области БД, а только в терминах UI — это источник рисков…
                                  • +1
                                    Сижу и думаю, а чего у нас такого нет… Потом вспомнил, что пототип дает полное представление о том, какая именно структура БД понадобится.
                              • 0
                                Ум, как сумма осознанного опыта, даден разработчикам и проектировщикам, как раз, чтобы максимально избежать подобных эксцессов :)
                                • 0
                                  Ошибки такого рода допускаются в основном на более ранних этапах разработки чем проектирование: анализ и постановка задачи, сбор требований и т. п. Да, некоторые вещи опытные разработчики делают на автомате, заботясь, зачастую даже неосознанно, о будущем поддерживании системы, но всех возможных сценариев развития системы не предусмотришь.
                                  • 0
                                    Действительно случаются ситуации, и то что эти ситуации случаются не часто, я считаю нормой, когда тот или иной модуль приходится переписывать, однако давненько я не встречал «переделок всего с нуля» и «нагромождения костылей во всех слоях».
                                    С другой стороны, если заказчик требует некий юзер стори которого не было на этапе постановки задачи, то в лучшем случае заказчику светит компромис.
                                    • 0
                                      Недавний пример — внезапно всплывает требование, что незашифрованные персональные данные не должны покидать клиент в принципе, то есть даже имея полный доступ к серверу персональные данные должно быть невозможно (в терминах криптографии) получить, ключа расшифровки на сервере быть не должно.
                                      • 0
                                        Вся логика перемещается на клиента? Нецензурная лексика? :)
                                        • 0
                                          Слава богу не вся, большинство логики работает с id клиента, но вот чисто интерфейсные штуки типа автодополнения фамилии тоже нецензурную лексику вызывают.
                                          • 0
                                            Фамилии можно и в словаре на сервере хранить. Они не являются идентифицирующим личность данными, потому что людей с одинаковыми фамилиями немало. Даже связка ФИО не идентифицирует личность.
                                            • 0
                                              Номер паспорта точно идентифицирующая.
                                              • 0
                                                Это да. Добавление даты рождения к ФИО сразу делает данные идентифицирующими, хотя это все еще не на 100% подтверждает личность.
                                                • 0
                                                  Там полные данные: ФИО, дата рождения, номер паспорта, кем и когда выдан, адрес регистрации.
                                                  • 0
                                                    Словарик можно сформировать не только на основании пользовательских данных :)
                                                • 0
                                                  В любом случае, это исключительная ситуация. Во вторых, если работа ведется с персональными данными… я бы плохо спал, если честно, потому, как контролирующие органы в разных регионах со своими тараканами, и ГОСТовским шифрованием их не всегда можно уговорить. Хотя, с хорошим юристом можно все.
                                                  • 0
                                                    Страшна не работа с данными, не их накопление и обработка, а возможность продажи.
                                                    • 0
                                                      Это не моя забота, этого пусть боится заказчик.
                                • 0
                                  Не согласен. Изменения в архитектуре сложны, и учитывают динамику роста определенных векторов/осей ответственностей.

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

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

                                        Они не парятся «метриками». Но сделают это наиболее быстро и наиболее качественно. От метрик никакого толку. Есть объем работ, который надо сделать. Есть путь, как это сделать наиболее оптимальным способом.

                                        Хотите замедлить работу или тормознуть совсем — вмешивайтесь в их работу, не пускайте на самотек и говорите, что им делать.
                                      • +5
                                        «Я могу творить, и я буду творить, хотите вы этого или нет».
                                        Вот оно!

                                        ps Хотите вы этого или нет, а я это себе в профиль поставлю.
                                        • +2
                                          Полностью согласен с автором, а еще не малое влияние на процесс и как следствие — результат оказывают социально-психологические взаимосвязи. Например, если в команде все крутые специалисты, которые начинают «выеживаться» и т.п. друг перед другом, то процесс будет приторможен и малопродуктивен, а результат будет хуже чем у менее профессиональной, но более дружной команды…
                                          • +2
                                            Чаще идет конфликт между тимлидом (как правило знающим компромисс между качеством и сроками) и «гением», утверждающим что в калькулятор следует заранее заложить возможности расчета орбит небесных тел с учетом релятивистских эффектов.
                                            • 0
                                              Основное и самое интересное слово, которое я у вас тут увидел — «заранее». Почему «заранее»? Потому, что нет уверенности, что получится незаранее — тогда, когда реально будет надо. Поэтому делаем не тогда, когда надо, а тогда, когда можно. Что, в общем, есть признак слабости. Всякое «заранее», как и прочие разновидности ориентации на то, что можешь, а не на то, что хочешь, есть признак слабости.

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

                                                  «Ты кричишь как бездомная
                                                  — Да здравствует дом!
                                                  Я кричу как безумный
                                                  — Да здравствует лужа!»

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

                                                  Это лирическое отступление. А вообще, делать всё вовремя — это дзен. И не только заканчивать вовремя. Но и начинать вовремя. Возможно это признак профессионализма? Когда человек лишен беспокойства и ждет нужного момента. Правильно распределяет для себя задачи и отталкивается только от того, что нужно.
                                            • +2
                                              Подпишусь под каждым словом!
                                              • –7
                                                Очень интересно, но совершенно не практично.
                                                • +6
                                                  Обычно быстро говнокодом невозможно написать (имхо).
                                                  Юра Малинов хорошо об этом сказал.
                                                  • +11
                                                    Элементарно. На поздних стадиях разработки проекта можно писать быстро и качественно, за счет уже сделанного инструментария.

                                                    На первых стадиях — легко. Что проще — сделать один God Object или сделать 15 интерфейсов и 2 слоя абстракции, чтобы потом их удалить, когда узнаешь, что предметная область-то совсем иная? Я против God Object и любитель DI, SOLID, IoC TDD etc, но если ты прорабатываешь задачи, делая скелет на скорую руку, ты всегда будешь быстрее.

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

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

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

                                                      Я не стесняюсь написать числа прямо в коде, текстовые строки и тд; потому что знаю — рано или поздно я заменю это на константы. И таких вещей очень много.
                                                      • +5
                                                        Тут есть один тонкий момент. Когда пишешь один, можно особо и не стесняться, но когда в команде, это уже накладывает определенные рамки. Помня о том, сколь часто самому приходится вскрикивать: «Да твою мать!», пугая окружающих, когда натыкаешься на очередной «шедевр», подложенный тебе заботливым другом, сам стараешься не подводить товарищей подобным образом, даже если сильно торопишься.
                                                        • 0
                                                          Для этого есть разделение труда.

                                                          Но, честно признаюсь, с этим не все гладко, и это действительно непростой вопрос. Терпимость к чужому коду — важное качество для командной работы. Даже к хорошему :)
                                                          • +1
                                                            Это неизбежно, как смерть и налоги (ц). Все мозги разные.
                                                          • 0
                                                            Слава Богу, в Java/Eclipse есть такие вещи, как чекстайл и рефакторинг. Хардкоры можно побороть потом, с минимальными усилиями. И архитектуру выправить.
                                                          • +4
                                                            Быстро и правильно — я таких пока не встречал, но они где-то есть, я точно знаю.

                                                            Не знаю, из таких я встречал только кодогенераторы. Обычным смертным, сколь бы гениальны они не были, всегда приходится балансировать между быстро и правильно в зависимости от конкретной ситуации.
                                                            • +1
                                                              Элементарно. На поздних стадиях разработки проекта можно писать быстро и качественно, за счет уже сделанного инструментария.

                                                              За счёт уже сденного говнокода с захардкоденными всё и вся — невозможно начать писать качественно.
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                • 0
                                                                  Ну почему невозможно? Возможно, просто параллельно работает код разного качества с костылями на стороне старого для связи с новым.
                                                                  • 0
                                                                    При этом, если вы переписываете говно-ядро, то вам необходимо обеспечить обратную совместимость — задача не очень тривиальная и иногда не позволяет полностью избавится от говнокода (если интерфейс говяный, то его придётся оставить). Либо вместе с ядром вам придётся переписывать клиентский код — т.е. почти всю систему, даже если отдельные части написаны хорошо, но используют говяный интерфейс/API.

                                                                    Кроме того, есть ещё один нюанс.
                                                                    По своему опыту я могу сказать что программисты делятся на две кадегории: говнокодеры и чистокодеры. Невозможно заставить чистокодера написать говнокод так же и наоборот. По этому, что бы сначала написать говноядро, а потом переписать его, вам придётся поменять команду разработчиков. А это вообще жесть.
                                                                    • 0
                                                                      Прокси, адаптеры и прочие подобные решения позволяют решить проблему совместимости, изолируя чистый код от говна. Вот пример, с которым работаю прямо сейчас. Было:
                                                                      function updateState($state)
                                                                      {
                                                                        global $USER;
                                                                      
                                                                        //...
                                                                        mysql_query("UPDATE users SET state = {$state} ... WHERE id = {$USER['id']}";
                                                                      }
                                                                      

                                                                      Стало:
                                                                      function updateState($state)
                                                                      {
                                                                        global $USER;
                                                                        $user_id = $USER['id'];
                                                                      
                                                                        UserAdapter::updateState($user_id, $state);
                                                                      }
                                                                      

                                                                      где UserAdapter::updateState($user_id, $state) проделывает всю работу получая объекты User по user_id и изменяя их состояние, пересекаясь со старым кодом только на уровне данных в MySQL. Сначала UserAdapter стремительно разрастался, но теперь стал потихоньку сокращаться.
                                                                      • 0
                                                                        При этом, вы не избавились от глобальной переменно $USER и не избавились от лишней функции updateState(). Вы просто написали новую чистокодерскую функцию UserAdapter::updateState();

                                                                        Где профит?
                                                                        • 0
                                                                          Профит в обратной совместимости. Старый код вызывает новую updateState не замечая разницы, новый работает непосредственно с User, а UserAdapter просто временный «мост» между старым и новым.

                                                                          Когда все функции с global $USER будут переписаны на UserAdapter, то от $USER можно будет избавиться, а в последствии и от UserAdapter.
                                                                          • 0
                                                                            Я не отрицаю, что всё можно переписать и избавиться от говнокода. Но что бы избавится от глобальной переменной $USER вам потребуется переписать ядро + клиентский код. Т.е. почти всю систему.

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

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

                                                                            $action = 'update';
                                                                            $what = 'State';
                                                                            $funcName = $action . $what;
                                                                            $funcName(23);
                                                                            


                                                                            TDD-тестов у вас нет и придётся тестировать ВСЁ приложение что бы убедиться в работоспособности. А это очень долго.

                                                                            Кстати, я очень сильно сомневаюсь, что программисты знакомые с паттернами (прокси, адаптеры и прочие подобные решения) могут начать использовать глобальную переменную $USER. Здаётся мне, вы за кем то переписываете чужой говнокод. Т.е. менеджер сменил команду разработчиков?
                                                                            • 0
                                                                              Ну, я опровергал тезис «За счёт уже сденного говнокода с захардкоденными всё и вся — невозможно начать писать качественно» вне контекста использования инструментария. С другой стороны часть старого кода копипащу в новый, особо в него не вникая, лишь убедившись визуально в отсутствии зависимостей или хардкода или как можно безопасней разрывая зависимости и вынося хардкод в константы и т. п.

                                                                              Не то чтобы переписываю, а должен внедрять новые фичи, править старые баги и т. п. Просто для себя решил, что лучше это делать параллельно с «сильным» рефакторингом существующего кода, чем вставлять костыли в существующем стиле. Заодно и тестами покрываю. С другой стороны, лет 10 назад мой код от этого бы принципиально не отличался бы :)
                                                                              • 0
                                                                                За счёт уже сденного говнокода с захардкоденными всё и вся — невозможно начать писать качественно

                                                                                … используя готовый говно-инструментарий.
                                                                                Просто эта фраза вырвана из контекста.

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

                                                                                Вы начинаете писать правильно не за счёт говнокода, а за счёт своего большого опыта. И вряд ли вы сможете наговнокодить глобальную переменную $USER, потому что прекрасно понимаете: чистокод пишется быстрее чем говнокод. Здесь можно поспорить только с TDD, которое даёт результат в переспективе, но может немного замедлить текущие задачи.

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

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

                                                                                  • +1
                                                                                    видишь, что сталкивался с озвученной проблемой

                                                                                    Это опыт.
                                                                                    Читать описания паттернов без понимания проблемы — бессмысленно. В голове будет каша.

                                                                                    а разработчик апстрима о рефакторинге слышать не хочет

                                                                                    ну да, ну да. Как это знкакомо… К сожалению, говнокодера нельзя заставить чистокодить.
                                                                                    • +1
                                                                                      Дайте ему в руки фреймворк, качество кода вынужденно станет выше.
                                                                                      • 0
                                                                                        Как раз вчера разбирался с сайтом который генерирует страницы по 7-8 секунд. Сайт написан на ZendFramework. Я очень сильно удивился когда на не очень сложных страницах увидел в логах по 1000-1800 SQL-запросов!!! Все они очень простые и лёгкие и выполняются в среднем по 0.6мс и БД совсем маленькая. Но 1800 запросов к БД на одной странице это жесть. ZandFramework не вставил мозги разработчику.

                                                                                        Красной таблетки не существует. (с)
                                                                                        • 0
                                                                                          Дайте нормальный фреймворк, а не микроскоп, которым будут гвозди забивать :)
                                                                                          • 0
                                                                                            По вашему мнению, существуют сайты для которых 1800 SQL-запросов на генерацию одной типовой страницы — это нормально?
                                                                                            • 0
                                                                                              Это уже другой вопрос, и он слабо относится к исходной теме, что количество говнокода можно сократить, если не давать в руки сложных инструментов, а ограничиться более примитивными. То, что примитивный инструмент может под капотом быть невероятно сложным, это уже проблема выбора инструмента.
                                                              • 0
                                                                Да, в корне верно! Стив Макконел в своей книге «Совершенный код» писал примерно о том же. Он говорил, что чем меньше связность элементов в системе (классов) и т.п., тем проще их использовать в других проектах. Таким образом проект действительно будет собираться как из кубиков.
                                                                • +1
                                                                  В реале, есть шанс что проект будет сначала разбираться на кубики…
                                                                  • 0
                                                                    Некомпетентность архитектора. И точка.

                                                                    У некоторых, ИМХО какая-то иллюзия, называться архитектором, и быть архитектором.
                                                              • +6
                                                                Вспомнил «Жизнь внутри пузыря» Ашманова, особенно идею об «общей шине» ( www.ashmanov.com/pap/bubble/#p4.9.2).
                                                                • +1
                                                                  О да, общая шина это пять!

                                                                  В далёком 2007м бумажная тогда ещё Компьютерра брала интервью у Ашманова, по общей шине там тоже проехались. «Общая шина… потому что Общая шина!», хе-хе.

                                                                  Способствует возвращению с небес на землю некоторых не в меру ретивых проектантов и снижению ЧСВ у них же.
                                                                  • +5
                                                                    Вы бы хоть продемонстрировали:

                                                                    image

                                                                    Действительно, доставляет. :)
                                                                    • +4
                                                                      Вы бы хоть продемонстрировали

                                                                      Да, действительно надо было. Исправлюсь, продемонстрирую другую картинку оттуда, которая тоже божественна и связана с данной статьей:

                                                                      image

                                                                      P.S. А вообще «Жизнь внутри пузыря» это конечно классика из разряда «Читать всем!», кто хоть как-то связан с IT.
                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                        • 0
                                                                          Только надо учитывать, что рассказанная история, пропущена через фильтр сознания Ашманова

                                                                          Конечно. Он и сам это признает в «Эпилог 2.0», отвечая на вопрос:

                                                                          2) А чего это автор получается весь в белом, а все остальные известно в чём? Или, словами из другого блога, почему автор выходит д'Артаньян, а все остальные персонажи — козлы?
                                                                  • 0
                                                                    Класс!
                                                                    • +1
                                                                      Огромное спасибо за ссылку. С удовольствием прочитал.
                                                                    • +1
                                                                      Савельев — фрик, если не ошибаюсь.
                                                                      • 0
                                                                        Его теории отлично описывают реальность и дают ее предсказуемость.
                                                                        И доктора наук в СССР фрикам не дают вроде, не? :)
                                                                        • 0
                                                                          Его теории отлично описывают реальность и дают ее предсказуемость.

                                                                          Какую-такую реальность? Его гипотезы довольно часто идут вразрез с мнением современной науки.

                                                                          И доктора наук в СССР фрикам не дают вроде, не? :)

                                                                          Только академика. СССР, если что, уже 20 лет не существует, а наука на месте не сидит…

                                                                          P.S. Про Савельева.
                                                                      • +3
                                                                        Брукс, перелогиньтесь!
                                                                        • +12
                                                                          Вы выросли. :) Это проходит каждый в своей области, ну разве кроме 5-10% клинических инфантилов, просто не каждый после этого пишет пост на Хабре :)
                                                                          • 0
                                                                            Эмоциональные и толстые высказывания — это, как правило, признак непрофессионализма. Так что автору еще расти и расти (без всяких обид).
                                                                            • 0
                                                                              Вы знаете, в частной беседе — да. Скромность и толерантность, дипломатия рулят.

                                                                              А вот если пытаться в группу людей что-то сложное донести — не поймут. Уверенно же и четко говоря простые вещи, вплоть до этапажа, вы гораздо быстрее поляризуете людей на несколько лагерей, один из которых и поведете.
                                                                            • 0
                                                                              Покажите мне их, хиде они, эти PMы?
                                                                            • 0
                                                                              Согласен на все 100%!
                                                                              Только мое мнение, что иногда надо переписывать с нуля даже на поздних стадиях. Лучше уж сделать еще одну итерацию и учесть имеющийся опыт, чем долго думать, а надо оно или не надо, тратя при этом время. Все равно время переписывание потом покроется меньшим количеством багов и более простой поддержкой.
                                                                              • +3
                                                                                Согласен. Вопрос планирования, чтобы это шло не бесконтрольно, а был какой-то вектор.

                                                                                А так, я даже писал с нуля MVC фреймворк однажды. Думал написать второй, но, побродив по зарубежным open source вариантам, нашел пару по душе и решил — что лучше помогать коллегам, чем думать, что ты умнее всех :)
                                                                                • +1
                                                                                  >> иногда надо переписывать с нуля даже на поздних стадиях

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

                                                                                    А вот недавно, обобщая свои выводы, увидел схожие тезисы у Брукса. Воистину, «все украдено до нас» (С)
                                                                                    • +4
                                                                                      Доберитесь. Эту книгу стоит прочитать еще до того как берешься за свой первый проект. В издании 1995 года говорил сам Брукс — я удивлен что эта книга все еще актуальна. При этом первое издание вышло еще в 75 году. А в издании 1995 года добавилось эссе «Серебряной пули нет». Которое в целом перекликается с вашим топиком.
                                                                                      • +1
                                                                                        Благодарю за совет и интересную информацию
                                                                                  • 0
                                                                                    Все верно, и это применимо к любой области.
                                                                                    Работают люди, а не методики. А качество работы людей зависит от того любят ли они свою работу или нет.
                                                                                    Вот и весь секрет.
                                                                                    • 0
                                                                                      Методики могут помогать и позволять следить за проектом. Но они должны быть приняты людьми.
                                                                                      • 0
                                                                                        Принять просто, но надо ведь еще и применять постоянно.
                                                                                    • +43
                                                                                      Если в туристическом походе вам приходится периодически менять планы из-за неожиданного ландшанфта или изменения погоды, значит ли это, что не следует прокладывать маршрут?

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

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

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

                                                                                      Другими словами, и проектирования, и методологии есть, и это хорошо. Но чтобы не возникло конфузов, все эти вещи нужно уметь правильно готовить, а не бездумно лепить agile потому что это круто и не заниматься оверинженирингом там, где ещё ничего не понятно.
                                                                                      • +5
                                                                                        Все это не работает без людей. В вашем посте любой пример это подтверждает. Прораб рулит рабочими, без него сами работают роботы и немцы. Здание рассчитывает умный архиетектор, и именно его косяк при самой крутой методе фатален
                                                                                        И тд

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

                                                                                        Корень успеха это талантливые люди. Остальное инструмент в их руках. А не люди а ля инструменты в руках подходов
                                                                                        • +3
                                                                                          Одно не исключает другого, любым людям (в том числе талантливым) нужна организация совместной работы.
                                                                                          • 0
                                                                                            Талантливый организатор
                                                                                            • +8
                                                                                              Спасибо, кэп!

                                                                                              Теперь понятно! Нужно было всего лишь устраивать на работу талантливых людей!
                                                                                              Пойду найму 10 талантливых программистов и пару талантливых проджект менеджеров… Всего-то делов!
                                                                                              • 0
                                                                                                Если у вас есть всего лишь месяц, то лучше потратить на эту благородную задачу,
                                                                                                чем на поиск методики, которая решит все сразу, или проектирования на бумаге всего и вся, вместо пяти итераций с релизами говнокода каждый день.
                                                                                                • 0
                                                                                                  Уже год ищем, пока нашли только двоих талантливых. Что мы делаем не так?
                                                                                                  Может быть вы нам подскажете место, где тусуются талантливые программисты?

                                                                                                  Поиск методики — дело неблагодарное. Всегда выбираешь из того, что знаешь по опыту, а дальше — по обстоятельствам, проекты то все разные.
                                                                                                  Да что это я, вам тут все в этой ветке про это пишут, а вы дальше гнёте)
                                                                                                  Предлагаю на этом остановиться)
                                                                                                  • 0
                                                                                                    Думаю, таланты вообще редкость, и продавать компанию сотрудникам — тоже талант
                                                                                          • +3
                                                                                            Корень успеха это талантливые люди. Остальное инструмент в их руках. А не люди а ля инструменты в руках подходов
                                                                                            Мне показалось, или вы обходными путями всё-таки дошли до первого тезиса Agile манифеста?
                                                                                            «Individuals and interactions over processes and tools» © agilemanifesto.org
                                                                                            А в начале статьи говорили, что это фуфло… :-)
                                                                                            • 0
                                                                                              да, мой опыт Agile искажен. в оригинале, конечно, оно так, как вы и говорите. об этом же я читал и у Мартина Боба в Rapid Software Development (один из авторов этого манифеста).

                                                                                              в реальности оч. мало людей так думает
                                                                                            • 0
                                                                                              > Методики и проектирование суть инструменты
                                                                                              Естественно! И у каждого инструмента своя область применения. Так же как нельзя отверткой забить гвоздь, так и проектирование не решит всех проблем проекта. Но это не означает, что «проектирования нет». И так же естественно, что инструментом нужно уметь пользоваться (необходимы профессиональные люди).
                                                                                              • 0
                                                                                                оно эволюционное. в обычном виде я считаю, для 99% проектов оно нахер не нужен, тк будет 100% оверинжиниринг и время на рынке пропущено.
                                                                                                • 0
                                                                                                  Для мелких 3-х месячных проектов (почти все мобильные приложения) — не нужно. Да и все веб приложения по MVC шаблону строятся, для них тоже не особо нужно проектирование. Нынче веб+мобильные — это порядка 80%, так что вы не далеки от правды. Но это частный случай (хоть и массовый). А в общем случае без проектирования в большом проекте сложно.
                                                                                                  • 0
                                                                                                    Легко, если сначала вы строите конструктор, а потом с его помощью решаете поставленную задачу.
                                                                                              • 0
                                                                                                Никто не спорит, что всё упирается в людей, а проектирование, методологии и т.п. — это всего лишь инструменты. Вопрос в том, нужны ли эти инструменты, или же люди и гвозди забивать, и брёвна пилить должны голыми руками.
                                                                                              • +1
                                                                                                Когда художник пишет картину, он её делает по линиям, сразу конечный вариант? Нет, сначала много набросков, общие элементы, а потом детали, детали, детали.

                                                                                                • 0
                                                                                                  Красивая метафора
                                                                                                • +2
                                                                                                  Отлично сказано!

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

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

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

                                                                                                  Ну а хвалебные отзывы о сверхневероятной эффективности каких-то методик оставим на совести консультантов — им же надо как-то продавать свои услуги.
                                                                                                  • 0
                                                                                                    Гибкие методологии требуют гибкого подхода к их внедрению. :)
                                                                                                    • 0
                                                                                                      Согласен насчет разумного подхода. Вопрос про курицу и Яйцо. Без программеров не нужен Agile, а с хорошими программерами Agile не нужен. Как-то так
                                                                                                      • 0
                                                                                                        Agile нужен не для написания красивого кода. Это заблуждение.
                                                                                                        Что-то мне кажется, что пора писать статью, зачем же нужны гибкие методики…
                                                                                                  • +1
                                                                                                    Мне кажется истина как всегда где то посредине. Хорошим программистам любящим свою работу так же нужны какие-то общие рамки и ориентиры, просто для того чтобы эффективно работать вместе. От того что перед написанием проекта будет составлена общая архитектура, хотя бы в виде: «Это мы пишем модулями, а этот функционал будем использовать во многих проектах поэтому выносим на api», а более детальное проектирование можно отложить на момент реализации конкретного блока приложения.

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

                                                                                                    • +3
                                                                                                      Надеюсь, этот пост прочитает как можно большее число манагеров и они наконец поймут, что можно хоть каждый день придумывать различные методологии, часами обсуждать новые фичи и в течении нескольких месяцев заниматься проектированием, но если у вас нет людей, которые могут «писать код, блять», то это пустая трата времени и денег.
                                                                                                      • 0
                                                                                                        Да, я эту мысль закладывал, как одну из основных
                                                                                                      • +21
                                                                                                        Я за статью поставил плюс, но, по-моему, от таких статей больше вреда чем пользы.

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

                                                                                                        Вы тут пишете про то, как сами перешли на третью стадию. А многие команды и разработчики даже и в первой стадии не находятся. Но, конечно, теперь им будет легче обосновать, почему надо забить на процессы и кодить как попало, без итераций, планирования, ретро и прочей «ненужной мишуры».
                                                                                                        • 0
                                                                                                          Люди разбегутся, пока будут выстраиваться процессы и болтовня по 100 часов в неделю.
                                                                                                          ИМХО!!!
                                                                                                          • +2
                                                                                                            Вам не повезло, если у вас сложилось мнение, что «процессы» — это «болтовня 100 часов в неделю».
                                                                                                            Эффективные процессы на то и эффективные, что они никого не задалбывают, а наоборот, помогают работать и получать наслаждение от стремительного развития проекта. Это как хороший дизайн, который не должен бросаться в глаза.

                                                                                                            А люди, которые не могут работать в команде по определенным правилам не просто разбегутся, а будут мной беспощадно уволены, ибо они неэффективны.
                                                                                                            • 0
                                                                                                              Удивительно, но мы как раз пришли именно к последней стадии. Черт, как тонко подмечено. Жаль, не удалось перейти снова к Сю.
                                                                                                        • +6
                                                                                                          Самое-то главное просмотрели: когда Нео выбирает и съедает одну таблетку, Морфеус ест _другую_.
                                                                                                          • 0
                                                                                                            Не только просмотрели, вообще не показали.
                                                                                                          • 0
                                                                                                            Я как PM тоже пришел к Вашим выводам примерно год назад. До этого страдал привязыванием методологий к разработке проектов. Лишь в нескольких случаях получалось создать нечто работоспособное, в иных случаях 90% процессов были просто не нужны в проекте.
                                                                                                            Скажу только одно — методологии (лучшие практики) знать необходимо, но слепо использовать их нельзя.
                                                                                                            Даю гарантию, что любому из ваших проектов пригодится только 1-5% процессов, описанных в методологиях, возможно даже вы возьмете по одному процессу из Kanban и PMBoK и этого будет достаточно.
                                                                                                            Не тратьте время на фигню в виде утренних скрамов, пленинг покеров и будет Вам счастье ;)
                                                                                                            • 0
                                                                                                              да, живем без них и супер.

                                                                                                              Вообще, умный программист решает 90% проблем разработки проекта. Остальные 10% решает умный PM.
                                                                                                          • 0
                                                                                                            Или же, если разработчики уже имели опыт рефакторинга в другой компании, они сходу предложат вам проектировать сразу. UML, использование сложнейших инструментов и так далее — давайте сразу сделаем все правильно, чтобы не переписывать. Это может касаться не только программистов — дизайнер будет стараться нарисовать сразу конечный макет, дабы сдать его без переделок.

                                                                                                            Знакомо — было на прошлой работе. В результате неделю просидел просто-так, думая, «а чтоб ещё добавить?». В результате, все изменения пошли уже после того, как я начал делать хоть что-то, помимо проектирования.
                                                                                                            • 0
                                                                                                              Спасибо, это лучшее вдохновение перед работой!
                                                                                                              С такими как вы, хочется работать и получать тот кайф от кода (некоторые это не понимают).

                                                                                                              Видно, накипело, как и у многих… Спасибо!