Кирпичики 2

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

SCRUM

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

1. У нас есть бэклог, в который мы стараемся заносить все наши планы и так или иначе его приоритезировать и оценивать.
2. Мы используем 2х недельные итерации.
3. В начале итерации (спринта) разбиваем истории на задачки и вешаем их на доску вида STORY\TASKS\IN PROGRESS\REVIEW\DONE.
4. Каждый день проводим короткие standup'ы.

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

РОЛЬ PRODUCT OWNER'а

В SCRUM-процессе одна из основных ролей это роль Product Owner'а. Без человека, который понимает, что он хочет, и готов инвестировать в это приличное время, работать не получается. К сожалению, в больших продуктовых компаниях  формальным Product Owner'ом является Product Manager, на котором висит несколько проектов и куча бюрократии. Надеяться на то, что он будет детально прорабатывать истории и вникать в детали, не приходится. Хорошо, если он может в общих чертах описать проблему и ожидаемый результат. Опыт использования разного рода аналитиков, проксирующих через себя функции Product Owner'а, в моей практике оказалась не очень удачным.  Для себя я сделал вывод, что менеджер проекта сам должен взять на себя функцию прокси между командой и настоящим product owner'ом и вести продукт опираясь на мнение Product Managment'а, stackholder'ов и команды. Ну это при условии, что ему не все равно, что будет на выходе. :)

Definition of Done

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

Мы применяем достаточно простой чеклист:

1. Фича собрана на CI сервере.
2. Код должен пройти Code Review командой.
3. Код покрыт unit тестами.
4. Все тесты зеленые.
5. Фичу посмотрели члены команды в тестовой лабе.
6. Нет ошибок\варнингов.
7. Нет серьезных замечании со стороны статических анализаторов кода.

Мы живем в реальном мире и, конечно же, часть пунктов этого списка часто нарушается, но при этом всем немного стыдно. :)

BACKLOG

Backlog и его ведение должно быть как можно проще, в противном случае на его поддержку быстро начнут забивать. Актуальный бэклог с простым механизмом оценки и приоритетов может сослужить хорошую службу и позволит не забыть что-то важное. Я использую PivotalTracker - он очень прост, и в этом его прелесть. Легко написать историю, оценить ее, изменить приоритет и поменять состояние.

По бэклогу мы строим burndown chart, который с некой долей вероятности показывает нам насколько далеки мы от релиза. Надо понимать, что backlog постоянно изменяется и дополняется, потому на графике неизбежны всплески и провалы.

SPRINT BURNDOWN CHART

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

CODE REVIEW

Ревью кода членами команды - одна из полезнейших практик. И самое главное в этом даже не поиск ошибок, их как раз выявляют на этом этапе достаточно редко. Главное это то, что в процессе ревью с кодом знакомятся остальные члены команды. Это ведет к расширению области знании как в конкретной технологии, так и в продукте в целом. Мы для ревью кода используем механизм pull request'ов GitHub'а. При этом ревьюятся не отдельные коммиты, а законченная функциональность или существенная ее часть. В этом нам помогает модель gitflow, где на каждую новую фичу создается отдельная ветка. 

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

SOURCE CONTROL

Активная фаза разработки требует наличия системы контроля версии. Я начинал с CVS, прошел SVN, StarTeam, Mercurial и остановился на git. В основу этого выбора легла статья "A successful Git branching model". На мой взгляд, подход, позволяющий независимо разрабатывать фичи продукта и постоянно иметь рабочую ветку, готовую к поставке, повышает качество и снижает напряженность при возникновении непредвиденных трудностей в процессе разработки фичи. Последнее время наша команда придерживается следующих простых правил.

1. Бренч master содержит результаты итерации в виде squash'ных  коммитов (по одному на итерацию), в комментарии которого максимально подробно описывают все, что было сделано по каждой фиче, и по сути являются ChangeLog'ом.
2. Бренч dev - завершенные фичи текущей итерации. Каждый коммит - завершенная фича с комментариями максимально подробно ее описывающими.
3. Бренчи для фичи могут содержать любые коммиты.

В основном я доволен этим подходом. Меня немного огорчает тот факт, что при использовании --squash теряется информация об исходных коммитах, а без использования squash в ветках dev и master появляется огромное число мелких коммитов с малоинформативными сообщениями, что затрудняет понимание истории разработки.

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

Continues Integration

Я уже не могу себе представить, как можно вести разработку, не имея Continues Integration, в задачи которого входит быстрая сборка последней версии, сборка всяких артефактов типа MSI\CD, прогон тестов и установка на тестовые машины. Причем основная причина такой любви к CI это банальная лень. Да, мне совершенно не хочется тратить время на сборку, установку и проверку базовой работоспособности новой версии вручную. Пусть это делает компьютер. За те 3-10 минут, которые  идет процесс сборки, я лучше посмотрю в окно или почитаю почту.

Я прошел длинный путь в сборке проектов, начав с nmake и bat, пройдя  через скрипты на Visual Build, прежде чем пришел к готовым  CI серверам.

Попробовав за 6 лет CruiseControl.NET, Hudson, Jenkins и TeamCity , я остановился именно на последнем. Прежде всего TC поставляется из коробки с кучей полезных вещей, которые к Jenkins надо еще прикручивать, ко всему прочему я полностью укладываюсь в бесплатные рамки TeamCity.

Еще один из аспектов CI серверов, к котором я пришел: их инфраструктура должна быть как можно проще. В идеале, помимо самого агента TeamCity я бы хотел видеть там только Visual Studio (если без нее никак). Чем билдер проще, тем легче добавлять агентов и восстанавливать его после падений.

Спасибо за внимание.

Кирпичики 1

Что такое опыт для программиста или менеджера? Почти в каждой вакансии мы читаем о том, что нужен опыт от N лет. Но из чего состоит этот опыт?

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

Опыт состоит как бы из кирпичиков. И из них можно быстро и качественно построить часть нового проекта. Попробую описать тот опыт и те кирпичики, которые накопились у меня. Сразу оговорюсь, что моя стезя - это продуктовая разработка, а продукты сосредоточены в русле Windows и последнее время используют .NET\C#. Я условно разделю свои "кирпичики" на технические и организационные и начну с общих вопросов.

THE TEAM

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

Мне нравится работать с молодыми и активными ребятами, но в то же время брать совсем вчерашних студентов, мне кажется слишком рискованным. Лично у меня наиболее удачным срезом для поиска новых членов команды являются ребята до 30 лет с опытом работы около 3х лет. У них уже есть какой-то опыт за плечами, и в то же время они еще не устали и не обросли непоколебимыми убеждениями. Они хорошо учатся, с радостью осваивают новое и весьма быстро становятся незаменимыми членами команды. Так же учитывая гибкую природу нашей работы, где важно мнение каждого члена команды, человек должен быть коммуникабелен.

МЕСТО

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

Имея свое помещение, команда может не только проводить спонтанные брейнштормы не мешая окружающим, но и использовать стены для размещения схем, белых досок и scrum-board.  Когда своего помещения нет, люди вынуждены придумывать всякие хитрости. Например, я знаю один open-space офис, где каждая команда каждый день приносит свою SCRUM-доску в переговорку на время стендапа.

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

Так же я не могу себе представить современный IT офис, в котором нет нормального WiFi, который открыт не 24h в сутки и к которому у сотрудников нет возможности подключаться через VPN.

Но, как ни странно, я все еще слышу об офисах, в которых программисты работают с 9 до 18, где на ночь просят выключать компьютеры, опечатывать комнаты и сдавать съемные диски под роспись. Мне удивительно, что так еще кто-то работает. :)

Кстати о времени работы. Опросы коллег показывают, что они оценивают свободный график, возможность поработать из дома и легко перенести отпуск в сумму равную 20% зарплаты.... Лично я вряд ли уже соглашусь работать с 9 до 18 - это адски неудобно. :)

ПЛЮШКИ

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

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

ЖЕЛЕЗО

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

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

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

Умение конфигурировать систему, ставить свой продукт и понимать его требования к системе очень помогают в разработке и отладке.

 Кстати о Hyper-V. Я пришел к нему пройдя VMWare Server и VMWare ESXi и пока не жалею. Лично для меня основным драйвером к переходу с ESXi стал тот факт, что бесплатная версия ESXi не поддерживает автоматизацию запуска\остановки\отката машин и не имеет единой морды для всех серверов разом. Hyper-V же все это прекрасно поддерживает, а учитывая, что в рамках MSDN подписки есть тот же SCVMM, то пользоваться им удобно. Так же мне как давнему пользователю Windows гораздо легче управлять такими серверами через привычные интерфейсы. В плане же быстродействия у меня сложилось ощущение, что Windows машины под управлением Hyper-V работают чуть быстрее и меньше подвержены деградации производительности со временем.

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

Увы, я часто слышу, что разработчики вынуждены поднимать виртуалки прямо у себя на машинах. Особенно это грустно видеть при работе с тяжелыми системами типа SharePoint, Exchange, AD etc, где для полноценной работы надо иметь далеко не одну виртуальную машину.

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

Спасибо за внимание.