Управление расползанием масштаба в Agile

TL;DR

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

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

Управление объемом

[I]Если вы предотвратите расширение масштабов проекта, как вы можете сказать, что проект Agile?

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

1. Как правило, новую работу следует вводить только во время планирования спринта.
2. Новая работа, которая имеет приоритет над текущей работой, требовала досрочного прекращения текущего спринта и возврата к планированию спринта.
3. Приоритет новой работы для проекта должен определяться владельцем продукта в сотрудничестве с заинтересованными сторонами, поэтому расширение масштаба на уровне проекта управляется на основе консенсуса относительно того, что предлагаемая работа имеет отношение к целям проекта.
4. В Scrum итерации представляют собой фиксированный временной интервал с относительно фиксированной стоимостью (исключая капитальные затраты), но объем является переменным ограничением.
5. «Расползание масштаба» в традиционном деловом понимании этого термина увеличивает общее время выполнения проекта. Добавляя масштаб к проекту, вы влияете на график (обычно удлиняя его). Вы управляете этим за счет прозрачности и эффективного общения с заинтересованными сторонами.

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

Компромиссы

Треугольник управления проектом обычно понимается как набор ползунков, состоящих из объема, графика и стоимости. (Примечание: есть и другие модели, но эта самая распространенная.)

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

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

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

Ваши интервьюеры правы — это не agile.

Суть Agile в том, что требования меняются. Ваше понимание проблемы меняется. Ваше понимание рынка меняется. То, что, как вы думали, нужно построить в январе, совсем не то, что, как вы знаете, нужно построить в июне.

Если вы настаиваете на том, чтобы заранее определить свои требования, произойдет одно из двух:

1. вы построите по спецификации и обнаружите, что построили что-то не то
2. вы будете игнорировать требования, превратив процесс определения требований в напрасную трату усилий, а сами требования — в мертвый документ.

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

Теперь: расширение масштабов. В первом приближении в отлаженном agile-процессе не существует такой вещи, как расползание масштаба. Есть новый масштаб — новые приоритеты и новые требования, которые ведут к новой работе, — но нет никакого сползания .

Первая проблема с расползанием масштаба в традиционном процессе — это когда организация лжет самой себе. Вы пообещали предоставить функции F к времени T на определенном уровне качества Q. ( Возможно, Q никогда не был явным, и вы, вероятно, никогда не собирались делать T в любом случае, но неважно.) Но теперь вы молча переопределили F , чтобы оно означало F+1 , F+2 , вплоть до того, кто знает, 2F , 3F стоит усилий, никогда явно не делая компромиссов между T или Q . Итак , Т поскользнется, иВопрос будет проскальзывать, но никто не признает, что никто за пределами организации разработчиков даже не знает, что это происходит, поэтому где-то после решающего момента, когда вы, наконец, признаетесь в этом себе и, наконец, сообщите своим заинтересованным сторонам плохие новости, они собираются (оправданно ) перевернуть крышки.

Это проблема, которую ваша доска контроля изменений и т. д. призвана предотвратить, — этот цикл отрицания и отказа.

Но даже с процессом контроля изменений, обеспечивающим честность организации, возникает другая проблема. Вы задались целью реализовать F к T , а теперь увеличили объем и сдвинули временную шкалу, и вы на пути к реализации 3F к 3T . С точки зрения команды разработчиков все в порядке.

Однако у более крупной организации большие проблемы, потому что вы не отгрузили никакого программного обеспечения. Вы теряете продажи (или долю разума в проекте с открытым исходным кодом) из-за своих более гибких конкурентов, у которых есть, даже если они поставили только F/2 функций. Вы упускаете возможность получить обратную связь от пользователей, поэтому ваши предположения о том, какие функции нужны вашим пользователям, не соответствуют реальности, и если вы, наконец , выпустите 3F , вы, вероятно, обнаружите, что это не то, что вам нужно. они хотят; вы потратили впустую 1F–2F усилий, и у вас впереди еще 2F–3F , чтобы наверстать упущенное.

Вот почему в Манифесте Agile говорится, что работающее программное обеспечение является основным мерилом прогресса. По сути, гибкая разработка довольно проста:

• Вы строите небольшую вещь
• вы отправляете это
• вы строите следующую маленькую вещь

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

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

Различные agile-практики по-разному защищают от этой проблемы.

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

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

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

Процессы типа Lean/kanban исключают итерации, но «извлекают» функции из бэклога только тогда, когда разработчики готовы работать над ними, то есть после того, как их предыдущая функция перешла в QA и/или была выпущена.

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

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

тлдр; Agile смещает акцент на обнаружение и создание решения для нужд клиента. Agile ценит «реагирование на изменения вместо следования плану», потому что нужно «приветствовать меняющиеся требования», чтобы «использовать изменения для конкурентного преимущества клиента».

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

Давайте сначала рассмотрим классическое управление проектами. В начале объем фиксируется, затем PM надеется правильно оценить стоимость и время. Когда все требования написаны, можно приступать к работе. По мере возникновения изменений и проблем необходимо что-то корректировать. Одним из распространенных решений является добавление большего количества людей, см . «Мифический человеко-месяц» , что увеличивает стоимость. На самом деле, как только проект начинается, два других аспекта (стоимость и время) также становятся фиксированными; любое увеличение любого из них считается неудачей. Основным результатом является отсутствие качества, часто также превышение бюджета и задержка, иногда несоблюдение соглашений об объемах, очень часто неудовлетворение потребностей клиента или упущение рыночных возможностей.

Теперь давайте посмотрим на agile-философию .. Вместо того, чтобы создавать полный набор спецификаций (объема) в начале, а затем пытаться предсказать стоимость и время, определяется основная потребность. Бэклог создается для представления желаний: желаний, которые могут быть или не быть фактическими требованиями. Затем этот список ранжируется в порядке ценности для клиента. Разработка начинается с основных элементов наивысшей ценности. Здесь важно отметить одну вещь: акцент уже смещен на мышление и подход к решению (или продукту), а не на классический проектный менталитет. Команда работает в небольших временных рамках, с фиксированными затратами и временем, чтобы предоставить решение небольшими, качественными, удобными шагами. Масштаб является гибким, потому что корректировки вносятся по мере того, как заказчик и команда лучше понимают, что на самом деле необходимо; они добавляют то, что изначально отсутствовало в желаниях, и удаляют то, что теперь осознается как ненужное или малоценное. Работа может остановиться в конце любой итерации, когда будет достигнут надлежащий уровень функциональности (объем).

В манифесте Agile это описано следующим принципом:

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

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

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

Команда разработчиков

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

Один из способов, с помощью которого сторонники XP могут оставаться честными, состоит в том, чтобы настаивать на написании ошибочного модульного теста (демонстрирующего необходимость усложнения) ПЕРЕД добавлением дополнительной сложности в систему.

http://www.agilenutshell.com/yagni

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

Короче YAGNI (Вам это не понадобится). Это должно работать как для функционального объема, так и для ограничения склонности разработчика перепроектировать систему.

Я думаю, что есть разные ответы на этот вопрос, в зависимости от контекста.

CodeGnome хорошо покрыл область высокого уровня «вне спринта» - в основном добавляйте элементы в отставание и либо расширяйте проект, либо отказывайтесь от других функций.

В рамках спринта этот вопрос становится более тонким. Я думаю, что важно различать «расползание масштаба» и «золотое покрытие» и «изменение в результате обучения».

Ползучесть области и позолота должны быть вынесены за пределы спринта и обработаны, как указано выше. У команды есть поставленная цель с историями и критериями приемлемости, и из-за характера agile-проектов требования часто расплывчаты, когда работа переносится в спринт. Часто во время разработки по мере продвижения работы возникает множество вопросов: «Должны ли мы сделать X как часть этого?» Там, где важно научить команду следовать принципам максимизации невыполненной работы и эффективной работы, чтобы выполнить минимум для достижения цели истории и спринта.

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

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

Означают ли они, что объем изменений вообще не меняется?

• Трудно назвать это «Agile», на самом деле. Несмотря на то, что время и/или бюджет можно изменить, тот факт, что вы не в состоянии принять меняющиеся потребности клиентов, станет серьезным запахом в любом Agile-проекте.

Означают ли они, что объем не увеличивается , но вынимать вещи и возвращать их обратно — это нормально?

• Это довольно просто; когда требуется изменение области действия, вам просто нужно определить, что следует исключить из области действия. Как правило, другим вариантом было бы увеличение времени или стоимости (хотя во многих случаях время является единственно полезным, так как многие способы вложить деньги в поздний проект, будь то с помощью новых членов команды или новых технологий, только сделают его более поздним). к первоначальным необратимым временным затратам). В этом случае, однако, это было бы «ползучестью области действия», и, таким образом, ваш единственный реальный вариант — управлять областью действия, добавляя и удаляя из области действия чистое изменение, равное нулю (или отрицательному, если окажется, что вы действительно в конце концов, вам не нужна эта огромная функция X, поэтому вы можете легко заменить ее меньшей функцией Y).

Означают ли они, что любое изменение масштаба допустимо, но не слишком часто и не бесконтрольно?

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

Может быть и другое значение, которое они имеют в виду, когда используют «расширение масштаба», но я думаю, что вышеперечисленные три являются наиболее распространенными. Если ничего не помогает, отбросьте любые предвзятые мнения и просто подумайте о том, какая реакция в рамках заданных ограничений будет необходима, чтобы принести пользу проекту, компании и клиенту. В конце концов, создание ценности — это и есть Agile.

Мое мнение (IANASM) заключается в том, что не существует такого понятия, как «расползание масштаба». В Agile вы должны работать над наиболее ценными для бизнеса функциями на данный момент в течение короткого периода времени (текущий спринт в терминах Scrum).

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

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

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

Идея состоит в том, что эти итерации должны быть достаточно длинными, чтобы полностью «сделать» набор функций (для определения «сделано» вашей командой — т. е. развернуть в рабочей среде), но не настолько длинными, чтобы изменения в бизнесе не реагировали. достаточно быстро.

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

Agile должен сбалансировать выполнение набора работ и период времени для выполнения этой работы, чтобы владельцы продукта не нервничали, что они никогда не получат «следующую вещь».

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

• Контекст меняется
• Мнения и точки зрения созревают или меняются
• Попытка решения — это опыт обучения, который дает новое представление о проблеме и возможных решениях.

Это цитата из книги « Объяснение экстремального программирования» :

XP — это путь совершенствования к совершенству для людей, объединившихся для разработки программного обеспечения. Его отличают от других методологий:

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

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

Нет такого понятия, как Scope Creep. Есть только более глубокое понимание.

Это предполагает лишь несколько вещей:

1. Вы и ваш клиент достаточно доверяете друг другу, чтобы часто сотрудничать
2. Если у вас фиксированная поставка, вы можете изменить объем
3. Если область действия фиксирована, вы можете изменить ее при доставке.
4. Вы создаете то, что, как вы знаете , ценно для ваших клиентов
5. Вы не отправляете $#^!

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

Я расширил это здесь , если вы хотите копнуть глубже.