Кукурузный лабиринт - одна из моих любимых задач. Это неприятно, особенно когда у вас нет карты и вы занимаетесь этим с маленькими детьми. У кого-то очень мало времени, прежде чем кто-то сойдет с ума, потому что «мы потерялись», или потеряет его, потому что он устал и ему нужно в туалет. И не было бы никакого удовольствия, если бы у нас была карта или GPS, чтобы указать путь. Приятно пытаться разобраться в этом самостоятельно, обнаруживая каждый тупик на пути к выходу из лабиринта.

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

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

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

Кукурузный лабиринт

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

На высоком уровне кукурузный лабиринт - это ряд небольших открытий и решений, которые приведут вас либо глубже в лабиринт, либо к его концу. Каждый раз, когда вы подходите к развилке кукурузного лабиринта, вы принимаете решение, какой путь выбрать. Последовательно идите по правильному пути и… победите!

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

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

Продолжение этой стратегии в лабиринте настроит вашу команду на успешное путешествие по лабиринту. Даже в самом сложном лабиринте команда может работать вместе, чтобы эффективно определить правильный путь через лабиринт.

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

  • Разведка. Какие маршруты являются тупиками, а какие ведут в другие пути?
  • Отчет - поделитесь своими выводами на месте встречи.
  • Решить - определите, как действовать.

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

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

Разработка программного обеспечения как кукурузный лабиринт

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

Разведка

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

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

Отчет

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

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

Решить

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

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

Заключение

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

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