Является ли гибкий подход слишком удобным оправданием для ковбоев?

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

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

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

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

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

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

Agile не более виноват в плохой практике разработки, чем BDUF. Проблема заключается в дисциплине или ее отсутствии в применении практики. Цель практики BDUF - определить направление проекта и заранее определить риски. Цель гибких практик состоит в том, чтобы поддерживать состояние разработки достаточно гибким, чтобы быстро менять направление. Гибкий проект может подготовить подробные пользовательские истории, поэтому команда знает о будущих направлениях и все еще выбирает 2 или 3 для каждой итерации для полной реализации. Проблема остается той же, какая бы методология ни использовалась: руководство позволяет ковбоям впадать в бешенство.

[BDUF: Большой дизайн впереди]

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

Тем не менее, магия в некоторых Agile- методологиях, таких как Scrum, заключается в том, что они предоставляют много информации о проблемах внутри организации. Включая проблемы внутри команды!

Затем вам будет предоставлена ​​возможность решить их по мере их возникновения.

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

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

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

Я вижу, что защита Agile Development говорит, что она не несет ответственности за сбои, вызванные ковбоями. Успех в Agile требует усердия и интеллекта.

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

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

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

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

Agile - это хорошо, если он работает на вашу команду.

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

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

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

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

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

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

(Если вы не поняли из вышесказанного, я не фанат "Capitol-A Agile" в меньшей степени. С другой стороны, я не думаю, что это также поощряет ковбоев.)

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

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

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

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

Организация всегда действовала относительно свободно, «неформально, гибко». Я бы не сказал, что это действительно Agile, это скорее «Agile in name», но просто несуществующая методология на практике. Разные команды работают по-разному, но поскольку общая организационная культура не имеет какой-либо методологии, кроме очень рыхлого процесса «Agile in name only» - это относительно ковбойский и хаотичный процесс, особенно в части интеграции (и во многих случаях ).

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

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

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

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

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

Теперь те, кто говорит «Agile», «XP», «Scrum» и т. Д., Говорят о хрупкости этой конкретной категории методологий. Аргумент таков: зачем использовать методологию, которая может саботироваться одним человеком, которому не хватает дисциплины, чтобы следовать всем правилам? Вопрос верный; однако, это симптом, а не причина. Если точный и значимый (это сложная часть) набор метрик процесса будет определен, проверен и получит своевременную обратную связь, учитывая, что, я думаю, мы обнаружим, что конкретная методология имеет мало общего с успехом. (Кстати, я видел успешные проекты, использующие множество методологий, и вдвое больше неудачников используют одни и те же методологии)

Так, каковы метрики? Они варьируются от проекта к проекту, от команды к команде и время от времени. Полезно для тех случаев, когда важен график доставки, и я лично использовал оценку навыков и качества. Большинство разработчиков могут точно оценить задачи, которые длятся неделю или меньше. Таким образом, один из подходов состоит в том, чтобы разделить проект на задачи на одну неделю разработки и отследить, кто сделал оценку. По мере продвижения проекта они могут менять свои оценки. После завершения задачи, если ее отключение более чем на 10% (1/2 дня), мы рассматриваем это так же, как ошибку - мы определяем, почему оценка была отклонена (то есть таблица базы данных не учитывалась), идентифицируем корректирующее действие (то есть привлечение администратора базы данных к оценке), а затем двигаться дальше. Используя эту информацию, мы можем создать такие показатели, как количество ошибок оценки в неделю, количество ошибок на разработчика,

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

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

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

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

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

Забавно, что никто не считает себя ковбойским программистом. Я держу пари, что многие из плакатов являются или были одним;)

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

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

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

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

• неверно - не в состоянии захватить требования.

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

• обособленно - они не содержат ценной обратной связи от работающей (хотя вырожденной) системы.