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

    О чем это


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

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

    На самом деле, после пары десятков проектов я пришел к выводу, что все это — не более чем заблуждения, и чудеса происходят только в книгах авторов, которые делают на своих бестселлерах миллионы. Или в головах консультантов, которые делают деньги, продавая вам фуфло в виде 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 и движущая сила мира. О вас хорошо сказал Айзек Азимов в своем рассказе «Профессия».

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

    Подробнее
    Реклама
    Комментарии 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
                                                                                                              Спасибо, это лучшее вдохновение перед работой!
                                                                                                              С такими как вы, хочется работать и получать тот кайф от кода (некоторые это не понимают).

                                                                                                              Видно, накипело, как и у многих… Спасибо!
                                                                                                              • 0
                                                                                                                Пожалуйста.

                                                                                                                Всех