Проблемы и решения
Привет друзья. В этой статье я опишу пять способов обеспечить соблюдение вашей командой разработчиков графиком поставки. Эта статья является продолжением статьи Как оценить команду разработчиков, где я описал пять показателей, которые менеджер может использовать для оценки общего состояния команды разработчиков. Доставка программного обеспечения - одна из важнейших задач, выполняемых командой по понятным причинам, поэтому очень важно, чтобы они выполнялись вовремя и с высоким качеством. Итак, приступим.
Постановка задачи
Команда инженеров, разрабатывающая программное обеспечение, которое вы используете, - это отличная группа людей. Они производят отличное программное обеспечение и очень внимательны к своим пользователям. Они всегда стремятся понять, как они могут помочь бизнесу, и никогда не отказываются от хорошей идеи или предлагают помощь, когда кто-то кричит. Звучит здорово, не правда ли? Единственная проблема здесь в том, что они никогда не соблюдают ни один из своих графиков доставки. Иногда задержки небольшие, всего несколько недель или максимум месяц, однако иногда задержки могут растягиваться на шесть месяцев и более. Когда команда постоянно пропускает сроки доставки, это довольно хороший признак того, что у них есть серьезные проблемы, которые необходимо решить. Итак, давайте разберемся, что здесь может пойти не так.
Так что же здесь может быть не так?
Есть множество причин, по которым команды не выполняют свои расписания. Я не буду освещать то, что находится вне нашего контроля, например стихийные бедствия и тому подобное. Мы будем покрывать только те предметы, которые в основном нанесены самим собой, либо самой командой, либо бизнесом, включая, но не ограничиваясь:
Команда не полностью понимает требования
Это может вызвать дорогостоящие переделки и задержки, если основные требования неправильно поняты или полностью упущены. Если команда реализации не полностью понимает, что требуется, это может иметь косвенный эффект на оставшуюся часть проекта. Неправильные предположения о времени / ресурсах, необходимых для доставки, технических аспектах поставки и степени риска, связанного с внесением этих изменений в программное обеспечение, могут повредить окончательный график поставки.
У команды нет данных о графике доставки
Когда команде доставки навязывают крайние сроки без консультации, это имеет демотивирующий эффект, при этом участие в соблюдении крайнего срока является первой причинно-следственной связью. Кроме того, не имея возможности внести свой вклад в график доставки, команда не может указать на какие-либо проблемы, которые затруднят соблюдение этого срока. Короче говоря, произвольно назначенный сверху график доставки обречен на провал.
Команда отвлеклась
Еще одна серьезная проблема для доставки - это когда группа доставки отвлекается на разные задачи и теряет график доставки. Время - единственный ресурс, который вы не можете купить больше, поэтому, когда он уходит, команда пропускает свой график доставки и отстает. Если все задачи, связанные с проектом, не будут тщательно отслеживаться, график доставки окажется под реальной угрозой. Неважно, сколько героических ночей команда выставит в последнюю минуту.
У команды возникли технические проблемы, из-за которых возникли задержки
Многие программные проекты были разрушены из-за технических проблем, и это по-прежнему остается одной из основных причин перерасхода программного обеспечения сегодня. Технические проблемы могут варьироваться от проблем с производительностью до совместимости устройств или сбоев при загрузке программного обеспечения. Какой бы ни была техническая проблема, все они могут нарушить график доставки. Специализированный человек должен полностью учитывать технические риски, чтобы обеспечить должный уровень дизайнерского мышления, чтобы гарантировать, что они не задержат проект.
Вещи всегда падают между трещинами
Независимо от того, что делает команда, есть вещи, которые упускают из виду и забывают. Будь то пользовательская документация, написание модульных тестов, нагрузочное тестирование или документация по развертыванию, эти забытые элементы могут задержать проект доставки, если они не были завершены. Каким образом недостающая часть документа может задержать проект, спросите вы? Если вы работаете в организации, в которой есть несколько отделов, ответственных за разные области, вам часто необходимо определить возможность взаимодействия между ними. Обычно это делается в форме документации о передаче или контрольных списков. Если критерии передачи обслуживания не выполняются, например. Документация для конечного пользователя обновлена или завершено и пройдено тестирование на проникновение, после чего заключительный этап развертывания проекта может быть отложен до тех пор, пока он не состоится. Независимо от позиции, у группы доставки должна быть формальная методология, чтобы гарантировать, что все "I" будут отмечены точками, а "T" перечеркнуты.
Лучший подход
Хорошо, давайте рассмотрим пять способов, которые помогут нашей команде инженеров выполнить поставленные задачи. Теперь, конечно, нет серебряной пули, и проекты все еще могут отклоняться от графика, но следование приведенным ниже методам даст команде больше шансов на успех.
1). Убедитесь, что требования четко определены и поняты
Важно обеспечить, чтобы требования (функциональность) были четко определены и поняты командой. Наличие набора четко определенных требований может показаться базовой задачей, и вы будете правы. Однако два фактора сильно усложняют эту задачу; это Детали и Связь.
Дьявол кроется в деталях
Старая пословица очень верна, что дьявол кроется в деталях. При разработке программного обеспечения это верно вдвойне: мелкие элементы оказывают значительное влияние на конечный результат. Если все детали не были конкретизированы и зафиксированы, это может потребовать дорогостоящих доработок для исправления нижестоящих. Затраты на исправление неправильной спецификации намного меньше, чем на исправление сломанного программного обеспечения ближе к концу проекта. Прекрасным примером здесь может быть отсутствие нефункционального требования относительно времени отклика. Отсутствие упоминания о том, что процедура, которая должна быть завершена менее чем за 1 секунду, может привести к тому, что разработчики выберут другой путь в разработке, который, будучи более легким в выполнении, никогда не даст результатов менее чем за 1 секунду, необходимых для бизнеса. Такая ошибка может привести к тому, что вся программа будет переписана, чтобы выполнять ее по мере необходимости, и это действительно очень дорогостоящая ошибка.
Общение - это то, что делает слушатель
Это цитата Марка Хорстмана («Инструменты для менеджеров»), который изначально был вдохновлен Питером Друкером, великим консультантом по менеджменту, который, по сути, изобрел современные методы управления. По сути, говорящий просто произносит слова, а перечисляющий - тот, кто их воспринимает и придает им значение. Это очень верно в отношении требований к программному обеспечению. Бизнес может иметь подробные бизнес-требования, однако, если они будут неправильно поняты или неверно истолкованы командой инженеров, тогда будут реализованы неправильные требования и график поставок будет пропущен. Важно помнить, что разработка программного обеспечения - это во многом международное дело, в котором участвуют разработчики со всех уголков земного шара. Небезопасно предполагать, что английский является первым языком, на котором говорят, поэтому важно обеспечить понимание требований и, что более важно, их смысл.
Как добраться
- Сбор требований. Большинство требований или пользовательских историй начинаются с обсуждения с представителями компании. Эти разговоры имеют место, чтобы конкретизировать то, что требуется. Эти требования могут быть задокументированы любым способом (пользовательская история или более подробная спецификация), если они зафиксированы и просты для понимания. Мы не будем вдаваться в религиозные дискуссии о том, что лучше: спецификация требований или пользовательская история, поскольку я считаю, что для каждого из этих методов есть место в зависимости от того, чего вы пытаетесь достичь, но это скорее история для другой пост.
- Время на анализ или обдумывание. Важным элементом, который часто упускают из виду, особенно в спешке, чтобы стать Agile, является время анализа, которое требуется всем бизнес-аналитикам, чтобы по-настоящему взяться за поставленную задачу. Это время позволяет аналитику взглянуть на проблему с разных сторон, имея время подумать над вопросами или вещами, о которых компания не задумывалась, которые затем могут быть подтверждены компанией для повышения качества требований.
- Начало проекта: После того, как аналитик собрал требования и получил некоторое время для анализа, следующим шагом будет начало проекта. Начальные этапы - это события, которые могут длиться пару дней или пару недель в зависимости от размера рассматриваемого проекта, они дают возможность команде, ответственной за реализацию проекта, собраться вместе, чтобы обсудить данный проект. Это время для общения инженеров, аналитиков и деловых людей, чтобы вместе обсудить то, что требуется, чтобы все были на одной странице. Здесь нюансы могут быть выявлены словами, а технические проблемы могут быть решены, по крайней мере, на доске или бумаге, пока группа доставки не почувствует себя уверенно, что они понимают, кто, что, как и как долго проект.
- Хранить в журнале очереди: Требования, подтвержденные компанией, должны храниться в журнале очереди продукта. Требования должны быть отсортированы в порядке приоритета бизнеса, чтобы инженерная группа могла легко понять наиболее важные элементы для бизнеса. Это станет важным во втором пункте. Бэклог продукта - это живой документ, доступный как для инженеров, так и для бизнеса.
2). Тщательно устанавливайте график доставки с учетом информации от команды доставки
Лучший способ получить точную оценку того, когда будут готовы проект, выпуск или исправление ошибки, - это спросить людей, которые выполняют эту работу. Конечно, у нас бывают ситуации, когда бизнесу необходимо удовлетворить критическую потребность бизнеса, которая была совершенно неожиданной, а контрольная дата - это абсолютная черта на песке. Это особенно верно в отношении нормативных изменений, которые, как правило, нельзя откладывать. Однако проработка деталей с командой доставки по-прежнему является лучшим способом получить хороший результат, так как команда может посоветовать сроки и этапы доставки, чтобы проект был завершен вовремя.
Время доставки
Чтобы определить, сколько времени потребуется для завершения проекта, нам нужно сложить время, необходимое для доставки каждой отдельной части. Сроки доставки могут быть долгими или короткими, в зависимости от объема и типа работы, которую необходимо доставить. На сроки доставки также могут повлиять планы на отпуск и другие проекты, которые команда должна поддержать. Команда доставки может сообщить обо всех этих различных факторах, которые могут повлиять на график поставки, а также использовать информацию, полученную с самого начала проекта, для оценки времени, чтобы предоставить требуемые функции. Теперь, в зависимости от продолжительности графика доставки, бизнесу может потребоваться доставка определенных рабочих элементов в первую очередь, чтобы соблюсти требуемые сроки. Вот тут-то и появляется поэтапная доставка.
Поэтапный показ
Поэтапная доставка - это когда мы разбиваем нашу общую поставку на более мелкие части, которые мы доставляем постепенно, пока не будет доставлен полный объем. Поэтапная доставка позволяет бизнесу получить программное обеспечение быстрее, чем обычно, и завершить приемочное тестирование и развертывание. Поэтапное выполнение работ - важный рычаг, который нужно использовать, если у вас нет времени для выполнения полного объема поставки, позволяя команде предоставлять ценность упорядоченным образом, не чувствуя спешки с соблюдением невозможных сроков.
Как добраться
- Вовлеченность команды: команда участвует в установлении графика доставки. Воспользуйтесь знаниями команды о системах, технической и предметной экспертизе. Никогда не принимайте никаких решений о доставке, не посоветовавшись с командой, не получив их отзывов и, что еще более важно, не соглашаясь с графиком.
- Праздники и отпуск: всегда учитываются при принятии решений о графике доставки. Всегда следите за тем, чтобы ваши планы отпусков были на виду, и принимайте их во внимание. Не пытайтесь втиснуть освобождение непосредственно перед тем, как кто-то уйдет в отпуск. В результате выпуск всегда будет поспешным и подверженным ошибкам.
- Готово - готово. В графике доставки остается достаточно времени, чтобы выполнить определение команды: «Готово». Это не должно быть предметом переговоров. Принуждение команды к сокращению сроков поставки является недальновидным и нелогичным.
- Начало проекта. Начальный процесс, о котором говорилось на первом этапе, - это отличный способ для команды освоиться с предъявляемыми требованиями и выявить все функциональные и нефункциональные аспекты работы. Начальный процесс является обязательным, особенно для более существенной части работы.
- Поэтапное выполнение: Поэтапное выполнение нескольких меньших объемов доставки для более быстрого предоставления ценности бизнесу - отличный способ снизить риск перерасхода. Команда может посоветовать, что они могут делать и когда.
- Изменения в объеме. Все изменения в объеме должны повлиять на график доставки. Если объем увеличивается, график доставки сдвигается. Уменьшение объема также может сократить сроки доставки, однако, если команда уже вложила усилия в предмет, который был исключен из области действия, экономия времени будет уменьшена.
3). Установите регулярные вехи, чтобы продемонстрировать прогресс
Один из главных «убийц» графиков поставки - это команда, отвлекающаяся на другую (возможно, более интересную) работу и слишком поздно оставляющая работу над проектом. Трудно наверстать время в конце проекта, когда команда должна укреплять код и готовиться к тестированию и принятию пользователями. Установка регулярных этапов или ритуалов во время проекта - отличный способ убедиться, что команда сосредоточена на поставленной задаче. Есть несколько способов включения регулярных контрольных точек в наш процесс доставки: спринты и демонстрационные мероприятия.
Спринты
Спринты - это гибкий метод доставки программного обеспечения, при котором требования, которые необходимо решить, разбиваются на небольшие части, называемые пользовательскими историями. Пользовательские истории - это то, над чем команда работает во время спринта. Планирование выполняется до начала спринта, и согласовывается, что будет выполнено во время спринта. Спринты обычно длятся две недели. Однако можно выбрать любую продолжительность, если она не растягивается слишком долго. Обычно мне нравится работать в двухнедельных спринтах. В конце спринта обычно бывает ретроспектива. Ретроспектива (Retro’s) позволяет команде оглянуться на то, что сработало, а что нет. Ретро-стиль не обязателен для каждого спринта, но хорошо собраться вместе даже неформально, чтобы обсудить, как прошел прошлый спринт.
Витрина продукта
Витрины продуктов - это ритуалы, позволяющие команде продемонстрировать прогресс. Мероприятия-витрины регулярно проводятся во время проекта и могут привлекать представителей бизнеса, чтобы продемонстрировать прогресс и то, как все будет работать. Это также дает команде по реализации точку фокусировки, чтобы гарантировать, что они продолжают выполнять задачу, с регулярными контрольными точками, обеспечивающими мотивацию.
Как добраться
- Выполнение спринтов. Разделите работу команды с помощью пользовательских историй и спринтов, чтобы разбить более важные задачи на более мелкие части, которые можно выполнять каждые две недели. Регулярная барабанная дробь спринта (планирование, выполнение, ретро) позволяет команде сосредоточиться на выполнении и получении небольших побед.
- Покажи: заставьте команду продемонстрировать свою отличную работу во время демонстрации продуктов. Пригласите ключевые заинтересованные стороны бизнеса, чтобы они были вовлечены. Используйте витрину, чтобы убедиться, что мы на правильном пути.
- Отмечайте победы. Отметьте это знаменательным событием, когда команда достигнет важной вехи или успешной презентации. Это может быть быстрый напиток в конце дня или пирог на следующий день, или даже простое признание хорошо выполненной работы.
4). Иметь сильное техническое лидерство
Техническое лидерство (технический руководитель) является важным аспектом любой команды разработчиков или разработчиков программного обеспечения. Техническое руководство руководит общими техническими аспектами разрабатываемого программного обеспечения. Решения, касающиеся языков и фреймворков, дизайна и архитектуры программного обеспечения, принимаются техническим руководителем. Технический руководитель также будет направлять и наставлять младших разработчиков, определяя основы того, как они будут доставлять программное обеспечение, устанавливать стандарты кодирования и руководить процессом проверки кода. Технические лидеры по-прежнему должны работать с инструментами, но часть их времени необходимо выделять на руководство командой, чтобы не перегружать их. Два важнейших элемента технического лидерства способствуют успеху команды инженеров: коммуникация и технические навыки.
Общение
Важная отличительная черта любого лидера - коммуникабельность. Коммуникация необходима для взаимодействия на всех уровнях, будь то взаимодействие с бизнесом, их коллегами или руководством. Сейчас у ИТ-специалистов есть немного плохая репутация плохих коммуникаторов, однако, чтобы быть эффективным, техническому руководителю необходимы отличные коммуникативные навыки.
Технические навыки
Это самоочевидно, но эффективный технический руководитель должен быть хорош в техническом плане. Независимо от используемого языка программирования или архитектуры, ваш технический руководитель должен понимать это изнутри и снаружи. Если компания переходит на новые технологии, технический руководитель должен иметь возможность быстро изучить их и адаптироваться. Технический руководитель становится его помощником, когда менеджеру по развитию нужно выполнить работу.
Как добраться
- Техническое руководство: Технические руководители должны нести ответственность за техническое руководство (язык программирования, дизайн программного обеспечения, рабочие процессы разработки и т. д.), а также надзор за персоналом разработчиков.
- Объем и требования. Технические руководители должны участвовать в определении объема и проверке требований, чтобы давать рекомендации и выявлять любые потенциальные проблемы до того, как они повлияют на график поставки.
- Наставничество и руководство. Технических руководителей следует активно поощрять к наставничеству и наставничеству младших членов команды. Многое из этого будет неформальным и органичным, если будет поощряться и культивироваться руководством.
- Проверка кода. Проверка кода является основной обязанностью технического руководителя. Технический руководитель должен активно контролировать проверки кодовой базы, обеспечивая соответствие стандартам кодирования, согласованным командой разработчиков.
- Технический долг: Управление техническим долгом необходимо отслеживать и контролировать. Хотя техническая задолженность не связана напрямую с каким-либо выпуском или проектом, она может быстро сорвать планы, когда достигнет стадии, влияющей на реализацию. Технические руководители несут ответственность за управление техническим долгом, чтобы обеспечить его устранение до того, как он станет серьезной проблемой.
5). Обеспечьте соблюдение методологии разработки
Методологии разработки - важная часть того, как доставляется программное обеспечение. Методологии описывают, как команда создает программное обеспечение, с подробным описанием всех происходящих процессов и ожидаемых результатов в конце каждого из них. Каждая команда разработчиков программного обеспечения использует методологию разработки. Однако они отличаются от того, как они реализованы. У некоторых есть подробный набор документации на своей вики, в которой описывается их методология, в то время как другие команды просто говорят о том, как они работают здесь. Примеры методологий включают Agile (scrum, kanban, XP и др.), Waterfall, Hybrid и т. Д. Методологии разработки обеспечивают основу для доставки программного обеспечения, гарантируя выполнение основных задач в дополнение к созданию критических артефактов. Методологии разработки создают два важнейших элемента для команды разработчиков: общий сценарий и выход на этап.
Общее пособие
Методологии разработки обеспечивают общее понимание процесса разработки. Методологии разработки охватывают все аспекты разработки, от того, как мы собираем и документируем требования, рабочие процессы кода (код, экспертная оценка, методы ветвления) до тестирования (прогрессивное, регрессионное, модульное и интеграционное) и, наконец, управление выпуском и развертывание. Разработчикам важно понимать, как ориентироваться в этом, чтобы выполнять свою работу.
Ворота сцены
Методологии разработки (могут) также обеспечивать выход на этапы цикла разработки. Эти ворота этапов являются точками обзора, которые определяют, можно ли перейти к следующему этапу. Хорошие примеры здесь включают проверку требований во время начального процесса, чтобы убедиться, что мы полностью понимаем требования, или, действительно, этап регрессионного тестирования, чтобы остановить появление ошибочного кода.
Как добраться
- Методология разработки. Убедитесь, что вы задокументировали выбранную вашей командой методологию и сохранили ее в вики. Внедрите методологию вместе с командой. На внедрение нового поведения может потребоваться некоторое время, так что наберитесь терпения.
- Определите правила группы. Существенным элементом вашей методологии должны быть правила вашей команды и определение того, что сделано. Командные правила определяют, как команды будут работать друг с другом, гарантируя, что каждый будет работать таким образом, который учитывает все типы личности.
- Определение done: определение done определяет, поскольку название предполагает, что команда считает законченной единицей работы. Это варьируется от разработанных / протестированных / задокументированных / созданных модульных тестов и всего, что находится между ними.
- Тестирование тестирование тестирование. Убедитесь, что тестирование и приемочное тестирование пользователей являются важной частью вашей методологии. Не экономьте на тестовых ресурсах и убедитесь, что в вашем проекте есть полный набор регрессионных тестовых примеров, определенных и желательно автоматизированных для увеличения скорости.
- Выходные на сцену. Убедитесь, что ворота на сцену установлены и соблюдаются, чтобы обеспечить соблюдение стандартов, определенных командой. Не выпускайте программное обеспечение, которое не было полностью протестировано и задокументировано.
Заключение
В этой статье я выделил пять ключевых областей, на которых нужно сосредоточиться, чтобы ваша команда инженеров выполняла заказы вовремя и с высоким уровнем качества. В конце концов, если вы сосредоточитесь на здравом смысле применения практик качественной инженерии, описанных в этой статье, вы сможете достичь хорошего результата и гарантировать, что ваша команда будет работать.