Как представить Agile команде, которая использует жесткие не Agile методы?

16

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

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


Я знаю, что это, возможно, связано с « Как бы вы внедрили гибкую методологию, такую ​​как Scrum », но здесь я задаюсь вопросом о том, как обойти / обойти тот факт, что компания навязывает определенный способ управления SDLC под ложным предлогом, что это единственный способ иметь контрольный журнал.

haylem
источник
Что такое сертификация? Это ISO-9000?
Роберт Харви
1
Вы немного света на детали; если сертификация требует определенного минимального уровня артефактов, чтобы оставаться сертифицированным, и компания уже плотно сопоставила эти артефакты с вашим процессом разработки таким образом, чтобы свести к минимуму воздействие, то нет никаких обходных путей.
Роберт Харви
@ Роберт Харви: ИСО-9001 был бы хорошим примером. Все, что требует проверяемых требований, тестирует спецификации и отслеживаемость для владельцев документов и задач.
Хайлем
@ Роберт Харви: Да, но картографирование должно быть проверяемым. Насколько я могу судить, большинство систем отслеживания проблем / дефектов / задач / ошибок могут быть частью контрольного журнала, поскольку они регистрируют владение задачей с течением времени. И даже может быть связан, в случае разработки программного обеспечения, с SCM для отслеживания номеров редакций. Кроме того, вы можете использовать свой трекер, чтобы идентифицировать требования, f-спецификации и тестовые идентификаторы, а также получить свои матрицы отслеживания оттуда.
Хайлем
@ Роберт Харви: особенно учитывая то, что отслеживание ISO-9001 не так сложно получить и поддерживать, но часто кажется, что его нужно рассматривать как нечто чрезмерно избыточное и многословное.
Хайлем

Ответы:

12

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

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

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

Затем вам нужно обобществить эту точку зрения и получить одобрение группы качества или отдела стандартов или как там это называется.

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

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

В крупных организациях контроль и надзор за крупными программами осуществляются с помощью офисов мониторинга проектов (PMO), которые проводят традиционное планирование для калькуляции затрат / учета / управления ресурсами и т. Д. - следовательно, им требуется много документации, но они могут отслеживать прогресс, используя Agile-методы (таблица выгорания SCRUM для одного). Им нужно знать, как такие методы, как непрерывная интеграция, помогают им раньше, а не позже, и, следовательно, для продуктивности каждого лучше избавиться от накладных расходов.

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

Йосек
источник
В то время как другие ответы были хорошими, я думал, что ваш самый трудный, чтобы попытаться ответить на конкретный вопрос, а не просто дать общие советы по использованию agile и попытаться выяснить, почему мы хотели бы использовать его. Хороший ответ. Благодарю.
Хайлем
@haylem: рад, что это помогло. в нашем случае мы назначили увлеченного члена команды Agile Champion для содействия переходу. Он дал всем нам знать об этом. Может быть, вы могли бы стать волонтером для такой роли.
JoseK
8

Сначала я бы отделил Скрам от Канбана.

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

Скрам принципиально отличается в том смысле, что это то, что вытеснит существующий процесс.

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

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

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

  • Спросите себя, почему вы хотите использовать Scrum . Вам нужно решить реальную проблему?
  • Убедитесь, что ВЫ привержены этому, потому что никто не сделает это за вас. Вы будете владельцем вещи. По крайней мере, пока это не принесет положительный эффект в организации
  • Тренируйся . Книг и интернета мало. Сначала идите на курс, иначе вы резко увеличите свой шанс неправильно внедрить Scrum. Что, вероятно, приведет вашу команду к худшим результатам, чем раньше
  • Сначала продай команду . Вы должны иметь их полную поддержку, очевидно,
  • Не предлагайте изменения, предложите тест . И подумай об этом. Scrum может не подходить для вашей организации (или для вашей команды)
  • Найти спонсора в топ-менеджменте

источник
+1: «Спросите себя, почему вы хотите использовать Scrum. Вам нужно решить реальную проблему?»: Очень хороший момент. Прежде чем внедрять новый способ работы, нужно спросить, что он пытается решить. К сожалению, внедрение SCRUM (или любого другого метода) для решения несуществующих проблем просто создаст накладные расходы и снизит производительность, а не увеличит ее (я говорю из непосредственного опыта).
Джорджио
3

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

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

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

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

Нико Хюйсамен
источник
1

Я - проворный тренер, и одним из ключей к изменению инициатив является участие на всех уровнях! Это включает руководителей, команды разработчиков, менеджеров и т. Д. Прежде чем объявить о больших или малых изменениях, я бы посоветовал сначала пригласить людей на борт. Делать это в разговоре от третьего лица - это самый простой способ для людей начать использовать новые идеи. Что такое третье лицо? Блог, видео на YouTube, презентация и т. Д. Таким образом, эти люди могут начать выдвигать свои собственные идеи и под вашим влиянием вступят в борьбу с инициативой перемен.

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

Канбан: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI

KanbAnimation
источник
+1 за бай-ин, особенно учитывая комментарии в вопросе, показывающие отсутствие бай-ина.
Майкл Даррант
@KanbAnimation: Я думаю, что вы должны сначала спросить себя, хорош ли SCRUM для компании, в которой вы пытаетесь его представить. (Из моего непосредственного опыта) SCRUM не лучше для всех видов проектов, и внедрение не делает всегда делает компанию более эффективной. Убедительные руководители (которым может не хватить технических знаний, чтобы понять последствия), чтобы ввести SCRUM, могут в долгосрочной перспективе нанести ущерб компании, если SCRUM не подходит для тех проектов, которые они делают.
Джорджио