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