Подтверждение и отмена

Статья
06/10/2015

, И и дэвида Starr, Scrum.org

Январь 2012 г.

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

Применение

Управление жизненным циклом приложений; Team Foundation Server.

Содержание этой статьи

Введение
Прозрачность, потерянная в Компании Анны
- Что люди думали, что происходит
- Что в действительности произошло
- Занятие
Техническая задолженность в Nanomedtronics AZ
- Что люди думали, что происходит
- Что в действительности произошло
- Занятие
Техническая задолженность усиливается при нескольких группах
План выпуска в корпорации A Datum
- Что люди думали, что происходит
- Что в действительности произошло
- Занятие
Методы широкого диапазона для получения результата
- Scrum of Scrums
- Непрерывная интеграция
Заключение

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

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

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

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

Прозрачность, потерянная в Компании Анны

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

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

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

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

Что она имела в виду, что она хочет это использовать? Не могла же она понять окончание спринта как готовность ПО!

Мы сказали Анне это как можно более аккуратно. Она пришла в ярость. «Что, по вашему, означает, работа не выполнена? Я видел первое приращение, второе приращение, и теперь я хочу начать использование. Разверните это и обучите нас SQL, чтобы мы могли использовать его."

Мы начали нервничать. Мы сказали Анне, что да, это было сделано. Но это не было типом готового объекта. Это было сделано для демонстрации, но были проблемы, требующие разрешения перед началом использования ПО.

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

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

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

После собрания наши текущие заказы были:

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

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

Что люди думали, что происходит

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

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

Что в действительности произошло

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

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

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

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

Занятие

Истинная прозрачность требует, чтобы все, рассматривающие Приращение, видели и понимали одно и то же. Прозрачная проверка приращения должна была позволить Анне управлять рисками и получить предсказуемость. Однако, поскольку приращение не было прозрачным, она не может обеспечить эффективность планирования.

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

В конце спринта 3, Анна верила, что было сделано 3/10 из всей работы, что было явно неверно.

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

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

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

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

Техническая задолженность в Nanomedtronics AZ

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

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

Что люди думали, что происходит

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

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

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

Что в действительности произошло

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

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

Завершенная и незавершенная работа

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

Анализ
Разработка
Анализ зависимости
Тесты производительности
Тестирование стабильности
Оптимизация кода
Тестирование иммунологического ответа
Интеграция с работой всех других команд, работающих над продуктом
Тестирование интеграции с работой всех других рабочих групп, так как приращение — сумма вкладов всех рабочих групп
Заметки о выпуске
Интернационализация для шести стран, где будет продаваться продукт
Пользовательский тест приемки
Тест регрессии
Анализ кода

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

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

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

Занятие

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

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

Техническая задолженность усиливается при нескольких группах

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

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

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

План выпуска в корпорации A Datum

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

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

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

Что люди думали, что происходит

На следующем рисунке показаны запланированные расписание и цикл выпуска.

Запланированные расписание и цикл выпуска

Предполагаемый первоначальный план:

9 спринтов
3 выпуска-кандидата, а затем полный выпуск
Компания-разработчик со штатом 800 сотрудников

Что в действительности произошло

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

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

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

Фактическое время проекта плюс время, необходимое для стабилизации

Версии-кандидаты имеют частично работающие функциональные возможности из ветвей кода для каждой группы. Требовалось 5 Месяцев «стабилизации» до выпуска. Одним особенно досадным дефектом, из-за которого поставка задерживалась больше всего, была "плохая производительность". Эта проблема была занесена в журнал в первом спринте.

Занятие

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

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

Методы широкого диапазона для получения результата

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

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

Scrum of Scrums

Если несколько групп Scrum работают на одном и том же проекте, им требуется метод координации работы. Я порекомендовал "Scrum из Scrum-ов" . Это ежедневное событие, проводящееся сразу после ежедневного Scrum-собрания каждой команды. Из каждой команды должен присутствовать кто-то из технических специалистов. Каждый представитель команды описывает, над чем только что работала его или ее команда. Затем он или она описывает, над чем он или она планирует работать в течение предстоящего дня. На основе этого сведения, представители попытаются определить любую необходимую переработку, предстоящие зависимости и любую работу, выполнение которое может понадобиться запланировать повторно.

Подход Scrum of Scrums успешно применялся во многих организациях. Тем не менее, это не отвечает требованиям. Зависимости и переработка могут идентифицировать успешно или безуспешно, поскольку проблемы предвидятся, но неизвестны. Неожиданные зависимости вызвали переработку и негативные результаты тестов. Некоторые группы тратят более 50% каждого спринта на работу с зависимостями и их переделку.

Непрерывная интеграция

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

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

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

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

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

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