Мои мысли о проблемах, возникающих при выполнении четвертого принципа Agile
В этом посте я хочу сказать, что для создания хорошего программного обеспечения разработчики и деловые люди должны стать намного ближе друг к другу. Я с нетерпением жду выкриков насмешек с обеих сторон в комментариях ниже!
Я собираюсь написать этот пост, рассказывая о двух «лагерях»: деловые люди — это менеджеры, бизнес-аналитики, директора и т. д., а технические специалисты — разработчики, тестировщики, специалисты по контролю качества и т. д. Очевидно, что в реальной организации существует континуум между ними, но я буду использовать простую модель «двух отдельных лагерей», чтобы проиллюстрировать свою точку зрения.
Agile-манифест изменил способ создания программного обеспечения. Я бы назвал его одним из самых важных документов, касающихся компьютерных наук, за последние 20 лет. Но, к сожалению, я считаю, что agile-движение не смогло… оправдать свое обещание.
Манифест детализирует двенадцать принципов, которых мы, разработчики, должны стараться придерживаться.
Эти двенадцать принципов — чрезвычайно действенный рецепт успеха при создании программного обеспечения. Но даже с учетом этого рецепта успеха многие проекты все равно терпят неудачу. Почему это?
Я думаю, это потому, что, хотя все говорят, что они «гибкие», в большинстве случаев это ложь. Едва ли кто-нибудь когда-либо даже смотрел на agile-манифест, не говоря уже о том, чтобы действительно пытаться «жить по принципам».
В этой серии постов я рассматриваю двенадцать принципов, перечисленных в манифесте, и действительно думаю о том, что они на самом деле означают с точки зрения личных и организационных изменений, необходимых для того, чтобы заставить их действительно работать.
Это четвертый пост в серии, и он рассматривает четвертый принцип, который
Деловые люди и разработчики должны ежедневно работать вместе над проектом.
Почему это хорошая идея?
Этот принцип даже не должен существовать. Насколько очевиднее может быть то, что люди, которые управляют бизнесом, должны тесно сотрудничать с людьми, которые создают продукты, от которых зависит бизнес?
Чтобы программный проект был успешным, он должен соответствовать двум основным принципам:
- Программное обеспечение должно работать по назначению, быть технически надежным и удобным в сопровождении.
- Продукт должен приносить прибыль бизнесу или удовлетворять другие потребности бизнеса.
Ни техническая команда, ни бизнес-команда сами по себе не в состоянии решить обе эти задачи. Для выполнения обоих требований требуется тесное сотрудничество между бизнесом и технической командой.
Само собой разумеется, что очень тесное сотрудничество между этими двумя «лагерями» сделает продукт более успешным, но, по моему опыту, эти два лагеря часто сталкиваются друг с другом только на собраниях по обзору спринта, где — давайте будем честными — трещины устраняются. замалчивается, и не всегда говорят правду…
Очевидно, что необходимо более тесное сотрудничество, но на практике это происходит редко.
Что сложного в этом?
Как и в случае со всеми принципами Agile-манифеста, это звучит просто, но за этой кажущейся простотой скрывается ряд действительно сложных проблем. Чтобы действительно «жить» по этому принципу, могут потребоваться значительные организационные, командные и проектные изменения.
Во-первых, я считаю правильным сказать, что во многих организациях существует менталитет «мы и они» между техническими и деловыми людьми в организации. Это происходит из-за того, что два лагеря имеют очень разные наборы навыков и часто очень разные интересы (в деловом смысле) друг от друга. Действительно сложно эффективно общаться с разными наборами навыков, и это может вызывать разочарование.
Часто потребности и желания каждого «лагеря» противоречивы. Техническая команда вполне может захотеть провести спринт по обслуживанию или спринт по производительности, что вполне может быть правильным выбором с технической точки зрения. Выплата технического долга чрезвычайно важна. Деловые люди могут знать, что у них есть еще один неотложный финансовый долг, который нужно погасить, и что отсрочка выпуска проекта поставит под угрозу существование компании. Кто прав, а кто виноват в конечном счете, можно узнать только в зеркало заднего вида, а увидеть это с точки зрения друг друга сложно.
Есть еще один вопрос для рассмотрения. Организации почти всегда строятся на иерархии. Как правило, в этой иерархии деловые люди располагаются над технической командой. Говорить правду власти тяжело, от этого никуда не деться, но и принимать мудрость от нижнего эшелона иерархии тоже тяжело. Это не хорошо для общения или сотрудничества.
Я часто наблюдал, как разработчики преуменьшают серьезные проблемы с кодовой базой или дают обещание, которое они могут с трудом выполнить в отношении даты поставки. Я также наблюдал, как люди, не являющиеся техническими специалистами, игнорируют явно более информированное мнение разработчиков, говорящих им, что что-то просто невозможно сделать. Оба являются примерами плохой коммуникации, и оба очень вредны для успеха проекта.
Наконец, я обнаружил, что очень часто разработчиков не интересует деловая сторона вещей, и они «просто хотят кодировать». Это прискорбно, но я думаю, что это факт жизни, который нужно принять. Я обнаружил, что гораздо интереснее работать над продуктами, в которых у меня есть хоть какое-то представление о бизнесе, рынке и клиентской базе.
Что люди делают неправильно?
Поскольку это сложно, этот принцип часто выполняется очень плохо или не выполняется вовсе.
Во-первых, в начале проекта бизнес часто выдает разработчикам неполные или трудновыполнимые «спецификации», а затем ожидает, что они выполнят все свои требования и даже больше.
На протяжении всего проекта единственным взаимодействием между лагерями часто является встреча по обзору спринта каждые две или три недели. Это слишком редкая каденция и (на мой взгляд) ужасный форум для ясного и открытого дискурса. Люди представляют свою работу, и при этом они по своей природе уязвимы и, естественно, будут «защищаться».
Наконец, два лагеря обязательно встретятся, когда выяснится, что проект опаздывает, возможно, ближе к концу цикла, и вина должна быть распределена…
Все вышеперечисленное — абсолютные провалы в общении с обеих сторон.
Я редко видел какие-либо усилия:
1. Чтобы команда разработчиков действительно понимала рынок, на котором будет продаваться их продукт.
2. Команда менеджеров, чтобы действительно понять ценность хорошо поддерживаемого кода и погашения технического долга.
Что нужно сделать, чтобы сделать это правильно?
Выше я упомянул, что существует проблема с организационной иерархией, которая мешает четкому и честному общению. Первое, что необходимо внедрить, это коммуникативный форум, где все равны, и нет никаких негативных последствий ни для кого из того, что там сказано. Еженедельная ретроспектива — хороший способ сделать это. На нем должна присутствовать вся команда, и это действительно должно быть одно из самых важных собраний в календаре.
Важно отметить, что на этой встрече никто ничего не демонстрирует, это просто форум для обсуждения:
- Что было хорошо на той неделе?
- Что не ладилось на той неделе?
- Какие идеи или мысли были у людей на той неделе?
Однако этот принцип требует ежедневной командной работы, а не еженедельной. Кто-то из бизнеса должен присутствовать на ежедневных стендапах, которые проводит техническая команда. И, несмотря на присутствие «босса», техническая команда должна продолжать открыто и честно говорить о том, над чем они работают и что им мешает. В свою очередь, деловая сторона не должна пытаться взять на себя эту встречу. Стенд-ап максимум 10 минут… верно?
Для менеджеров — тяжелая пилюля. Нравится вам это или нет, программное обеспечение будет готово, когда оно будет готово. Оценивать программное обеспечение сложно, и лучшее, что вы получите, — это обоснованное предположение. По моему опыту, разработчики (включая меня) часто переоценивают то, чего они могут достичь за определенное время. Чем активнее бизнес вовлечен в процесс разработки, тем лучше он справляется с причинами задержек.
В основе этого лежит общение. Четкое, открытое, честное и эффективное общение. Другого пути нет.
А четкая, открытая, честная и эффективная коммуникация — это сложно. Это сложно во всех сферах жизни, но, возможно, труднее всего в деловой/корпоративной среде.
Однако с этим нет ярлыков, и преимущества очевидны. Подготовьте свою команду к трудным разговорам и действительно начните жить по этому принципу!
Want to Connect? You can get in touch on Linkedin.
