Эффективные способы внедрить Agile на рабочем месте?

По вашему опыту (анекдотично или иным образом), каковы некоторые эффективные способы внедрения Agile в не-Agile организацию или компанию?

ОБНОВЛЕНО: Кто-нибудь может рассказать о случаях, когда вы пытались представить Agile, но вас «сбили»? Кроме того, у вас теперь есть ретроспективное понимание, почему вас «сбили»?

ЭТО ТРУДНО, НО НЕВОЗМОЖНО. Если вы не живете в раю. Для конкретных шагов, которые вы можете предпринять, я искренне рекомендую взять копию Fearless Change

• Сначала получите поддержку со стороны руководства . Если вы не сделаете ничего другого, это будет компенсировать это. Если верхний уровень - это «Последний срок вчера», «Рабочие выходные в течение следующих 3 месяцев», «Почему вы пишете тесты, когда это необходимо? кодирование? .. мы можем проверить позже. Додо просто не полетит.
• Посмотрите, подходит ли культура вашей организации для гибкой. Это было кое-что, что я пропустил .. Чтобы позаимствовать строку из книги. Процесс будет легче-быстрее, если культура поддерживает и лелеет новые идеи, дает людям время учиться и делать новые вещи, достаточно терпелив, чтобы поддерживать инновации с долгосрочные выгоды и не считают отказ быть смертным приговором
• Люди : Определите новаторов: ранние последователи: раннее большинство: позднее большинство: соотношение отстающих. Первые 3 - это ваша целевая аудитория изначально ... должна составлять около 30-40% ... это дает вам критическую массу для раскрутки. Проблема в том, что Agile привлекает внимание к слонам в комнате. Недостатки и проблемы становятся легко заметными. Если вы живете в месте, где произошел «взрыв Бозо» (цитируя термин Гая Кавасаки) , изменение будет действительно медленно и больно .. если вообще. Мы склонны считать, что если идея хорошая, она будет принята. Не правда. Многие социологические причины поднимают их головы.
• Далее не пытайтесь слишком много вещей одновременно. Успокойся .. успокойся . Хитрость заключается в том, чтобы использовать рефакторинг-традиционный-подобный подход. Найдите маленькие раны здесь и там и залатайте их проворной повязкой. Убедитесь, что люди понимают практику и преимущества, и они должны принять их с течением времени. Не все прилипнет, но в целом скоро станет лучше. Как скоро зависит от ряда переменных, некоторые из которых находятся вне вашего контроля.
• Это огромные личные инвестиции, чтобы это произошло . Перепроверьте, готовы ли вы взять на себя это обязательство и пройти через взлеты и падения, которые оно приносит. Также вам, возможно, придется передать эстафету кому-то другому или более высокопоставленным. Будьте готовы отказаться от смены владельца ради блага. Не впадайте в синдром «Это мой ребенок».
• Agile различен для каждой команды, каждой организации . Не все, что вы прочитали / предложите, сработает. Пусть принятие поможет вам понять, что будет работать для вашего сценария. Найдите другие способы, которые компенсируют практики, которые не укоренились.

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

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

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

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

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

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

Удачи!

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

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

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

Завяжи им горло, но без них не замечая;)

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

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

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

Улучшайся в первую очередь. В самом деле. Пример - сильный способ говорить о гибкой. Более того, как кто-то уже сказал, избегайте технических определений и просто используйте термины, которые могут понять менеджеры и руководители. Две недели вместо спринта; Планирование вместо Sprint Planning или Planning Game; Менеджер по продукту вместо владельца продукта и так далее. Мишель Слайгер сделала потрясающую презентацию о Agile в Waterfall Enterprise . На самом деле нужно посмотреть видео. Вы также можете быть заинтересованы в других видео о гибкой усыновления .

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

С уважением

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

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

В команде разработчиков внедрение Agile - это гораздо больше, чем вы можете контролировать.

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

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

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

Шаг 1: убедитесь, что ваш проект имеет серьезное отставание, и убедитесь, что он имеет приоритет

Шаг 2: познакомьтесь с практиками SCRUM (управляемые итерации, ежедневные переходы, scrum-master, владелец продукта, графики полного обновления)

Шаг 3: каждая команда представляет итерацию с вылетом

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

Прежде всего, понимайте, что будет сопротивление (БУДЕТ), поэтому будьте готовы справиться с этим.

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

Люди всегда противостоят переменам, и переход к схватке довольно большой. Мотивация и направление являются ключевыми.

Первый шаг - мотивировать людей дать шанс схватке. Я обнаружил, что Google Tech Talk Кена Швабера был очень полезен для того, чтобы заставить людей осознать преимущества схватки, в то же время предоставляя хорошее представление. Начните с людей, которые, по вашему мнению, будут восприимчивы к изменениям, будь то разработчики или менеджеры, чтобы вы могли придать определенный импульс. В какой-то момент необходимость в менеджерах на вашей стороне будет необходимостью, но то, как вы справитесь, зависит от вашей среды.

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

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

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

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

Удачи!

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

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

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

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

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

1) вы можете начать использовать scrum в несколько более свободной форме для немедленного управления существующими рабочими очередями. Но посмотрите и на Канбан.

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

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

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

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

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

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

Несколько лет назад я был консультантом в очень крупной компании (около 20 000 сотрудников), которая выполняла множество крупных программных проектов для предприятий. Я был на одном из них. Довольно критический.

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

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

Любой, включая меня, имел опыт работы со Scrum. Итак, мы обнаружили структуру, сделав ...

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

Я думаю, чтобы внедрить что-то в такое предприятие, вы должны уважать следующие принципы:

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

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

• Вы не должны предлагать изменить всю организацию сразу . Вы должны предложить пилотный проект, за который вы бы взяли на себя ответственность. Я советую вам ставить реалистичные цели, такие как значительное увеличение наглядности того, что происходит в проекте. Это, ИМХО, основной вклад Scrum в управление программным обеспечением. Это позволяет человеческому здравому смыслу действовать и, таким образом, двигаться вперед.

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

Если вы будете следовать принципам и прийти с фактами, это будет работать. О фактах вы найдете в книге « Программное обеспечение за 30 дней»: как гибкие менеджеры преодолевают трудности, радуют своих клиентов и оставляют конкурентов в прахе . Это последняя книга создателей Scrum, Кена Швабера и Джеффа Сазерленда .

В блоге Кена о книге вы можете прочитать:

Джефф Сазерленд и я сделали это. Мы вместе написали книгу, наше первое совместное написание с момента первоначальной публикации Scrum в 1995 году. Что побудило нас? Вопрос, который нам часто задают:

Как мы продаем Scrum нашему руководству?

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

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

[...]

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

Но тогда отдел исследований и разработок решает, что он пойдет гибко. Речь не идет о планировании заранее за два месяца до написания кода. Спринты будут короткими, и после спринтов вы получите оценки с очень низким разрешением материала, который находится в списке заданий / дорожной карте. R & D понимает, что требования меняются слишком часто, чтобы классический водопад был эффективным, но менеджеры по продуктам хотят иметь четкое, продуманное и продуманное видение того, как продукт будет выглядеть через 12 месяцев.

Таким образом, проблема заключается в том, чтобы примирить их. Как я уже сказал, мы видим, что это все время происходит с нашими клиентами. Таким образом, наше решение заключается в объединении инструментов, используемых как для спринтов, так и для долгосрочного планирования. Хорошо, теперь вот часть бесстыдной пробки, так что не стесняйтесь взять ее с крошкой соли. Одной из наших уникальных особенностей является то, что мы используем масштабируемый пользовательский интерфейс для управления задачами. Это означает, что очень легко углубиться в некоторую пользовательскую историю / задачу и уточнить ее. (Вы можете посмотреть, как это выглядит здесь ). На самом деле в нашей системе вообще нет понятия «проект». Это все задачи, содержащие другие задачи, связанные с другими задачами (действительно, фрактал). Это создает хорошее размытие между пользовательскими историями, задачами, проектами, эпопеями и т. Д.

На практике многие из наших пользователей, практикующих гибкие методологии, создают телескопический план, который объединяет долгосрочную дорожную карту (или отставание) с управлением краткосрочными спринтами (или итерациями). Менеджеры по-прежнему видят приблизительный план основных функций, ожидающих добавления, а разработчики просто увеличивают масштаб и решают реальные рабочие задачи. Одним из преимуществ этого является то, что он уменьшает количество «торга», которое происходит, когда менеджеры рассматривают рабочий план. Вместо команды разработчиков, предоставляющей только очень приблизительные оценки (например, «4-6 недель!»), Они получают возможность увеличить масштаб каждой рассматриваемой пользовательской истории и разбить ее на более мелкие куски. Когда вы делаете это, внезапно становится меньше места для торга. Вы тратите 10 минут, разбивая 5-недельную пользовательскую историю на куски размером около 1 дня, и вдруг аргумент не «нет, вы можете сделать это быстрее. нет, мы не можем. да, вы можете». но «вот что входит в эти усилия, включая всю скрытую работу, которую первоначальная оценка не учитывала. Что вы предлагаете исключить? Обеспечение качества? Тестирование? Обучение нового парня? Настройка среды сборки?».

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

Хорошо, я чувствую, что это превращается в коммерческий шаг, поэтому я остановлюсь сейчас. :)