Какая методология программирования подойдет нам?

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

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

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

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

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

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

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

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

Скажите им, хорошо, мы пойдем проворным, это требует, среди прочего:

• разделение развития и поддержки
• формальный процесс сбора требований - под контролем ИТ-команды. «Истории» и т. Д. Звучат очень расплывчато, но на самом деле это «формальный» метод, одетый, чтобы выглядеть неформально.
• планирование находится под контролем ИТ-команды.

Если они этого не принимают, то скажите им, что вы не можете быть проворными.

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

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

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

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

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

Возможно ли это изменение в культуре? Да, но в вашем случае почти наверняка нет.

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

Компании НИКОГДА не меняются изнутри, когда деньги легки. Почему они, они успешны, несмотря на неудачи разработки программного обеспечения, а не из-за успехов разработки программного обеспечения.

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

посмотрите на extremeprogramming.org - XP - это форма Agile с легко понятными аспектами, которые вы можете выбрать и выбрать в виде корзины; очень хорошее место для начала

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

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

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

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

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

ТЕПЕРЬ, чтобы ответить на ваш вопрос более прямо:

Учитывая ваш обзор вашей среды, я предлагаю вам сначала выбрать Agile-реализацию (например, Scrum, XP и т. Д.). Затем измените подход к своей среде, четко обозначив процесс работы вашей команды, например:

• Получить запрос от пользователя (ей);

• Приоритезация пользовательских запросов;

• Измерить влияние улучшения на существующую систему (возможно, во время ваших ежедневных / еженедельных регулярных встреч);

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

• Выполните фактическое улучшение (я) на существующей системе (то есть кодирование).

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

Это должно обеспечить некоторую структуру (и порядок), в то же время сохраняя некоторое подобие гибкого подхода.

С учетом вышесказанного помните, что старая английская фигура речи «Как проворный как обезьяна» не была придумана без причины!

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

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

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

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

Конечно, вам нужно инвестировать в юнит / систему / регрессионное тестирование, автоматические сборки, собачьи собачки и т. Д., Чтобы попасть туда, если вы еще не там.

Сначала я бы предложил собрать некоторые данные. Сядьте в спокойное время и выясните, что на самом деле является статус-кво - как это делается. Если менеджмент одержим внедрением чего-то, что они могут назвать гибким, то подумайте, что будет работать для вашей команды, составьте документ, наберите «Agile» по названию, и вы готовы идти вперед. Имейте в виду, что единственное, что они действительно знают об agile, - это слово и некоторая смутная связь с быстротой его обычного определения на английском языке. Итак, я защищаю то, что ваша команда выходит перед проблемой, находит подход, который подходит вам, а затем представляет его вашему руководству как Agile (tm). В противном случае какой-нибудь PHB собирается взять книгу и попытаться вставить квадратный колышек в круглое отверстие, и никто не будет счастлив.

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

Самое большое препятствие - денежное. Если все в зелёном соусе, гораздо сложнее сказать, что что-то не так и нужно что-то менять.

Удачи.

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

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

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

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

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

• Бережливая разработка программного обеспечения - Мэри и Том Поппендик
• Гибкая разработка программного обеспечения - Роберт С. Мартин

и за дополнительный кредит (потому что я думаю, что это отличный компаньон для других упомянутых мной книг):

• Чистый код - Роберт С. Мартин