День 254. Канбан (I)

Читаю вот такую книгу:

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

Введение

Канбан — одна из методологий гибкий разработки, направленная на возможность завершения работ «точно в срок» и равномерно распределяющая нагрузку между всеми членами команды. Первая канбан-система была реализована на заводе Toyota, на более позднее развитие методологии в значительной мере повлияли работы Элияху Голдратта по теории ограничений. 

Канбан основывается на следующих принципах:

— концентрация на качестве

— снижение количества незавершенных задач

— частые релизы

— баланс требований и пропускной способности

— приоритизация

— борьба с источниками вариативности для улучшения предсказуемости

 

КОНЦЕНТРАЦИЯ НА КАЧЕСТВЕ

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

Тестированием должны заниматься профессиональные тестировщики. Они находят дефекты и предотвращают их попадание в готовый продукт. Если вы будете просить разработчиков писать модульные тесты и автоматизировать их для автоматизированного регрессионного тестирования, то это возымеет серьезный эффект. Казалось бы, если просить разработчиков сначала писать тесты, то это дает психологическое преимущество. Так называемая разработка через тестирование (Test Driven Development, TDD) действительно, судя по всему, помогает: тестовое покрытие выглядит более полным.

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

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

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

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

2. Ревью кода повышает качество 

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

Как у нас в piano: ревью кода — обязательный этап. До тех пор пока код не будет просмотрен другими разработчиками из твоей команды и кем-то из лидов других команд, а в особо критичных случаях system lead engineers (обычно бывает 2-5 ревьюеров) он не отдается на тестирование и не может быть выпущен в прод. Кроме того, некоторые команды используют практику командного ревью — дважды в неделю они садятся всей командой и просматривают код с целью ознакомления смежных модулей.

3. Совместный анализ и проектирование улучшают качество 

Когда команды просят работать вместе над анализом проблем и проектированием решений, качество обычно выше. Я предлагаю командам проводить сессии совместного командного анализа и проектирования.

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

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
Был на сайте вчера в 17:34
Читателей: 17 Опыт: 537.013 Карма: 2.54599
все 18 Мои друзья