->
Что такое план вообще?
Содержание
План и тестирование проекта объединяет задачи проекта, расчетную продолжительность, зависимости и конечные результаты вместе в запланированную модель реальности .
Если вы относитесь к плану как к предсказанию будущего, вы бы очень осторожно на него полагались, но мы обычно так и поступаем.
Возможно, вы сталкивались с руководителями проектов, которые относятся к своему плану как к своей личной реальности — своему собственному иллюзорному миру. Но мы не должны быть столь суровыми с менеджерами проектов — они часто мотивированы создать план и выполнить его, несмотря ни на что.
План не является реальностью; это модель реальности, требующая постоянных изменений.
Но сначала давайте получим четкое представление о полезности плана.
Почему план?
Целью планирования обычно является создание согласованного подхода, набора обязательств, зависимостей, затрат и графика реализации проекта. План представляет собой соглашение между заинтересованными сторонами проекта, поставщиками и участниками, которое обычно устанавливает следующее:
- Какие ресурсы требуются и когда
- Когда задачи должны начинаться и заканчиваться, и кто будет их выполнять
- Навыки, необходимые для выполнения задач
- Инструменты и технологии, поддерживающие план
- Результаты и когда они будут доставлены
- Затраты усилий и необходимых ресурсов
- Процесс продвижения проекта/процесса по его этапам
- Риски, которые угрожают родам.
Некоторые из этих аспектов могут быть указаны в стратегии или уже реализованы. Например, может быть известно, какие поставщики задействованы и что они будут делать для проекта. Возможно, инструменты и технологии, которые будут использоваться, уже известны и используются. Люди, тестовая среда и данные могут быть готовы. Также может существовать стратегия, определяющая используемый процесс, подход или методы.
Но в то время как стратегия излагает принципы или теорию, план описывает практические аспекты или логистику того, как проект будет реализовываться в реальности.
Стратегия устанавливает, как проект будет выполняться в принципе, план определяет и подтверждает, как проект будет выполняться на практике.
Для многих менеджеров проектов план — это то, что содержится в Microsoft Project, но жизнеспособный план зависит от того, знают ли все участники проекта, что и как они делают. Чтобы достичь этого, план и знания о том, как что-то будет делаться, должны быть доведены до сведения всех участников.
Планирование — это путешествие, а не задача
Цитируя бывшего президента США Дуайта Д. Эйзенхауэра, «планирование — это все. План — ничто». Это мнение настолько важно, что его можно повторять почти в каждом контексте работы над системными проектами. Но что значит сказать, что план — ничто? Какой смысл планировать, если в результате получается бесполезный план?
План, к которому вы приходите, никогда не бывает бесполезен, но мнение Эйзенхауэра связано с актом планирования и его ценностью по сравнению с планом. Давайте быстро сравним, как планирование работает в более структурированных и гибких/непрерывных проектах по отдельности.
Структурированное и гибкое планирование
В долгосрочном проекте ваш бизнес, поставщики и внутренний ИТ-персонал должны знать, какие обязательства от них требуются, чтобы они могли планировать доступность людей и физических ресурсов.
Сбор необходимой информации для создания плана занимает драгоценное время. При всей зависимости от ресурсов и людей, а также приверженности и эффективности поставщиков, а также внутренних сотрудников, многое может пойти не так. Некоторые вещи пойдут не так. Из-за этого план, как предсказание будущего, сопряжен с трудностями.
На следующий день после публикации плана и каждый последующий день появляется новая информация и требуется некоторая корректировка. Требования сбрасываются; поставщики доставляют с опозданием; среды, тестовые данные или инструменты не готовы вовремя. Список можно продолжить. Планирование никогда не бывает разовой задачей, это непрерывная — почти ежедневная — деятельность.
Часто незапланированные события воспринимаются как шум и не привлекают особого внимания. Но позже некоторые из этих мелких сбоев становятся серьезными проблемами. Одна из проблем каскадных проектов заключается в том, что эта непрерывная корректировка может быть обременительной, поскольку любые изменения рассматриваются как ненужные переделки. Проекты часто продолжаются, несмотря ни на что, в надежде, что «ночью все будет хорошо». Но это бывает редко, и об этом много раз говорилось:
Как проект может опаздывать на год? День за днем.
Agile-подход отчасти является реакцией на разочарование в фиксированных или негибких планах. Гибкость — проверенная альтернатива инерции громоздких поэтапных подходов. Но значит ли это, что agile-проекты не планируют? Нет.
Даже в Agile необходимо предварительное планирование для структурирования работы, распределения ресурсов и планирования — по крайней мере, на высоком уровне — процесса выпуска в ближайшие месяцы. Но итерация за итерацией, а часто и день за днем, общий план постоянно корректируется с учетом событий и новой информации, которая появляется.
Планирование — это непрерывное обучение, а не задача с результатом.
Планирование тестирование
До сих пор мы рассматривали планирование проекта в цикле и предположили, что это очень непрерывная деятельность. Теперь мы сосредоточимся конкретно на планировании тестирования в проектах.
Планирование тестирования очень похоже на планирование проекта — на самом деле это план меньшего масштаба. Конечно, план тестирования также должен интегрироваться с более крупным планом проекта, поскольку он зависит от других действий и результатов проекта (а от тестирования зависят и другие задачи). Часто планы тестирования нарушаются из-за несоблюдения этих зависимостей.
Планы тестирования относительно просты в общих чертах. Может быть несколько действий, которые зависят от родительского проекта. Это то, что часто появляется как задачи в более крупном плане проекта. Но эти действия распределяются по команде, возможно, с большим количеством элементов тестирования, для которых нужно планировать и выполнять тесты.
Этот уровень детализации не так важен для графика менеджера проекта и обычно определяется и управляется на локальном уровне внутри команды тестирования .
Давайте рассмотрим некоторые из основных элементов вашего плана тестирования.
Практические результаты
Каковы результаты тестирования?
Что за вопрос! Конечно, это спецификации испытаний, тесты, результаты и отчеты? Результаты, по сути, содержатся в документации , поэтому все, о чем нам нужно беспокоиться, это подготовить документы и поставить галочки в некоторых полях.
Но этот подход, хотя и распространенный, отчасти виноват в том, что тестировщики (и тестировщики) приобрели репутацию дорогих, плосконогих бюрократов, не имеющих большой ценности. Ведь кто читает эти объемные документы?
Предположим, что в гибком проекте нет намерения создавать тестовую документацию. Это более чем вероятно, так что же на самом деле дает тестирование в таких ситуациях? Какую ценность вообще имеет тестирование? Немного поздно задавать эти вопросы, не так ли?
Когда тестируется компонент, подсистема или вся система, результат свидетельствует о том, как система ведет себя в той или иной ситуации или контексте. Данные о поведении системы собираются и сопоставляются для представления заинтересованным сторонам (разработчикам, пользователям, менеджерам и т. д.), чтобы они могли принять решение: исправить ошибки, интегрировать компонент, принять или отклонить функциональность, выпустить или развернуть подсистему. системы или системы в целом.
Результат тестирования — это свидетельство поведения системы, используемое заинтересованными сторонами для принятия решения.
Теперь в некоторых проектах важно предоставить тестовую документацию, чтобы записать, как тест был определен, разработан, реализован и выполнен. Но именно свидетельство поведения системы является конечной ценностью для заинтересованных сторон.
Ценность тестирования заключается в степени уверенности заинтересованных сторон в принятии решений на основе тестовых данных.
Эти доказательства можно систематически собирать, сводить в таблицы и анализировать с помощью сложных инструментов управления тестированием и представлять заинтересованным сторонам в элегантных графических форматах. Или же рукописные заметки могут быть использованы тестировщиком для устного представления истории тестирования владельцу продукта на стендап-совещании.
Как бы они ни были собраны и представлены, конечной задачей тестирования является передача доказательств.
Как
Независимо от масштаба проекта или методологии тестирование зависит от определенного ряда действий. Мы посмотрим на общий процесс глазами тестировщика (или команды), а затем рассмотрим некоторые из возникающих вариаций.
Есть то, что можно было бы назвать «тестированием», а есть «тестирование-поддержка» или «логистика». Чтобы убедиться, что вы включили все действия в план, вы можете найти таблицы под полезными контрольными списками.
Одно из действий в приведенной выше таблице, которое вы, возможно, не очень хорошо узнаете, — это действие обратной связи. Вам, должно быть, уже приходилось работать с плохими требованиями.
Действия по обратной связи, обзору и проверке — это когда тестировщики, продумав и смоделировав требование, обнаруживают проблемы и могут использовать примеры, чтобы продемонстрировать, где требования отсутствуют, неоднозначны или противоречивы.
Если вы считаете требования плохими, определенно стоит сделать поправку на эту деятельность.
Тестовая логистика
Тестовая логистика поддерживает указанные выше тестовые действия. В то время как приведенный мной список мероприятий по тестированию является достаточно полным, логистика тестирования варьируется в зависимости от проекта и организации. Поэтому приведенный ниже список не является исчерпывающим. В своем проекте потрудитесь продумать каждое действие или зависимость, необходимые для проведения тестирования.
Ресурсы (человеческие, физические)
Мы часто используем слово «ресурсы» по отношению к людям, участвующим в наших проектах, и для некоторых это неудобно. Люди не вещи, они, конечно же, люди. В небольших проектах можно использовать имена, но в более крупных организациях, когда проектные группы задействованы и могут быть еще не укомплектованы персоналом, количество ресурсов — это просто сокращение для количества людей.
Что еще более важно, важно не столько количество людей, сколько их возможности. Конечно, люди работают по-разному и, как правило, с разной скоростью, так что вам нужно будет учитывать это при планировании.
Помимо людей, на разных этапах вам потребуются различные физические ресурсы для продолжения тестирования. Они варьируются от обыденных до очень конкретных, и отсутствие любого из них может поставить под угрозу миссию по тестированию.
Возможно, вам уже посчастливилось получить доступ к полностью оборудованной, управляемой, специализированной тестовой лаборатории. Если вы этого не сделаете, вам может потребоваться указать все — от физического пространства и мебели до стикеров и ластиков — чтобы определить вашу рабочую среду.
В таблице ниже приведены некоторые типичные требуемые ресурсы. Ваш список будет значительно отличаться, без сомнения.
Когда вы определили все ресурсы, необходимые для реализации вашего плана, подумайте, нужны ли вам дополнительные действия в вашем плане для их приобретения.
Ваша сеть поддержки
Если бы люди и навыки, необходимые для тестирования, находились под вашим контролем, проекты могли бы быть намного проще! Но немногие команды обладают всеми необходимыми навыками или авторизацией и доступом к необходимым физическим ресурсам. Многие проекты укомплектованы персоналом и работают в стиле матричного управления. Ключевые члены команды фактически отчитываются перед менеджерами других специализированных отделов, и вы получите от них ограниченные обязательства.
Возможно, вам потребуется указать определенное количество часов в день или запланировать время, чтобы получить доступ к вышеперечисленным навыкам специалиста. Иногда вас спросят, какой уровень обслуживания является приемлемым, например, «высокоприоритетные запросы будут обработаны в течение тридцати минут и т. д.».
оценки
Оценка программных проектов — непростое дело. Много было написано о том, что оценка сложна или даже невозможна. Но оценки требуются во всех проектах, и чем больше проект, тем больше мы зависим от них.
Нам нужны оценки для создания расписания, но проблема в том, что оценка не дает вам точности. Лучшее, что мы можем сделать, — это рассчитать усилие или затраченное время с некоторой долей уверенности или вероятности.
Некоторые люди считают оценку черной магией, и даже существует движение #NoEstimates со значительным числом последователей. Существует много споров о том, может ли оценка быть достаточно точной и является ли она вообще хорошей практикой в проектах по разработке программного обеспечения.
Оценка никогда не будет точной наукой. Но, судя по моему опыту, некоторым я чувствую себя комфортно, разделяя эти принципы:
- Требования ошибочны и неточны.
- Люди более или менее грамотные, добросовестные и трудолюбивые.
- Чем меньше предмет работы, тем легче его оценить; разбивайте большие задачи на более мелкие, где это возможно, и сводите оценки к более крупной задаче.
- Оценка основана на опыте. Если у вас их нет, найдите, где опыт других актуален и может быть адаптирован.
- Ваша работа уникальна, поэтому ищите образцы работы в других известных ситуациях, где у вас есть опыт.
- Попросите других оценить и сравнить. Обсуждение расхождений выявляет различия в ожиданиях, уверенности и тщательности.
- Оцените наилучшую ситуацию, а затем наихудшую ситуацию. Хорошая оценка находится где-то посередине.
Оцените сегодня и приступайте к работе; завтра и каждый последующий день, с полученными знаниями, ваша оценка выполнения будет улучшаться.
Зависимости, риски и предположения
В предыдущей статье мы обсуждали риски и роль тестирования в управлении рисками . Риски продукта связаны с тем, отвечает ли продукт потребностям пользователей в отношении функциональных или технических требований. Здесь основное внимание уделяется рискам для фактического плана доставки.
В проектах что-то идет не так. В процессе планирования вам необходимо четко указать, какие риски неудачи вы учли и допустили. Здесь есть три аспекта: зависимости, риски и ответы.
Зависимости
Зависимости представляют собой список необходимых человеческих и физических ресурсов, а также предшествующие действия, которые должны быть завершены, чтобы ваши запланированные действия были успешными и реализованными.
Всегда есть зависимости для любой тестовой активности, будь то крупномасштабное тестирование на системном уровне или сеанс исследовательского тестирования функции. Зависимости охватывают три основных аспекта.
Риски
Риск — это вероятность провала вашего плана во время выполнения. Риск связан с такими вещами, как:
- Ваши оценки: что может привести к тому, что ваши оценки будут неверными? Более сложная, дефектная, неполная или постоянно меняющаяся система может повлиять на ваши оценки.
- Люди недоступны, им не хватает опыта или навыков, или они не полностью привержены вашей фазе проекта. Это могут быть члены команды или люди из вашей сети поддержки.
- Инфраструктура, такая как тестовая среда, инструменты (или обучение использованию инструментов) или офисные помещения, недоступна, ненадлежащим образом подготовлена или неисправна.
- Действия-предшественники не завершаются вовремя (или от них отказываются, поставляют частичную или дефектную продукцию или вообще не доставляют).
Ответы
Для каждого из этих рисков вам необходимо оценить вероятность, воздействие и, где это существенно, соответствующую реакцию или ожидаемые последствия. Эти ответы, как правило, принимают одну из следующих форм:
- Допущение: риск считается достаточно низким, чтобы его можно было игнорировать или считать несущественным. Но это на радаре и записано как предположение (о наличии, полноте и т.д.)
- Скорректируйте: риск значителен, но есть некоторые действия, которые могут уменьшить его влияние на план. Например, если тестируемая система поставлена частично, а функции отсутствуют, то план можно скорректировать, чтобы протестировать только те функции, которые доступны.
- Следствие: некоторые риски не могут быть ассимилированы. Если система доставлена с опозданием, тестирование не может начаться, пока она не будет доставлена.
Коммуникация, приверженность и отчетность о проделанной работе
Наконец, мы подходим к важному, но часто упускаемому из виду аспекту планирования. Вы можете создать план проекта со всеми задачами, участниками, ресурсами, обязанностями, зависимостями, сроками, усилиями и затратами. Или это может быть словесное взаимопонимание между членами agile-команды.
В любом случае, план должен быть эффективно доведен до всех, чтобы все знали, что требуется и когда.
Согласованный план – это договор между участниками. Если менеджер команды подписывает план, это прямо или косвенно означает обязательство выполнить часть контракта, которую выполняет его команда.
План представляет собой договор между участниками.
В менее формальных проектах может вообще не быть письменного плана или обязательств. В этих обстоятельствах план представляет собой непрерывный разговор между членами команды. Команда собирается ежедневно, и текущие задачи в плане обсуждаются в режиме реального времени. Над чем работают люди? Прогресс идет в соответствии с ожиданиями? Какие проблемы испытывают люди? Какие проблемы блокируют прогресс?
Во всех проектах цель отчета о ходе выполнения двойная. Очевидно, что необходимо сообщать, где каждый находится с точки зрения своей текущей проектной деятельности. Но отчет о проделанной работе — это также непрерывная периодическая проверка того, что прогресс может поддерживаться, и подтверждения того, что на приверженность участников можно положиться.
