Как стать автором
Обновить

Прагматический Процесс Разработки в «не-книжных» условиях

Время на прочтение 4 мин
Количество просмотров 1.8K
Доброго времени суток.

Хочу поделиться некоторыми идеями которые помогают мне в Святой Войне с Хаосом в процессе разработки ПО. Для определенности картины добавлю несколько деталей: я — менеджер проектов, фирма средних размеров (~40 мозгов) занимается оффшорным программированием, команда смешанная (15% сеньоры, 35% девелоперы, 35 джуниоры, 15% стажеры, причем есть еще деление по специализации — разработка, качество, инфраструктура).

Процесс


Источников создания хаоса более чем достаточно — длинная цепь связи с заказчиком, неоднородная и в общем, молодая команда, «славянский менталитет» ( эксцентричное творчество и частые медитации ;) ), проблемы коммуникаций, политические игры сейлс-людей (Sales — те кто нас «продают») и т.д.

В хаосе работать неправильно. Он является первоисточником задержек, потерь качества, несогласованности скопов с заказчиком. Нужно строить Процесс или Жизненный Цикл разработки ПО. Книг об этом предмете очень много, и они отнюдь не бесполезны, но прямого выхода на *наш* случай я к сожалению не нашел. Повторюсь, это *мой* опыт. Вполне возможно что кому-то из Вас, друзья мои, и удалось по книге внедрить, скажем, Скрам. Мне, к сожалению, не удалось. Чем больше условностей требовал процесс тем быстрее он уходил в долину Неприжившихся Процессов.

Метод проб и ошибок привел к некоторому прагматическому подходу, который работает (стучу по дереву). Процесс выглядит вот так:

Это итеративный Agile процесс. Требования представлены в виде коротких User Stories. Спецификация — в виде Test Cases. Здесь мы взяли многое от Скрам. У нас есть Product Owner, он как правило, американец, его задача — плотно общаться с заказчиком и сформировать консистентное представление о проекте у себя в голове, к его портрету можно добавить также то что он был или является программистом и способен оценивать техническую сторону проблемы. В начале итерации митингуем, обсуждаем задачи которые идут на итерацию. Как правило в этот момент у нас есть список User Stories (имена задач). В дальнейшем QA инженер (инженер по качеству) пишет короткие спецификации на каждую историю в формате Test Cases.

Первая итерация — архитектурная, во время которой строятся слои будущей системы, пишутся прототипы темных мест. Все итерации начиная со второй — функциональные. Длина итерации 3-4 недели.

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

Для мониторинга отдельной итерации используются беклоги (backlog).

Вот так выглядит план функциональной итерации с 2-мя бэклогами:

image

Первый бэклог традиционно содержит User Stories и согласованные с заказчиком Change Requests (или в общем, по-простому, фичи), второй — баги, относящиеся к данной итерации. Первый бэклог мы называем Спринт, как в Скраме.

Причем прогресс выполнения фичи или бага получается интересным путем. Есть одна проблема — программисты не любят писать отчеты. Также иногда много времени уходит на понимание того, что пора кому-то задать вопрос. Есть современный подход который позволяет отлично справляться с такими проблемами. Это микроблог. Примером микроблога является Twitter. Представьте себе онлайн инструмент в котором программист может зайти в свою задачу и написать короткий пост вроде: «С задачей я немного застрял, придется поменять тип связи между двумя сущностями в модели: User и Training. А еще в кулере вода закончилась. Полный бардак. Процент выполнения — 47». Дальше этот онлайн инструмент отобразит введенное программистом последнее значение прогресса задачи на общем Гантте итерации.

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

В качестве упомянутого онлайн инструмента мы используем свою разработку. Однако чтобы не быть обвиненном в спаме, в этом посте ссылку я не буду указывать. Наверное я опишу его позже в блоге «я пиарюсь». Однако, для работы с Ганттом и микроблогом можно использовать другой популярный инструмент — dotProject. Мы использовали функциональность логов под задачами в этом инструменте некоторое время.

Обрубаем хвосты задачам или где заканчивается фича.


У нас долго не получалось сдавать фазы и проекты в срок в приемлемом качестве. Основной проблемой были «хвосты» у функциональных задач в виде нудного списка багов.

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

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

На самом деле проблема заключалась в разном понимании ситуации «фича сделана» у программистов и QA-щиков. Из-за коротких итераций тестирование проводилось уже после интеграции всех недоделанных фич на последней неделе. И кошмар наступал. Это был праздник Хаоса.

Как проблема решилась? Мы ввели правило — 100% по своей задаче программист ставить не имел право. Его последний микропост должен был выглядеть примерно так: «я все сделал. Слышите? ВСЕ! Прогресс — 99%». Дальше шел микропост тим лида или менеджера: «ай молодец! Проверяет Женя. Прогресс — 99%». Женя — это QA-щик. Он в большинстве случаев находил 1-2 бага имплементации, 1-2 потерянных участков из Test Case, 1-2 юзабилити огреха и писал под задачей такой пост: «есть баги [тут идет их список со ссылками на баг-трекер]. Прогресс — 60%». Дальше идет доработка задачи…

Эти 100% — 60% = 40% и есть хвост задачи. Описанным подходом мы научились его обрубать.

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

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

Удачи.
Теги:
Хабы:
+11
Комментарии 14
Комментарии Комментарии 14

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн