Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Это хорошо, когда вы имеете возможность разгребать бардак, который творится. Столкнулся с ситуацией, что устроился в маленькую команду Java разработчиков (4 человека). Все 3 разработчика старше меня на 12 лет, опытные, но культура разработки не сходится с моей чуть больше чем совсем. Вообщем у нас 0 тестов (тестирование ручное), ручной деплой, смесь языков в виде Java в jsp. css — файлы и js файлы тоже JSP с вставками Java переменных. Вместе они работают около 20 лет, и ничего они слушать не хотят про deploy одной кнопкой или про тестирование — им это не нужно, и так все работает. Вообщем ищу работу :)
А им и не надо слушать это. Любое программирование — от бизнеса. Идите к тем, кто в этой команде считает деньги. И внятно и четко распишите плюсы и минусы. Кроме карт-бланша вы заработаете и авторитет — а на нем можно выехать очень далеко. А если вы не сможете расписать плюсы, то тогда обратный вопрос: а с чего вы взяли, что порядок и бэст практис лучше для бизнеса, чем то УГ, что есть?
Огромное спасибо за статью!
Даж всплакнул.
Мы на проекте для себя решили, что в оценку задач по умолчанию закладывается устранение техдолга в затронутом коде. Это позволяет постепенно дорабатывать напильником проблемные места. К счастью до менеджмента удалось донести необходимость этого. "А почему так долго?" "Так техдолг рефакторингом красен." Могут правда снять задачу со спринта, если время не устраивает, и подсунуть какую-нибудь другую :-)
Мне еще попадались великолепные вводные от заказчика в стиле «будем использовать АААА, оно кривое и не очень подходит, но оно наше! А великолепно подходящее ББББ не наше».
Если речь об используемом стеке или инструментах, то это как бы не его совсем компетенции, а Ваши.
Речь о стеке, формально — да, вы правы. Фактически же тебе просто говорят «у нас есть мега библиотека и ее надо прикрутить» т.е. задача изначально ставится не «реализовать такую-то функциональность», а «прикрутить такую-то библиотеку». Безусловно, это просчет менеджмента что такую задачу вообще поставили, но инженерам от этого не легче (доказывать что падает все именно из-за этой библиотеки пришлось долго и упорно, но в релизную версию мы ее таки не пустили). Более того, я сталкивался и с проектами, построенными по принципу «проект дело десятое, но глючное поделие заказчика должно быть в его основе», хотя это уже обычно демки разной степени сложности, а не боевые проекты (а вот «прикрутить библиотеку» было в боевом)
Ну, выходит заказчик заказывает не функциональность а интеграцию с имеющимися решениями? Может у него бизнес на этом построен. Если так, то как говориться, кто деньги платит, тот девушку и ужинает.
Бывает и желание усидеть на двух стульях, когда в принципе у заказчика есть несколько формально независимых групп, но результат работы одних групп навязываются другим именно по принципу «наше», хотя этот навязываемый компонент ни является ни бизнесообразующим для заказчика, ни лучшим решением в своем сегменте. Важно чтобы заказчик не перескакивал грань между «давайте соптимизируем и будем использовать наш компонент т.к. мы полностью контролируем его и всегда можем уточнить у разработчиков» и «плевать на все, используем наше!!! Корпоративный дух!!!!»
А по поводу денег — согласен полностью, но я потому и отвечал не на саму статью, а на коммент в стиле «хотел сделать все как надо — начальство запретило». Статья-то как раз очень понравилась и совершенно по делу, жаль только не всегда это выполнимо из-за административных проблем (но этот момент ИМХО и не входил в рамки данной статьи, а то бы монография получилась)
А по поводу денег — согласен полностью, но я потому и отвечал не на саму статью, а на коммент в стиле «хотел сделать все как надо — начальство запретило». Статья-то как раз очень понравилась и совершенно по делу, жаль только не всегда это выполнимо из-за административных проблем (но этот момент ИМХО и не входил в рамки данной статьи, а то бы монография получилась)
Чёрт! Вы описали почти идеальный план построения хорошей продуктовой команды из ничего!
Очень удачная статья, спасибо!
Спасибо, отличная статья, очень удачно суммирует опыт «борьбы» с legacy и организационным бардаком. Особенно импонирует позиция автора, который при виде проекта с явными проблемами не плачет и не вешается, а берет и наводит порядок.
Вот насчёт последней части, где про докапывающихся до фигни заказчиков.
Это совсем уже не компетенция разработчика. Ну, есть такие люди, и их много, которые всегда пытаются продавить скидку, хапнуть чуть больше нахалявку и т.д. И тут все вопросы к сейлзам — за что они вообще хлеб едят?
Хочет заказчик поиметь нахалявку производительность х2? Сейлзы должны тут же сказать «обязательно, всенепременно!» и выкатить допик с мотивированной сметой, которая увеличивает стоимость х2 и сроки х3. Но не доводить до абсурда, разумеется. Если заказчик увидел реально полезную штуку, которая почти ничего не стоит в смысле реализации (пресловутые 15 минут) — её можно и подарить, абсолютно бесплатно, за подписание актов, например)
Но, ещё раз, это совсем не инженерные вопросы. И на попытки сейлзов свалить ещё и это на программистов нужно отвечать предельно жестко в рамках допустимого.
Это совсем уже не компетенция разработчика. Ну, есть такие люди, и их много, которые всегда пытаются продавить скидку, хапнуть чуть больше нахалявку и т.д. И тут все вопросы к сейлзам — за что они вообще хлеб едят?
Хочет заказчик поиметь нахалявку производительность х2? Сейлзы должны тут же сказать «обязательно, всенепременно!» и выкатить допик с мотивированной сметой, которая увеличивает стоимость х2 и сроки х3. Но не доводить до абсурда, разумеется. Если заказчик увидел реально полезную штуку, которая почти ничего не стоит в смысле реализации (пресловутые 15 минут) — её можно и подарить, абсолютно бесплатно, за подписание актов, например)
Но, ещё раз, это совсем не инженерные вопросы. И на попытки сейлзов свалить ещё и это на программистов нужно отвечать предельно жестко в рамках допустимого.
Согласен. Именно это я имел в виду. С той разницей что в моём случае вместо продажников продуктовые менеджеры и аналитики берут на себя коммуникацию с заказчиком.
… если PM, например, хронически прогибается под заказчика, беря без ведома команды обязательства…
Согласен с вами. Важно чтобы решение о цене реализации, в описанной ситуации, принималось не продажником и не заказчиком.
Огромное спасибо за статью — плюсую и преклоняюсь перед вашей несгибаемостью. Сам в похожей ситуации, но уже опустил руки. У нас большой enterprise-проект на ASP.MVC (C#). Уровень легаси зашкаливает:
Есть конечно и плюсы, и даже телодвижения в сторону улучшения и борьбы с legacy, но говнокод растет быстрее, т.к. (лучше и не скажешь):
- SVN (на Git не переходим, т.к. генеральному нужно редактировать в репозитории некоторые input-файлы, а он не программист, кривая его обучения гиту — большая; на распил репозитория на «код» и «input»-файлы пока не соглашаются).
- Deploy ручной на AWS Windows-сервера через RDP.
- Низкая компетенция разработчиков — все пришли из мира desktop-разработки, никто не в курсе как работает HTTP в принципе, JavaScript пишется с трудом и в виде ужасных «спагетти».
- Бизнес логика в огромных контроллерах (есть экшены по 500 строк и больше).
- Генерация HTML местами жестко зашита в бизнес-логике.
- Само приложение реализовано stateful (например, entity, выбранный на предыдущей странице, сохраняется в сессии и на следующей странице выбирается оттуда, вместо передачи его ID через URL).
- ну и много чего еще...
Есть конечно и плюсы, и даже телодвижения в сторону улучшения и борьбы с legacy, но говнокод растет быстрее, т.к. (лучше и не скажешь):
вы можете кинутся грудью на амбразуру рефакторинга… И погибнуть, поскольку остальная команда будет успевать «говнокодить»
Сочувствую.
Я так полагаю, что скупой платит дважды: рано или поздно игнорирование текущих проблем ударит по проекту и компании, и накапавшие по долгам проценты могут убить даже успешный продукт.
А проблемы с качеством кода, которые вы описали, на мой взгляд можно решить тремя способами: тесты, тесты и тесты. Без тестов не будет ни рефакторинга, ни SOLID и прочих прелестей, с которыми приятно иметь дело.
Я так полагаю, что скупой платит дважды: рано или поздно игнорирование текущих проблем ударит по проекту и компании, и накапавшие по долгам проценты могут убить даже успешный продукт.
А проблемы с качеством кода, которые вы описали, на мой взгляд можно решить тремя способами: тесты, тесты и тесты. Без тестов не будет ни рефакторинга, ни SOLID и прочих прелестей, с которыми приятно иметь дело.
Эта одна из немногих статей за последнее время, которую захотелось прочитать полностью, спасибо автору!
Столкнулся с похожими проблемами на моей текущей работе около полутора лет назад, с того времени внедрил несколько подходов и технологий: git, IoC, централизованное логирование в elasticsearch, новый трекер задач. Несколько задач решил через микросервисы.
Кстати, на мой взгляд автор не сказал про важную часть — логирование.
Я долго убеждал в необходимости писать логи в одно хранилище с последующем оповещением ответственных лиц о произошедших событиях.
Столкнулся с похожими проблемами на моей текущей работе около полутора лет назад, с того времени внедрил несколько подходов и технологий: git, IoC, централизованное логирование в elasticsearch, новый трекер задач. Несколько задач решил через микросервисы.
Кстати, на мой взгляд автор не сказал про важную часть — логирование.
Я долго убеждал в необходимости писать логи в одно хранилище с последующем оповещением ответственных лиц о произошедших событиях.
Да, логирование важно, безусловно.
Изначально в описываемом проекте логирования настроено не было, и проблем соответственно с его кривой политикой. А фреймворк в этом плане не мешает: при необходимости можно расставить точки где угодно и начать писать что угодно в любой момент.
Изначально в описываемом проекте логирования настроено не было, и проблем соответственно с его кривой политикой. А фреймворк в этом плане не мешает: при необходимости можно расставить точки где угодно и начать писать что угодно в любой момент.
Плюсую поднятую тему!
Кроме логирования важен сбор метрик приложений при тестировании и в продакшен. Иначе все NFR, под которыми подписываетесь бессмысленны. Так же как и быстрое определение а что именно «тормозит» и не работает.
Для JVM решений описывал возможную реализацию в статьях:
Кроме логирования важен сбор метрик приложений при тестировании и в продакшен. Иначе все NFR, под которыми подписываетесь бессмысленны. Так же как и быстрое определение а что именно «тормозит» и не работает.
Для JVM решений описывал возможную реализацию в статьях:
- «DevOps: отправляем метрики и спим спокойно»;
- «Публикация логов в Elasticsearch — жизнь без регулярных выражений и без logstash».
Статья интересная, но непонятно, какова была ваша роль и насколько велики были данные вам полномочия? По моему опыту (пусть, возможно, и меньшего solution — не знаю, что вы имели ввиду конкретно под enterprise — так, скромный американский стартап до сотни человек, solution, приносящий в год единицы миллионов прибыли, и тайная главная цель, состоящая в продаже этого стартапа), для этого нужен как минимум уровень CTO (в случае стартапа), ну, или не знаю кого в вашем случае. В общем так, чтобы chairman компании, в порыве откровенности, сказал: "Слушай, даю тебе все полномочия, увольняй, нанимай кого хочешь (бюджет в таких-то рамках обеспечу), но мы должны зарелизиться в начале декабря! Даю тебе лично годовую зарплату в качестве бонуса" :)
Имея такие возможности, и соответствующие такой позиции знания, как надо: думаю, при наличии определенной доли удачи можно задачу решить. Если же речь идет о позиции с намного меньшими полномочиями, то сто процентов возникнут трудности и проблемы. Что поделать, если релиз менеджер знает лишь юникс-шелл, и его шансы (а главное желание) освоить MSBuild равны 0? Но при этом — он очень хороший парень, пришел задолго до вас, друг CEO, и работает уже в третьем стартапе с chairman-ом? Уволить (или даже критиковать) вам его просто-напросто не дадут — это конфликт в коллективе, и, вероятнее всего, расстанутся с вами. Или вы обнаружили, что уровень QA ниже плинтуса, они пропускают реально тяжелые showstoppers, но вместо это порождают кучу false reports? Но разогнать отдел — не ваших полномочиях. И так далее, и тому подобное.
Я полностью согласен с тем, что вы написали (и даже добавил бы еще) — например, обязательную тренировку разработчиков на code review и требование творческого и серьезного подхода к этому вопросу (просто ужас, что творится с code review — процедура теряет весь смысл). Ну и много еще чего можно добавить. Но применить это в реальной жизни можно лишь имея большие полномочия, твердые знания, умение убеждать начальство, а также твердый характер (вы решили уволить мать-одиночку, которую непонятным образом повысили в QA из рядового тестера-«кнопконажимальщика» до инженера).
Имея такие возможности, и соответствующие такой позиции знания, как надо: думаю, при наличии определенной доли удачи можно задачу решить. Если же речь идет о позиции с намного меньшими полномочиями, то сто процентов возникнут трудности и проблемы. Что поделать, если релиз менеджер знает лишь юникс-шелл, и его шансы (а главное желание) освоить MSBuild равны 0? Но при этом — он очень хороший парень, пришел задолго до вас, друг CEO, и работает уже в третьем стартапе с chairman-ом? Уволить (или даже критиковать) вам его просто-напросто не дадут — это конфликт в коллективе, и, вероятнее всего, расстанутся с вами. Или вы обнаружили, что уровень QA ниже плинтуса, они пропускают реально тяжелые showstoppers, но вместо это порождают кучу false reports? Но разогнать отдел — не ваших полномочиях. И так далее, и тому подобное.
Я полностью согласен с тем, что вы написали (и даже добавил бы еще) — например, обязательную тренировку разработчиков на code review и требование творческого и серьезного подхода к этому вопросу (просто ужас, что творится с code review — процедура теряет весь смысл). Ну и много еще чего можно добавить. Но применить это в реальной жизни можно лишь имея большие полномочия, твердые знания, умение убеждать начальство, а также твердый характер (вы решили уволить мать-одиночку, которую непонятным образом повысили в QA из рядового тестера-«кнопконажимальщика» до инженера).
Пришёл просто разработчиком. Проект по размерам средний, основные проблемы не в размере, а сложности предметной области и наследии. Начал по пунктам налаживать разработку: тесты, git, deploy. Предыдущий ведущий разработчик вскоре покинул команду. В итоге получилось что стал исполнять роль тим лида: проектирование, техническая постановка задач.
Полномочий, как таковых, увы кот на плакал — вся разработка и я формально в аутсорсе, весь менеджмент внутри компании, заказчик вообще в другой стране и департаменте корпорации. Поэтому решения о найме / увольнении достаточно оперативно и прямо принимать я не имею никакой возможности. Только последовательно отстаивая свою линии: повторять месяц, другой, третий:
— мало фронтенда надо усилить, засыпемся на новых фичах, бла-бла-бла…
— нужен выделенный QA, засыпемся багами с релизом, бла-бла-бла…
Глядишь, через пол-года корпоративная махина начинает тебя слышать и пытаться искать человека. И в таком духе. В общем долго и тяжело.
До того участвовал в стартапе, где мне был дан карт-бланш: набирай сколько надо людей, плати сколько надо чтобы работали. Конечно при таком раскладе эффективность построения команды на порядок отличается.
Полномочий, как таковых, увы кот на плакал — вся разработка и я формально в аутсорсе, весь менеджмент внутри компании, заказчик вообще в другой стране и департаменте корпорации. Поэтому решения о найме / увольнении достаточно оперативно и прямо принимать я не имею никакой возможности. Только последовательно отстаивая свою линии: повторять месяц, другой, третий:
— мало фронтенда надо усилить, засыпемся на новых фичах, бла-бла-бла…
— нужен выделенный QA, засыпемся багами с релизом, бла-бла-бла…
Глядишь, через пол-года корпоративная махина начинает тебя слышать и пытаться искать человека. И в таком духе. В общем долго и тяжело.
До того участвовал в стартапе, где мне был дан карт-бланш: набирай сколько надо людей, плати сколько надо чтобы работали. Конечно при таком раскладе эффективность построения команды на порядок отличается.
Не очень понял, почему вы взялись за эту работу, не имея на тот момент никаких полномочий?
Как вы собирались всё исправить при «живом» тимлиде, который этого не сделал, будучи просто разработчиком? Или же вам прямо на собеседовании ПМ и тимлид сказали, что готовы и хотят улучшений, что вы для этого и нужны, и что они, в свою очередь, будут вас в этом поддерживать?
Как вы собирались всё исправить при «живом» тимлиде, который этого не сделал, будучи просто разработчиком? Или же вам прямо на собеседовании ПМ и тимлид сказали, что готовы и хотят улучшений, что вы для этого и нужны, и что они, в свою очередь, будут вас в этом поддерживать?
На тот момент основной мотивацией взяться за проект было получить в резюме строчку с именем крупной компании и стабильное (в сравнении с чередой стартапов) место работы. Ну и применить на практике, теоритические, по большей части, знания о рефакторинге.
О том насколько сильно будет затронут весь процесс речи не шло.
Как мне представляется, никто из занятых в проекте на тот момент не представлял себе масштаб предстоящих мероприятий =)
О том насколько сильно будет затронут весь процесс речи не шло.
Как мне представляется, никто из занятых в проекте на тот момент не представлял себе масштаб предстоящих мероприятий =)
Спасибо. Залип в статью, оторвался только что б ссылку скинуть коллегам.
От себя хотелось бы добавить, что в нескольких местах где работал бизнес-аналитики занимаются максимум распределением задач по разработчикам и подготовкой версий в редмайне. Без бизнес-анализа =( В итоге приходится общаться напрямую с разработчиками сервисов, которые мы у себя юзаем вместо того, что бы запереть в комнате двух БА и добиться от них прописанной логики взаимодействия и описания параметров запросов =(((.
От себя хотелось бы добавить, что в нескольких местах где работал бизнес-аналитики занимаются максимум распределением задач по разработчикам и подготовкой версий в редмайне. Без бизнес-анализа =( В итоге приходится общаться напрямую с разработчиками сервисов, которые мы у себя юзаем вместо того, что бы запереть в комнате двух БА и добиться от них прописанной логики взаимодействия и описания параметров запросов =(((.
Да, сталкиваюсь с аналогичными проблемами. Аналитики пытаются излагать то как они видят реализацию, а не требования, при этом, зачастую скидывая анализ сырых требований на разработчиков. Ну и пытаются менеджерить, не обладая ни знанием, ни опытом.
Я это называю «работа не на своём уровне абстракций» =)
Я это называю «работа не на своём уровне абстракций» =)
Трекер задач — не менее важен в разработке чем IDE. Это краеугольный камень процесса разработки: в нём должна начинаться и заканчиваться любая активность в проекте. Нет задачи — нет кода.
При всём уважении и практически полном согласии с остальным текстом статьи вынужден констатировать, что там, где я работаю, и у меня лично в частности, трекеры задач как таковые не приживаются почему-то, ну никак. И я лично для себя полезности в них не нахожу, только лишние затраты времени, может потому что проекты не очень большие, 1-3 человека над одним трудится, может потому что нет конкретно «кодеров», а есть программист, который сам себе задачу ставит из очень размытых требований, сам с заказчиком общается и т.п.
А вот про тесты и квалификацию это прям в тему, как раз один коллега, высокооплачиваемый ведущий специалист, увольняется, оставив в наследство после себя гору
Если программист 1, конечно жиру поднимать, пожалуй излишне.
Если двое, то, в принципе они и экселем могут обойтись.
Но по мере увеличения разработчиков и потока задач, важно уметь найти след всех изменений продукта: кто, что, когда и почему. В идеале не должно вноситься ни единой строчки кода без соответствующей задачи в трекере.
Трекер инструмент управления командной разработкой, чем больше команда, тем этот инструмент становиться более необходим.
Насчёт высокооплачиваемого спеца без тестов — наблюдал аналогичное не так давно.
Опытнейший спец, любимец менеджеров по причине циничного отношения ко всему: надо — запилим. За день, хорошо, за день. За чес? Говно-вопрос. Ничто не вечно, конечно он в итоге ушёл. И бедный его коллега: оставшийся с наследством без тестов, на костылях и палках работающим.
Мы же пишем код не для того чтобы писать, а читать его =)
Если двое, то, в принципе они и экселем могут обойтись.
Но по мере увеличения разработчиков и потока задач, важно уметь найти след всех изменений продукта: кто, что, когда и почему. В идеале не должно вноситься ни единой строчки кода без соответствующей задачи в трекере.
Трекер инструмент управления командной разработкой, чем больше команда, тем этот инструмент становиться более необходим.
Насчёт высокооплачиваемого спеца без тестов — наблюдал аналогичное не так давно.
Опытнейший спец, любимец менеджеров по причине циничного отношения ко всему: надо — запилим. За день, хорошо, за день. За чес? Говно-вопрос. Ничто не вечно, конечно он в итоге ушёл. И бедный его коллега: оставшийся с наследством без тестов, на костылях и палках работающим.
Мы же пишем код не для того чтобы писать, а читать его =)
Мне кажется, что дело не только в количестве разработчиков, а в соотношении количества незакрытых запросов на человека за итерацию. Причем если число разработчиков растет, то и предел при котором нужен трекер тоже понижается.
Не согласен здесь с вами по поводу трекера. Использую джиру и другие трекеры/системы, даже если работаю один. Во-первых, если у человека нет чёткого плана, то в большинстве случаев работа будет выполняться медленнее. Во-вторых, бывает полезно отслеживать затраченное на задачи время — от простого улучшения планирования, до, например, внеплановых отчётов на внезапные «а чем ты занимался весь месяц?». В-третьих, имея перед собой список задач, гораздо проще расставить их приоритеты. В-четвёртых, если есть список задач, то не будет «боязни чистого листа» — создаётся тикет, содержащий «общее» описание задачи, затем связанные тикеты, содержащие уже более точно выделенные вещи, затем тикеты, содержащие более детальные задачи и т.д., до тех пор, пока что-то абстрактное и непонятное не будет представлено в виде простейших задач, с которыми не возникнет никаких проблем. Я это говорю не просто как что-то гипотетическое — всё в полной мере «выстрадано» на собственном опыте. Конечно, бывает и такое, что заказы простейшие, на день или несколько дней работы — тут план вполне может в голове держаться (если область хорошо известна и задачи абсолютно никаких вопросов не вызывают — в общем, рутина). Но любой хоть сколько-нибудь серьёзный проект ощутимо выигрывает от использования трекеров/инструментов планирования и т.п.
P.S. Закончили ли вы уже тот проект? Сколько времени заняли все эти изменения и сколько всего времени проект разрабатывался?
P.S. Закончили ли вы уже тот проект? Сколько времени заняли все эти изменения и сколько всего времени проект разрабатывался?
Участие ещё не закончил, я в нём ~ год и восемь месяцев. Описанные мероприятия охватывают примерное первые полтора года.
Разработка проекта же велась с 2013 года, и будет продолжаться, эксплуатация формально началась с конца 2015, но по факту активное использование ещё не началось — по сути тянется фаза приёмки, чендж реквесты постоянно появляются.
Разработка проекта же велась с 2013 года, и будет продолжаться, эксплуатация формально началась с конца 2015, но по факту активное использование ещё не началось — по сути тянется фаза приёмки, чендж реквесты постоянно появляются.
Трекер задач нужен даже для одного разработчика.
Я вот 1Сник, работал в торговой компании (т.е. не софтверная компания, а отдел поддержки и разработки приложений из 3 человек + 2 сисадмина);
И что хочу сказать: мне в трекере ставились задачи (и на разработку и на правку багов), я оные задачи выполнял, и в конце недели вполне обоснованно мог сказать начальству: я потратил столько-то времени на это и столько-то на вот это, а вот эту критическую фичу я вообще сверхурочно реализовал, она хрупкая, и сейчас я поставил себе же задачу «причесать» эту фичу. Все довольны: управленцы видят сроки работ, пользователи видят, когда к их запросу приступят, QA видят, когда надо начать тест той или иной фичи.
Я вот 1Сник, работал в торговой компании (т.е. не софтверная компания, а отдел поддержки и разработки приложений из 3 человек + 2 сисадмина);
И что хочу сказать: мне в трекере ставились задачи (и на разработку и на правку багов), я оные задачи выполнял, и в конце недели вполне обоснованно мог сказать начальству: я потратил столько-то времени на это и столько-то на вот это, а вот эту критическую фичу я вообще сверхурочно реализовал, она хрупкая, и сейчас я поставил себе же задачу «причесать» эту фичу. Все довольны: управленцы видят сроки работ, пользователи видят, когда к их запросу приступят, QA видят, когда надо начать тест той или иной фичи.
Отличная статья, спасибо!
Меня заинтересовало, как стало возможным повернуть эту громадину и сколько времени на это ушло?
Как боролись с сопротивлением коллектива?
У меня тоже наполеоновские планы были все сделать правильно, однако одно заинтересованное лицо считает что знает процессы разработки ПО лучше, и приходилось ему «сдаваться». В итоге технический долг вырос примерно до 4-5 программисто-месяцев, а я предпочел искать новую работу вместо дальнейшего увеличения этой кучи. Ибо не могу…
Меня заинтересовало, как стало возможным повернуть эту громадину и сколько времени на это ушло?
Как боролись с сопротивлением коллектива?
У меня тоже наполеоновские планы были все сделать правильно, однако одно заинтересованное лицо считает что знает процессы разработки ПО лучше, и приходилось ему «сдаваться». В итоге технический долг вырос примерно до 4-5 программисто-месяцев, а я предпочел искать новую работу вместо дальнейшего увеличения этой кучи. Ибо не могу…
Коллектив разработчиков, по сути полностью поменялся в течении первого года на более адекватный. Не идеальный, но более соответствующий новым требованиям. Насколько я могу судить, если повысить планку, то люди склонные развиваться остаются и развиваются, те кто не может уходят сами. Это процесс не долгий, сопротивление скорее пассивное. Но коллектив, как частный случай социума склонен адаптироваться к изменяющимся условиях, порой и методом естественного отбора. Про время ответил выше.
В целом, я на многие вопросы связанные с инертностью большой организации стал реагировать более спокойно, чем раньше. Главное сигнализировать как можно раньше, регулярно и достаточно настойчиво. Время расставит всё на свои места, порой надо помнить что твоя ответственность ограничена тем, чтобы только указать на проблему, при этом возможности решить её в оперативном режиме нет из-за инертности / недостатка полномочий.
В целом, я на многие вопросы связанные с инертностью большой организации стал реагировать более спокойно, чем раньше. Главное сигнализировать как можно раньше, регулярно и достаточно настойчиво. Время расставит всё на свои места, порой надо помнить что твоя ответственность ограничена тем, чтобы только указать на проблему, при этом возможности решить её в оперативном режиме нет из-за инертности / недостатка полномочий.
Ничего не сказано о том, что делать с самой главной проблемой энтерпрайза. Всё время речь идёт о том, как повысить эффективность людей. Это имеет смысл, когда работы много, а людей мало. Тогда и разделение труда даст заметный эффект. И всё прочее более-менее релевантно. Но это совсем другая история. В энтерпрайзе же существует ровно обратная проблема. Как понизить эффективность людей таким образом, чтобы они были заняты всё время, выполняя небольшой объём работы? Важно, чтобы никто из тех, кто хорошо разбирается в каком-то отдельном фрагменте этой огромной системы, не ушёл из компании. Теоретически, компания даже готова платить им полноценную зарплату за просмотр смешных картинок из интернета, лишь бы они оставались на своём месте и были готовы немножко поработать при необходимости. Но ведь официально такое объявить невозможно. Это будет как-то не комильфо. Соответственно, нужно как-то занять разработчиков работой. Понятно, что с низкоквалифицированными дело обстоит проще. Их не требуется замедлять. Они и так работают достаточно медленно. Но что делать с высококвалифицированными, чтобы они не заскучали?
Энтерпрайз энтерпрайзу рознь, видимо.
Мне скучать не приходилось, и всем работы хватало. Но, спасибо менеджменту, и с эффективностью особо никто мозг не насиловал.
Касательно автобусного фактора, есть хорошо известные методики: code review, ping pong, соглашения по кодированию, требования к внутренней документации, workshops. Если есть буфер на смешные картинки, то уж лучше имхо использовать его на указанные мероприятия.
Мне скучать не приходилось, и всем работы хватало. Но, спасибо менеджменту, и с эффективностью особо никто мозг не насиловал.
Касательно автобусного фактора, есть хорошо известные методики: code review, ping pong, соглашения по кодированию, требования к внутренней документации, workshops. Если есть буфер на смешные картинки, то уж лучше имхо использовать его на указанные мероприятия.
Для себя я определяю энтерпрайз следующим образом. Это не просто разработка и поддержка большой системы, а такой процесс разработки, при котором компания получает деньги не столько за внедрение новых фич, сколько за то, чтобы всё работало как раньше. Новые фичи приходится делать очень редко. Гораздо чаще нужно просто фиксить баги. При этом под «гораздо чаще» имеется в виду то, что в среднем раз в две недели обнаруживается баг, который можно пофиксить за час. Так что, наверное, всё-таки нет. Не энтерпрайз энтерпрайзу рознь. Описанная мной проблема присуща энтерпрайзу в принципе. Это его дистинктивное свойство. Если такой проблемы нет, то тогда это просто не энтерпрайз в моём понимании, а всего лишь разжиревший стартап.
С автобусным фактором не всё так просто. Такие простые техники, как code review и прочее, помогают снизить риски незначительно. Люди, занятые в разработке, ценны не тем, что хорошо ориентируются в кодовой базе. Это скорее приятный бонус. Основную ценность образует их опыт работы в специфической предметной области. Например, кто-то в течение шести последних лет занимался реализацией взаимодействия системы с РЖД. Он может легко ответить на любой вопрос о том, как что работает в РЖД. Задокументировать все его знания невозможно. Кто-то другой пять лет разрабатывал модуль для взаимодействия, к примеру, с Почтой России. С ним то же самое. Без него нельзя не то что исправить баг… Нельзя даже понять, где баг, а где широко известная в узких кругах особенность поведения, которая на первый взгляд выглядит странно, но на самом деле была выстрадана годами опыта практической эксплуатации.
С автобусным фактором не всё так просто. Такие простые техники, как code review и прочее, помогают снизить риски незначительно. Люди, занятые в разработке, ценны не тем, что хорошо ориентируются в кодовой базе. Это скорее приятный бонус. Основную ценность образует их опыт работы в специфической предметной области. Например, кто-то в течение шести последних лет занимался реализацией взаимодействия системы с РЖД. Он может легко ответить на любой вопрос о том, как что работает в РЖД. Задокументировать все его знания невозможно. Кто-то другой пять лет разрабатывал модуль для взаимодействия, к примеру, с Почтой России. С ним то же самое. Без него нельзя не то что исправить баг… Нельзя даже понять, где баг, а где широко известная в узких кругах особенность поведения, которая на первый взгляд выглядит странно, но на самом деле была выстрадана годами опыта практической эксплуатации.
Спасибо за статью! Отлично от А до Я все расписано. Такое ощущение, что в своей новой команде вы навели полный порядок.
Вопрос назасыпку: что посоветуете вместо связки Confluence + Jira + Bitbucket для небольшой команды (4-6 человек)? Перевели код на github, но баги там вести неудобно. Есть сторонние сервисы, типа Waffle.io или HuBoard, которые превращают GitHub issues в некое подобие Jira, но этого мало. Ну и плюс ко всему нет вообще никакой альтернативы Confluence. Jira/Confluence — отличные продукты до того момента, пока ты не начинаешь заниматься их администрированием и вот там начинается самый ад. Atlassian видимо не особо парится проблемами своих кастомеров… :(
Вопрос назасыпку: что посоветуете вместо связки Confluence + Jira + Bitbucket для небольшой команды (4-6 человек)? Перевели код на github, но баги там вести неудобно. Есть сторонние сервисы, типа Waffle.io или HuBoard, которые превращают GitHub issues в некое подобие Jira, но этого мало. Ну и плюс ко всему нет вообще никакой альтернативы Confluence. Jira/Confluence — отличные продукты до того момента, пока ты не начинаешь заниматься их администрированием и вот там начинается самый ад. Atlassian видимо не особо парится проблемами своих кастомеров… :(
Сам я эти продукты не администрировал, не слышал об особых проблемах с ними.
Кроме Jira работал в паре мест с Redmine, пожалуй его можно рассматривать как более легковесную альтернативу. Но, опять так по наслышке, сам не администрировал, проблемы с администрированием там не исключены.
Меня Attlasian, как пользователя вполне устраивает.
Кроме Jira работал в паре мест с Redmine, пожалуй его можно рассматривать как более легковесную альтернативу. Но, опять так по наслышке, сам не администрировал, проблемы с администрированием там не исключены.
Меня Attlasian, как пользователя вполне устраивает.
Redmine когда я с ним работал отлично заменял и confluence и jira, но явно не подходил для доступа к вашему проекту внешнего заказчика. Авторизация и доступ были как мед — либо есть, либо его сразу нет. Решалось подобное заведением отдельного проекта для заказчика и переноса комментариев «из и в» в наиболее честный и полный трекер для разработчиков.
К тому же его раньше можно было упаковать с jruby и деплоить в java веб контейнеры, чтобы не разводить зоопарк с веб серверами и рантаймами.
К тому же его раньше можно было упаковать с jruby и деплоить в java веб контейнеры, чтобы не разводить зоопарк с веб серверами и рантаймами.
+1
Jira неудобная.
Создавать заявки можно, а дальше головняк.
Jira неудобная.
Создавать заявки можно, а дальше головняк.
Вместо Jira можно использовать TargetProcess, Trello
Вместо Confluence — нужно смотреть как именно вы сейсам ее используете, тогда можно будет что-то порекомендовать.
Вместо Confluence — нужно смотреть как именно вы сейсам ее используете, тогда можно будет что-то порекомендовать.
Мне понравилась в свое время YouTrack от JetBrains. На мой взгляд для маленьких команд — самое то
Вы молодец! :)
П.С.
О менеджерах:
Иногда приходит такой менеджер без пяти шесть и говорит:
— Заливай на прод, нету времени объяснять.
:)
П.С.
О менеджерах:
Иногда приходит такой менеджер без пяти шесть и говорит:
— Заливай на прод, нету времени объяснять.
:)
Не проблема. Легким нажатием кнопки (за пять минут до шести можно успеть это сделать) в тимсити запускаем билд, в который входят установки зависимостей, сборка, юнит тесты, приёмочные тесты, тестовый прогон миграций на дампе базы с прода, автобекап перед выкатом на сервере…
Когда билд закончится (пол седьмого), я уже буду подъезжать к дому. Если не закончиться успешно — ничего страшного, просто упал билд, ну бывает.
В совсем крайнем случае бэкап предыдущей версии создан, процедура отката отрепетирована.
Утром всё можно на свежую голову поправить.
Когда билд закончится (пол седьмого), я уже буду подъезжать к дому. Если не закончиться успешно — ничего страшного, просто упал билд, ну бывает.
В совсем крайнем случае бэкап предыдущей версии создан, процедура отката отрепетирована.
Утром всё можно на свежую голову поправить.
Примерно в таком же г довелось участвовать. Могу сказать что неправильные пчелы, делают неправильный мед. Процессы лишь слегка улушат ситуацию, ситуация изменила тренд, когда на проекте появились комптетентные люди.
У людей как и у меня не проходит желание «переписать все нафиг», но это не целесообрзно, по этому методично и планово как только сталкиваемся с проблемным кодом, его переделываем.
У людей как и у меня не проходит желание «переписать все нафиг», но это не целесообрзно, по этому методично и планово как только сталкиваемся с проблемным кодом, его переделываем.
В том и профит процессов, что они могут помогать даже неправильным пчёлам делать правильный мёд. И привлечь компетентных людей, либо вырастить таких, проще имея отлаженные процессы.
git + docker — нельзя пофиксить что-то по горячему на проде — очередной билд затрёт
CI + автотесты — нельзя в продакшен выкатить нерабочую сборку
сбор метрик, CRAP, цикломатической сложности — можно автоматом заворачивать пул реквесты без должного покрытия или откровенный овногод и т.д.
git + docker — нельзя пофиксить что-то по горячему на проде — очередной билд затрёт
CI + автотесты — нельзя в продакшен выкатить нерабочую сборку
сбор метрик, CRAP, цикломатической сложности — можно автоматом заворачивать пул реквесты без должного покрытия или откровенный овногод и т.д.
Они не помогают, они ограничивают залепить г-но :)
Это все равно что на слив поставить фильтр крупных фракций, да кусков больше не будет, но малопригодная жижа остается.
Это все равно что на слив поставить фильтр крупных фракций, да кусков больше не будет, но малопригодная жижа остается.
Я как идеалист и романтик, склонен полагать, что при достаточном количестве и качестве фильтров (продолжая вашу аналогию), а ещё и дистилляции (в виде код-ревью и парного программирования например) можно получить пригодную для питья воду из чего угодно =) Чем водококанал, насколько я знаю, успешно и занимается.
Конечно, многие вещи удалось завершить не без известного лимита доверия со стороны PM и периодов относительного затишья в графике проекта. Но, до идеала, как всегда далеко.
В сложном технологическом проекте, придметная область которого близка команде, вполне можно покрыть почти все юнит и интеграционными тестами своими силами. А если QA как манна небесная окажется в команде, то ему достанутся высокоуровневые вещи: тест-планы и приемочные тесты для конкретных потребителей проекта, ближе к специфике их бизнеса.
А вам за что деньги платят: за послушание или за эффективную работу?) Можно найти какой-либо баланс между работой над бизнес-задачами и улучшением QA автоматизации втихоря?
Один неявный плюс автоматизации про который часто забывает менеджмент — не разбегутся из проекта профессионалы от регулярного демотивирующего manual monkey testing.
Один неявный плюс автоматизации про который часто забывает менеджмент — не разбегутся из проекта профессионалы от регулярного демотивирующего manual monkey testing.
Да, проблема качества почти везде актуальна, на QA многие экономят.
Но вот чтобы начать использовать TDD / unit testing не вижу возможных объективных организационных проблем (кроме отсутствия компетенции у самих разработчиков), было бы желание. Это чисто внутренний вопрос разработки, а на качество влияет очень хорошо. Начальство и знать не обязано, пишут разработчики тесты или нет.
Но вот чтобы начать использовать TDD / unit testing не вижу возможных объективных организационных проблем (кроме отсутствия компетенции у самих разработчиков), было бы желание. Это чисто внутренний вопрос разработки, а на качество влияет очень хорошо. Начальство и знать не обязано, пишут разработчики тесты или нет.
Ваша миссия показать ему простую арифметику: час разработчика как правило в N-раз дороже часа «ручного» тестировщика. За несколько полных дней тестирования имеющимися в команде разработчиками, легко сжигается зарплата зарплата выделенного тестера. Не забываем о простое разработки.
Позволю себе не согласиться с этим утверждением — хороший тестировщик должен иметь зарплату сравнимую с зарплатой разработчика, да, быть может, немного меньше, но уж никак не «в N раз». Ибо вклад в итоговое качество продукта вносят и те и другие, причем далеко не всегда можно утверждать, что разработчик — намного больше. Возможно, вместо того, чтобы нанимать мануальщика-«обезьянку» за копейки, лучше стоит взять сеньора, но быть уверенным, что он так же горит энтузиазмом, как и вы — и с обеих сторон (QA и девелопмент) качество будет непрерывно расти.
Согласен со всем с автором кроме того что касается unit-testing. Если код низкого качества то обычно методы с бизнес логикой по 100+ строк в которых делается все и вся. Писать юнит тесты на такие методы не имеет смысла потому что вы банально не можете предсказать состояние системы после его выполнения: данных слишком много или результаты слишком разнообразны. Другая причина — вы банально не сможете покрыть все кейсы использования этого метода. Даже хороший код, который пишется на основе существующего кода низкого качества не получится сделать лучше в силу обстоятельств. Поэтому мой список действий по улучшению продукта:
-) terminology (Терминология должна быть общей для того чтоб избежать недопомниманий на любых этапах разработки, + документирование например на wiki. Терминология может отличаться от сервиса к сервису но должна иметь описание по которому можно было связать два разных сервиса)
-) naming conventions (название классов и методов должны дублировать общепринятую терминологию, пардон, java specific: а так же package naming)
-) database (практика показывает что качество data access layer в первую очередь зависит от структуры субд. Новые обьекты СУБД ссылаются на уже существующие и не позволяют сделать новые фичи — «хорошо», изменение существующей схемы можно делать кардинально или итеративно, желательно «per feature»)
-) presentation layer (PL) > business logic layer (BLL) > data access layer (DAL) (выделение 3х слоев в серверном приложении это один из важных шагов на пути к качественному коду: single responsibility. Написание качественного DAL невозможно без улучшения схемы СУБД, BLL без DAL, PL без BLL)
Только по коду:
-) code formatter (в идеале должен лежать в git вместе с кодом и подхватыватся IDE)
-) static code analysis (в идеале должен быть интегрирован в IDE. Developer должен думать о качестве кода во время разработки, что позволяет приобрести полезную привычку вместо надоедливых e-mail от CI&CD )
Заметка манагерам:
-) програмеры часто концентрируют все внимание на решении одной задачи (что является прямой противоположностью с менеджерской работой), поэтому им не только лень переключать внимание на что-то другое а еще и тяжелее (уровень концентрации выше), поэтому нужно сделать так чтоб они не тратили свое внимание и концентрацию на что-то другое. Девелоперы лажают с билдами? — Выделите время на автоматизацию процеса. Девелоперы лажают с деплойментом? Упростите процесс, сделайте билды более тонкими а деплойменты более частыми. Девелоперы плохо тестят фичи, баги? Выделите время на написание чего-то что поможет упроситить тестирование как для девелопера так и для qa
-) terminology (Терминология должна быть общей для того чтоб избежать недопомниманий на любых этапах разработки, + документирование например на wiki. Терминология может отличаться от сервиса к сервису но должна иметь описание по которому можно было связать два разных сервиса)
-) naming conventions (название классов и методов должны дублировать общепринятую терминологию, пардон, java specific: а так же package naming)
-) database (практика показывает что качество data access layer в первую очередь зависит от структуры субд. Новые обьекты СУБД ссылаются на уже существующие и не позволяют сделать новые фичи — «хорошо», изменение существующей схемы можно делать кардинально или итеративно, желательно «per feature»)
-) presentation layer (PL) > business logic layer (BLL) > data access layer (DAL) (выделение 3х слоев в серверном приложении это один из важных шагов на пути к качественному коду: single responsibility. Написание качественного DAL невозможно без улучшения схемы СУБД, BLL без DAL, PL без BLL)
Только по коду:
-) code formatter (в идеале должен лежать в git вместе с кодом и подхватыватся IDE)
-) static code analysis (в идеале должен быть интегрирован в IDE. Developer должен думать о качестве кода во время разработки, что позволяет приобрести полезную привычку вместо надоедливых e-mail от CI&CD )
Заметка манагерам:
-) програмеры часто концентрируют все внимание на решении одной задачи (что является прямой противоположностью с менеджерской работой), поэтому им не только лень переключать внимание на что-то другое а еще и тяжелее (уровень концентрации выше), поэтому нужно сделать так чтоб они не тратили свое внимание и концентрацию на что-то другое. Девелоперы лажают с билдами? — Выделите время на автоматизацию процеса. Девелоперы лажают с деплойментом? Упростите процесс, сделайте билды более тонкими а деплойменты более частыми. Девелоперы плохо тестят фичи, баги? Выделите время на написание чего-то что поможет упроситить тестирование как для девелопера так и для qa
У меня ощущение, что автор описывает не свой реальный опыт работы, а фантазии на тему как должно быть. Почему? В одном из постов выше есть правильный вопрос по полномочия «автора». Чтобы все это сделать, и нагнуть остальных сотрудников компании… полномочий хватит только у директора… или владельца (выбить бюджеты но новый софт, более грамотных сотрудников, лишать премий особо упорытых и увольнять особо сопротивляющихся и саботажников… еще много чего)
Автор описывает свой реальный опыт работы. Описанные им фантазии удалось воплотить в жизнь. Менеджмент смотрит на результат, и если он достигается то кредит доверия к разработке растет, а затем может быть направлен на лоббирование управленческих решений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что делать с чужими долгами?