Записки тимлида

3 правила Kanban

2010-11-28T11:27:00.000-08:00

Перечитывая русскую версию «Kanban vs Scrum: выжимаем максимум» обратил внимание, что главное в Kanban’е — правильный ритм.

И всего 3 правила:

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

Потому что иногда:

ретроспектива отнимает слишком много времени и сил;
планирование бесполезно и бессмысленно;
на демонстрациях нового функционала смех перемешивается с храпом;
sprint backlog устаревает в течение дня;
product owner… хм… его просто нет.

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

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

А что если заказчик хочет всего сразу и, пусть не завтра, а на следующей неделе? Плюс куча мелких недоработок и «технологических долгов», которые не успеваешь сделать, заваленный «текучкой». Уф…

Канбан: Лучше строить, чем ломать. Нужна ретроспектива — включите её в свой ритм. Например, раз в неделю в понедельник, когда команда приходит в себя после длинных выходных. Забывают, что делали на прошлой неделе? Не вопрос, попробуйте ретроспективу в пятницу. И закажите в офис пиццу. Экспериментируйте.

Планируете регулярно? Супер, если планы выполняются. Не выполняются — попробуйте планировать только при появлении новых работ. А может, дело не в частоте планирования, а в его качестве? Попробуйте увеличить оценку каждой задачи в 1,5 раза или добавить время на тестирование и релиз для каждой задачи.

Экспериментируйте — один из главных принципов agile.

Почему не пишут юнит-тесты

2010-07-14T12:25:00.000-07:00

Сейчас почти нет никого, кто не слышал про юнит-тесты. Многие знают, что TDD (test driven development) - это круто, потому что тесты позволяют:

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

Тем не менее тесты пишут не все. А если и пишут, то редко запускают. Бывает, что и часто запускают, но небольшое покрытие кода.

Анализ ситуации на примере нескольких проектов, показал, что есть несколько причин такого попустительства:

лень;
незнание;
недоверие;
бесполезность существующих тестов;
тесты тяжело поддерживать;
тесты долго выполняются.

Лень. Она же отсутствие свободного времени. Можно по-разному бороться с этим явлением. Например, одному талантливому, но жутко занятому программисту X повесили рядом с рабочим местом плакат: "X, когда уже напишешь юнит-тесты!". Удивительно, но через некоторое время это повысило покрытие кода с 0 до 20%. Но, как правило, лень скрывает другие, более глубокие причины.

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

Недоверие. Признаюсь, N лет назад, когда впервые услышал об автоматическом тестировании, я не поверил, что оно работает. И даже те, кто несколько лет пишут автотесты, не всегда верят в такую практику как Test First (вначале тесты, потом код). Другие искренне считают, что их код и так идеальный, и юнит-тесты - лишняя трата времени. Приходится убеждать и напоминать, что "Совершенный код" - всего лишь название книги.

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

Тесты тяжело поддерживать. Как правило, это связано с тем, что не придерживаются практики Test First, которая заключается и в том, что после появления ошибки вначале её нужно воспроизвести в тестах, а потом чинить. Либо опять же много интеграционных тестов. Может быть вызвано и тем, что не используются вспомогательные тестовые фреймворки (для .Net самые распространённые Rhino Mocks и Moq).

Долго выполняются. А значит - редко запускаются. И в итоге запускаются не всеми. Что ведет к тому, что тесты становятся бесполезными. Долго - это больше минуты. Здесь обычно все просто. Юнит-тесты не должны обращаться к базе, файлам или другим сетевым ресурсам. Однако интеграцию тоже нужно тестировать. Хороший вариант известен давно: разнести автотесты на группы - интеграционные и юнит-тесты. Юнит-тесты запускать при коммите или при каждой автоматической сборке. Интеграционные - при ночном билде.

Ну и в завершение - список анти-паттернов юнит-тестирования.

Программисты и кодировщики

2010-07-08T14:51:00.000-07:00

По роду работы приходится периодически проводить собеседования. Первое, что стараюсь выяснить о кандидате: кто передо мной - программист или кодировщик?

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

Или, перефразируя один фильм, кодировщик делает то, что его просят, а программист - что нужно сделать на самом деле.

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

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

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

Вот несколько градаций уровня "мастерства":

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

Стандарты кодирования, C#

2010-02-06T01:52:00.000-08:00

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

Примеры стандартов для С#
Наборов таких стандартов очень много — достаточно хорошие есть на RSDN, другие примеры можно посмотреть здесь или здесь.

Внедрение
Хорошие стандарты содержат только общие рекомендации и в каждой компании или даже в каждом проекте дорабатываются и дополняются в зависимости от специфики.

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

Ситуацию можно изменить как минимум 2-мя способами:

Регулярные code review («инспекции кода») — в этом случае кто-то должен взять ответственность на себя и постоянно «держать руку на пульсе». Потому что в глазах программиста разработка обычно выглядит так.
Автоматическая проверка с помощью статических анализаторов кода.

Конечно, лучше всего сочетать эти 2 подхода.

Проверка стандартов кодирования C#
Для C# существует достаточно много инструментов:

FxCop — встроенный в Visual Studio анализатор кода на основе правил от Microsoft. Из недостатков — полная невозможность хоть какой-то настройки. Использовать as is сложно — потому что некоторые правила Microsoft вызывают недоумение. Кроме того, внедрить сразу все стандарты в уже действующий момент потребует много времени. Которого обычно не хватает.
Resharper — пожалуй, самый популярный статический анализатор кода. Уже не очень понимаю, как без него вообще можно писать на C# :) К сожалению, сам по себе никак не интегрирован со средствами компиляции.
StyleCop — ещё один бесплатный продукт Microsoft. Вот он-то уже позволяет проверять почти полноценно — настройка интеграции с MSBuild описана здесь. Есть и недостатки — правила можно настраивать, но, к сожалению, только отключать. Хотя для почти полного счастья есть плагин, который позволяет интегрировать Resharper и StyleCop.
CodeIt.Right — этот инструмент позволяет почти все. Но он платный, поэтому попробовать на практике пока не довелось.

Впрочем, до многих других бесплатных и платных инструментов руки тоже пока не дошли.

Опыт использования
Одно из правил lean development («бережливой разработки») — в случае наличия проблем останавливать процесс. Это необходимо, чтобы разобраться с ситуацией и избежать повторения ошибок в будущем. Именно поэтому я за те инструменты, которые позволяют проверять стандарты автоматически — на этапе компиляции. А ещё лучше — на этапе написания кода :)

Сейчас я использую связку Resharper при кодировании + StyleCop при компиляции. Пока хватает, но хотелось бы возможности создавать и настраивать свои правила. К примеру, по нашим стандартам необходимо, чтобы имя private («закрытого») поля в классе начиналось с символа «_» (подчеркивания), а по стандартом Microsoft это запрещено.

При первой проверке проекта (в терминах Visual Studio), который существует уже полтора года (Resharper использовался с самого начала), выдалось большее 1000 предупреждений. Исправить их сразу было нереально, поэтому после вдумчивого анализа часть правил была отключена. Число предупреждений снизилось до 600. С этим уже можно было работать — пару вечеров, и проект соответствует стандартам.

После этого была настроена проверка стандартов при компиляции. И настала очередь других проектов :)

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

Стандарты и шаблоны, чеклист

2010-01-30T10:28:00.000-08:00

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

составление ТЗ;
оценка объёма работ и планирование;
шаблоны проектирования и драйверы разработки;
стандарты кодирования (автоматическая проверка с помощью статических анализаторов кода);
контроль хода работ – taskboard (доска задач), планы в MS Project или учет задач в JIRA;
тестирование – ручное и автоматическое (функциональное, модульное, динамические анализаторы кода);
обработка ошибок и запросов от пользователей или заказчика;
сборка проекта и формирование релиза – компоненты, настройки системы и скрипты для обновления БД;
deployment (развертывание системы на «рабочих» серверах);
мониторинг состояния системы – блокировки в БД, загрузка процессора, оповещения об ошибках и т.п.;

В идеальном проекте все эти операции стандартизированы. Это означает, что не нужно каждый раз «придумывать велосипед» – всегда можно воспользоваться уже существующим опытом. Но стандарты не стоят на месте – меняется ситуация, меняются подходы.

Проект «с нуля» – хороший шанс улучшить свои методики, кардинально их пересмотрев.

Желательно чтобы все шаблоны были описаны в базе знаний и доступны «по паре кликов». Но без излишнего фанатизма: если описание большое и сложное – пользоваться им никто не будет. Иногда достаточно просто ссылки на билдсервер или багтрекер – где можно посмотреть все настройки.

Лучший пример паттернов – ссылки на репозиторий с реально работающим кодом.

Манифест гибкой разработки

2009-10-29T15:06:00.000-07:00

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

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

Таким образом, хотя и существует ценность в понятиях, стоящих в правой части этих сравнений, мы ценим понятия, стоящие в левой части, больше. "

Полностью про манифест и 12 принципов agile прочитать можно здесь (перевод от авторов agileguru.org).

Драйверы разработки, agile

2009-10-25T14:07:00.000-07:00

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

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

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

Таких драйверов может быть много, они как и обычные программные драйверы могут конфликтовать, а могут использовать одновременно. Ниже описаны самые распространенные в мире agile, которые отлично сочетаются друг с другом - DDD, TDD и BDD.

Domain Driven Design (DDD)
Подход к проектированию, которые говорит как и в каком порядке нужно проектировать структуру класов приложения. Основная идея - что проектирование должно базироваться на объектах, определяющую предметную область (domain), которые содержат в себе не только свойства, но и бизнес-логику. А доступ к данным и отображение - вещи второстепенные.

Шаблоны описаны здесь, отлично прокомментировано здесь.

Test Driven Development (TDD)
Разработка, управляемая тестирования. Вначале пишем юнит-тесты (или модульные тесты), потом реализацию кода для того, чтобы эти тесты проходили.

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

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

Информация есть здесь, здесь и здесь.

Test Plan Driven Development (TPDD)
Разработка, управляемая историями тестирования. Драйвер для улучшения взаимодействия с QA-специалистами. Тест-планы служат исходной информацией о задаче для разработчика. Первая версия пишется сразу после планирования итерации, затем тест-планы уточняются разработчиками перед передачей задачи в тестирование. Если изменения в требованиях - то они сразу вносятся в тест-планы.

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

Автоматическая сборка проекта

2009-10-22T08:28:00.000-07:00

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

Лучшие на мой взгляд сервера интеграции:

TeamCity (поддерживает Java и .Net)
CruiseControl (реализация на Java, порты для .Net и Ruby)
Maven (только Java)

Сборка проекта может запуститься по:

коммиту - факту попадания изменения в репозиторий;
расписанию - наиболее известны т.н. "ночные сборки";
нажатию на кнопку "Поехали" - если нужно сделать срочно.

Не все билды одинаково полезны, поэтому в проекте рекомендуется иметь несколько типов билдов:

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

Ретроспектива

2009-10-22T01:02:00.000-07:00

Ретроспектива – один из видов командной активности в гибких методологиях (XP, Scrum).

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

Один из алгоритмов проведения выглядит так:

1) Вся команда собирается в переговорке - реальной или виртуальной. Вся - значит вся. Это командная практика. Если собрать команду не получается - см. ограничение практики ниже.

2) Если не первая ретроспектива, фиксируем без оценок и выявления причин.:

какие улучшения удалось внедрить;
какие не удалось;
что утратили.

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

4) Фиксируем то, что не понравилось (-).

5) Генерируем новые идеи по улучшениям - технические и как улучшить процесс, чтобы добиваться лучшего результата. (!).

6) Голосуем за пункты из 3-5. Каждый имеет несколько пунктов голоса на (+), (-) и (!).
Рекомендуется по 3, но все зависит от размеров команды и количества оцениваемых пунктов.

7) Самый интересный момент. Определяем, что будем улучшать на следующем отрезке:

то, что особенно понравилось (по результатам голосования) - оставляем, обязательно это повторим;
то, что особенно не понравилось - решаем, что с этим делать;
решаем, как будем внедрять особенно понравившиеся новые идеи.

8) Фиксируем все одобренные и выбранные командой улучшения. Можно их делить на процессные и технические, или как-то ещё. А можно просто хранить одним списком.

Ограничения практики: здесь.
Доп. инфа: здесь.

Что почитать прямо сейчас

2009-10-21T00:00:00.000-07:00

Рекомендуемые книги

Фредерик Брукс «Мифический человеко-месяц», 1975 г.
Кент Бэк «Экстремальное программирование», 2002 г.
Кент Бэк, Мартин Фаулер «Экстремальное программирование. Планирование», 2003 г. В инете не нашел, можно только купить.
Эдвард Йордон «Путь Камикадзе», 2005 г.
Мартин Фаулер «Рефакторинг», 2005 г.
Хенрик Книберг «Scrum и XP: Записки с передовой». Скачать можно здесь.
Хенрик Книберг и Маттиас Скарин «Kanban vs Scrum: выжимаем максимум». Скачать можно здесь.
Бибичев Андрей «Практика внедения Scrum: трудности и пути их преодоления». Скачать можно здесь.

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

Статьи

Статьи на AgileRussia.
Один из лучших авторов статей по философии программирования — Джоэл Спольски.
Статьи по проектированию интерфейсов и usability на fresh.gui.ru.
Про непрерывную интеграцию.
Манифест гибкой разработки на agileguru.org.

Книга "SCRUM и XP: заметки с передовой"

2009-10-11T02:00:00.000-07:00

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

Task Board или как понять: что происходит?

2009-10-03T00:45:00.000-07:00

Люблю наглядность и хорошие статьи. Например вот эту от Никиты Филиппова.

"Одним из лучших способов достижения прозрачности и визуализации процесса разработки - эффективная работа через Task Board.

Какие задачи выполняет Task Board:

Отражает список задач, поставленных на недельную итерацию (Sprint), по которым Product Owner может оценивать успехи и корректировать приоритеты.
Позволяет оперативно взаимодействовать с командой и вовремя прояснять спорные моменты
Позволяет сделать прозрачным процесс для заказчика:

"Что то вы медленно все делаете... Вы вообще что-нибудь делаете?" "А где мои проекты?" На эти и многие другие вопросы помогает ответить хорошо организованный Task Board.

Итак, от теории к практике и в обратном порядке."

Продолжение на agilerussia.ru...

Кто такой тимлид?

2009-10-02T14:47:00.000-07:00

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

Итак, тимлид — это полу-менеджер, полу-программист, причем обе составляющих достаточно важны. Конкретные пропорции этих обязанностей могут и должны варьироваться, в зависимости от:
1) Компетенции тимлидов.
2) Используемого в организации процесса.
3) Ситуации и требований.
Главное — чтобы он оставался программистом, и не превратился в менеджера. Примерный список возможных обязанностей и ответственности тим-лида:

1) Тимлид несет личную ответственность за результат работы всей группы, за процесс разработки в группе, и за людей в группе.
2) Тимлид отвечает за назначения задач внутри группы, принимая во внимание личные особенности людей, их компетенции, и их обучение.
3) Тимлид отвечает за порядок выполнения задач и их перебалансировку, принимая во внимание риски и приоритеты, а также технические риски, а также текущую ситуацию.
6) Тимлид отвечает за план работы _своего_ подразделения, который разрабатывает сам в рамках полученных директив, а также за соответствие этого плана директивам и целям верхнего уровня. Также, тимлид проводит еженедельный контроль продвижения по этому плану.
4) Тимлид обязан оказать своевременную помощь своим сотрудникам, лично, или обеспечив ее снаружи.
5) Тимлид участвует в планировании работ подразделения — лично. А именно, он дает свой вклад в разработку общих больших планов, анализ рисков, и расстановку приоритетов.
6) Тимлид отчитывается о прогрессе по плану на уровне подразделения.
7) Тимлид может частично делегировать свои обязанности членам своей команды, но не ответственность.

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

Взято с http://www.rsdn.ru/forum/management/2972662.flat.aspx