DEVPROM

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

Описание

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

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

Описание

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

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

Описание

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

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

Метод MoSCoW получил свое название от акронима, образованного следующими классификациями приоритета: Must have (Должен иметь), Should have (Следовало бы иметь), Could have (Может иметь) и Would like (Хотелось бы иметь). Буква «о» делает акроним произносимым.

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

Описание

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

Анализ Кано раскладывает характеристики продукции по двум осям:

• степень, в которой функция реализована в продукте и

• уровень удовлетворенности клиентов.

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

• обязательные (threshold),

• ожидаемые (performance) и

• приводящие к восхищению (excitement).

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

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

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

• увеличение или сохранение доходов,

• сокращение или устранение расходов,

• улучшение уровня обслуживания,

• соблюдение нормативных и социальных обязательств,

• реализация маркетинговой стратегии и

• повышение квалификации персонала.

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

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

Описание

Баклог продукта, изначально пришедший из Scrum, используется во многих методологиях Agile и вводится в начале проекта. Баклог или журнал незавершенной работы – это постоянно меняющийся документ, который развивается во время выполнения проекта по мере накопления знаний о продукте и клиентах. Владелец продукта (Product Owner) отвечает за упорядочение элементов баклога на основе знаний и пользе бизнесу, важности фич или других соответствующих критериев. При управлении баклогом, элементы должны быть упорядочены так, чтобы наиболее важные элементы находились в верхней части списка и упорядочены по убыванию приоритета. В XP (eXtreme Programming) незавершенная работа по функциональности может управляться как журнал историй пользователя. Бизнес-аналитик может выступать в качестве владельца продукта или помогать ему.

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

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

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

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

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

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

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

Storyboarding служит

• для выявления, проработки, организации и проверки требований,

• для общения с разработчиками по поводу того, что им предстоит разработать,

• чтобы показать разные варианты предлагаемого решения и

• как входная информация для тестов.

Описание

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

При использовании для описания взаимодействия с системой, раскадровка показывает, как будут выглядеть экраны, и как они будут сменяться один другим. При использовании для описания бизнес организации, раскадровка показывает взаимодействие с бизнес-процессами, такими как бэкофис.

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

Описание

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

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

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

Описание

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

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

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

Истории пользователя могут быть использованы:

• для фиксации и установления приоритета потребностей пользователя,

• в качестве основы для оценки и планирования выпуска продукта,

• в качестве основы для создания приемочных тестов пользователя,

• в качестве показателя для измерения ценности релиза,

• в качестве единицы для отслеживания (трассировки) соответствующих требований,

• в качестве основы для проведения дополнительного анализа,

• в качестве единицы управления проектами и отчетности.

Описание

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

Усилиями членов IIBA и экспертами сообщества Agile был разработан черновик The Agile Extension of the BABOK, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.

Со своей стороны мы хотим привлечь пользователей DEVPROM, участников команд, следующих принципам Agile, к активному обсуждению этих практик, их использованию и адаптации под встречающиеся задачи и условия.

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

Story Decomposition

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

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

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

Оглядываясь назад, а смогли ли они каким-то образом повлиять на индустрию? InfoWorld собрал несколько интересных высказываний от подвижников Agile, участвовавших в этом с самого начала. Вот мнение тех людей, которые стояли у истоков, по поводу Agile 10 лет спустя:

• “I’d say we transformed the industry.” – http://c2.com/~ward/">Ward Cunningham

• “It’s had a pretty significant effect on the industry.” – Scott Ambler

• “I don’t have a sound-bite answer for you on that.” – Kent Beck

• “You still have to do it [Agile] well…. You can do Agile poorly.” – Ian McLeod

• “Sometimes, developers can call practices “Agile” when they are really not.” – Damon Poole

Небезызвестная компания Atalassian проводит примечательный конкурс: The Ultimate Wallboard Contest. Все желающие могут опубликовать фотографию или видеоролик, на которых изображена работа информационного радиатора в их проектах.

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

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

В мире Agile основным элементом требований принято считать истории пользователей (user stories, пожелания).

В классическом Скрам, (таком, о котором говорят его создатели), не найти ни спецификаций, ни описания вариантов использования (use cases), ни, тем более, документов с пугающим словом ТЗ.

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

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

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

• "Можно задать новый тег или выбрать существующий из списка"

• "На сообщение может быть задано несколько тегов"

• "Теги сообщений образуют облако тегов"

• "Облако тегов доступно на любой странице блога".

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

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

Но существует еще один термин, гораздо менее распространенный у нас - Epic (эпик). Что же это такое, зачем оно и чем отличается от историй пользователей?

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

Получаем примерно такую структуру требований:

1. персона (например, автор блога)

2. активность в системе (публикация сообщения)

3. действие (ввести текст сообщения и опубликовать его; отметить сообщение тегами; сохранить черновик сообщения)

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

"Как автор блога, я должен иметь возможность публиковать свои сообщения в блоге, чтобы заинтересовывать читателей и формировать лояльное сообщество вокруг моего блога" - это пример epic'а.

Давайте посмотрим на различия в приведенных примерах истории пользователя и эпика:

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

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

Mike Cohn, наиболее влиятельный в Agile сообществе гуру историй пользователей, предлагает описывать эпики по тому же шаблону, что и истории пользователей, как в приведенном выше примере).

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

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

Используя Devprom в своих проектах, мы записываем Активности в системе (epic) в качестве Функций, в привязке к которым создаются Пожелания (истории пользователей). При этом Персоны - это просто теги ("Блоггер Иванов"), по которым легко можно получить срез всей требуемой этой персоне функциональности.

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

В этой статье я хочу показать каким образом можно быстро и практически бесплатно построить инфраструктуру автоматизированного тестирования вашего Web-приложения. В качестве объекта тестирования возьмем некоторое Web-приложение, которое может быть установлено на различные платформы, поддерживает несколько версий PHP, должно работать с использованием основных браузеров, может устанавливаться различными способами (через инсталлятор, путем подкладывания скриптов самого приложения и т.п.)

С целью максимально снизить стоимость организации и поддержки подобной инфраструктуры тестирования будут использоваться все возможные способы автоматизации: подготовка окружения, развертывание приложения, тестирование и сведение результатов в единый отчет. Хочется получить следующее: нажали одну кнопку (или вообще ничего не нажимали, а оно запустилось по расписанию) и через некоторое время получили отчеты о прохождении тестов на всех нужных окружениях и вариантах развертывания. Рассмотрим подробнее все шаги построения собственной тестовой лаборатории.

Подготовка окружений

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

VMWare предлагает бесплатный продукт для одновременного запуска нескольких виртуальных машин на тестовом сервере. Сами виртуальные машины можно создавать при помощи инструмента VMWare Converter. Теперь на тестовом сервере один раз настраиваем все возможные варианты окружений в которых будет тестироваться наше приложение, например, используем различные ОС, обеспечиваем тестирование через IE6 и IE7 (без необходимости деинсталлировать IE браузер, установленный по умолчанию).

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

Развертывание приложения

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

При помощи pstools мы организуем:

• копирование инсталлятора на виртуальную машину и установку приложения в тихом режиме

• копирования архива с приложением и его распаковку, в случае, если установка приложения допускает ручное развертывание

• копирование исходных кодов тестов и их компиляцию на виртуальной машине для тестирования приложения через браузеры IE6 и IE7

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

Все варианты сценариев развертывания содержатся в .bat файлах или исполняемых скриптах (jscript, vbscript).

Тестирование приложения

Для тестирования Web-приложения будем использовать связку NUnit и Watin, которые также распространяются бесплатно и реализуют отличную инфраструктуру для автоматизированного тестирования.

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

Запускается тестирование, прокликивающее приложение.

Сведение результатов

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

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

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

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

Управление конфигурациями

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

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

Подключение вашей инфраструктуры тестирования

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

Пример реализации такой интеграции можно посмотреть в исходном коде плагина NUnit.TestReport.AddIn, который умещается на трех экранах монитора.

Немного информации о прошедшей в начале июня в Екатеринбурге региональной конференции AgileDays, посвещенной гибкой разработке программного обеспечения и организованной нашими партнерами, компанией ScrumTrek.

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

4 июня AgileDays отправился в путешествие на Урал, а точнее в Екатеринбург!

Наш партнер, компания ScrumTrek, организующая отличные тренинги по Agile практикам, выпустила свой Agile-чеклист, по которому любой желающий может проверить: соответствует ли их процесс настоящему Scrum.

Итак, Agile-чеклист, подготовленный ScrumTrek, это

"Краткое, но исчерпывающее описание основных практик Scrum и Agile в виде чеклиста. Вся информация о Scrum в засушенном виде, без воды и занудных длиннот. Содержит описание основных процессных практик (daily standup, burndown), но не технических (TDD, nightly builds)."

Поскольку мы разработали инструмент, автоматизирующий процесс разработки ПО с использованием гибких методологий, то решили проверить, а "правильный" ли процесс заложен в систему управления проектами DEVPROM?

Команда (team)

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

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

Конечно, индустрия программного обеспечения, не обошла этот момент стороной. Созданы формальные методики и инструментарий для верификации алгоритмов и программного кода, однако, стоимость владения и использования таких методик и инструментов значительна, так что большей части разработчиков настольных приложений, сервисов и приложений уровня предприятия, такие расходы не по карману, просто пользователи не смогут купить такие продукты. Причем, уровень качества подобных приложений находится на приемлемом уровне. Формальная верификация - удел медицинского ПО, приложений, критически важных для жизни, безопасности и т.п. Существуют промежуточные решения, например, DBC (design by contract, programming by contract), интегрирующие возможности формализации контрактов непосредственно в язык программирования, однако, в промышленном использовании подобные решения применяются редко.

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

Модульное тестирование

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

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

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

Приемочное тестирование

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

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

Интеграционное тестирование

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

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

Необходимые условия автоматизации тестирования

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

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

• Архитектура приложения должна быть модульной или разделенной по слоям, с тем, чтобы каждый слой мог быть протестирован независимо от остальных. Например, распространенная архитектура MVC (model view controller) - хорошо тестируема на каждом уровне и вы можете применить все современные практики по автоматизации тестирования.

• Тестами должны быть покрыты практически все участки вашего приложения. В этом вам поможет методика test driven development (TDD). Суть методики заключается в том, что тесты (модульные или приемочные) создаются перед тем, как реализуется логика приложения. Таким образом, заранее продумывается контракт, интерфейсы со стороны внешнего пользователя (например, другой программы или класса).

Рекомендую руководителям проектов, использующим Agile практики и методологии, и архитекторам приложений посмотреть на выступление Ребеки Парсонс (CTO at ThougthWorks) и Мартина Фаулера.

Обсуждаемая проблема заключается в том, что Agile - это эффективно, полезно, да и просто модно :) Но Agile базируется на некоторых обязательных приципах, ориентированных на сильные и самоорганизованные команды: "Individuals and interactions over processes and tools". С другой стороны в организационной структуре крупных и даже средних компаний всегда присутствует роль архитектора (иногда подменяемая позицией технического директора), обязанностями которого являются:

• Достижение целей компании за счет снижения расходов на изобретение велосипедов, то есть следование принципам повторного использования кода, компонентов и решений.

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

• Соблюдение корпоративных правил (стиля) при разработке систем, реализация "правильных" решений, своевременных и технологически современных решений.

Зачастую получается так, что есть несколько выделенных архитекторов (уровня предприятия, процессов, данных, интеграционных и т.п.), на которые приходится десяток команд по 10 - 20 человек в каждой. Вопрос состоит в том, как архитекторам стать вовлеченными во все эти проекты, в условиях ограниченного рабочего дня, как заставлять команду следовать правилам в организации кода, если сразу же возникает масса конфликтов с командами, работающими в рамках Agile. Как учесть нефункциональные требования, о которых заказчик может и не задумываться?

Спикеры дают следующие ответы на эти вопросы:

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

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

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

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

В коллекции наглядных картинок о Scrum пополнение - Visual Studio ALM Rangers Projects Scrum Guide, результат командной работы VSTS Rangers.

Единственное, на мой взгляд, для объяснения Scrum "с нуля" может показаться перегруженной для восприятия.

Ну и еженедельные скрамы, вместо ежедневных, немного настораживают :)

Зато явно прописано, что нужно иметь Definition of Done и Sprint Goal - об этом часто забывают.

Но все равно, лучшая по своей наглядности картинка у Mike Cohn:

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

Отличительной особенностью конференции стал упор на практический опыт и реальное применение гибких методологий. Программа была разделена на 3 трека – experience report, technical excellence, main stage. Особенный интерес у участников вызвали доклады представителей крупных компаний. Евгений Сорокин и Антон Бевзюк из компании Intel рассказали о том, как эволюционировали их подходы за более чем семь лет применения Agile в проектах компании. Дмитрий Никонов рассказал об опыте использования Scrum в компании Microsoft и Amazon, Артем Марченко – о подходах к планированию в компании Nokia.

Серия докладов была посвящена одной из самых актуальных проблем – масштабированию Agile на большие команды. По забавному совпадению доклады на эту тему делали три Дмитрия: Лапыгин (IBM), Лобасев (DEVPROM) и Викторов (F-Secure).

Отдельный трек был посвящен техническим докладам, в рамках которого Тимур Маркунин (IBM) и Евгений Злобин (Microsoft) провели «соревнование» платформ IBM Rational Jazz и MS Team System. Соревнование проходило в непринужденной обстановке, которое вызвало бурное обсуждение.

В рамках конференции прошел тренинг-сертификация "Scrum Master Certification". Участники тренинга стали сертифицированными скрам-мастерами. Тренинг провел Senior Coach компании Danube, сертифицированный Scrum-тренер Dan Rawsthorne.

Несколько отзывов от участников и докладчиков AgileDays'09:

«Весьма интересными и полезными оказались доклады представителей различных компаний о том, как в их компаниях внедрялся Scrum, и на какие грабли они наступали в процессе внедрения, - рассказал Евгений Ларчик, Ланит-Терком. - Понравилась свободная атмосфера на конференции, возможность в любой момент подойти к докладчику, чье выступление меня заинтересовало, и обсудить вопросы, которые остались после его доклада. С удовольствием буду участвовать в таких мероприятиях и впредь».

«Уникальное по формату и содержанию мероприятие, аналогов которому в России до этого не было, а лет 5 назад подобного рода конференция была невозможна (ИТ-сообщество было не готово к "промышленному" использованию гибких методологий). Уже некоторые подсмотренные практики и рекомендации используем в своей работе» Олег Клименко, КазСофт.

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

"Мы успешно внедрили Agile, а точнее одну из его практик - Scrum в стандартной по размеру команде разработчиков из 5-7 человек, и нам было интересно посмотреть на опыт более крупных коллег по ИТ-рынку, таких как Intel и IBM, чтобы узнать заранее о болезнях роста. В целом обмен опытом состоялся, конференция прошла на достойном уровне, подтвердив право называться Всероссийской / Международной (нужное оставить). Несомненно, будем приезжать еще" Денис Ермаков, Веблайм

«Очень радует, что у нас проводятся такие мероприятия, но еще более - что они собирают такое количество людей. Интерес к гибой разработке растет с каждым годом, здесь в этом можно убедиться наглядно. И, в этом же ключе, трудно переоценить значение практических докладов о внедрении и использовании Agile, которым на конференции выделена целая секция» Максим Гапонов, Авто ру

С фотографиями, презентациями и видео можно ознакомиться на сайте конференции www.agiledays.ru

Классическими индикаторами прогресса в разработке ПО являются resource usage (утилизация ресурсов) и сравнение фактически выполненного объема работ к плановому. Индикаторы полезные, но достаточно требовательные и сложные в восприятии, да и могут применяться только если вы используете классический инструмент планирования, с применением диаграмм Ганта.

В Agile проектах применяются более простые и наглядные индикаторы состояния процесса разработки, например, доска задач или диаграмма "сжигания", то есть burndown chart. В этом посте хочу объяснить как использовать этот график для оценки текущего статуса проекта и анализа проблем.

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

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

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

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

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

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

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

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

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

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

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

9 декабря на AgileDays мы будем рассказывать про то, как внедрить Agile на уровне компании, в нескольких (десятках?) проектов, учитывая потребности и интересы всех заинтересованных в процессе и разрабатываемом продукте сторон.

О докладе:

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

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

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

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

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

И, конечно же, подробности о самой конференции:

Большая часть конференции будет посвящена докладам тех, кто реально практикует Agile. На конференции не будет голых Success Stories - в любой, даже самой крутой истории успеха, есть немало печальных страниц о проблемах, трудностях и о том, как команды с ними справлялись. Им будет уделено особое внимание.

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

Специальная группа докладов будет посвящена реальному использованию суперсовременных подходов к разработке. Это те самые страшные аббревиатуры, о которых интересно читать, но совершенно непонятно, как применять на практике, вроде DDD, BDD, FDD и TDD.

В рамках конференции пройдет тренинг-сертификация "Scrum Master Certification". Участники тренинга смогут стать сертифицированными скрам-мастерами . Тренинг проведет Senior Coach компании Danube, сертифицированный Scrum-тренер Dan Rawsthorne.

Посмотреть подробную информацию о конференции и зарегистрироваться можно на официальном сайте конференции AgileDays.ru

До встречи на конференции!

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

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

• Стикеры со временем теряют липкие свойства и, при слабом дуновении ветерка из открытого окна, смешивают все ваши карты. В идеале вам потребуется магнитная доска и сотня другая магнитиков.

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

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

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

Одной из основных практик Agile является использование Task Board (доски задач), которая позволяет удобным образом визуализировать состояние итерации (спринта) и вовлечь команду в активную работу с задачами итерации. С описанием этой практики и примерами использования вы можете познакомиться в статье TaskBoard: Управление в стиле Agile

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

Дополнительным преимуществом использования доски задач является возможность формирования пула задач (task pool), из которого участники проекта черпают задачи. Вот несколько преимуществ этого подхода:

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

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

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

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

На закладке "Задачи" участники проекта видят пул задач, причем этот пул можно разделить по фазам разработки: аналитики просматривают пул задач анализа, тестировщики - пул задач по тестированию. Как только участник освобождается от текущей задачи он берет из пула следующую.

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

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

Постом Agile: использование time boxing мы открыли серию заметок по использованию Agile практик в разработке программного обеспечения и применению их в системе управления процессом разработки DEVPROM.

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

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

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

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

• плохая адаптируемость - разработка ПО всегда связана с изменением функционального скоупа, при этом вам приходится перекраивать план по несколько раз на дню и отвлекать команду на оценку или переоценку задач. И ни в коем случае нельзя ошибиться :)

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

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

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

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

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

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

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

В большинстве проектов требуемый функционал (скоуп) недостаточно известен на ранних стадиях и постоянно меняется на последующих стадиях. Именно для таких проектов рекомендуется использование Agile и одной из его практик в частности: time boxing (time box, равные по продолжительности итерации или итерации фиксированной длительности).

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

Вот основные преимущества, которые дает вашей команде практика time-boxing:

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

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

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

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

В системе управления проектами DEVPROM реализована уникальная возможность использования Agile практики time-boxing совместно с формированием плана работ по итерации, что особенно актуально для распределенных команд, которые не могут часто собираться в одной комнате перед доской для планирования.

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

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

Для 100% кросс-функциональной команды, где разработчик = тестировщик = аналитик, это наверное не так важно - если анализ требований будет не успевать, остальные накинутся и помогут. Но много ли таких команд вы знаете?

(далее рассуждаем, приняв эффективность аналитической деятельности 1 разработчика меньше эффективности такой же деятельности 1 аналитика)

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

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

А burndown продолжает показывать, что все в норме!

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

Вот например в DEVPROM такой показатель измеряется и всегда доступен команде рядом с burndown графиком.

В марте, при информационной поддержке DEVPROM, в Москве пройдут два мероприятия, которые наверняка будут вам интересны:

Тренинг по Test Driven Development (13-14 марта)

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

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

Язык и используемые технологии здесь не имеют значения, Test Driven Development успешно применяется разработчиками на C++, Java, C#, Pithon, PHP и других языках программирования.

К сожалению, на текущий момент в аудитории осталось всего 4-5 свободных мест, поэтому для посещения тренинга просто черкните письмо на admin@devprom.net с темой Test Driven Development и мы сразу же вас зарегистрируем.

Стоимость участия составляет 16 тысяч рублей, тренинг пройдет 13-14 марта в Москве.

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

Agile labs - конференция разработчиков программного обеспечения (31 марта)

Однодневная двух-трековая конференция IT специалистов, работающих с применением Agile практик или еще только обращающих на них свое внимание.

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

Ознакомиться с программой конференции и зарегистрироваться на нее вы можете на сайте конференции: http://agile-labs.ru/conf/program

До встречи!

Команда DEVPROM

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

Но обычно, когда говорят об обратной связи, имеется ввиду связь Заказчик-Команда разработки, то есть заказчик все время корректирует наше движение вперед.

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

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

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

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

На мой взгляд, для адекватной формы обратной связи нужно:

• сделать ее максимально доступной пользователю, а не маленькой ссылкой внизу страницы

• помещать заведенные пользователями пожелания в журнал (User Backlog?), к которому обязательно давать доступ пользователям

• подписывать пользователя по email на все действия с его пожеланием (запланировано на итерацию, реализовано, отложено и т.п.)

• иметь возможность комментировать пожелание для общения пользователя и команды, с отправкой уведомлений по email

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

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

Звучит заманчиво?

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

Форма встраивается на сайт несколькими строками html кода, цвета, размер и шрифты настраиваются.

Вдобавок ко всему, к форме прилагается и отличный инструмент для управления проектами DEVPROM.

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

Вы как думаете?