Как внедрить scrum на предприятии Waterfall?

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

Есть два типа вещей, которые мы создаем в программном обеспечении:

• Новые и отличительные вещи
• Вещи, похожие на то, что мы делали раньше, и хорошо понятные.

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

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

Итак, вот ваше «Обязательное действие»: наладьте взаимодействие с бизнес-экспертами.

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

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

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

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

Этого ни в коем случае недостаточно, чтобы гарантировать успех (ничто не гарантирует), но наряду с другими предложениями это должно помочь вам начать. Удачи!

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

Поскольку в конце каждого спринта есть функциональный продукт, бизнес быстро увидит плоды своих требований. Когда вы запускаете свой (двух)недельный спринт, бизнес устанавливает истории для этого спринта.

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

Чтобы получить одобрение от ваших разработчиков, я делаю быстрые и эффективные стендапы:

• Встреча длится 10 минут, без исключений
• Каждый получает равную долю времени, чтобы заявить
  • что они делали вчера,
  • что они делают сегодня и
  • любые вопросы.
• Таймер издает звуковой сигнал, и следующий человек уходит (в большинстве случаев у нас еще остается время)
• Любые обсуждения запрещены (люди могут встретиться после стендапа, если захотят). Просто продолжайте говорить: «Давайте отключим это».

Это сделает ваших разработчиков счастливыми, потому что они тратят всего 10 минут в день (утром) на короткие встречи. Конечно, начало спринта и ретроспектива длиннее, но мы стараемся сделать их максимально продуктивными.

Вы МОЖЕТЕ изменить свою местную культуру. Вам не нужно много бай-ин*. Просто начните проводить скрамы и спринты и скажите своим клиентам, что они скоро начнут получать работающий продукт.

* Из личного опыта, когда я делал то же самое в 100-летней твердой компании из списка Fortune 500. Это можно сделать, и для этого и существует политика!

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

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

Удачи!!

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

Возможно, вы уже пробовали, но тем не менее изменение методологии (особенно при снижении жесткости процесса) в крупной компании имеет два основных препятствия:

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

Таким образом, Agile может быть ответом на неправильный вопрос.

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

Мое предложение в этом случае состояло бы в том, чтобы иметь хорошего бизнес-аналитика, способного лучше преобразовывать требования между ИТ <-> бизнесом. Если так случится, что этот человек также является скрам-мастером или кем-то в этом роде, отлично! Но я бы сказал, что лучше иметь хорошего BA с некоторыми навыками Scrum, чем Scrum Master (или любую другую роль Scrum) с некоторыми навыками BA.

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

Успех!

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

Глядя на ваши комментарии, все они сводятся к одной конкретной причине - плохим требованиям.

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

Все эти комментарии восходят к одной проблеме — плохим или неполным требованиям.

Итак, на ваш вопрос «Есть ли ДОЛЖНЫ СДЕЛАТЬ, прежде чем я попробую этот пилотный проект?» — да, вы ДОЛЖНЫ получить ответственность за фазу требований, сформулированную и назначенную».

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

Возвращаясь к моему предыдущему комментарию: Scrum может помочь, но только если вы сначала получите ответственность за обработанные требования. Waterfall определенно нуждается в довольно четко определенной области действия, чтобы работать, но Scrum также является своего рода водопадным процессом (одна вещь должна быть сделана перед другой — требования необходимы до разработки, то есть до QA и т. д.). Таким образом, даже переход на Scrum требования должны быть определены лучше, чем то, что вы получаете в настоящее время. С помощью Scrum вы, вероятно, сможете избежать более слабых требований, чем полный водопадный процесс, поэтому, вероятно, это лучшая методология для вашего приложения, но пока вы не исправите другую часть, вы будете продолжать видеть те же результаты.

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

В нашей организации из 12–20 человек (с 3–5 командами) мы добились этого, прочитав книгу Книберга и обратившись к кому-то с опытом, но это был небольшой подъем в гору, чтобы все заработало даже в организации такого размера.

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

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

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

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

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

Гео, очень, очень сложно изменить процесс, используемый всей организацией, особенно крупной. Я работаю в компании, в которой работает около 300 человек, 50% из которых составляют поставки программного обеспечения. В течение последних 18 месяцев я руководил проектами с использованием Scrum (остальная часть организации использует внутренний процесс, который является более водопадным или итеративным). Мой опыт показывает, что, несмотря на проблемы с текущим внутренним процессом и несмотря на то, что мои проекты, основанные на Scrum, выполняются вовремя и с меньшими ресурсами, чем аналогичные проекты без Scrum, по-прежнему наблюдается значительное отсутствие интереса к переходу большей части организации на Scrum. Это в первую очередь потому, что это большие перемены, а люди боятся больших перемен, никогда не бывает подходящего времени, чтобы совершить прыжок (у нас всегда есть большой проект в работе!).

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

Хотя я сторонник Scrum и думаю, что в конечном итоге это поможет в вашей ситуации, я также согласен с другими ответами, что ваша проблема не в процессе, а в требованиях. Сначала я бы сосредоточился на попытке получить требования более высокого качества на раннем этапе. Одна вещь, которая может помочь, — это использование пользовательских историй, их, как правило, проще (меньше усилий) для бизнеса писать, и это увеличивает вероятность того, что они их напишут. Последующие беседы с бизнесом для уточнения деталей в истории будут означать, что ваши разработчики и тестировщики имеют некоторое представление о том, что нужно предоставить. У вас может не быть полной копии записанных деталей, но я считаю, что 80% игры заключается в том, чтобы убедиться, что люди, выполняющие работу, знают, что нужно сделать,

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

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

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

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

Попросите всех участников прочитать:
http://www.halfarsedagilemanifesto.org/ в течение недели.
Затем запланируйте двухчасовую встречу, чтобы поговорить об этом.

Вышеупомянутый ресурс подчеркивает следующие моменты:

Манифест для половинчатой ​​гибкой разработки программного обеспечения

Мы слышали о новых способах разработки программного обеспечения, платя консультантам и читая отчеты Gartner. Благодаря этому нам было сказано ценить:

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

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

• Сотрудничество с клиентами при заключении контрактов в рамках строгих контрактов, разумеется, и при условии строгого контроля изменений

• Реагирование на изменение вместо следования плану при условии наличия подробного плана реагирования на изменение и его точного соблюдения

• То есть, в то время как элементы слева звучат хорошо в теории, мы являемся корпоративной компанией, и мы ни за что не откажемся от элементов справа.