DEVPROM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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