Как сделать декомпозицию в excel
В этом разделе описывается создание шаблона для структурной декомпозиции работ (WBS) в Microsoft Dynamics AX. WBS представляет собой список задач, которые менеджер проекта планируется завершить по проекту. Если некоторые задачи одинаковы для нескольких проектов, можно создать шаблон WBS, содержащий эти задачи. Используйте шаблон WBS в качестве начальной точки для WBS проекта.
Шаблон WBS можно создать для часто используемых проектов. Например, компания по ИТ-консалтингу создает программное обеспечение для своих клиентов. Проекты компании обычно включают пять задач: планирование, дизайн, тестирование, установку и обслуживание. Следовательно, менеджер проекта создает шаблон WBS и добавляет в него пять задач. Когда начинается новый ИТ-проект, менеджер проекта создает WBS для ИТ-проекта с помощью шаблона, а затем добавляет другие задачи, работников, даты начала, даты окончания и прочие сведения в WBS.
После создания WBS с помощью шаблона WBS можно добавить или удалить задачи и изменить последовательность задач в WBS в соответствии с требованиям проекта. Также можно изменить усилие и продолжительность задач в WBS проекта.
Создайте шаблон WBS, используя любой из перечисленных ниже методов.
Создайте шаблон WBS с помощью пустой формы шаблона WBS.
Сохраните существующий шаблон WBS как новый шаблон WBS.
Сохраните WBS из конкретного проекта в качестве шаблона WBS.
В Microsoft Dynamics AX 2012 R3 или накопительное обновление 7 либо более поздней версии для AX 2012 R2 можно использовать Microsoft Project для создания шаблона WBS, который можно использовать в Microsoft Dynamics AX. Дополнительные сведения см. в разделе Создание или обновление проекта с помощью Microsoft Project.
Необходимые условия
В следующей таблице показаны обязательные компоненты, которые должны быть подготовлены до начала работы.
Связанные задачи конфигурации
Настройка календарей для рабочих периодов, которые будут использоваться в проектах. Дополнительные сведения см. в разделе Создание календарей рабочего времени.
Выбор рабочего календаря, который будет использоваться по умолчанию для новых проектов. Дополнительные сведения см. в разделе Настройка параметров для системы табелей учета рабочего времени.
Настройка категорий проектов. Дополнительные сведения см. в разделе Создание категорий и групп категорий для проектов.
1. Создание шаблона WBS с помощью пустой формы шаблона WBS
Для создания шаблона WBS с помощью пустой формы выполните следующие действия.
Щелкните Управление и учет по проектам > Настройка > Проекты > Шаблоны структурной декомпозиции работ. В области действий щелкните Создать шаблон структурной декомпозиции работ.
В форме Создать шаблон структурной декомпозиции работ введите уникальное имя шаблона WBS. При необходимости введите описание шаблона WBS.
Флажок Активный устанавливается автоматически. Чтобы сделать шаблон WBS недоступным для проектов, снимите этот флажок.
Когда шаблон WBS готов к использованию, можно изменить его статус. Для изменения статуса откройте шаблон WBS, а затем на экспресс-вкладке Детали строки установите флажок Активный.
В форме Создать шаблон структурной декомпозиции работ нажмите кнопку ОК.
В форме Шаблон структурной декомпозиции работ для %1 - %2 обратите внимание, что в первой строке содержится имя шаблона WBS, сумма усилий в часах для всех задач и общая продолжительность всех задач. Эти поля невозможно изменить напрямую. Вместо этого усилие и продолжительность в первой строке обновляются при изменении усилия и продолжительности задач.
Чтобы добавить задачу, в разделе Область действий щелкните Задача. Введите сведения о задаче в следующие поля.
Предшественники
Введите номер задачи, которую необходимо выполнить до того, как может быть начата текущая задача. Задаче может предшествовать несколько других задач.
Категория
Введите категорию проекта. Категория используется для определения выручки и стоимости задачи. Дополнительные сведения о категориях проектов и группах категорий см. в разделе О группах категорий проекта.
Усилия (часы)
Введите расчетное общее количество часов, необходимых для выполнения задачи. Количество часов может представлять несколько работников, назначенных задаче. Расчетное общее количество включает все часы, которые могут разнести работники поставщика.
Число ресурсов
Введите количество работников, необходимых для выполнения задачи. В это количество входят работники поставщика.
Продолжительность (дни)
Введите расчетное количество рабочих дней, необходимых для выполнения задачи. Если ввести дату начала и окончания, продолжительность рассчитывается автоматически.
Чтобы изменить позицию задачи в шаблоне WBS, используйте следующие кнопки в разделе Область действий.
Внешн. отступ
Перемещение задачи на один уровень вверх. Задача автоматически перенумеровывается для новой позиции. Например, в шаблоне WBS с тремя родительскими и одной дочерней задачей повышается уровень дочерней задачи 2.1. Задача с повышенным уровнем становится задачей 3, а бывшая задача 3 становится задачей 4.
Можно выбрать несколько задач для уменьшения отступа. Если щелкнуть Уменьшить отступ, выбранные задачи перемещаются на один уровень выше по сравнению с предыдущим уровнем.
Внутр. отступ
Перемещение задачи на один уровень вниз. Задача с пониженным уровнем становится дочерней задачей родительской задачи, стоящей над ней. Например, при понижении уровня задачи 2 она становится дочерней задачей задачи 1, и ее номер автоматически изменяется на 1.1. Если у задачи 1 имеются другие дочерние задачи, задача с пониженным уровнем располагается в конце списка дочерних задач родительской задачи.
Можно выбрать несколько задач для увеличения отступа. Если щелкнуть Увеличить отступ, выбранные задачи перемещаются на один уровень ниже по сравнению с предыдущим уровнем.
Переместить задачу вверх
Перемещение задачи на одну строку вверх от ее текущей позиции. Используйте этот процесс для определения последовательности дочерних задач родительской задачи и изменения последовательности родительских задач в структуре WBS. При перемещении родительской задачи все ее дочерние задачи перемещаются вместе с ней.
Переместить задачу вниз
Перемещение задачи на одну строку вниз от ее текущей позиции. Используйте этот процесс для определения последовательности дочерних задач родительской задачи и изменения последовательности родительских задач в структуре WBS. При перемещении родительской задачи все ее дочерние задачи перемещаются вместе с ней.
Для удаления задачи выберите задачу и в разделе Область действий щелкните Удалить.
2. Сохранение существующего шаблона WBS как нового шаблона WBS
Можно создать шаблон WBS с помощью другого шаблона WBS, а затем изменить скопированный шаблон.
Для создания шаблона WBS с помощью существующего шаблона выполните следующие действия.
Щелкните Управление и учет по проектам > Настройка > Проекты > Шаблоны структурной декомпозиции работ. На странице списка Шаблоны структурной декомпозиции работ откройте шаблон для копирования. В форме Шаблон структурной декомпозиции работ для %1 - %2 в области действий на вкладке СДР щелкните Экспортировать СДР как шаблон.
В форме Сохранить как введите уникальное имя шаблона WBS. При необходимости введите описание шаблона WBS.
Обновите страницу списка Шаблоны структурной декомпозиции работ для просмотра нового шаблона WBS.
3. Сохранение WBS из конкретного проекта в качестве шаблона WBS
Менеджеру проекта может потребоваться использовать WBS проекта в качестве начальной точки шаблона WBS. Например, предлагается новый тип проекта, и задачи, которые необходимо выполнить для завершения нового типа проекта, не известны полностью в начале проекта. В ходе проекта WBS проекта обновляется по мере добавления и изменения задач. По завершении проекта менеджер проекта сохраняет WBS из нового типа проекта в качестве шаблона WBS. Затем, когда другой клиент запросит проект того же типа, менеджер проекта сможет использовать шаблон WBS для создания WBS данного проекта.
Чтобы сохранить WBS для конкретного проекта в качестве шаблона WBS, выполните следующие действия.
Щелкните Управление и учет по проектам > Обычный > Проекты > Все проекты. Выберите проект. На панели "Действия" на вкладке План в группе Мероприятия щелкните Структурная декомпозиция работ.
В форме Структурная декомпозиция работ для %1 - %2 в области действий на вкладке СДР щелкните Экспортировать СДР как шаблон.
В форме Сохранить как введите уникальное имя шаблона WBS. При необходимости введите описание шаблона WBS.
Далее
Техническая информация для системных администраторов
При отсутствии доступа к страницам, которые необходимы для выполнения этой задачи, свяжитесь с системным администратором и предоставьте сведения, представленные в следующей таблице.
Конфигурационные ключи
Для этой задачи конфигурационный ключ не требуется.
Роли безопасности
Для создания шаблона WBS необходимо быть членом роли безопасности, включающей полномочия Ведение мастера мероприятия по проекту (ProjActivityMasterMaintain).
Иерархическая структура работ (WBS) в Excel используется для визуального представления порядка выполнения различных задач и мероприятий проекта, расписания ресурсов во время планирования проекта. Это позволяет нам разделить или разделить проект на более управляемые части, классифицируя задачи проекта по иерархии событий, которые затем разбиваются на серию задач, выполнение которых не зависит от других задач. Кроме того, он используется для распределения соответствующего оборудования, затрат, материалов, рабочей силы и продолжительности времени для выполнения каждой задачи.
Как создать иерархическую структуру работы в Excel?
Вы можете скачать этот шаблон Excel с иерархической структурой работ здесь — Шаблон иерархической структуры работ в Excel
В Excel доступны шаблоны для шаблонов декомпозиции работ. С помощью этих шаблонов мы можем создать два вида структурной декомпозиции работ:
Древовидная структура
Эта структура выглядит следующим образом:
Табличный вид
Это выглядит так:
Шаг 1: Сбор материалов
- Заявление о содержании проекта: это подробное описание задач и результатов проекта.
- Заявление о требованиях: это подробное описание результата, который будет доставлен
- Активы организационного процесса: сюда входят политики, руководства, шаблоны, процедуры, планы организации.
- План управления содержанием проекта: это документ, который помогает понять, как можно вносить изменения в содержание проекта.
Шаг 2: Сборная команда и заинтересованные стороны
Этот шаг включает определение того, кто может помочь в создании WBS. Это требует сотрудничества с членами команды. Например, члены команды могут помочь записать все задачи для завершения проекта.
Шаг 3: Определение представления и подхода WBS
Представление может быть в виде таблицы или древовидной структуры, как описано выше. Например, для конкретного проекта два представления WBS выглядят следующим образом:
Шаг 4: Определение основных результатов и уровней
Это включает разбиение основных результатов на дополнительные компоненты и уровни. В WBS есть три уровня. Первый — это полный проект, второй включает в себя все результаты, необходимые для завершения проекта, а третий включает разделение или разбивку результатов на более мелкие части, такие как рабочие пакеты. У рабочих пакетов есть связанное с ними правило, то есть они не должны выполняться менее чем за 8 или более чем за 80 часов. Это правило 8/80 применяется только к рабочим пакетам, поскольку это элементы, которые назначаются члену команды вместе с назначенным крайним сроком.
Шаг 5: 100% правило
Это правило гласит, что каждый уровень разбивки в WBS должен иметь все элементы результатов, которые представляют 100% его родительских результатов. Это правило необходимо для того, чтобы не было дубликатов. Для этого необходимо убедиться, что сумма всех результатов WBS составляет 100% от всего проекта. 100% следует применять ко всем подуровням для достижения оптимальных результатов.
Шаг 6: Схема нумерации
После определения компонентов WBS каждому компоненту должен быть присвоен номер, который можно назвать идентификатором WBS. Он представляет собой место в структуре WBS, в котором размещается каждый уровень WBS. На первом уровне первый номер или идентификатор должен быть равен 1, а следующие компоненты нумеруются после этого последовательно. Например, 1.1 будет назначено для первого элемента подуровня, 1.1.1 — для последующих элементов подуровня. 1.2 будет назначено для другого подэлемента первого уровня.
Шаг 7: Словарь WBS
Это документ, в котором описаны все элементы WBS.
Итак, после всех этих шагов шаблон WBS должен выглядеть следующим образом:
Описания задач могут быть сдвинуты вручную с помощью кнопок «Отступ» на вкладке «Главная» или с использованием условного форматирования. Кроме того, другой подход может заключаться в создании списка, в котором схема нумерации также является частью описания задачи, чтобы не требовать дополнительных отступов.
После декомпозиции проекта мы настроили Excel для доступа или получения данных. Теперь давайте посмотрим, как мы можем создать один такой шаблон в Excel:
Шаг 1: Создайте следующие столбцы сверху:
- ID задачи
- Описание задания
- Предшественник
- Владелец
- Роль
- % Завершения
- Дата начала
- Дата окончания
- Доставить
Шаг 2: После создания этих столбцов необходимо отформатировать ячейки. Сначала форматируем идентификатор задачи ячейки. Чтобы отформатировать его, мы сначала выделяем столбец, предназначенный для номеров идентификаторов задач, щелкнув букву в верхней части столбца. Щелкните правой кнопкой мыши выбранный столбец, а затем выберите «Форматировать ячейки» -> «Число» и установите десятичные разряды на 1. Затем мы форматируем столбец: Предшественник, который будет отслеживать зависимости задач. Он должен быть настроен так же, как «ID задачи». «Дата начала» и «Дата окончания» должны быть настроены для принятия введенных дат.
Шаг 3: Введите данные.
Шаг 4: Затем мы можем использовать условное форматирование для различных задач, например, скажем, мы хотим выделить задачи, которые связаны с конкретным конечным результатом или назначены конкретному участнику, или задачи, которые должны быть выполнены в течение определенного временного диапазона.
Шаг 5: Мы также можем видеть функцию «панель данных» для графического представления столбца типа «% завершения». Эта функция доступна в раскрывающемся списке «Условное форматирование».
Одним из самых важных факторов, влияющих на скорость разработки и успех запуска проекта, является правильная декомпозиция идеи продакт-менеджера в задачи для непосредственно программирования. Как правильно это делать? Взять сценарий работы новой фичи от продакта и сразу начать кодить? Сначала написать приёмочные тесты, а потом – код, который будет обеспечивать их прохождение? А, может, переложить всё на плечи разработчиков – и пусть они в ходе скрам-покера сами решают?
Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.
Почему это важно?
Необходимо помнить о том, что процесс разработки – это не только непосредственно сеанс написания кода. Когда мы говорим о разработке, я призываю смотреть на весь процесс целиком, начиная от постановки задачи и заканчивая стабильной работой фичи у наших пользователей. Если не брать в расчёт все этапы, которые предшествуют кодированию и следуют за ним, то очень легко можно попасть в ситуацию, когда все что-то делают, выполняют свои KPI, получают бонусы, а результат получается плачевный. Бизнес загибается, конкуренты «душат», но при этом все – молодцы.
Почему так происходит? Всё просто: человеческая психология заставляет людей смотреть на ситуации с точки зрения собственного комфорта. Разработчику не всегда хочется думать о том, что будет с кодом после его написания. Решил задачу – и хорошо. Его крайне редко это интересует (именно поэтому мы, айтишники, и работаем в этой отрасли – наша мотивация в основном держится на интересности задач), ведь в отношениях с людьми столько неопределённости. Гораздо более комфортно многие разработчики чувствуют себя, сидя за компьютером и сосредоточившись на решении своей собственной интересной задачи – блокчейнах с нейросетями – им совсем не хочется отвлекаться и думать о каких-то продакт-менеджерах, дедлайнах, пользователях, которые потом будут использовать их гениальное произведение (а то ещё и критиковать начнут!).
Это не плохо и не хорошо – мы ценим разработчиков именно за вдумчивое и грамотное решение технических задач. Но узкий взгляд на проблемы часто останавливает развитие. И речь о развитии не только конкретных людей, но и компании в целом. Ведь рост компании и совершенствование корпоративной культуры возможны только с ростом каждого сотрудника. Поэтому нам важно иногда вылезать из «кокона» и заставлять себя смотреть на проблемы шире, чтобы этот рост стимулировать.
И, разумеется, если такой важный этап, как декомпозиция, поручить человеку, который смотрит на всё исключительно с точки зрения собственного удобства, есть реальный риск огрести кучу проблем на последующих этапах: при слиянии результатов его работы с результатами других, при code review, при тестировании, выкладке в продакшн, и т. д.
Таким образом, определяя для себя, как правильно разбить ту или иную задачу, прикидывая, с чего следует начать и куда в итоге прийти, важно учитывать как можно больше факторов, а не смотреть на проблему только «со своей колокольни». Иногда для того чтобы всё работало быстрее и эффективнее на следующих этапах, приходится делать что-то сложнее и медленнее на том этапе, за который отвечаете вы.
Хороший пример – написание юнит-тестов. Зачем мне тратить своё драгоценное время на написание тестов, если у нас есть тестировщики, которые потом и так всё протестируют? А затем, что юнит-тесты необходимы не только для облегчения процесса кодинга – они нужны также и на последующих этапах. И нужны как воздух: с ними процесс интеграции и проверки регрессии ускоряется в десятки, сотни раз, на них базируется пирамида автоматизации. И это даже если не брать в расчёт ускорение вашей собственной работы: ведь «потрогав» код в каком-то месте, вам самому нужно убедиться в том, что вы ненароком что-нибудь не сломали. И один из самых быстрых способов это сделать – прогнать юнит-тесты.
Workflow
Многие команды, чтобы как-то формализовать отношения между участниками процесса, договариваются о правилах работы в коллективе: согласовывают стандарты кодирования, общий workflow в системе контроля версий, устанавливают расписание релизов и т. д.
Стоит ли говорить, что если изначально договориться о процессе, не принимая во внимание весь жизненный цикл фичи, то можно получить замедление и «грабли» в будущем? Особенно если учесть рост проекта и компании. О преждевременной оптимизации не забываем, но если есть процесс, который хорошо работает на разных масштабах, то почему бы его не использовать изначально?
Говоря о workflow разработки, многие, кто использует Git, сразу вспоминают (всуе) о некоем «стандартном git-flow», считая его идеальным, правильным, и часто внедряют его у себя. Даже на конференциях, где я выступал, рассказывая про workflow в Badoo, меня несколько раз спрашивали: «Зачем вы изобрели своё, почему не используете стандартный git-flow?» Давайте разбираться.
Во-первых, обычно, говоря про этот флоу, имеют в виду вот эту картинку. Я взял её из статьи Vincent Driessen “A successful Git branching model”, в которой описывается схема, довольно успешно работавшая на нескольких его проектах (было это в далёком 2010 году).
Сегодня некоторые крупные игроки на рынке хостинга кода вообще предлагают свой флоу, критикуя «стандартный git-flow» и описывая его недостатки; дают свои схемы, рекомендации, приёмы.
Во-вторых, даже у нас в компании у разных команд разный флоу. Флоу разработки серверного кода на PHP, демонов на С/ С++ и Go, флоу мобильных команд – они разные. И пришли мы к этому не сразу: пробовали разные варианты, прежде чем остановиться на чём-то конкретном. К слову, отличается в этих командах не только workflow, но ещё и методологии тестирования, постановки задач, релизы и сам принцип доставки: то, что поставляется на ваши личные серверы и на компьютеры (смартфоны) конечных пользователей, не может разрабатываться одинаково по определению.
В-третьих, даже принятый workflow является скорее рекомендацией, чем непререкаемым правилом. Задачи у бизнеса бывают разные, и хорошо, если вам удалось выбрать процесс, покрывающий 95% случаев. Если же ваша текущая задача не вписывается в выбранный флоу, имеет смысл посмотреть на ситуацию с прагматической точки зрения: если правила мешают вам сделать эффективно, к чёрту такие правила! Но обязательно посоветуйтесь с вашим менеджером перед принятием окончательного решения – иначе может начаться бардак. Вы можете банально не учесть какие-то важные моменты, которые известны вашему руководителю. А, возможно, всё пойдёт как по маслу – и вы сумеете изменить существующие правила так, что это приведёт к прогрессу и станет залогом роста для всех.
Если всё так сложно, да ещё и флоу – это не догма, а всего лишь рекомендация, то почему бы не использовать одну ветку для всего: Master для Git или Trunk для SVN? Зачем усложнять?
Тем, кто смотрит на проблему однобоко, этот подход с одной веткой может показаться очень удобным. Зачем мучиться с какими-то ветками, париться со стабилизацией кода в них, если можно написать код, закоммитить (запушить) в общее хранилище – и радоваться жизни? И правда, если в команде работает не очень много человек, это может быть удобно, поскольку избавляет от необходимости слияния веток и организации веток для релиза. Однако данный подход имеет один очень существенный недостаток: код в общем хранилище может быть нестабильным. Вася, работающий над задачей №1, может легко сломать код других задач в общем хранилище, залив свои изменения; и пока он их не исправит/ не откатит, код выкладывать нельзя, даже если все остальные задачи готовы и работают.
Конечно, можно использовать теги в системе контроля версий и код-фриз, но очевидно, что подход с тегами мало отличается от подхода с ветками, как минимум потому что усложняет изначально простую схему. А уж код-фриз тем более не добавляет скорости работе, вынуждая всех участников останавливать разработку до стабилизации и выкладки релиза.
Так что первое правило хорошей декомпозиции задач звучит так: задачи нужно разбивать так, чтобы они попадали в общее хранилище в виде логически завершённых кусочков, которые работают сами по себе и не ломают логику вокруг себя.
Feature branches
При всём многообразии вариантов workflow у нас в компании у них есть общая черта – они все основаны на отдельных ветках для фич. Такая модель позволяет нам работать независимо на разных этапах, разрабатывать разные фичи, не мешая друг другу. А ещё мы можем тестировать их и сливать в общее хранилище, только убедившись, что они работают и ничего не ломают.
Но и такой подход имеет свои недостатки, основанные на самой природе фичебранчей. В конце концов, после изоляции результат вашей работы нужно будет слить в общее для всех место. На этом этапе можно огрести немало проблем, начиная от мерж-конфликтов и заканчивая очень длительным тестированием/ багфиксингом. Ведь отделяясь в свою ветку кода, вы изолируете не только общее хранилище от ваших изменений, но и ваш код – от изменений других разработчиков. В результате, когда приходит время слить свою задачу в общий код, даже если она проверена и работает, начинаются «танцы с бубном», потому что Вася и Петя в своих ветках затронули одни и те же строки кода в одних и тех же файлах – конфликт.
Современные системы хранения версий кода имеют кучу удобных инструментов, стратегий слияния и прочее. Но избежать конфликтов всё равно не удастся. И чем больше изменений, чем они витиеватее, тем сложнее и дольше эти конфликты разрешать.
Ещё опаснее конфликты, связанные с логикой кода, когда SCM сливает код без проблем (ведь по строкам в файлах конфликтов нет), но из-за изоляции разработки какие-то общие методы и функции в коде изменили своё поведение или вообще удалены из кода. В компилируемых языках проблема, как может показаться, стоит менее остро – компилятор валидирует код. Но ситуации, когда сигнатуры методов не поменялись, а логика изменилась, никто не отменял. Такие проблемы сложно обнаруживать, и они ещё более отдаляют счастливый релиз и заставляют перетестировать код много раз после каждого слияния. А когда разработчиков много, кода много, файлов много и конфликтов много, всё превращается в сущий ад, ибо пока мы исправляли код и перепроверяли его, основная версия кода уже ушла далеко вперёд, и надо всё повторять заново. Вы всё ещё не верите в юнит-тесты? Хе-хе-хе!
Чтобы этого избежать, многие стараются как можно чаще сливать результаты общей работы в свою ветку. Но даже соблюдение этого правила, если фичебранч будет достаточно большим, не поможет избежать проблем, как бы мы ни старались. Потому что чужие изменения вы к себе в код получаете, но ваши изменения при этом никто не видит. Соответственно, необходимо не только почаще заливать чужой код в свою ветку, но и свой код в общее хранилище – тоже.
Отсюда – второе правило хорошей декомпозиции: фичебранчи должны содержать как можно меньше изменений, чтобы как можно быстрее попадать в общий код.
Параллельная работа
Хорошо, но как же тогда работать в отдельных ветках, если несколько программистов трудятся над одной и той же задачей, разбитой на части? Или если им нужны изменения в общих для разных задач частях кода? И Петя, и Вася используют общий метод, который в рамках задачи Пети должен работать по одному сценарию, а в задаче Васи – по другому. Как им быть?
Тут многое зависит от вашего цикла релизов, потому что моментом завершения задачи мы считаем момент попадания её на продакшн. Ведь только этот момент гарантирует нам, что код стабилен и работает. Если не пришлось откатывать изменения с продакшна, конечно.
Если цикл релизов быстрый (несколько раз в день вы выкладываетесь на свои серверы), то вполне можно сделать фичи зависимыми друг от друга по стадиям готовности. В примере с Петей и Васей выше создаём не две задачи, а три. Соответственно, первая звучит как «меняем общий метод так, чтобы он работал в двух вариантах» (или заводим новый метод для Пети), а две другие задачи – это задачи Васи и Пети, которые могут начать работу после завершения первой задачи, не пересекаясь и не мешая друг другу.
Если же цикл релизов не позволяет вам выкладываться часто, то пример, описанный выше, будет непомерно дорогим удовольствием, ведь тогда Васе и Пете придётся ждать дни и недели (а в некоторых циклах разработки и года), пока они смогут начать работать над своими задачами.
В этом случае можно использовать промежуточную ветку, общую для нескольких разработчиков, но ещё недостаточно стабильную, чтобы быть выложенной на продакшн (Master или Trunk). В нашем флоу для мобильных приложений такая ветка называется Dev, на схеме Vincent Driessen она называется develop.
Важно иметь в виду, что любое изменение в коде, даже слияние веток, вливание общих веток в стабильный Master и т. д., обязательно должно быть протестировано (помните про конфликты по коду и логике, да?). Поэтому если вы пришли к выводу, что вам необходима общая ветка кода, то нужно быть готовым к ещё одному этапу тестирования – после момента слияния необходимо тестировать, как фича интегрируется с другим кодом, даже если она уже протестирована в отдельной ветке.
Тут вы можете заметить, что можно ведь тестировать только один раз – после слияния. Зачем тестировать до него, в отдельной ветке? Верно, можно. Но, если задача в ветке не работает или ломает логику, этот неработоспособный код попадёт в общее хранилище и мало того, что помешает коллегам работать над своими задачами, ломая какие-то участки продукта, так ещё и может подложить бомбу, если на неправильных изменениях кто-то решит базировать новую логику. А когда таких задач десятки, очень тяжело искать источник проблемы и чинить баги.
Следовательно, у нас появляется третье правило хорошей декомпозиции: задачи должны разделяться так, чтобы их можно было разрабатывать и релизить параллельно.
Feature flags
Но как же быть в ситуации, когда новое изменение бизнес-логики – большое? Только на программирование такой задачи может уйти несколько дней (недель, месяцев). Не будем же мы сливать в общее хранилище недоделанные куски фич?
А вот и будем! В этом нет ничего страшного. Подход, который может быть применён в этой ситуации, – feature flags. Он основан на внедрении в код «выключателей» (или «флагов»), которые включают/ выключают поведение определённой фичи. К слову, подход не зависит от вашей модели ветвления и может использоваться в любой из возможных.
Простым и понятным аналогом может быть, например, пункт в меню для новой страницы в приложении. Пока новая страница разрабатывается по кусочкам, пункт в меню не добавляется. Но как только мы всё закончили и собрали воедино, добавляем пункт меню. Так же и с фичефлагом: новую логику оборачиваем в условие включённости флага и меняем поведение кода в зависимости от него.
Последней задачей в процессе разработки новой большой фичи в этом случае будет задача «включить фичефлаг» (или «добавить пункт меню» в примере с новой страницей).
Единственное, что нужно иметь в виду, используя фичефлаги, – это увеличение времени тестирования фичи. Ведь продукт необходимо протестировать два раза: с включённым и выключенным фичефлагом. Сэкономить тут можно, но действовать следует крайне деликатно: например, тестировать только то состояние флага, которое выкладывается пользователю. Тогда в процессе разработки (и выкладки по частям) задачи её тестировать вообще не будут, а проведут тестирование только во время проверки последней задачи «включить фичефлаг». Но тут надо быть готовым к тому, что интеграция кусков фичи после включения флага может пройти с проблемами: могут обнаружиться баги, допущенные на ранних этапах, и в этом случае поиск источника проблемы и устранение ошибок могут дорого стоить.
Заключение
Итак, при декомпозиции задач важно помнить три простых правила:
- Задачи должны быть в виде логически завершённых кусочков кода.
- Эти кусочки кода должны быть маленькими и должны максимально быстро попадать в общий код.
- Эти кусочки должны разрабатываться параллельно и выкладываться независимо друг от друга.
Куда уж проще? Кстати, независимая выкладка, на мой взгляд, — самый важный критерий. Из него так или иначе проистекают остальные пункты.
Расписание проекта определяет, какую работу необходимо выполнить, какие ресурсы будут выполнять работу и период времени, за который необходимо завершить работу. Расписание отражает все работы, связанные с выполнением проекта в срок. В Dynamics 365 Project Operations, вы создаете график проекта следующим образом:
- Разбить работу на управляемые задачи.
- Оценка времени, необходимого для выполнения каждой задачи.
- Установка зависимостей задач.
- Установка длительности задач.
- Оценка общих ресурсов, которые будут выполнять задачи.
Расписание проекта создается на вкладке Расписание страницы Проект.
Задачи
Первый этап в создании расписаний проекта — разбить работу на части, которые можно контролировать. Расписание в Project Operations поддерживает следующие возможности:
- Сводные задачи или задачи контейнера
- Задачи листового узла
Сводные задачи
Сводные задачи могут хранить другие сводные задачи или задачи листовых узлов. У них нет собственных усилий работы или стоимости. Вместо этого, их усилия работы и стоимость являются суммой рабочих усилий и стоимости их задач-контейнеров. Дата начала сводной задачи — это дата начала задач-контейнеров, а дата окончания — дата окончания задач-контейнеров. Имя сводной задачи можно редактировать, но свойства расписания, включая усилия, даты и длительность, нельзя изменить. При удалении сводной также удаляются все ее задачи-контейнеры.
Задачи листового узла
Задача листового узла представляет наиболее детализированную работу над проектом. Они содержат расчетное усилие, ресурсы, запланированные даты начала и окончания и продолжительность.
Создание иерархии задач
Добавление задачи
Чтобы добавить одну или более задач, выполните следующие действия.
- Перейти к Проекты и выберите и откройте запись проекта, для которого вы хотите создать расписание.
- Перейдите на вкладку Задачи.
- Выбрать Добавить новую задачу, введите имя задачи и нажмите клавишу "Ввод".
- Введите другое имя задачи и снова нажмите "Ввод", пока не получите полный список задач.
Управляйте иерархией задачи
При понижении уровня задачи она становится дочерней задачей, расположенной непосредственно над ней. ИД расписания задачи затем заново рассчитывается, чтобы он был основан на ИД расписания ее нового родительского элемента и следовал структурной схеме нумерации. Родительская задача теперь является сводной задачей. Поэтому она становится сверткой своих дочерних задач. При повышении уровня задачи она перестает быть дочерней задачей своей прежней родительской задачи. ИД расписания затем повторно рассчитывается, чтобы он отражал обновленную глубину задачи и ее положение в иерархии. Усилия, стоимость и даты предыдущей родительской задач пересчитываются, чтобы они не включали эту задачу.
Чтобы понизить или повысить уровень задачи, выполните следующие действия.
- На странице Проект на вкладке Задачи под Сводные задачи, выберите три вертикальные точки возле имени задачи, а затем выберите Сделать подзадачу.
- Выберите задачу, чтобы понизить или повысить уровень. Чтобы выбрать более одной задачи, выберите задачу, нажмите и удерживайте Ctrl, а затем выберите дополнительные задачи.
- Выбрать Понизить уровень или Повысить уровень подзадачи, чтобы переместить задачи под или из-под сводных задач.
Перемещение задач вверх и вниз
Задачи можно переместить на любой уровень структурной декомпозиции работ одним из двух способов:
- Выберите еще одну задачу и перетащите их в желаемое расположение.
- Выберите одну или несколько задач, щелкните правой кнопкой мыши и выберите Вырезать, выберите ячейку назначения в расписании, а затем щелкните правой кнопкой мыши и выберите Вставить.
Атрибуты задачи
Название задачи описывает работу, которая должна быть выполнена. В Project Operations атрибуты, связанные с задачей, описываются расписание задачи и ее требования к комплектации штата.
Атрибуты расписания
Атрибуты Усилия, Дата начала, Дата окончания и Длительность определяют расписание для задачи.
В следующей таблице показаны дополнительные атрибуты расписания.
Конечное отображаемое имя | Окончательное описание |
---|---|
Объем завершенных работ (часы) | Объем завершенных работ по задаче в часах. |
Срок действия | Отображает длительность задачи в днях. |
Общий объем работ | Общий объем работ по задаче в часах. |
Готово | Дата/время окончания. |
% выполнения | Процент завершения задачи. |
Группа проекта | Доску задач можно сгруппировать по группе, чтобы каждая группа имела собственный столбец. |
Объем оставшихся работ (часы) | Объем оставшихся работ по задаче в часах. |
По левому краю | Дата и время начала. |
Полное имя | Имя задачи. |
ИД | Идентификатор задачи в структурной декомпозиции работ. |
В качестве администратор вы можете определить пользовательские поля в сущности задачи. Однако поля не могут отображаться в сетке расписания. Чтобы увидеть свои пользовательские поля, добавьте их на страницу сведений Задача проекта.
Атрибуты персонала
Атрибуты комплектации штата доступны через поле Ресурсы в расписании. Можно выполнить поиск существующего ресурса или выбрать Создать, и в области Быстрое создание добавить участника проектной группы в качестве нового ресурса. Когда вы выполняете поиск ресурса с помощью средства выбора ресурсов в сетке задач, в представлении доски или на диаграмме Ганта, поиск возвращает либо существующих участников проектной группы, либо активные резервируемые ресурсы.
Поля Роль, Единица распределения ресурсов и Название должности используются для описания требований к персоналу для задачи. Эти атрибуты комплектации штата вместе с расписанием задачи используются для поиска доступных ресурсов для выполнения этой задачи.
- Роль: укажите тип ресурса, необходимый для выполнения задачи.
- Единица выделения ресурсов: определите единицу, из которой должны быть назначены ресурсы для задачи. Этот атрибут влияет на стоимость и оценку продаж для задачи, если стоимость и ставка выставления счетов для ресурса задается на основе единицы выделения ресурсов.
- Название должности: введите имя для универсального ресурса, который служит заполнителем для ресурса, который в конечном итоге сделает работу.
Поле Ресурсы содержит название должности универсального ресурса или именованного ресурса, когда он будет найден.
Поле Категория содержит значения, которые отражаются более широкий тип работы, в который можно сгруппировать задачу. Это поле не влияет на планирование или комплектацию штата. Вместо этого поле используется только для отчетности.
Зависимости задач
Можно использовать расписание в Project Operations для создания отношений предшественника между задачами. Поле Предшественник использует одно или несколько значений для указания задач, от которых зависит данная задача. При назначении значений предшественника для задачи задача может начаться, только после того как все задачи предшественника будут завершены. Из-за этой зависимости запланированная дата начала задачи переустанавливается на дату завершения задачи-предшественницы.
Режим задачи не влияет на обновления, которые можно вносить в даты начала и окончания предшествующих или зависимых задач.
Специальные возможности и сочетания клавиш
Сетка Расписание полностью доступна и может использоваться со средствами чтения экрана, такими как Narrator, JAWS или NVDA. Можно перемещаться по области сетки с помощью клавиш со стрелками (как в Microsoft Excel), можно использовать клавишу TAB для перехода между интерактивными элементами пользовательского интерфейса, и можно использовать клавишу со стрелкой вниз, клавишу ВВОД или клавишу ПРОБЕЛ, чтобы выбирать и открыть раскрывающиеся меню.
Ограничения проекта
Вы должны знать о следующих ограничениях, если используете структурную декомпозицию работ в Project Operations. Эти ограничения применяются к проектам и задачам. Дополнительную информацию см. в разделе Ограничения и границы Project for the Web.
Поле | Лимит |
---|---|
Максимальное общее количество задач для проекта | 500 |
Максимальная общая длительность для проекта | 3650 дней (10 лет) |
Максимальное общее количество ресурсов для проекта | 150 |
Максимальное общее количество ссылок (только преемник) для проекта | 600 |
Максимальное общее количество пользовательских полей для проекта | 10 |
Максимальное количество элементов контрольного списка на задачу | 20 |
Ограничения задач
Поле | Лимит |
---|---|
Максимальное количество уровней иерархии | 10 уровней |
Максимальное количество ссылок (преемник + предшественник) | 20 |
Максимальная длительность листовой задачи | 1250 дней |
Максимальная длительность сводной задачи | 3650 дней (10 лет) |
Максимальное количество ресурсов, назначенных задаче | 20 ресурсов |
Поддерживаемый диапазон дат для задачи | 01.01.2000 – 31.12.2149 |
Каковы ваши предпочтения в отношении языка документации? Пройдите краткий опрос (обратите внимание, что этот опрос представлен на английском языке).
Опрос займет около семи минут. Личные данные не собираются (заявление о конфиденциальности).
Шаблоны управления проектами являются неотъемлемой частью тиражирования успешных проектов. С помощью бесплатных шаблонов Microsoft Excel вы можете превратить ваши простые электронные таблицы в мощные инструменты управления проектами.
В этой статье вы найдете некоторые из самых полезных и бесплатных шаблонов управления проектами Microsoft Excel и отслеживания проектов, которые вы хотите использовать для своего следующего проекта.
В этой статье:
Шаблоны управления проектами Microsoft Excel
Давайте посмотрим на лучшие шаблоны управления проектами Microsoft Excel.
Примечание. Здесь мы рассмотрим как собственные, так и сторонние шаблоны. Чтобы найти предустановленные шаблоны таблиц Excel, откройте Excel и найдите соответствующее ключевое слово на экране « Новый документ». Если вы уже в Excel, перейдите в « Файл»> «Новый», чтобы вызвать поиск по шаблону. Обратитесь к разделу « Управление шаблонами Microsoft Excel » ниже для получения более подробной информации.
Шаблоны временной шкалы проекта Excel
Excel поставляется с несколькими временными шкалами и шаблонами диаграмм Ганта, предоставленными Microsoft, но также включает в себя шаблоны из Vertex42, одного из самых популярных сторонних ресурсов для электронных таблиц.
1. Рабочий план Хронология
Шаблон временной шкалы рабочего плана подходит для базового проекта с несколькими этапами. Когда вы вводите свои данные в таблицу, дорожная карта будет обновляться автоматически.
Этот шаблон поставляется с Microsoft Excel 2016.
2. Диаграмма Ганта с отслеживанием даты
Диаграммы Ганта являются одним из основных в каждом наборе инструментов менеджера проекта. Они помогают вам визуализировать поток ваших задач и отслеживать прогресс.
С помощью этого шаблона вы можете создать полную диаграмму Ганта с минимальными усилиями. Просто введите каждое задание, вместе с описанием, кому оно назначено, процентное значение для обозначения прогресса, дату начала и количество дней до завершения.
Этот шаблон является Microsoft Excel по умолчанию.
3. Сроки и задачи проекта
Если вы хотите интегрировать вехи в базовую временную шкалу, этот шаблон, предоставленный Vertex42, идеален. Он сочетает в себе лучшие элементы диаграммы Ганта, то есть визуализацию потока задач, с вехами, зависшими над временной шкалой. Просто заполните соответствующие таблицы, чтобы заполнить визуальный.
Вы можете найти этот шаблон, выполнив поиск в Excel.
Шаблон плана проекта Excel
План проекта — это документ. которые могут требовать диаграмм Excel, но в остальном составлены в Microsoft Word. Однако для базовых проектов вам может потребоваться только документ Microsoft Excel.
4. Простая диаграмма Ганта
При поиске в хранилище шаблонов Excel шаблонов плана проекта вы в основном найдете различные варианты диаграмм Ганта, включая эту простую диаграмму Ганта из Vertex42. Что отличает его от диаграммы Ганта, приведенной выше, так это включение этапов проекта.
Этот шаблон включен в Microsoft Excel.
5. Шаблон планировщика событий
План проекта действительно не то, что вы обычно составляете в Excel. Но если ваш проект достаточно прост, например, планирование вечеринки, вам нужен твердый одностраничный шаблон, в котором перечислены основные задачи и вы можете определить график и бюджет. Этот шаблон из Office Templates Online — отличное начало.
Шаблон отслеживания проектов Excel
При поиске трекера вы увидите удивительное сочетание личных и деловых шаблонов таблиц Excel для отслеживания. Вы можете сузить область поиска, выбрав категории, связанные с задачей управления проектом, с которой вы работаете.
6. Отслеживание затрат по видам деятельности
Этот шаблон отслеживания может помочь вам получить представление о прямых, косвенных, а также общих и административных затратах на продукт.
7. Шаблон отслеживания проекта
Этот шаблон Vertex42 необходим, если вы работаете с несколькими различными клиентами, проектами и / или результатами. Он объединяет детали проекта, расходы, статусы задач и сроки выполнения.
Шаблоны бизнес планов
В Microsoft Office есть собственная категория для бизнес-планов. Воспользуйтесь предложенным бизнес-поиском и выберите категорию « Бизнес-планы » справа.
Вы найдете следующие шаблоны Microsoft Excel:
- Затраты на запуск
- Контрольный список бизнес-плана
- Контрольный список бизнес-плана с SWOT-анализом
Дополнительные шаблоны бизнес-планов шаблоны бизнес-планов , посмотрите нашу специальную статью.
Поиск онлайн-шаблонов
Не можете найти нужный шаблон управления проектом в Excel? Обратитесь к стороннему онлайн-ресурсу для более широкого выбора шаблонов таблиц Excel. Мы рекомендуем следующие сайты.
Vertex42
На этом сайте есть несколько отличных шаблонов управления проектами для Microsoft Office 2003 и выше. Сайт отмечает, что его шаблоны в основном связаны с планированием проекта. Для более сложных задач может потребоваться Microsoft Project или другое программное обеспечение для управления проектами.
На странице, посвященной управлению проектами , вы найдете список полезных материалов, включая, помимо прочего, следующее:
Каждая страница содержит краткое описание того, что делает шаблон, один или несколько шаблонов, а также дополнительные советы и рекомендации для соответствующего инструмента управления проектами. Это отличный ресурс для начинающих менеджеров проектов.
TidyForm
TidyForm имеет респектабельный выбор шаблонов управления проектами Microsoft Excel. Самые популярные категории перечислены на главной странице. Если вы не можете сразу найти то, что вам нужно, переключитесь в раздел « Бизнес » или попробуйте функцию поиска.
Когда вы прокрутите до конца раздела, вы увидите список популярных категорий и связанных категорий. Это может быть полезно при поиске нужного шаблона.
Мы рекомендуем следующие страницы:
Все еще ищете идеальный шаблон? Возможно, вам придется создавать пользовательские шаблоны Excel. чтобы получить именно то, что вы хотите.
Управление шаблонами Microsoft Excel
Сначала посмотрим, какие шаблоны вы уже установили в Microsoft Excel. Для этой демонстрации мы использовали Excel 2016, но процедура аналогична в Microsoft Office 2013 и Office 2019.
Значения по умолчанию
Когда вы запускаете Microsoft Excel, первое окно, которое вы видите, будет содержать поле поиска для онлайн-шаблонов. Когда вы начинаете с существующей книги, перейдите в Файл> Создать, чтобы перейти к тому же представлению.
Microsoft Excel поставляется с набором предустановленных шаблонов. Они перечислены под полем поиска. Вы можете закрепить избранные, нажав на соответствующий символ в правом нижнем углу списка.
Искать в Интернете больше шаблонов проектов
Самый быстрый способ найти нужный вам шаблон — это поиск. Как только вы начнете поиск, например, для термина « проект» , вы также увидите категории шаблонов, перечисленные рядом с шаблонами, которые соответствуют вашему поиску.
Сузить поиск
Отличная особенность заключается в том, что вы можете сузить область поиска, выбрав несколько категорий. Это поможет вам исключить шаблоны, которые могут соответствовать вашему ключевому слову, но не нужной категории. С другой стороны, вы можете обнаружить, что идеальный шаблон не доступен в Microsoft Excel.
Предварительный просмотр и создание шаблона
При нажатии на шаблон вы увидите предварительный просмотр с кратким описанием того, что предоставляет шаблон. Вы также можете закрепить шаблон из его предварительного просмотра; символ находится в правом верхнем углу.
Чтобы загрузить и использовать шаблон, нажмите кнопку « Создать» , чтобы открыть новую книгу Microsoft Excel с предварительно заполненным шаблоном.
Шаблон готов, установлен, иди
Пока вы заняты этим, просмотрите наш список полезных офисных шаблонов. и запаситесь шаблонами деловых писем. Шаблоны
Мы рассмотрели много советов по управлению проектами и уловок прошлого. Когда вы разберетесь с шаблонами, вы можете рассмотреть дополнительные инструменты и решения. Например, знаете ли вы, что Outlook отлично подходит для управления проектами ? Аналогично, вы можете использовать OneNote для управления проектами. И вы можете интегрировать OneNote с Outlook для управления проектами. ? Возможности безграничны.
Читайте также: