Комментарии 15
Добрый день! За статью спасибо, инструмент интересный, можно перенять опыт использования на проекты.
Диаграмму развертывания и компонентов надо было все таки обезличить, добавить/удалить несколько элементов и выложить в нормальном разрешении.
Метамодель клевая, было бы здорово если бы поделились драфтом.
Про презентации и заказчиков — у нас еще не любят сильно сложные презентации, большую модель смотреть не станут — поэтому упрощаем обычно, выносим основную инфу и запрашиваем решения, такие вещи максимум прикладываем бэкапом к презентации.
Вопросы — а как вы ставите по этому задачи разработчикам/тестерам/etc? Есть ли экспорт в Jira/Redmine?
Используете ли вы MS Project для планирования? Я думал что вы на этапе предпроектного обследования (или пресейла) составляете план проекта, который вставляете в договор — далее по нему работы надо переработать в EA? Как заказчику показываете, что план в договоре подразумевает именно то, что разработано в EA?
Диаграмму развертывания и компонентов надо было все таки обезличить, добавить/удалить несколько элементов и выложить в нормальном разрешении.
Метамодель клевая, было бы здорово если бы поделились драфтом.
Про презентации и заказчиков — у нас еще не любят сильно сложные презентации, большую модель смотреть не станут — поэтому упрощаем обычно, выносим основную инфу и запрашиваем решения, такие вещи максимум прикладываем бэкапом к презентации.
Вопросы — а как вы ставите по этому задачи разработчикам/тестерам/etc? Есть ли экспорт в Jira/Redmine?
Используете ли вы MS Project для планирования? Я думал что вы на этапе предпроектного обследования (или пресейла) составляете план проекта, который вставляете в договор — далее по нему работы надо переработать в EA? Как заказчику показываете, что план в договоре подразумевает именно то, что разработано в EA?
Спасибо за комментарии – учту на будущее.
Теперь к ответам и ремаркам:
Про презентации и заказчиков: Да, согласны, заказчики не любят сложные презентации. Мы такие и не делаем. Но когда речь идёт про обоснование трудозатрат и сроков, показать матрицу зависимостей бывает полезно, это помогает показать масштаб потенциальных изменений. Собственно, вопрос «Почему не за один день?" (утрирую, конечно), уже ставится не ребром, и возникает более конструктивное обсуждение. Заказчик становится причастным к деталям и причинно-следственных связям, что всем полезно, на наш взгляд.
Про инструменты: В своей работе мы используем разного рода инструменты — зависит от специфики проекта, масштаба, команды и т.п. EA больше про то, чтобы сложить в одном месте большинство артефактов жизненного цикла системы — требования, архитектуру, дизайн, постановки и т.п. Если говорить про закрытие договора, то зачастую результаты работ явно описаны – как правило, это набор документов + ПО. Документы (часть документов – проектные решения, спецификации, ТЗ – мы можем выгрузить из EA) должны быть проверены соответствующими специалистами заказчика. ПО должно быть проверено в ходе ряда испытаний. То есть ЕА мы используем как источник части отчётных документов.
- Про задачи: Задачи мы ставим через jira. В задаче (кроме обычного описания, версий и прочего) указывается путь (просто как текст) в проект EA к постановке (2.2.4. Про постановки) или её части (если задача для конкретного разработчика более мелкая, чем постановка). Интеграции из jira в EA, к сожалению, у нас нет: нельзя кликнуть на путь и открыть проект или его часть.
Спасибо за оперативный ответ!
1. Ага, ну для ПМа проекта со стороны заказчика — самое то — показать как компоненты системы связаны между собой, за каким из компонентов что стоит и сколько это может стоить — тут клево, что и внутренний инструмент, и внешний, менять по 100 раз не надо. И на пресейл, условно, можно взять для предметного разговора и торгов. Для проджектбордов — увы, приходится браться за Visio, упрощать.
2. Умно. У нас тоже зоопарк — план в MS Project, далее идет некая функциональная карта (Visio), которую можно показать на кикоффе, далее план бьется в задачи Jira, те бьются на пакеты работ. Результат каждой задачи — кусок фунционала или документ, условно есть итерации в рамках которых может быть решена одна или несколько задач.
В итоге — задачи, итерации и ФК связаны проджект планом — ты видишь какая итерация, какие куски должны быть готовы, что сейчас по ним делается.
Отчет соответственно делаешь основываясь на плане из проджекта — оформляется примерно так — помечаешь сделанные работы как сделанные, просроченные — красные, будущие — синие, по каждой просроченной работе даешь объяснение. Что в этом хорошего — то, что из проджекта работы попадают и в зарплатную систему, куда все списывают время по проектным задачам, и в итоге видишь каждую задачу не только как часы, но и как расходы (в зарплатной системе же ставки есть) — это очень полезно для подсчета и прогнозирования бюджета. Вопрос — если не секрет, а вы как считаете бюждеты — из Jira данные в Payroll-систему идут? Или выгрузки загрузки руками ПМов?
1. Ага, ну для ПМа проекта со стороны заказчика — самое то — показать как компоненты системы связаны между собой, за каким из компонентов что стоит и сколько это может стоить — тут клево, что и внутренний инструмент, и внешний, менять по 100 раз не надо. И на пресейл, условно, можно взять для предметного разговора и торгов. Для проджектбордов — увы, приходится браться за Visio, упрощать.
2. Умно. У нас тоже зоопарк — план в MS Project, далее идет некая функциональная карта (Visio), которую можно показать на кикоффе, далее план бьется в задачи Jira, те бьются на пакеты работ. Результат каждой задачи — кусок фунционала или документ, условно есть итерации в рамках которых может быть решена одна или несколько задач.
В итоге — задачи, итерации и ФК связаны проджект планом — ты видишь какая итерация, какие куски должны быть готовы, что сейчас по ним делается.
Отчет соответственно делаешь основываясь на плане из проджекта — оформляется примерно так — помечаешь сделанные работы как сделанные, просроченные — красные, будущие — синие, по каждой просроченной работе даешь объяснение. Что в этом хорошего — то, что из проджекта работы попадают и в зарплатную систему, куда все списывают время по проектным задачам, и в итоге видишь каждую задачу не только как часы, но и как расходы (в зарплатной системе же ставки есть) — это очень полезно для подсчета и прогнозирования бюджета. Вопрос — если не секрет, а вы как считаете бюждеты — из Jira данные в Payroll-систему идут? Или выгрузки загрузки руками ПМов?
Рассматривали более продвинутые (чем SVN и shared DB) методы совместной работы в Sparx EA? EA Cloud, EA PRO Cloud Server / Express / WebEA.
Вопрос — если не секрет, а вы как считаете бюждеты — из Jira данные в Payroll-систему идут? Или выгрузки загрузки руками ПМов?
Отвечу кратко, потому что эта тема достойна отдельной заметки. Мы ведём учёт трудозатрат по проектам. Уровень гранулярности, правила списания трудозатрат от проекта и инструменты учёта от проекта к проекту могут различаться. В итоге они все «сливаются» в одну систему учёта, фиксированную для проекта. Наверняка, это происходит автоматически (сам никогда не интересовался, но, поскольку мы в принципе стараемся избегать ручных операций в своей работе, я вряд ли ошибусь). Имея трудозатраты и ставки, мы можем получить всё остальное – текущие расходы, сопоставления плана и факта, учесть при необходимости в бухгалтерских расчётах.
P.S. прошу прощения, случайно ответил не тот комментарий — пока не очень опытный пользователь хабра в части комментариев и статей.
Добрый день. Хорошо, что подняли тему. Когда разбирался и внедрял EA, в рунете мало информации нашел.
На мой взгляд Вы не полностью используете функционал ЕА. Ведь это не только функционпльный интерфейс. По сути это набор данных, который можно использовать повсеместно. Файл проекта ЕА — это обычная база MS Access (да и MSSQL как я понял Вы пробовали). Есть возможность интеграции с другими системами.
Вы не используете диаграммы классов? Привлекаете ли Вы разработчиков к ведению документации или используете только для PM?
На мой взгляд Вы не полностью используете функционал ЕА. Ведь это не только функционпльный интерфейс. По сути это набор данных, который можно использовать повсеместно. Файл проекта ЕА — это обычная база MS Access (да и MSSQL как я понял Вы пробовали). Есть возможность интеграции с другими системами.
Вы не используете диаграммы классов? Привлекаете ли Вы разработчиков к ведению документации или используете только для PM?
Спасибо за комментарий.
Диаграммы классов мы используем – они на картинке с метамоделью в её правой части. Просто отображены без атрибутов и методов.
Вопрос наполнения репозитория согласно метамодели – вопрос конкретного проекта.
Но, как правило, тот, кто реализует постановки (а не ставит их или проектирует каркас приложения – базовые классы, интерфейсы, правила взаимодействия – словом, формирует дизайн ПО), не изменяет наполнения репозитория и соответствующие диаграммы.
Встречный вопрос: какие из функций EA мы, на ваш взгляд, недоиспользовали?
Диаграммы классов мы используем – они на картинке с метамоделью в её правой части. Просто отображены без атрибутов и методов.
Вопрос наполнения репозитория согласно метамодели – вопрос конкретного проекта.
Но, как правило, тот, кто реализует постановки (а не ставит их или проектирует каркас приложения – базовые классы, интерфейсы, правила взаимодействия – словом, формирует дизайн ПО), не изменяет наполнения репозитория и соответствующие диаграммы.
Встречный вопрос: какие из функций EA мы, на ваш взгляд, недоиспользовали?
Статья отличная, спасибо!
Буду благодарен за информацию по методике анализа взаимного влияния проектов в общей информационной системе.
Буду благодарен за информацию по методике анализа взаимного влияния проектов в общей информационной системе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Готовим проект в Sparx Enterprise Architect. Наш рецепт