agile software engineering · agile software engineering ... Бизнес пользователи...

Agile Software Engineering (методология гибкой разработки)

Андрей Панкратьев, Департамент разработки программного обеспечения, SAP Labs

22 Октября, 2014 года

© 2014 SAP SE or an SAP affiliate company. All rights reserved. 2 Customer

Содержание

Скрам

Разработка Через Тестирование

Качество Программного Обеспечения

Спецификация на Примере

ABAP Unit


Скрам “Увеличение Продукта”


Одного Скрама Недостаточно!

Управление Проектами

Планирование Спринта (Sprint Planning)

Обзор Итогов Спринта (Sprint Review)

Ретроспективное Совещание (Sprint

Retrospective)

Ежедневное Совещание (Daily Scrum)

Владелец Продукта (Product Owner)

Скрам Мастер (Scrum Master)

Команда (Team)

Бэклог Продукта (Product Backlog)

Бэклог Спринта (Sprint Backlog)

Гибкая Методология Разработки

Разработка Через Тестирование (Test-Driven

Development)

Чистый Код (Clean Code)

Рефакторинг (Refactoring)

Парное Программирование (Pair Programming)

Простой Дизайн (Simple Design)

Коллективное Владение (Collective Ownership)

Непрерывная Интеграция (Continuous Integration)

Приемочные Тесты (Acceptance Tests)

Исследовательское Тестирование (Exploratory Testing)


Гибкие Проекты Более Успешные


Сравнение Waterfall и Agile Проектов

Waterfall

Все требования должны быть определены и

детально описаны до начала разработки;

Детально структурирован, что облегчает его

применение к малоопытным командам;

Проекты легко контролируются, отслеживаются

ресурсы, риски, время;

Качество имеет первоочередной приоритет по

сравнению со стоимостью и временем

Agile

Итеративная разработка;

Быстрое получение первой/пробной версии

продукта для тестирования

Легко воспринимаются корректировки и

изменения в процессе разработки

Конечный пользователь вовлечен в процесс с

самого начала

Разработка Через Тестирование


Мотивация Тестирование: Раньше, Чаще и Автоматически

Чем позже обнаружена ошибка, тем она дороже

Мы должны тестировать код как можно чаще и раньше

Как мы можем делать регрессионное тестирование

эффективно и часто?

Автоматическое тестирование не оказывает стрессового

воздействия и обеспечивает корректность существующей

функциональности

Как будет замечательно обнаруживать ошибки

мгновенно (в режиме реального времени)?


Объяснение Разработки Через Тестирование Цикл


Объяснение Разработки Через Тестирование Три Правила

Три основных правила от Роберта Мартина (дядюшки Боба).

Пишите только тот код, который протестирован.

Начинайте писать тесты с малого, а затем наращивайте их.

Пишите ровно столько кода, сколько необходимо для прохождения теста.

После того как все тесты пройдены очистите код и дизайн (рефакторинг).


Выгода I

Сосредоточьтесь на главном, так как

Тесты кодифицируют требования

Тесты управляют разработкой функциональности

Вы делаете только то, что необходимо в данный

момент

Уверенность

Подстраховка

Поощряет изменения

Отталкивает ошибки


Выгода II

Улучшается качество кода

API годный к использованию

Декаплинг и тестируемость

Живая Техническая Документация

Тесты как исполняемый список

требований

Тесты объясняют использование

API


Написание “F.I.R.S.T. Class” Модульных Тестов Характеристики Хороших Модульных Тестов

Fast тесты работают быстро

Isolated тесты полностью изолированы

Repeatable неизменное поведение в любом окружении

Self-Validating два состояния (есть ошибка / нет ошибки)

Timely тесты пишутся до написания продуктивного кода



Внешнее Качество (взгляд пользователя)

Корректность (Correctness)

Производительность (Performance)

Удобство (Usability)

Безопасность (Security)

Внутреннее Качество (взгляд разработчика)

Читаемость (Readability)

Возможность поддержки (Maintainability)

Возможность расширения (Expandability)

Повторное использование (Reusability)

Тестируемость (Testability)


Симптомы/Следствия Низкого Внутреннего Качества

Внутреннее качество имеет тенденцию к снижению

Каждое новое изменение встраивается в существующий низкокачественный код и тем самым создает

новые проблемы

Эффект “Разбитых Окон”

Архитектура разрушается

Производительность снижается

Новые изменения (требования) трудно реализовать

Все больше и больше затрат приходится на исправление ошибок

Исправленные ошибки появляются вновь

Затраты на тестирование возрастают

Внешнее качество страдает

Изменения приводят к непредвиденным последствиям, ведущим к ошибкам


Результаты Хорошего Внутреннего Качества

Хорошо для конечного пользователя и владельца продукта

Разработки не останавливаются со временем

Ошибки легко исправляются

Новые требования легче добавлять

Хорошо для разработчиков

Разработки завершаются в срок

Меньше давление

Больше уверенности и удовлетворенности


Как достичь Высокого Внутреннего Качества Нет Технических Долгов

Не накапливайте технических долгов . . .

Код должен очищаться как можно чаще

Архитектура и дизайн должны быть

адаптированы во время разработки


Как достичь Высокого Внутреннего Качества Общее Понимание

Нужно иметь общее понимание качества и дизайна внутри команды

Обсуждение дизайна и архитектурных

решений

Обсуждение соглашения по коду, качеству

Согласование общих правил


Как достичь Высокого Внутреннего Качества Критерии Готовности

Определите в команде (включая владельца продукта) адекватный набор критериев готовности

повышающих внутреннее качество.

В дополнение к функциональным критериям

готовности можно добавить:

Модульное тестирование должно покрывать по

крайней мере x % кода

Увеличение продукта не должно требовать

регрессионных тестов

Тесты должны выполняться в системе

интеграции

Спецификация на примере


Спецификация на Примере Выполняемая Спецификация, Живая Документация, Приемочные Тесты

Проблемы

Спецификации туманны и неоднозначны

Бизнес пользователи и разработчики говорят на разных языках

Бизнес пользователи не могут проверять или писать модульные тесты

Документация не обновляется

Решения

Спецификация на примере:

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

Автоматические приемочные тесты:

Перенесите примеры в исполняемую форму


Приемочное Тестирование Выполняемая Спецификация

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

Тестирование черного ящика, написанные на языке бизнес пользователей (экспертов)

Однозначные, Поддающиеся проверке

Легко понимаются

Определяет закончена ли разработка требований

Документируют поведение


Приемочное Тестирование vs. Модульное Тестирование

Проверочное Тестирование:

Проверяет что система удовлетворяет

требованиям

Пишутся для бизнес-пользователей

Ориентированы на бизнес

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

Проверяет что модуль построен правильно

Пишутся для разработчиков

Технически ориентированы


Разработка Через Приемочное Тестирование (ATDD)


Различные Виды Приемочных Тестов

Проверить чистую бизнес логику до уровня отдельных классов

Пройти по всему пользовательскому интерфейсу и проверить изменения в базе данных

Приемочные тесты обычно являются интеграционными тестами

Нужно иметь твердую основу модульных тестов чтобы легко обнаруживать ошибки и

дополнить их интеграционными тестами


Автоматизация

Тесты автоматически выполняются

Тесты выполняются без ручного вмешательства

Тесты выполняются в системе интеграции

Тесты создают набор регрессионных тестов

Тест представляют собой живую документацию которая автоматически проверяется

ABAP Unit


ABAP Unit

ABAP Unit это официальная библиотека модульного тестирования ABAP

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

Полностью интегрирован в язык программирования ABAP

Обеспечивает assertion-методы для тестирования ожидаемых результатов

Продуктивный код и код модульных тестов связаны и поставляются вместе

По умолчанию продуктивный код не может быть выполнен в продуктивной системе

Доступно с версии 6.40

Сфера Действия

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

тестов


Синтаксис Релиз 702 и Выше

ABAP классы для модульных тестов обычно реализуются в виде локальных ABAP объектов

(классов) в главной программе, которая содержит тестируемую функциональность.

CLASS ltc_wallet DEFINITION FINAL FOR TESTING

RISK LEVEL HARMLESS DURATION SHORT.

PRIVATE SECTION.

METHODS: add_one_banknote FOR TESTING.

ENDCLASS.


ABAP Unit во Время Выполнения

Все тесты выполняются независимо друг от друга

Выполняются в неопределенном порядке

Одна инстанция тестового класса для тестового метода

Один rollback в конце каждого тестового класса


Проверка Тестов Класс CL_ABAP_UNIT_ASSERT (Версия 7.0 EhP 2 и выше)

Статический

метод

Описание

ASSERT_EQUALS Обеспечивает равенство двух объектов данных

ASSERT_DIFFERS Обеспечивает неравенство между 2 (элементарными) объектами данных

ASSERT_BOUND Обеспечивает что ссылка на переменную существует

ASSERT_NOT_BOUND Обеспечивает что ссылка на переменную не существует

ASSERT_INITIAL Обеспечивает что объект данных имеет начальное значение

ASSERT_NOT_INITIAL Обеспечивает что объект данных имеет НЕ начальное значение

… …

agile software engineering · agile software engineering ... Бизнес пользователи...

Documents