Прогрессивный IT мир согласен, что настало время отказаться от тяжелых и громоздких схем в пользу гибких методологий, качественного продукта и партнерских отношений. Конференция AgileDays’12, которая пройдет 23-24 марта в Москве, станет для вас глотком свежего воздуха, открыв новые возможности в IT разработке.

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

AgileDays’12 – прекрасная возможность для новых бизнес-знакомств с самыми продвинутыми представителями IT из России, стран СНГ, Европы и США.

Будьте на острие событий с AgileDays’12!

Присоединившись к нашему Agile фестивалю, вы услышите выступления передовых экспертов индустрии разработки ПО, таких как: David Hussman, Асхат Уразбаев, Никита Филиппов, Дмитрий Лобасев, Сергей Дмитриев, Максим Дорофеев, Борис Вольфсон, Андрей Бибичев и других.

Приглашенный гость конференции David Hussman – ключевой докладчик AgileDays’12 – истинный agile евангелист, продвигающий agile как образ мышления (mindset), а не следование практикам конкретных методологий, в избытке представленных в современном agile сообществе.

Программа AgileDays’12 будет состоять из:
- докладов по новейшим веяниям agile сообщества, опыту успешного и неуспешного внедрения agile в различных компаниях из всех сфер бизнеса;
- мастер-классов, игр-симуляций, которые являются прекрасной возможностью усвоить практические навыки и действенные техники от agile экспертов;

Уже сейчас вы можете ознакомиться с формирующейся программой конференции.
А если у вас есть интересный опыт в сфере agile, поделитесь им с нами, став докладчиком AgileDays’12. До 31 января мы ждем ваши заявки!

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

Не откладывай регистрацию на потом, стань участником AgileDays’12 прямо сейчас!
Узнайте больше и поделитесь своим опытом внедрения Agile, общаясь в неформальной обстановке с докладчиками и участниками со всей России, стран СНГ, Европы и США.

Все самые передовые идеи, подходы и лучшие практики индустрии разработки ПО будут обсуждаться именно здесь, на AgileDays’12!

http://agiledays.ru/
https://twitter.com/#!/AgileDays
http://www.facebook.com/AgileDays

Дата и место проведения: 23-24 марта, Москва, ул. Шипиловская д.28, бизнес-отель Милан.
Телефон:             +7 495 991-69-20       Ирина Цыбденова.
E-mail: irina@scrumtrek.ru

10-12 апреля в Digital October в очередной раз пройдет «самая человечная из технических конференций» - Software People 2012. В течение трех дней российские и зарубежные эксперты будут проводить доклады, мастер-классы и панельные дискуссии, посвященные темам проектирования интерфейсов, человеческого фактора в разработке ПО, юзабилити и UX ПО.

Одним из ключевых докладчиков в этом году станет Джефф Де Люка. Джефф – IT-стратег мирового уровня, пятикратный лауреат IBM Rating 1, автор одной из 6 признанных Agile-методологий «Feature-Driven Development».

Эксперт выступит с мастер-классом «Как с помощью FDD делать отличный софт». Слушатели узнают, как добиться лучшей прозрачности (visibility) проектов, что такое полезная для клиента функция,  как описать проект в виде классифицированного списка полезных функций (client-valued feature), насколько полезна стратегия уменьшения рисков и многое другое из 25-летнего опыта спикера в ИТ-индустрии.

В день мастер-классов Александр Орлов и Вячеслав Панкратов расскажут о «Мотивации без бюджета».  Эксперты продемонстрируют 6 практических инструментов для оценки уровня внутренней мотивации сотрудников. Спикеры рассмотрят такие актуальные вопросы, как падение интереса человека к работе, развитие сотрудника в том направлении, в котором он действительно хочет развиваться, проблема «рутинной» работы.

Узнать подробнее о стоимости мероприятия и зарегистрироваться можно на сайте конференции.

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

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

В активе The Atlantic Systems Guild более сотни реализованных проектов, около 500 статей, а также свыше 200 книг. Наиболее известные из них переведены на русский язык: «Человеческий фактор: успешные проекты и команды», «Deadline. Роман об управлении проектами», «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения», «Балдеющие от адреналина и зомбированные шаблонами». Техники, впервые разработанные и внедренные The Atlantic Systems Guild, используются во всем мире. Можно без преувеличения сказать, что книги Тома ДеМарко и его коллег оказали огромное влияние на индустрию разработки ПО.

По окончании тренинга участники  получают сертификат Certified ScrumMaster от Scrum Alliance.

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

• Инициировать Scrum проекты и управлять ими
• Создавать общее видение для всей команды
• Планировать релизы с помощью User Stories и оценивать их используя Story Points
• Направлять свою Scrum команду посредством анализа спринтов и проведения ретроспектив
• Создавать окружение, в которой команды будут самоорганизовываться и добиваться больших успехов

Тренер: Robin Dymond  (ссылка на http://www.scrumalliance.org/profiles/5066-robin-dymond) – Тренер и консультант Scrum, Agile и Lean методов из США. Робин 21 год в разработке программного обеспечения. Он прошел весь путь, начиная от Software Research Engineer, далее Project Manager, VP и CEO собственной компании. На данный момент Робин вляется управляющим партнером компании Innovel LLC (ссылка на http://www.innovel.net/), США, занимающейся Lean Agile обучением и консалтингом с клиентами в Европе, Украине и США.

Стоимость: Специальная стоимость действует  для тренинга в Санкт-Петербурге: $950 USD (обычная цена составляет $1250). При регистрации до 13 февраля стоимость составит $875 USD.  В стоимость включены: 2 года членства в Scrum Alliance, распечатанные материалы курса, цифровая копия учебных материалов, а также обеды и кофе-паузы.

Подробное описание тренинга здесь:

http://www.scrumalliance.org/courses/20113616-certified-scrummaster

Зарегистрироваться на тренинг можно здесь:

http://www.scrumtraining.com/upcoming-events/

По всем вопросам обращайтесь volha.ikhelis@gmail.com или tanuha.vasilyeva@gmail.com, а также звоните по телефону +79213475361.

Электронная книга доступна бесплатно для скачивания со следующих сервисов в PDF:

• Скачать с Яндекса
• Скачать с Dropbox

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

Содержание

• Предисловие
• Agile-методологии
• Scrum – гибкий управленческий фреймворк
• Управление продуктом
• Управление командой
• Управление контрактами
• Управление рисками
• Инженерные практики
• Контроль и обеспечение качества
• Анализ требований
• Масштабирование Agile
• Бережливое производство
• Как внедрить Agile за 14 недель
• Гибкие компании-аутсорсеры
• Консалтинг-компании и независимые тренеры

Благодарности

Спасибо всем, кто помогал в работе над данными материалами, в том числе по плану внедрению Agile: Евграшин Тимофей, Гармаш Максим, Ковязин Егор, Козлов Илья, Колосова Ксения, Лукьянчикова Наталья, Паньшин Дмитрий, Подурец Михаил, Рогачев Сергей, Свердлов Андрей, Сорокин Евгений, Сурикова Ирина, Тарасенко Анна, Уразбаев Асхат, Шабакаева Лия.
Особую благодарность также выражаю многочисленным рок и хард-рок группам, без которых создание этой книги было бы невозможно.,

На всякий случай

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

Рецензии

• Рецензия от Александра Бындю

Часть вторая

Продолжаю серию постов, про автоматизацию QA процессов. Уже готов пост про связку Selenium 2 + TestNG, но прежде мне бы хотелось немного поговорить о самом процессе автотестирования и его внедрении.

Предыдущие статьи на эту тему:

Вводная часть

Часть первая

Те, кто смотрели фильм “Начало” (Inception), помнят, что до того, как мы начинаем действовать, у нас появляется идея. А до того, как у нас появляется идея, должна возникнуть мысль, которая все и породит. Так что же побуждает нас перейти к автотестам, какие страхи нам приходится побеждать? Обо всем этом я и хотел бы поговорить в этом посте.

На определенном этапе своего развития команда подходит к этапу, когда уже члены команды притерлись друг к другу, мы пишем хорошие продукты и все у нас хорошо, но надо двигаться дальше. И здесь настает время Lean, бережливого производства. Команда начинает улучшать имеющиеся у нее процессы, уменьшать или вообще избавляться от потерь времени, ресурсов и так далее. И именно отсюда появляются задачи на автоматизацию процессов, чтобы экономить время высококвалифицированной команды QA и DEV на более сложные задачи, требующие непосредственного человеческого участия. Это отдельная большая тема, сегодня я хочу поговорить только о небольшом кусочке – автоматизации тестирования.
Итак, почему же мы начинаем заниматься автоматизацией тестирования:

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

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

Содержание

1. Цель тестирования в Agile

2. Планирование задач по тестированию на итерацию (спринт)

• Работа с документацией часть 1 – стори тесты
• Работа с документацией часть 2 – акцептанс тест кейсы
• Анализ требований
• Декомпозиция задач
• Практика по оценке задач, имитация.

3.Ежедневный стендап митинг

• Практика проведения стендап митингов
• Введение в историю перед разработкой и тестированием

4.Написание тест кейсов в Agile

• Подход к разработке тест кейсов
• Практика по написанию тест кейсов

5.Передача истории из разработки в тестирование

• Практика проведения передачи истории в тестирование

6.Тестирование готовой истории

• Практика тестирования, написания дефектов, работа с тестами
• Взаимодействие с разработчиками

7.Автоматизация тестирования в Agile

• Подход к автоматизации в Agile
• Примеры применения автоматизации с использованием TestComplete и Selenium
• Практика

8.Работа с частыми изменениями в Agile

• Оценка изменений
• Обновление тест кейсов
• Перепроверка
• Обновление автоматизации
• Ревью и ретроспектива

9.Советы и рекомендации

Целевая аудитория

Разработчики, тестировщики, менеджеры проектов, лидеры команд.

Описание тренинга

Kanban – современная гибкая (agile) методика управления проектами. Она произошла из философии Lean и TPS (Toyota Production System).  Термин Канбан имеет дословный перевод: “Кан” значит видимый, визуальный, и “бан” значит карточка. Kanban успешно используется для проектов в стадии поддержки продукта, для команд – разработчиков продуктов, для внутренних отделов компаний, проектов с высокой степенью специализации членов команды и во многих других ситуациях. Переход на Kanban для многих команд помогает быстро идентифицировать проблемы и эффективно бороться с ними.

Цель тренинга – подготовить участников к практическому применению Kanban в реальных проектах.

Поток работ

- Управление и визуализация потока работ

- Упражнение «Поток работ»

- Ограничение одновременно выполняющейся работы в Канбан

- Картирование потока ценности (Value Stream Mapping)

Методология Канбан

- Работа с багами, управление приоритетными работами, декомпозиция на технические задачи

- Канбан-карточка

- Ограничение одновременно выполняющейся работы в Канбан

Каденции

- Понятие каденции

- Проведение демо

- Планирование работ

- Проведение ежедневного стендапа

Командная работа и улучшение процессов

- Самоорганизация проектной команды

- Постоянное улучшение процесса

- Проведение ретроспектив

- Применение методики «5 почему»

- Системный подход к оптимизации процессов

Кайдзен

- Метрики эффективности процесса

- Упражнение «Оптимизация процесса»

- Устранение узких мест

- Устранение потерь

- Уменьшение вариативности

Внедрение ЛИН

- Стратегия и тактика внедрения ЛИН

- Применение ЛИН в вашем проекте

http://www.infoq.com/articles/agile-architecture

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

Точки архитектурного взаимодействия

На Рисунке 1 показан гибрид scrum-а[1], экстремального программирования (Extreme Programming)[2] и последовательного управления проектом (sequential project management) – то, что я нашел эффективным для проведения работ по архитектуре в 14 Agile проектах, на протяжении последних восьми лет.

Рисунок 1. Гибридная схема для работ по Agile архитектуре. Вовлеченность архитектора в ход проекта помогает достигать проектных целей. Таблица 1, ниже, объясняет элементы схемы: точки взаимодействия (зеленым), критически важные навыки (золотым) и функции архитектора (красным).

Таблица 1 кратко описывает элементы Рисунка 1. Архитектурные функции – это те, которые обычно выполняет архитектор в проекте, хотя список не исчерпывающий.

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

Предварительное планирование

В Agile проекте каждая функция архитектора начинается с предварительного планирования, как это в основном происходит и в других проектах, не зависимо от методологии. Архитектор:

• принимает основные решения по аппаратному и программному обеспечению (hardware and software), в основном используя существующие корпоративные стандарты, и возможно приводит “доказательства правильности концепции” (proofs-of-concept) при необходимости использования новых продуктов;
• определяет важные шаблоны проектирования на высоком[3] на детальном[4] уровне;
• определяет основные возможности для повторного использования компонентов и сервисов;
• создает высокоуровневые диаграммы;
• описывает атрибуты качества[5], технические и бизнес, и определяет их допустимый уровень[6]; и
• определяет каналы взаимодействия встречаясь с заинтересованными лицами (stakeholders), чтобы понять их проблемы и показать им основное техническое направление.

Хотя большинство из этих пунктов не отличается от работ в не-Agile подходах, предварительные работы по архитектуре для Agile разработки содержат небольшое, но важное отличие.Архитектура скорее должна включать набор опций, чем специфическое решение.Такой подход основывается на Agile допущении, что эмпирические знания, собранные всеми участниками при построении системы, сделают лучшие опции более очевидными[7].Результат будет успешным, если архитектор не ограничивается одним решением слишком рано, и особенно это важно при Agile разработке. Использование итераций, создание работающей системы после каждой итерации, поощрение взаимодействия, имеет обратный эффект, который дает всем участникам значительные возможности, чтобы найти лучшие решения позже, если они не смогли понять их раньше[8].

Например, в проекте хранилища данных возник вопрос: поставлять данные непосредственно в другое место или строить промежуточное хранилище. Прямая передача данных (direct feed) оказалась более сложной, что приводило к снижению надежности и эффективности работы. Однако промежуточное хранилище использовало больше места, что приводило к росту стоимости жизни системы.Архитекторы отметили следующее: 1) любой из этих вариантов отвечает целям бизнеса, 2) мы не может определить, какой дизайн лучше, 3) мы уверены, что команда сможет принять правильное решение в пределах архитектурных границ.По мере развития проекта ответ стал очевиден, команда его легко определила и архитекторы подписались под ним.Определение диапазонов и границ более соответствует Agile подходу, чем определение специфических решений, но архитекторы должны все же определить эти диапазоны и границы заранее.

Доска задач и баклог

Предварительное планирование быстро переходит в определение задач на доске (storyboard­ing) и в построение баклогов продукта и отдельного спринта, причем архитектор является основным заинтересованным лицом (stakeholder).Архитектор должен посещать ранние сессии по определению задач на доске (storyboarding) и добавлять архитектурные user story, которые задают фундамент или определяют архитектурное направление.Он или она должны также посещать последующие сессии по определению задач на доске между спринтами, чтобы вносить архитектурные user story, которые “настраивают” архитектуру или корректируют нежелательные отклонения. Архитектор должен работать с product owner-ом, чтобы приоритезировать эти истории и построить их в соответствии с бизнес функциональностью в спринтах.

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

Например, программа хранилища данных стремилась достичь высокого уровня интеграции корпоративных данных.Архитекторы выступали за использование размерного моделирования (dimensional modeling) как основного подхода [прим. переводчиков: см. http://www.interface.ru/public/wh/wh_.htm ]. Они также выступали за использование bus matrix [прим. перевод: см. http://en.wikipedia.org/wiki/Enterprise_bus_matrix] как основного инструмента для организации работы с данными, потому что bus matrix поддерживает декомпозицию и итеративность[9].Бизнес (и большинство технических специалистов) никогда не использовали bus matrix, поэтому архитекторы должны были проявить содействие на первой сессии по определению задач на доске.На третью сессию product owner-ы распечатали свои user story в формах bus matrix.К пятой сессии команда выразила обеспокоенность, что успех оценивается только по компонентам bus matrix. Поэтому, мы должны были немного отступить и отметить менее заметную работу, такую как повторно используемые компоненты, решение вопросов качества данных и внедрение новых инструментов. Подход получил свой собственный толчок, но стартовал он благодаря содействию со стороны архитекторов.

Участие в спринте

Написание кода – это мощный способ убедиться в том, что архитектор полностью понимает создаваемую архитектуру[10]. Но мы будем допускать, что организация получает большую ценность от того, что использует архитекторов сразу на нескольких проектах, хотя при этом снижается их способность вникнуть во все детали одного проекта.К счастью, agile предлагает решение—доверяй команде. Для этого нужно,чтобы архитектор взаимодействовал с командой во время спринта, понимая цели и помогая решить возникающие проблемы дизайна[11].Чтобы справиться одновременно с несколькими проектами, архитектор должен оставить специфику команде. Пока ревью архитектуры работающей системы показывает высокое качество архитектуры, архитектор может оставлять детали членам проектной команды, будучи уверенным, что их общие знания и глубокое знание задачи будут направлять работу над системой в нужное русло. Поэтому, реальное участие в реализации оправданно, если спринт сошел с верного пути в архитектурном или другом смысле.В такое время архитектор становится полноправным членом команды, размещается вместе с ней, и полностью подчиняется задачам команды.

Например, существует давний вопрос по архитектуре хранилищ данных: использовать нормализованное или размерное моделирование, и до какой степени[12]. В одном из agile проектов хранилища данных архитекторы решили этот вопрос так: для максимальной функциональности нужна реализация обеих моделей в их полной форме. После нескольких спринтов скорость проекта не соответствовала требуемым срокам – общая проблема, независимо от методологии.Чтобы посмотреть, помогут ли архитектурные изменения увеличить скорость проекта, в начале четвертого спринта я поучаствовал в проекте как полноправный член команды.На основе этого полноправного участия в проекте, а также вдохновенных замечаний от семи экспертов их двух команд, стало очевидно, что протаскивание всех данных через нормализованную модель, с тем чтобы положить их в размерную модель, не нужно для удовлетворения бизнес целям (для этого конкретного проекта, а не в общем). Мы планировали нормализованный уровень целый год, а потом, на базе нового понимания, мы убрали его в течение 30 дней. Для этого были нужны обсуждения с менеджментом и архитектурным руководством, но изменение было сделано в следующем спринте и дало проекту значительное увеличение скорости.

Работающая система

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

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

Навыки Agile архитектора

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

Декомпозиция в форме спринтов

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

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

В первом примере нам нужно построить корпоративный веб сервис для данных третьей стороны, используя сервис ориентированную архитектуру (service-oriented architecture, SOA). Проектная команда использовала подход с девятью спринтами, структурированный вокруг трех основных областей технической функциональности: интерфейс сервиса, уровень сохраняемости (persis­tence layer) и получение внешних данных.В первых двух спринтах команда опубликовала интерфейс сервиса.Вызов сервиса возвращал только одну жестко прописанную запись, но транзакция была через абсолютно функциональный вызов сервиса с хорошо определенным контрактом.Архитектурно это задействовало Java, стандарты веб сервисов, XML, шаблоны вызова, и дало клиентской системе результат для построения экранов, которые можно было показать бизнесу. Во второй группе спринтов команда сделала так, что сервис мог возвращать около 100 записей из локальной базы, но пока не от внешнего поставщика.Это определило базу данных, модель данных и объектно-ориентированный слой для работы базой, и дало больше кейсов, которые можно было показать на бизнес ревью. В третьей группе спринтов команда сделала запросы сервера к внешнему поставщику данных.Это включило в себя решение вопросов межсетевой защиты, формата данных внешнего поставщика данных, и требований к времени задержки. С самого начала растущая функциональность сервиса показывала меру прогресса основываясь на работающей системе, позволяя команде сфокусироваться на более узком наборе технических вопросов, и в то же время давая бизнесу видимый результат.

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

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

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

Взаимодействие с Product Owner-ом

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

К счастью почти все работы по дизайну имеют непосредственное отношение к атрибутам качества, и почти все улучшения атрибутов качества переводятся в ценность для бизнеса.Сопровождаемость (maintainability) системы позволяет делать бизнес функциональность на более поздних спринтах быстрее, быстрее внедрять в жизнь желаемые улучшения, что в свою очередь дает более высокую скорость выхода на рынок.Масштабируемость позволяет поддерживать высокую производительность, даже когда система проходит через пик активности во время маркетинговой компании, что предотвращает потерю бизнеса в критические моменты.И так далее. Естественно связь хорошей архитектуры с ценностью для бизнеса не уникальна для Agile разработки.Но власть, которую Agile разработка дает product owner-у, делает особенно важной необходимость объяснять значение хорошей архитектуры часто. Особенно важна эта пропаганда на первых нескольких спринтах, когда нужно построить базовые для архитектуры компоненты, которые сложно изменить впоследсвтии[15], и эта работа невидима для пользователей.

Например, мы делали интранет приложение, в котором предполагалось иметь около 300 экранов ввода. Мы могли бы сделать столько экранов, сколько возможно на первых нескольких спринтах, чтобы показать быстрый прогресс и вселить уверенность в заинтересованных лиц. Тем не менее мы убедили product owner-а позволить команде построить гибкий дизайн ввода полей, который бы можно было широко использовать на всех экранах.Это привело к тому, что на первых спринтах было мало экранов, но зато повысилась сопровождаемость системы. Ближе к концу проекта это позволило значительно повысить скорость создания экранов, что было бы невозможно, если бы мы не объяснили product owner-у важность ранних архитектурных работ, и не получили бы согласие на эти работы.

Архитектурный баклог

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

Чтобы иметь четкое представление об архитектуре и чтобы определять приоритет работ, нужен отдельный архитектурный баклог для отслеживания архитектурных работ.Согласно большинству литературы, есть только один баклог.На практике, мне показалось полезным поддерживать несколько физических баклогов, каждый из которых сфокусирован на своей цели, но все они вместе составляют один логический баклог.Баклог того, что выходит за рамки проекта (out-of-scope backlog) определяет то, что не является целью проекта, баклог пожеланий (wish list backlog) перечисляет работы, которые вероятно никогда не будут сделаны. и т.д.Такая модульность помогает оставлять понятным основной баклог, и не терять при этом перспективу. То же самое с архитектурным баклогом. Он поддерживается архитектором, сообщается product owner-у и команде в подходящее время и в подходящем месте. Пункты из этого лога передвигаются в основной баклог в зависимости от решения product owner-а, под влиянием архитектора. Я считаю, что очень полезно дать пунктам вес и оценку, которая показывает степень архитектурного качества проекта. Такая оценка дает понятный механизм для подталкивания product owner-а, чтобы можно было передвигать истории из архитектурного в основной баклог, и сделать их.

Инкрементальная архитектура предприятия

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

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

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

Межсистемное требование базируется на наблюдении, что системное взаимодействие потенциально вводит новый уровень шаблонов дизайна[16] и может сместить все атрибуты качества. Например, две системы могут масштабироваться индивидуально,но не масштабироваться, когда они взаимодействуют. В основном это определение архитектуры предприятия не зависит от agile, но с точки зрения agile, основные аспекты – это взаимодействие и сотрудничество между архитекторами, архитекторами и технической командой и product owner-ами.

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

Взаимодействие с agile командой и product owner-ами лучше всего достигается за счет физической децентрализации архитекторов и за счет того, что они обсуждают проблемы архитектуры предприятия в моменты взаимодействия.Централизованные активности, которые я предлагаю, являются важными, но не основными в работе архитектора. Архитектор должен проводить столько времени, сколько это целесообразно, вместе с командой и product owner-ом, чтобы максимизировать возможности для прямого общения.Когда архитектор защищает аспекты архитектуры для проектной работы, он или она должны использовать доводы архитектуры предприятия. Например, когда архитектор защищает определенный набор ПО и аппаратного обеспечения, нужно основывать это не только на нуждах проекта, но также на направленности архитектуры предприятия – подобно шаблонам дизайна и атрибутам качества.Это особенно важно для вопросов межсистемного взаимодействия. Архитектор может понять динамику межсистемного взаимодействия, в отличие от команды и product owner-а, поэтому архитектор ответственен за то, чтобы сделать видимыми скрытые проблемы или определить более широкие возможности, которых не увидят другие. Основной целью для всех, включая архитектора,остается бизнес функциональность, для которой проект был профинансирован, и краткосрочные проблемы, которые возникают во время проекта.Но хорошее видение целей архитектуры предприятия и эффективное включение хорошей архитектуры на каждом спринте на каждом проекте, ведут к постоянному совершенствованию архитектуры предприятия.

Например, в 2009 году моя компания получила промышленную награду за “Создание Agile бизнес интеллектуальной инфраструктуры.”[17] Компания профинансировала проект по бизнес причинам в 2008 году, тогда как архитектура была задумана в 2006 – за два года до любой возможности реализовать ее. Проблема была в том, что исследователи, работавшие над архитектурой, использовали платформу, изолированную от основного хранилища данных, что привело к высокой избыточности данных и неправильным процедурам. В то же время, основное хранилище данных использовало технологии, которые не отвечали нуждам исследователей, и имело слишком большие ограничения для исследовательских работ.

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

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

Об авторе

James Madison – старший архитектор в крупной страховой компании и основной инструктор на agile тренингах в отделе архитектуры предприятия. Его agile проекты включают Web, клиент-ориентированную, сервис ориентированную архитектуру, хранилища данных, и не традиционные для agile проекты, такие как построение инфраструктуры и миграция платформы. Madison имеет степень магистра по computer science, Rensselaer Polytechnic Institute. Контакты: madjim@bigfoot.com.

[1] K. Schwaber, Agile Project Management with Scrum, Microsoft, 2004

[2] K. Beck and C. Andres, Extreme Programming Explained: Embrace Change, 2nd ed., Addison-Wesley Professional, 2004

[3] M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 2002

[4] E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, 1995.

[5] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 2nd ed., Addison-Wesley Professional, 2003, pp. 71–98

[6] R. Kazman, M. Klein, and P. Clements, ATAM: Method for Architecture Evaluation, tech. report CMU/SEI- 2000-TR-004, ESC-TR-2000-004, Software Eng. Inst., Carnegie Mellon Univ., 2000.

[7] M. Poppendieck and T. Poppendieck, Lean Software Development: An Agile Toolkit for Software Development Managers, Addison-Wesley Professional, 2003, pp. 38–45, 103–111.

[8] K. Schwaber and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2002, pp. 23–30

[9] R. Kimball and M. Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling,” John Wiley & Sons, 2002, pp. 78–88

[10] V. Subramaniam and A. Hunt, Practices of an Agile Developer: Working in the Real World, Pragmatic Bookshelf, 2006, pp. 155–157

[11] M. Fowler, “Who Needs an Architect?” IEEE Software, vol. 20, no. 5, 2003, pp. 11:13

[12] M. Ross and R. Kimball, “Differences of Opinion,” Intelligent Enterprise, 6 Mar. 2004

[13] J. Madison, Very Large Calculation Systems, Casualty Actuarial Soc., 2009

[14] J. Shore and S. Warden, The Art of Agile Development, O’Reilly, 2008, pp. 214.

[15] M. Fowler, “Who Needs an Architect?” IEEE Software, vol. 20, no. 5, 2003, pp. 11:13

[16] G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addison-Wesley Professional, 2003

[17] “Best Practices in Business Intelligence: Creating an Agile BI Infrastructure,” Computerworld, 2009;

http://www.computer.org/portal/web/computingnow/softwareThis article first appeared in IEEE Software magazine. IEEE Software‘s mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change.

Так вот, видов тестирования очень и очень многое: нагрузочное, ad hoc, sanity, black box, white box и так далее. И долгое время я не встречал хорошей и понятной, по моему мнению, системы, которая бы содержала нормальную группировку всех этих видов, а так же давала объяснение, когда и зачем какие нужно их использовать. И буквально на днях прочитал про Agile Testing Quadrants (ATQ), про которые и хочу рассказать.

Идея данной систематизации изначально принадлежит Brian Marick, а затем была доработана Lisa Crispin, которая является одним из авторов упомянутой книги. По ссылкам можно найти их записи про ATQ.

Собственно сама система выглядит вот так:

Как видно, классическая диаграмма 2*2. Итак, по одной из осей тесты делятся на бизнес-ориентированные и технологически-ориентированные, по другой оси – на тесты для поддержки команды и для “критики продукта”. Сразу хочу отметить, что нумерация ничего не говорит о том, когда нужно проводить эти тесты.

Пройдем по каждому из секторов.

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

Сектор Q2 содержит в себе более высокоуровневые тесты, которые уже имеют отношение к бизнесу. Успешное прохождение этих тестов является обязательным, чтобы говорить о завершенности какого-либо функционала. Потому что мы можем говорить, что тот или иной функционал сделан, когда он решает одну из поставленных бизнес-пользователями задач. На этом уровне в основном тестируется внешняя оболочка приложения: интерфейс, API, веб-сервисы и так далее. С другой стороны, этот сектор включает в себя тестирование прототипов, мокапов, дизайна и так далее. Часто для обозначения тестов, входящих используют термин приемочное тестирование, хотя это не совсем верно, так как тесты из секторов Q3 и Q4 так же стоит отнести к приемочному тестированию.

Тесты из сектора Q3 подразумевают обязательное участие экспертов в доменной области, экспертов по usability, пользователей и так далее. Так уж часто бывает, что реализованный функционал на самом деле не решает проблемы заказчика, или же что-то было понято неправильно командой разработкой. Опять же, могли возникнуть новые аспекты работы с доменными объектами или выяснилось, что спроектированный интерфейс не удобен пользователям. Как раз тут и вступают в дело тесты, предназначенные для “критики” продукта. Сразу оговорюсь, что слово “критика” здесь имеет положительный оттенок. Само собой, что данное тестирование может быть только ручным, потому что ни один скрипт не может выявить обозначенных проблем, хотя мы, конечно, можем использовать вспомогательные средства, например, для загрузки данных.

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

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