Дневник разработчика или Плохие решения

    image



    С завтрашнего дня начинаем жить по-новому. Будет у нас Скрам и будет счастье. Полная демократия: никаких начальников, команда сама решает, что ей делать, бюрократия отменяется, главное – сделать заказчику хорошо.

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

    Ну-ну. Поживём-увидим.



    Начинаем новый проект. Ну, слава богу!

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


    Познакомили нас с новым сотрудником, будет у нас Product Owner или, по-русски говоря, представитель заказчика. Зовут Рита. Обаятельная женщина. Очень любит поговорить.

    Задашь ей простой вопрос, так она заводит спич на полчаса. Смотришь на неё и думаешь: “Э, да ты ж не понимаешь ни черта!”.

    Через пять минут сомневаться начинаешь: “Да нет, вроде дело говорит”.

    В конце осознаёшь, что так и не получил ответа на свой вопрос. Так и уходишь.

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

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



    Да, бюрократии и впрямь стало меньше. Потому что все забили на документирование вообще. Теперь информация передаётся в основном из уст в уста. Я, конечно, всё понимаю, мы очень даже agile, но не до такой же степени…



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

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



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

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

    Встретил их в коридоре через полчаса: вышагивает Коля, за ним девушки, и все галдят: “Новая модель… старая модель… требования клиента…”.

    Бедные…



    Получил пулл реквест на ревью. Ошибка в экспорте графика: пропорции высоты и ширины отличаются от оригинала. Странно, ведь я уже когда-то решал эту проблему и позаботился обо всех пропорциях… Решена проблема была оригинально: коллега просто умножил высоту на 1.25.

    Спрашиваю его:

    – Что этот коэффициент означает?
    – А это, – говорит, – я подобрал. Теперь всё хорошо будет.

    Во как! Подобрал он… А что же будет с экспортом других чартов? Стали разбираться, оказалось, что надо просто слегка поменять последовательность вызовов. В каких-то очень редких случаях используются свои установки для канваса, и надо пересчитывать пропорции после этого.

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



    Сегодня Рита сообщила, что приняла решение использовать бесконечный скроллинг при отображении списка документов. Пытался убедить её, что ситуация в REST-сервисе постоянно меняется: одни пользователи добавляют документы, другие удаляют. В результате, в форме либо будут появляться лишние элементы, либо они будут пропадать, поэтому лучше использовать старую добрую паджинацию. На что мне было отвечено, что такая ситуация редка, а бесконечный скроллинг – это модно и сексуально, пользователи будут довольны.

    Довольны? Хм… Я бы расстроился, если бы обнаружил, что список не соответствует текущему состоянию…



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

    Хорошо, что мы самолёты не конструируем…



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

    Вдруг их скрам-мастер Витя подскакивает и как закричит кому-то:
    – Что ты мне всё пишешь! Скажи орально!

    И тут их прорвало. Все сразу загалдели. Орально. Шум поднялся необычайный.

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

    Витя говорит:

    – Ты авторизацию в сервисе менял?
    – Да, – отвечаю, – менял. Теперь пользователи без прав не могут читать ресурс. Надо другой путь использовать.
    – Вот ты поменял, – говорит, – а у нас теперь приложение перестало работать.

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

    Хотел я им сказать: “Что ж вы, черти, тесты-то ни разу не запустили, ведь неделя уже прошла!”, но посмотрел на их лица, развернулся и пошёл делать откат в сервисе.



    Собрал нас сегодня главный и говорит:

    – Надо бы эпик завести. Хотим машинное обучение ввести для настройки результатов поиска.

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

    – Полного описания нет ещё, я вам кину ссылки, на то что есть. Подумайте пока, – отвечает. И ушёл.

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

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


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

    Витя взгляд отводит и говорит:

    – Не, не нашли пока. Времени совсем не хватает…

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

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


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

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



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

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

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

    Конфликт интересов


    Вы – разработчик. Проект или часть проекта, над которыми вы работаете – это ваш любимый ребёнок. Вы создаёте и пестуете его, вы хотите, чтобы у вас получилось совершенное творение. Чтобы ваши коллеги и пользователи могли сказать: «Да, это классная вещь!».

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

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

    Что же делать?

    Скорее всего, придётся переломить себя, уповая на то, что нынешние костыли удастся убрать впоследствии…

    Впрочем, не всё так печально. В долгосрочной перспективе – бизнес ваш союзник в борьбе за качество, если он, конечно, не враг себе.

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

    Возможен ли успех?


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

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

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

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

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

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

    Что важнее: качество продукта или умение продавать?


    Качественный продукт, увы, не является залогом успеха.

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

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

    Плохие решения


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

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

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

    Нестрогие правила


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

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

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

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

    Нарушение правил


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

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

    Сложность настроек


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

    Отсутствие анализа проблемы


    Ваша система позволяет пользователю создавать отчёты на основе DSL. Решено вначале, что DSL содержит все свойства отчёта. По прошествии некоторого времени один из клиентов просит вас добавить возможность хранить часть установок отдельно – это нужно для решения каких-то внутренних проблем клиента. Заводить задачу в Jira «Add external settings» без предварительного анализа проблемы будет ошибкой. Прежде всего, надо ответить на вопрос: а зачем это вообще понадобилось? Вполне может оказаться, что клиент просто хочет скрыть часть установок для некоторых пользователей. Может быть, стоит задуматься о разбиении DSL на части с авторизацией этих частей? Решение не столь быстрое, но, возможно, стратегически верное.

    Политические решения


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

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

    Заключение


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

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

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

    Хочу пожелать долгой жизни вашим проектам!
    Поделиться публикацией

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

      0
      Спасибо, но такое надо в пятницу выкладывать ;-)
        0
        Классно! Спасибо!
          +1
          Рассказ прикольный, только имхо он в первую очередь про то, как можно испортить полезную вещь, забывши про RTFM… :)

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

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

          Аджайл — это просто принцип, и отключение головы в нём не предусмотрено :) Если нужен на проекте архитектор — значит нужно, чтобы команда была им укомплектована. Если разработчиков много — значит нужны лиды в необходимом количестве и время у них на то, чтобы менторить и ревьюить всё, что надо. И надо, чтобы каждый понимал, за что отвечает лично он, и за что — его смежник. И чтобы матрица эта была без пустот… И всё норм будет… :)
            0
            Вы всё правильно говорите. Только я ведь не про Аджайл писал, в общем-то. Неважно, какая технология разработки используется, главное – чтобы решения принимались продуманно и ответственно.
              0
              Да я понимаю. Статья — про внедрятелей новых методологий с дефицитом ресурса на «подумать» :)
                0
                Вот за «дефицит подумать» совсем не факт, кстати.
                Кейзы типа «у нас все сложно, нам нужно больше людей, а поскольку я манагер, то с большим количеством людей я буду более важным манагером с большими бюджетами» или «наши пару куюэев вообще не справляются, но тут есть фирмочка (к котороя я и моя маленькая южная семья не имеет никакого отнощения) и там буквальна за 5 мин (максимум за пару лет) 300 загорелых спартанцев все потестят» — их никто не отменял ;)
            0
            Аджайл это не быстро, это гибко и дорого!
              0
              Документация должна быть. точка. И не важно это аджаил, водопад или что-то другое.
                0
                Должна быть. И на холивары ушло больше времени чем на написание самой документации. Только читая манифест Agile люди, переиначивают пункт «Рабочий софт важнее всеобъемлющей документации» по своему, просто обрезая до «документация не нужна».
                  0
                  Везде где я работал, документация была краеугольным камнем + дополнительно всегда требовалось документировать код продукта и тестов. У меня даже привычка выработалась, начинаю писать функцию, сразу пишу ее шапку в которой описываю для чего она нужна, все входные и выходные параметры. В итоге это занимает минимум времени, зато потом если возврщаюсь к ней — все прозрачно. Поэтому страннослышать, что где-то нет документации. Но это скорее мой опыт и у кого-то может быть другой. Не скрою часто встречал документацию для галочки особенно на наших оборонных предприятиях и приходилось из них ее клещами вытаскивать с тех пор зарекся работать в проектах с такими закзчиками.
                0

                Отличная статья! Разделяю боль. Я как и вы не против Agile. Да только настоящего. Прямо по манифест плюс естественно свои мысли. И мысли могут и полностью отменить все догмы. Или поддержать и дополнить. Или для одного проекта поддержать, а для другого разнести в пух и прах. Agile ведь. А как вы думали? Четыре чувака собрались и сказали это хорошо… И все? Да фиг им просто из чувства противоречия. Причем если я скажу свои хотели, то меня тапками закидают.… И будут правы!


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

                  0
                  Я не совсем, понял причем тут Agile. Если product owner девочка (ну или мальчик, всё равно), которая не может ответить на простой пример. Если скрам-мастер, не может обеспечить данными для тестирования, то это скорее говорит о полной некомпетентности людей. И не важно по какой системе они работают. Такие люди любой проект превратят в балаган, только будут его называть не Agile/Scrum, а «иновационной методологией, основанной на интеграции концепций»
                    0
                    Да, вы правы, конечно.

                    Я, собственно, не про технологии писал. Я хотел сказать, что в отличие от бизнеса, для разработчика самым важным критерием является качество. Это то, чем человек может гордиться в будущем. Когда вам приходится скрепя сердце выполнять решение, калечащее ваш проект, вам ведь нелегко, правда? Поэтому разработчик должен по возможности противиться непродуманным решениям.
                      0
                      А разве входит в роль скрам-мастера обеспечение тестовыми данными? Как мне казалось, его основная задача — модерирование скрам-процессов, следит за тем, чтобы далеко не отклонялись от соглашений без формального их пересмотра.
                      +1

                      Главное, чтобы проект из agile не стал fragile.

                        0
                        Есть цели, требования, задачи и здравый смысл.

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

                        Все остальное второстепенно.
                          0
                          Есть цели, требования, задачи и здравый смысл

                          Это точка зрения бизнеса. Конечная цель – максимум прибыли. И это правильно. Мне, как разработчику, эта цель тоже близка, потому что я тоже заинтересован в успехе продукта.

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

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

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

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

                              Если требуется рефакторить приложение, нужно рефакторить и орг. структуру компании.
                                0
                                Вот тут-то и возникает тот конфликт интересов, о котором я писал.

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

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

                                  Хотя, тут снова конфликт интересов — команда, которая не заинтересована в навязанной ей ф-сти, может сделать её криво или не в те сроки, которые ожидаются. Так что да, рубить проект на корявые куски может быть лучшим решением. Что делать, если бы разрабатывалось в одиночку и для себя, можно сколько угодно корпеть над идеальными решениями. Но при разработке большими командами — только так (мой модуль — не лезь в него), иначе ты можешь долго всё вылизывать, а соседи-индусы завтра навалят говнокода.
                                0
                                Однозначного ответа точно нет. Это сильно зависит от важности системы для компании. Одно дело если это компания одного продукта, и совсем другое если эта система лишь одна из сотен, которых компания делает.
                              0
                              Когда изучаешь новомодные технологии, надо понимать, что там очень мало нового (обычно вообще ничего) и очень много маркетинга. Ведь за любым брендом стоят лекции, вебинары, курсы, книги: и все это приносит хороший доход. Поэтому на Западе очень любят взять старую идею и выдать ее за что-то новое.

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

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

                                Самое читаемое