Пребывание Agile в водопаде
У нас есть крупное корпоративное приложение, в котором проекты разрабатываются и, наконец, кодируются с использованием формализованного процесса водопада. Мне часто дают изменения кода для не связанных инициатив только потому, что они находятся в том же разделе кода. Все инициативы должны быть перевернуты одновременно. Команда разработчиков также мало что говорит о масштабах или сроках поставки. Мы не можем общаться с пользователями, мы должны пройти через группу требований, которые не знают бизнес.
Есть ли у кого-нибудь какие-либо советы о том, как внедрить даже самые маленькие гибкие методы в такую укоренившуюся среду.
6 ответов
По крайней мере, вы могли бы начать писать модульные тесты или даже - насколько позволяют обстоятельства - самостоятельно тестировать управляемую разработку (возможно, распространяя идеи и среди ваших со-разработчиков). Вы можете многое изменить без управления, даже не заметив ничего;-)
Конечно, в среднем или лучшем месте люди в управлении не совсем глупы. Со временем, когда вам удалось повысить осведомленность об этих проблемах среди команды разработчиков, вы (как команда, вместе) также можете поговорить с высшим руководством и убедить их сделать шаги в правильном направлении. Начните с малого, получите конкретные результаты и опирайтесь на них - и используйте рычаги, находя союзников как в команде разработчиков, так и (насколько это возможно) среди руководства и пользователей.
Очень часто определенные процессы выполняются только потому, что "мы всегда так делали". Если вы можете показать людям, что есть лучшие способы - и доказать это убедительными аргументами - у вас есть хорошие шансы на успех. Обратите внимание, что руководство и пользователи нуждаются в совершенно иных аргументах, чем разработчики. Вы можете попробовать сделать грубые расчеты затрат и выгод (или Google - я уверен, что есть много вещей в сети об этом). Я также помню, что есть хороший материал об этом в первой книге Кента Бека по XP. Вы также можете собирать статистику ошибок, которая со временем (надеюсь) показывает, что функции, разработанные гибким способом, имеют заметно меньше дефектов на более поздних этапах (тестирование интеграции или производство). (Для этого вам нужна система отслеживания дефектов, если у вас ее еще нет.)
Еще один полезный инструмент - это задавать вопросы. Если вам что-то - документ, способ ведения дел - вы не понимаете, решитесь задать вопросы:
- Почему мы делаем это так, как мы?
- Есть ли способ лучше?
- Нужно ли вообще это делать?
- Кому нужен этот документ?
- Какая информация ей действительно нужна из этого?
- Содержит ли она правильную информацию для нее?
- Это актуально?
- Кто обновляет это?
Часто люди просто воспринимают вещи как "данные", но когда вы начинаете спрашивать о причинах, вы можете найти много интересных вещей... и идей для улучшения.
Очень полезный гибкий инструмент - это ретроспектива. После каждой итерации (как бы это ни называлось в реальном процессе) команда собирается вместе и обсуждает
- что пошло не так в этой итерации, и как убедиться, что это не повторится (или, по крайней мере, улучшить это в некоторой степени)
- что прошло хорошо и как сделать так, чтобы это продолжалось
Это может быть довольно легко воспринято руководством, и это хороший способ начать положительные изменения. Самое главное, чтобы проснуться и активировать людей - чтобы все поняли, что успех или провал проекта (в какой-то степени) в их собственных руках, что они могут сделать что-то, чтобы улучшить ситуацию.
По моему опыту, крупные предприятия занимаются рисками, прогнозируемостью и измеримыми результатами. Вам будет проще (хотя, возможно, и не легко) представить Agile, если вы покажете, как он лучше согласуется с этими показателями, чем существующие практики.
Возможность частой отправки, даже если вы еще этого не делаете: используйте инструменты CI и сценарии автоматической сборки для сборки и упаковки вашего приложения. Таким образом, вы готовы использовать любую возможность для постепенного выпуска нового кода, который может появиться.
Измерьте свою производительность сейчас, чтобы у вас была базовая линия: чем больше вы можете измерить, тем лучше.
- Среднее количество часов программиста на "функцию".
- Средняя продолжительность времени между проверкой кода и обнаружением дефектов в этом коде.
- Средний промежуток времени между обнаружением дефектов и разрешением дефектов в производстве.
- Среднее количество времени, необходимое для выявления, устранения и развертывания исправлений дефектов.
- и т.п.
Спроектируйте изменения в этих показателях в Agile-процессе: например, в большинстве случаев, чем раньше мы обнаружим ошибку, тем проще / дешевле ее будет исправить, поэтому преимущества от TDD и быстрых выпусков в QA должны быть легко количественно оценены.
Начните с малого: вам может быть предложено расписание водопадов, но вы все равно можете разбить его на итерации, так что сделайте это. Приведите свои инженерные практики в порядок, затем начните пытаться отрегулировать процесс. Посмотрите, можете ли вы попробовать Agile на небольшом вспомогательном проекте в качестве доказательства концепции.
Найдите спонсора: постарайтесь убедить кого-то в порядке клевания выше, чем вы, в достоинствах Agile. Привлечь их помощь в формулировании аргументов "Agile vs. Waterfall" в терминах, знакомых лицам, принимающим решения.
Будьте терпеливы... это может занять время, чтобы увидеть результаты.
... или нет Если вы глубоко заинтересованы в Agile и получаете нулевую поддержку, найдите новую работу. Да, это полезно для осуществления изменений от животного зверя, но также полезно работать с людьми, которые разделяют ваши идеи о создании программного обеспечения.
Agile - это разрушение стен водопада. BDUF; одновременный многокомпонентный выпуск; отсутствие связи между разработчиками и владельцами бизнес-процессов; Запланированные итерации - все они стоят на вашем пути в процессе водопада.
В моем положении мы разрушили многие из этих стен - и это началось с получения прямого доступа к клиенту. Когда это произошло, клиент получил продукт получше. Это привело к более счастливым клиентам. Это отогнало такие вещи, как BDUF и т. Д.
У нас до сих пор нет настоящих итераций / спринтов, непрерывной интеграции и т. Д., Но мы добираемся до этого. (Старые привычки и все такое.)
Мне кажется, проблема не в том, что вы используете Waterfall, а не Agile. Дело в том, что у вашей реализации водопада большие проблемы. Наиболее очевидно:
Собирается требование, кто не знает бизнес
Водопад может и работает хорошо, если все сделано правильно. Я думаю, что это звучит так, как будто некоторые из вовлеченных людей и как они поступают неправильно, не концептуальный процесс.
Вы, как команда разработчиков, можете по-прежнему координировать свои действия внутри компании с использованием гибких методов (разработка через тестирование, парное программирование, карты историй, CI, общий язык и т. Д.)
Ловкость, на мой взгляд, заключается в том, чтобы иметь возможность быть уверенным в изменениях в программном обеспечении и предотвратить большие потери в функциях, которые никому не нужны в трех шагах по пути водопада. Тестирование и рефакторинг и предотвращение чрезмерного проектирования являются ключевыми здесь.
В зависимости от вашего домена, автоматическое тестирование и непрерывная интеграция должны быть выполнимы.
Кроме того, подумайте о том, чтобы придумать свой собственный, очень детализированный список выкатов (дюймовые камни) для ваших текущих назначенных задач. Это должно помочь вашим оценкам работы быть более предсказуемыми и облегчить вам объяснение любого отклонения графика и незапланированных задач.
В общем, следите за некоторыми показателями в вашей системе. Если вы можете показать, что Agile-техника добавляет ценность (сокращенное время цикла, пониженный уровень дефектов и т. Д.), Вам будет легко продать свое лидерство в этой технике.
... в зависимости от менеджера, вы можете избежать использования слова Agile, особенно если вы просто ищете небольшую победу при использовании одной техники.