11 Jul 2014

Корпоративные стандарты или Мама анархия?

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

Стандарты и Соглашения (СиС) можно разделить например так:

  • СиС по написанию кода

  • СиС по процессу разработки и доставки

  • СиС по оформлению UI (UI приложений и документов)

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

  • Место1 (~60K человек, ~15K приложений). Есть СиС по UI документов и приложений, по возможным фреймворкам и библиотекам, а также по тому как должен выглядеть конечнный бинарник.

  • Место2 (похожие цифры: ~60K человек, ~15K приложений). Есть СиС только по оформлению документов.

  • Место3 (>1K человек, ~20 приложений). Есть СиС по: Оформлению документов, Инструментам и процессу сборки, Процессу проверки артефактов, Версионированию приложений, Версионированию баз данных, Хранению кода, Конфигурированию приложений, Процессу релиза.

Корпоративные СиС - вредители

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

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

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

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

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

Оправдания-неудачники для стандартов

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

Чтоб проще было ротировать людей. Это как правило тоже неудачный довод (хотя по-моему встречается чаще всего). Во-первых, люди часто сами хотят ротироваться чтоб сменить обстановку, попробовать новые подходы, чтоб скучно не было. А тут вы со своей унификацией. Во-вторых, повторюсь, проекты разные и требования к ним тоже могут быть разными. Если вы, к примеру, унифицируете используемые фреймворки и технологии, вы можете сильно усложнить эффективную разработку, например, будут проблемы с производительностью или архитектурой, народу прийдется вставлять костыли только ради унификации.

Оправдания-удачники для стандартов

Интерфейс между командами. Разработку могут поддерживать несколько команд, например, вашими окружениями заведует отдельная DevOps команда, или ваше приложение тестирует отдельная QA команда, или релизят продукт какие-то левые люди, или кто-то для вас настраивает CI, или… Для таких команд вы можете быть не единственными, они могут изменять вам еще с 10ю проектами. И если каждый из этих проектов - уникальный, то такие команды-сервисы будут страдать и работать неэффективно. Т.е. будет разумно если такая команда напишет документ, которому будут следовать все остальные. Как пример, CI команда может потребовать чтоб все работали только с Maven.

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

Уменьшить кол-во поддержки в будущем. Если разные команды владеют одним инструментом (Nexus, JIRA, CI, etc.) так может случиться, что все они по-разному его настраивают и в какой-то момент произойдет коллапс. Чтоб этого не произошло, либо у каждой команды должны быть свои инструменты, либо стоит задуматься над общими соглашениями.

Имеется экспертиза. Допустим есть ИнструментА, которым на очень хорошем уровне владеют N людей. И есть возможность использовать альтернативный ИнструментБ, о нем вчера вахтерша рассказала. Понятно, что любой инструмент не идеален, но учитывая обстоятельства использовать ИнструментБ - значит повышать риски. Да, нам хочется разнообразия. Да, истину постигают в сравнениях. Конечно имеет смысл поэкспериментировать если этому способствует обстановка, вдруг ИнструментБ окажется намного удобней. Но важно не переборщить, один новый инструмент/фреймворк на проект - достаточно, чтоб не забыть о сладостном геморрое. За сим, если у вас есть экспертиза в компании, логично если все команды будут использовать по возможности ИнструментА.

Какими должны быть стандарты

Если уж вы решились стандартизировать что-либо в своей конторе, то вот несколько советов.

Возможности не следовать стандарту быть не должно. Для этого здорово если все проверки автоматизируются. Хотите, чтоб commit message начинался с Issue ID? Сделайте hook который будет проверять формат и отвергать коммит если он не соответствует стандарту. Код должен следовать соглашениям? Настройте проверки, которые будут валить сборку если правила не соблюдены. Если же стандарт существует только на словах/в документе, то всегда будет находиться кто-то, кто ему будет не следовать. Это чревато тем, что народ будет тратить время на разбирательства и пояснения, а делать это не захочется уже на 3ий раз. В какой-то момент начнут забивать все.

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

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

Способы автоматизировать проверки:

  • VCS hooks

  • Maven Enforcer Plugin

  • PMD

  • Доп. проверки на CI сервере

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

Обратная связь от автоматизации должна быть информативной. Т.е. если какое-то правило нарушено и проверка не прошла, сообщение об ошибке должно содержать пояснение, предложения (как исправить ситуацию), возможно ссылки на доп. ресурсы и, на худой конец, контакты людей кто может проконсультировать.

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

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

Гайдлайны - выгодней стандартов. Гайдлайны отличаются от стандартов необязательностью. Вы можете описать какие-то требования к проектам/процессам, но лишь как советы, мол, так будет лучше и проще для всех, следовать им желательно, но не обязательно. Так, например, поступают Atlassian, у которых есть UI гайдлайны. Большинство, стоит заметить, им следуют, даже учитывая что следование этим правилам никто не проверяет.

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

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

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

Read more
08 Jul 2014

Agile vs. Логирование Работы

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

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

  • Кто-то слишком ленивый, ведь логирование отвлекает от прямых обяазанностей ради “какой-то бюрократии”.

  • У кого-то просто нет для этого навыков. Есть люди, которые не умеют этого делать - когда забудут, а когда вовсе не придумают что написать… А чукча, оказывается, не писатель. Всему конечно можно обучиться при желании, но желания нет.

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

Полезность в логировании на самом деле огромная - человек упорядочивает свою работу; понимает насколько он завершил задачу, а сколько еще осталось; дает возможность другим понять и продолжить его труд если вдруг кирпич на голову. В общем-то это важная практика для time management’a.

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

Как Agile начистил рожу логированию

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

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

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

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

Залогированное время помогает находить проблемы. Т.е. если человек потратил слишком много времени на какую-то задачу, то либо он плохо разбирается в этой области (и ему нужно помочь), либо задача поставлена неверно, либо та часть приложения с которой он работает - проблематична. Да, это правда может помочь, но только если эти все проблемы не обсуждаются на ежедневных статус-митингах. Т.е. логирование времени тут заменяет общение с людьми. На самом деле общение с людьми не заменить, это всегда более эффективно, поэтому в данном случае (логирование времени как инструмент для выявления проблем) - это один из симптомов того что команда мало общается. На daily standups проблемы и так бы выявились при правильном подходе.

Если логировать, то как?

Во-первых, главное - это логировать не время, а сделанную работу. Лучшее место для этого - commit message если вы работаете с кодом и/или issue tracker. Так мы прогресс держим близко к тому где все крутится, не нужно далеко ходить чтоб узнать что конкретно сделал тот или иной член команды.

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

По логированию времени (или в общем по time management’у) есть много всего, повторять чужое не хочу, но посоветую все-таки очередной раз попробовать Pomodoro ;) У меня получилось где-то с третьего, и все равно периодически забрасываю.

Подытожим

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

Read more