Сообщество AgileRussia проводит открытый семинар на тему «Методология Scrum»
13 сентября, в 19.00 на территориии офиса Luxoft

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

В нашей программе две части:
«Обзор методологии Scrum» и «Внедрение Scrum: Опыт одной компании».

Обзор методологии Scrum

1. Зачем нужен Scrum?
2. Основа методологии Scrum
3. Роли, артефакты и жизненный цикл
4. Преимущества и применимость методологии

Ведущий — Асхат Уразбаев

Внедрение Scrum: Опыт одной компании

1. Состояние до внедрения Scrum
2. Внедрение Scrum
3. Трудности, с которыми мы встретились
4. Как мы с ними справлялись
5. К чему стремимся сейчас

Ведущий — Никита Филиппов

Семинар бесплатный, чтобы на него попасть — запишитесь здесь по кнопке [Участвую], указав при регистрации в системе свои реальные ФИО (этого требует пропускная система Luxoft).

AgileRussia Community

Побывал я на РИТе-2008. Скажу я вам, впечатления незабываемые :)

Каждый четвёртый веб-проект не вписывается в отведённый ему бюджет, а почти в каждом третьем случае разработчики не могут закончить работу к дедлайну. Такую мрачную статистику выявило новое исследование, проведённое компанией New Bamboo, которая занимается разработкой ПО на Ruby on Rails. В опросе участвовали около ста IT-менеджеров и директоров компаний.

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

Неприглядная картина веб-разработки дополняется и другими цифрами. Оказывается, даже после всех согласований, возможного дополнительного финансирования и продления сроков 21% проект всё равно не соответствует требованиям заказчика. Печальные цифры сохраняются не только для крупных, но и для совсем мелких проектов. Ситуация усугубляется, если заказчик требует усложнить преокт и добавить в него модные современные технологии: социальные сети, приложения электронной коммерции, фичи Веб 2.0.

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

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

Рассмотрим типичную ситуацию.

27 мая 2008 года в Москве прошла третья международная конференция SQA Days 2008, в которой участвовали более 200 специалистов по тестированию и обеспечению качества программных систем, а также другие заинтересованные лица. Конференция посвящалась вопросам, связанным с тестированием и обеспечением качества веб-приложений.

Предлагаем ознакомиться с видео основных докладов

Ретроспектива (от лат. retrospectare, «взгляд назад») — взгляд в прошлое, обозрение того, что было в прошлом.

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

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

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

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

И ТакСегодня я хотел бы немного рассказать о новом тренинге. Он раскрывает секреты управления софтверными продуктами в условиях постоянных изменений. ;).

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

Часто ли вам приходилось работать в Agile проектах, где общая цель итерации не совсем ясна?! В проекте, в котором есть Backlog, но люди, которые участвуют в развитии продукта не понимают целей релиза. Как оказалось это происходит во многих компаниях, как в малых, так и в компаниях с многомиллионными бюджетами. Дело в том, что многие фразу «Конец итерации = законченный и рабочий продукт» понимают как, написание «идеального» стабильного кода к концу итерации, забывая об истинных бизнес-целях продукта.
Я бы хотел, чтобы мы не совершали таких ошибок.

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

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

Начинать данную статью с различных вводных матчастей о «Великой силе SCRUM'а» и «ущербности водопадной методологии» считаю пустой тратой времени, поскольку в интернете и так достаточно много ресурсов, позволяющих узнать всё: от историй предпосылок создания технологий до всех преимуществ и недостатков в текущих реализациях. Как говорится: «Кто ищет, тот всегда найдет...» (с) :-).

Хочу поделиться неким опытом и даже скорей всего своим мнением о «существующем зоопарке ПО» в некоторых ИТ-компаниях, а именно подходах и реализациях.

Итак, начнем…

Естественно, для написания нового или улучшения существующего продукта предварительно нужно исследовать рынок, проанализировать потребность заказчиков, написать кучу каких-то нелепых концепций и ТЗ, в которых для «большего страха и мощи системы» необходимо как можно больше применять такие выражения как: «… на основе существующих артефактов, разработанная метамодель поможет реальным пользователям ...», обязательно использовать только термины и аббревиатуры и конечно же обязательным условием является описание «сферических коней в вакууме». Затем надо детально проанализировать все эти концепции, обрасти еще миллионами моделей: от простых IDEF-диаграмм до огромных UML-моделей со всякими ассоциациями, агрегациями и прочей «атрибутикой». В итоге получаются все новые и новые «пауки». Конечным пользователям глубоко наплевать на эти модели, диаграммы и т.д., им нужны рабочие кнопки…

После этого начинается непосредственно разработка, программисты начинают «клепать» то задуманное, о чем писалось в ТЗ. Опустим документирование и тестирование… перейдем сразу к выходу продукта на рынок. Маркетологи разработали кучу бумажек о выходе продукта «СуперМегаСистемаПро», которая позволит не только быть «системой, автоматизирующей то-то и то-то», но также (причем без лишней скромности)… она… она… она вообще позволяет «автоматизировать весь мир» :-). Вроде все хорошо, система мощная, современная, но почему-то заказчики недовольны… вроде система обо всем, а на самом деле не о чем. В итоге существующие продукты начинают ругать все кому не лень, а внедренцы в тихоря при помощи SDK (если есть) «клепают» все новые и новые плагинчики, лишь бы заказчик был доволен. Следствие, зоопарк разрастается…

Существующие проблемы ПО находятся прямо «на поверхности», их не надо искать, а уж тем более вытаскивать из глубины. Но тем не менее, начинаются новые обсуждения, новые концепции… в итоге «кто в лес, кто по дрова»… но главное, существующие недостатки завуалированы емкими терминами и как следствие новая система только стала еще сложнее и не понятнее. Жалко потраченного времени (2-5 лет), а уже тем более жалко выкидывать «тонны кода», ведь программисты не виноваты.

После разведенной мною демагогии о «водопадном подходе» :-) имеет смысл перейти к реально рабочей технологии SCRUM. Данная технология действительно помогает оживлять продукты и способствует разработке новых и качественных продуктов.

Инициативная группа разработки решила поработать по SCRUM, пытаясь исправить существующее положение вещей. Была сформирована команда в составе: программисты, аналитики и тестировщики, в которой как и положено технологии был ProductOwner со своим ProductBacklog'ом и SCRUM-мастер.

Процесс
Практику SCRUM мы объединили с некоторыми практиками XP (eXtreme Programming). SCRUM позволяет решить вопросы управления и организации, а XP специализируется на инженерных практиках. Из XP мы позаимствовали: парное программирование, рефакторинг, CodeReview и стилевое описание кода. Также на ретроспективах мы определили для себя ряд правил, которых мы придерживаемся. Для проектирования качественного GUI применяем практику использования персонажей.

Используем только легковесное документирование: диаграмма БД и UML-модель, которые разрастаются только в ходе разработки, соответственно — это не такие страшные пауки, как было описано выше.

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

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

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

SCRUM — митинг
Ежедневные встречи проводятся 2 раза в день возле SCRUM-доски. После встречи делается отметка на графике сгорания. Задача считается выполненной, т.е. переносится в «Done», только после тестирования. Программист может взять следующую задачу в «InProgress» только после одобрения аналитиком предыдущей задачи, взятой на выполнение. Диаграмму сгорания «подбивает» Скрам-мастер. Чтобы не превышать временной 15-минутный лимит, встреча проводится стоя. На встрече мы определяем, что мы сделали, что будем дальше делать, какие проблемы. Стараемся не обсуждать технические детали, но не всегда получается. Обычно встреча длится не более 10 минут. Если на митинге были определены некоторые технические проблемы, то их обсуждение проводится после скрам-митинга возле «стены проектирования» (доска с маркерами).

SCRUM — доска
В качестве скрам-доски мы используем обыкновенную пробковую доску. Область доски мы разделили на три части: ToDo (что надо сделать), InProgress (В работе), Done (Выполнено).

Однако, мы ведем и электронную версию доски (UserStory, задачи, % участия задействованных участников команды и т.д.) в программе. Это делается «для истории», в работе мы пользуемся только доской.

График сгорания
График сгорания является наглядным индикатором прогресса. Ось X — это ось времени. Ось Y — трудоемкость невыполненных задач. Задача считается выполненной если она проверена тестировщиком, во всех остальных случаях задача не выполнена.

Выполненные задачи переносятся в раздел «Done» скрам-доски. Таким образом график отображает сумму трудоемкости задач, находящихся в разделах «ToDo» и «InProgress». После ежедневных митингов, диаграмма сгорания «подбивается» с учетом выполенных задач за день. Также информация о выполнении заносится в программу, в которой наглядно отображается дата взятия задачи в «InProgress», дата выполнения данной задачи. В продукте автоматически подсчитывается средняя скорость команды, фокус-фактор. Данная информация иногда может помочь в переоценке трудоемкости задач и фокус-фактора команды.

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

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

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

В результате работы по SCRUM наша команда смогла решить многие из тех проблем «на поверхности» быстро и качественно (правда систему не оживляли, писали с нуля).
Да пребудет с нами «великая сила SCRUMа» и дайте пользователям рабочие кнопки!!!

На прошлой неделе я посетил конференцию Agile Labs, организованную УЦ Люксофт при поддержке ГУ ВШЭ.

Изначально я был настроен скептически, потому что доклады про agile-методы уже примелькались, осенью было много сказано об этом на конференции SECR 2008, была специализированная мини-конференция AgileDays. В общем, я ждал повторения в докладах тех же уже порядком затёртых идей. Поэтому я планировал сходить послушать парочку докладов утром, а потом ещё прийти вечером на обещанную «битву гигантов»: противники agile против сторонников, Панкратов против Уразбаева.

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

Уже сложно найти сайт и специалиста в области менеджмента, которые не говорят о важностях эмоционального интеллекта применительно к проектной деятельности. Я спрашиваю их — а делать то чего? Разводят руками или начинают говорить о красивых абстракциях и грандиозных результатах. Но я опять не понимаю. Тогда говорят, это сложный вопрос, а тебе стоит найди правильного человека для своей команды, он чувствует это всё. А другие советуют почитать Кови или книгу о сабже, после этого ты и поймешь.

Мне кажется можно организовать все проще. Основная идея — потенциал команды складывается из ментальных и эмоциональных усилий команды. IQ + EQ. Если с IQ понятно, то вот как прокачивать EQ?

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

Исходные материалы для развития эмоционального интеллекта:

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

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

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

Ни для кого не секрет, что для слаженной работы команды, особенно в проектах управляемых по методологии Agile, важен эффективный обмен информацией между участниками. Для того, чтобы информационные потоки не разрушались под влиянием человеческого фактора, стандартные процедуры по управлению информацией автоматизируются. В данной статье рассмотрен пример технической инфраструктуры, использующейся сотрудниками компании ООО «Креатив Медиа» при разработке Web-проектов на платформе Java, например, в проекте социальной сети Campus.ru.

Specter – инфраструктура для составления объектно-поведенческих спецификаций для .NET. Он предоставляет возможности для обеспечения разработки, руководствуясь поведением системы (BDD), требуя от разработчиков написания исполняемой спецификации для объектов перед написанием самих объектов. Технически это ни чем не отличается от разработки по средствам тестирования (TDD), хотя различия в форме написания снимают психологический барьер для написания “тестов” для кода, которого ещё не существует. Есть множество проектов для различных платформ, реализующих данную идею (К примеру RSpec для Ruby, NSpec для .NET. Подробнее о средах здесь).
Specter использует возможности мета-программирования языка Boo (CLR .NET) для написания неплохо читаемых спецификаций.

Участники:
Асхат Уразбаев(ScrumTrek.ru), Денис Миллер, Никита Филиппов(ScrumTrek.ru)

Обсуждаемые темы:
* Проблемы разработки ПО
* Что такое Agile?
* Чем приятен Waterfall
* Сравниваем Agile и не-Agile
* Буддизм в Agile