Управление проектами

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

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

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

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

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

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

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

В большинстве случаев лучше использовать числовое значение в качестве имени параметра в справочнике и писать подробную информацию в описании.

Вот несколько примеров использования справочника:

• Хорошим примером является использование справочника единиц измерения, которые можно разделить на три поля: код, краткое имя, полное имя. Значения из справочника будут использоваться во всем проекте. Для переменных можно привязать значения другой переменной в качестве допустимых значений. Для этого необходимо добавить соответствующую запись в привязку в формате переменной. Целью является поле, к которому вы хотите привязать справочник, с параметром #choices:

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

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

Без справочника обработка ошибок менее успешна. На одном из шагов набора правил проверяется общее количество партий. Если сумма партии неверна, набор правил завершается. В результате получается текстовое сообщение, указанное в выражении, которое неудобно обрабатывать:

В таких случаях удобнее использовать справочник. Текст сообщения с картинки выше должен быть заменен на код ошибки:

Справочник содержит поля для этого кода ошибки с кратким и полным описанием ошибки на нескольких языках.

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

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

Пример иллюстрирует, как справочник обеспечивает удобную обработку ошибок, учитывает ролевую модель и совместим со многими языками.

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

Пример контекстных групп:

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

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

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

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

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

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