В предыдущих частях Краткое содержание:
«Часть 1»
I Вступление
II Анализ рынка решений
1. Стандартизация функций систем, представленных на рынке
2. Недостатки существующих систем
3. Вызовы при создании системы поддержки производства информационных систем
III Проектирование базовой структуры системы
1. Деление решаемых проблем по типам
«Часть 2»
2. Требования и задачи для них
3. Спецификации и задачи для них
4. Сборки и задачи для них
5. Анализ фазы проектирования
Продолжим начатое в предыдущей части разрушение привычных шаблонов и конструирование других, новых.
Затронем вкратце и организацию процесса с точки зрения проектного управления. В виду того, что мы говорим о производстве более менее уникальных продуктов, то сущность – «Проект» уже упоминалась в предыдущих разделах.
Поскольку большинство методологий разработки ПО пропагандируют здоровый итерационный подход, то добавим еще один элемент, членящий проект на более мелкие его части — итерации. При этом не будем распыляться на весь процесс производства информационных систем, а организуем работу в итерациях только для активностей, связанных непосредственно с реализацией требований в коде. Это немного снизит масштабируемость нашей системы, но мы в самом начале отмечали, что универсальность существующих продуктов снижает их технологическую пригодность. Поэтому будем кроить систему под себя.
В стандартных трекерах чаще всего итерации обозначают в задачах при помощи меток, эпиков или прочих дополнительных признаков. Мы же введем дополнительную сущность «Итерация».
Возможная модель данных представлена на рис.7.
Рисунок 7. – Модель организации проекта
Предоставим возможность набирать «Спецификации» в итерацию через новый элемент «Scope на итерацию». Это позволит разрулить проблему, неизбежности реализовывать одну спецификацию в нескольких итерациях. Подавляющее большинство проектов совсем неидеальна и этот шанс может оказаться весьма нелишним.
В элементе «Scope на итерацию» добавим признак «Реализовано», организуя таким образом чек-лист для индикации успехов (ну или провала). Теперь при реализации спецификации в коде и после его тщательной проверки, можно “прокрыжить” ее в списке Scope на итерацию. А при желании этот процесс и вовсе можно автоматизировать, например, по статусам выполненных задач. ИТ менеджеры очень любят такие наглядные тюнинги в стили минимализма – только он, список задач и галочка о ее выполнении, ничего лишнего, отвлекающего внимание.
Теперь зайдем с обратной стороны Scope. Там в тылу, где ожидается получать подтверждение запланированному, завяжем «Scope на итерацию» на «Задачи SRS». Таким образом, мы сможем отслеживать все активности, выполненные по спецификациям, совершенные в рамках итерации. Те, кто внимательно читает статью, наверняка заметил, что теперь у нас образовалась избыточная связь: «Задача SRS» связана напрямую со «Спецификацией» и вдобавок, еще через «Scope на итерацию». В этих обстоятельствах, кто уж как привык разруливать подобные затруднения. Например, можно убрать связь на спецификацию, но это усложнит работу с данными. В частности задачу SRS нельзя будет выставить без итерации. А мало ли что. Или же оставить избыточную связь, но обеспечить непротиворечивость данных в ссылках. Для этого тоже есть предостаточно средств.
И уж как принято в приличном обществе, каждая итерация должна закончиться итоговой сборкой с реализованной функциональностью, в соответствии со взятым на себя обязательствами (спецификациям на итерацию). Для этого установим в «Итерации» ссылку на «Сборку».
Протестируем нашу модель вот таким сценарием работы:
На нашу модель данных этот сценарий ложится в легкую.
Итак, что мы имеем? Мы можем получить Scope по итерации, в качестве контекста реализуемого функционала. Просмотреть списки задач по типам, по исполнителям и т.п. в качестве плана исполнения. Увидеть отчеты о том, что и как из этого выполнено. И в итоге получить текущую версию продукта.
Работы по изменению (управлению) требований могут производиться вне итераций. Хотя если принципиально включить их в ее рамки, можно добавить еще одну сущность «Scope требований на итерацию» и наследовать ее от общего предка см. рис. 8. Аналогично, при острой необходимости, можно включить в итерацию еще и работы по сборкам.
Рисунок 8. – Модель организации Scope на итерацию
Рассматривая тему сборок в самом начале, мы затронули проблему интеграционных решений, подразумевающих включение в продукт одновременно нескольких сборок разных подсистем, складывающихся в единый программный комплекс. В этой плоскости возникает дилемма: с одной стороны в одном проекте задействовано одновременно несколько актуальных сборок, с другой одна и та же сборка может попасть в разные проекты и войти в разные конечные продукты. Волей неволей нависает необходимость включения еще одного элемента – «Продукт».
По факту целевой продукт как раз и должен оказаться результатом всего процесса создания информационной системы в проекте.
Для такого поворота нам теперь необходимо убрать существующую связь «Сборки» с «Проектом», а установить ее через дополнительный элемент «Сборка в Продукте», так как показано на рис.9.
Рисунок 9. – Модель организации учета целевого продукта
Поскольку собирая по крупицам новую версию целевого продукта, далеко не всегда требует выполнять пересборку самих этих крупиц (входящих в нее подсистем), то для «Сборки в продукте» укажем версию самого продукта для которой актуальна выбранная сборка. Решение так себе, и этот механизм конечно можно реализовать покрасивши.
Как вариант в этом решении, сборку каждой подсистемы, можно представлять, как отдельный продукт и формировать целевой продукт из других более элементарных продуктов.
Мы в данной публикации уже не раз вскользь затронули тему коммуницирования участников в проекте. Например, рассматривали комментирование требований и спецификаций, в ходе их обсуждения. В стандартных продуктах чаще всего есть еще полезная функция — уведомлений, информирующая участников о выставленном задании, об упоминании в комментариях и т.п.
Но вот еще одна интересная тема, которую не часто встретишь в предлагаемых продуктах – проведение совещаний и митингов в рамках рассматриваемой системы. Ведь удобно, планируя встречу, определять обсуждаемые вопросы на основе того набора элементов, которым мы оперируем в нашей системе: требований, спецификаций, сборок, итераций, заданий и т.п. Опять же и участники обсуждений всегда под рукой, в виде stakeholders (заинтересованных лиц проекта). Можно даже заранее подготовить проекты решения проблем, и позволить приглашенным накануне ознакомиться с повесткой.
Возможная модель данных представлена на рис.10.
Рисунок 10. – Модель организации совещаний
Например, представьте такую картину: несколько команд, участвующих в проекте удаленно, общаются по телефону или при помощи звукопердающих мессенджеров и обсуждают «горящий» проект. Все уже искрит и накалено до предела. Еще не страшно? Тогда усугубим. В дискуссии участвуют и аналитики, и тестировщики и разработчики, и менеджеры проекта. По началу, как не крути тема одна – кто виноват? Представили?
Ну допустим, первый вопрос обсудили, прокричались, открыли друг другу глаза, на то кем они являются на самом деле. Пора переходить ко второму — что делать? Вот тут как раз и может пригодиться заранее подготовленный список вопросов, а еще лучше — список подготовленных к нему проектов решений, которые все участники обсуждения видят на своих экранах. А теперь представьте, что прямо из вопроса любой может перейти, например, в требование или задачу по его реализации. Увидеть комментарии, отчеты. Ткнуть кого-то носом в цифры и факты. И так же легко и непринужденно вернуться обратно к страничке с вопросами. Удобно?
Но это еще не все. После обсуждения вопроса, можно сразу сформировать решения по нему, зафиксировав план дальнейших действий, который в последующем может трансформироваться в задачи исполнителям. И все, все участники оперативно это все сразу видят и молча соглашаются, или же громко возмущаются. А главное, что все это зафиксировано в системе и топором это уже не вырубишь. И теперь уже не надо прикладывать фоточки с рукописными каракулями. Такие блиц митинги очень продуктивны и эффективны в плане исправления ситуации в лучшую сторону.
В системе по спискам совещаний проекта, можно легко освежить в памяти былые баталии и возгордиться оперативно и эффективно принятыми мерами, устранившими все препятствия возникшие на пути к созданию продукта.
«Часть 1»
I Вступление
II Анализ рынка решений
1. Стандартизация функций систем, представленных на рынке
2. Недостатки существующих систем
3. Вызовы при создании системы поддержки производства информационных систем
III Проектирование базовой структуры системы
1. Деление решаемых проблем по типам
«Часть 2»
2. Требования и задачи для них
3. Спецификации и задачи для них
4. Сборки и задачи для них
5. Анализ фазы проектирования
IV ПРОЕКТИРОВАНИЕ ЭЛЕМЕНТОВ ИНФРАСТРУКТУРЫ СИСТЕМЫ
Среди бесчисленных видов волшебства созидание предоставляет большую свободу. Каждый созидает по-своему. Выкладывайся на полную и найди собственную форму.
(Сказка о хвосте феи)
Продолжим начатое в предыдущей части разрушение привычных шаблонов и конструирование других, новых.
1. Общая инфраструктура проекта
Затронем вкратце и организацию процесса с точки зрения проектного управления. В виду того, что мы говорим о производстве более менее уникальных продуктов, то сущность – «Проект» уже упоминалась в предыдущих разделах.
Поскольку большинство методологий разработки ПО пропагандируют здоровый итерационный подход, то добавим еще один элемент, членящий проект на более мелкие его части — итерации. При этом не будем распыляться на весь процесс производства информационных систем, а организуем работу в итерациях только для активностей, связанных непосредственно с реализацией требований в коде. Это немного снизит масштабируемость нашей системы, но мы в самом начале отмечали, что универсальность существующих продуктов снижает их технологическую пригодность. Поэтому будем кроить систему под себя.
В стандартных трекерах чаще всего итерации обозначают в задачах при помощи меток, эпиков или прочих дополнительных признаков. Мы же введем дополнительную сущность «Итерация».
Возможная модель данных представлена на рис.7.
Рисунок 7. – Модель организации проекта
Предоставим возможность набирать «Спецификации» в итерацию через новый элемент «Scope на итерацию». Это позволит разрулить проблему, неизбежности реализовывать одну спецификацию в нескольких итерациях. Подавляющее большинство проектов совсем неидеальна и этот шанс может оказаться весьма нелишним.
В элементе «Scope на итерацию» добавим признак «Реализовано», организуя таким образом чек-лист для индикации успехов (ну или провала). Теперь при реализации спецификации в коде и после его тщательной проверки, можно “прокрыжить” ее в списке Scope на итерацию. А при желании этот процесс и вовсе можно автоматизировать, например, по статусам выполненных задач. ИТ менеджеры очень любят такие наглядные тюнинги в стили минимализма – только он, список задач и галочка о ее выполнении, ничего лишнего, отвлекающего внимание.
Теперь зайдем с обратной стороны Scope. Там в тылу, где ожидается получать подтверждение запланированному, завяжем «Scope на итерацию» на «Задачи SRS». Таким образом, мы сможем отслеживать все активности, выполненные по спецификациям, совершенные в рамках итерации. Те, кто внимательно читает статью, наверняка заметил, что теперь у нас образовалась избыточная связь: «Задача SRS» связана напрямую со «Спецификацией» и вдобавок, еще через «Scope на итерацию». В этих обстоятельствах, кто уж как привык разруливать подобные затруднения. Например, можно убрать связь на спецификацию, но это усложнит работу с данными. В частности задачу SRS нельзя будет выставить без итерации. А мало ли что. Или же оставить избыточную связь, но обеспечить непротиворечивость данных в ссылках. Для этого тоже есть предостаточно средств.
И уж как принято в приличном обществе, каждая итерация должна закончиться итоговой сборкой с реализованной функциональностью, в соответствии со взятым на себя обязательствами (спецификациям на итерацию). Для этого установим в «Итерации» ссылку на «Сборку».
Протестируем нашу модель вот таким сценарием работы:
- Для итерации отбирается определенное количество спецификаций, включаемое в Scope;
- По Scope на каждую строку создается Задача SRS на реализацию спецификации в коде;
- Регистрируется в системе новая сборка;
- После выполнения всех задач по разработке, выставляется зада на сборку;
- По Scope на каждую строку создается Задача SRS на тестирование;
- После установки сборки на стенды, выполняются задачи на тестирование;
- По Scope на каждую строку, которая не прошла успешное тестирование, выставляются Задачи SRS на исправления ошибок;
- Повторяется с п.4, пока будут выявляться ошибки;
- Собирается крайняя в итерации сборка, подводятся итоги итерации.
На нашу модель данных этот сценарий ложится в легкую.
Итак, что мы имеем? Мы можем получить Scope по итерации, в качестве контекста реализуемого функционала. Просмотреть списки задач по типам, по исполнителям и т.п. в качестве плана исполнения. Увидеть отчеты о том, что и как из этого выполнено. И в итоге получить текущую версию продукта.
Работы по изменению (управлению) требований могут производиться вне итераций. Хотя если принципиально включить их в ее рамки, можно добавить еще одну сущность «Scope требований на итерацию» и наследовать ее от общего предка см. рис. 8. Аналогично, при острой необходимости, можно включить в итерацию еще и работы по сборкам.
Рисунок 8. – Модель организации Scope на итерацию
2. Интеграционные решения
Рассматривая тему сборок в самом начале, мы затронули проблему интеграционных решений, подразумевающих включение в продукт одновременно нескольких сборок разных подсистем, складывающихся в единый программный комплекс. В этой плоскости возникает дилемма: с одной стороны в одном проекте задействовано одновременно несколько актуальных сборок, с другой одна и та же сборка может попасть в разные проекты и войти в разные конечные продукты. Волей неволей нависает необходимость включения еще одного элемента – «Продукт».
По факту целевой продукт как раз и должен оказаться результатом всего процесса создания информационной системы в проекте.
Для такого поворота нам теперь необходимо убрать существующую связь «Сборки» с «Проектом», а установить ее через дополнительный элемент «Сборка в Продукте», так как показано на рис.9.
Рисунок 9. – Модель организации учета целевого продукта
Поскольку собирая по крупицам новую версию целевого продукта, далеко не всегда требует выполнять пересборку самих этих крупиц (входящих в нее подсистем), то для «Сборки в продукте» укажем версию самого продукта для которой актуальна выбранная сборка. Решение так себе, и этот механизм конечно можно реализовать покрасивши.
Как вариант в этом решении, сборку каждой подсистемы, можно представлять, как отдельный продукт и формировать целевой продукт из других более элементарных продуктов.
3. Поддержка коммуникации
Мы в данной публикации уже не раз вскользь затронули тему коммуницирования участников в проекте. Например, рассматривали комментирование требований и спецификаций, в ходе их обсуждения. В стандартных продуктах чаще всего есть еще полезная функция — уведомлений, информирующая участников о выставленном задании, об упоминании в комментариях и т.п.
Но вот еще одна интересная тема, которую не часто встретишь в предлагаемых продуктах – проведение совещаний и митингов в рамках рассматриваемой системы. Ведь удобно, планируя встречу, определять обсуждаемые вопросы на основе того набора элементов, которым мы оперируем в нашей системе: требований, спецификаций, сборок, итераций, заданий и т.п. Опять же и участники обсуждений всегда под рукой, в виде stakeholders (заинтересованных лиц проекта). Можно даже заранее подготовить проекты решения проблем, и позволить приглашенным накануне ознакомиться с повесткой.
Возможная модель данных представлена на рис.10.
Рисунок 10. – Модель организации совещаний
Например, представьте такую картину: несколько команд, участвующих в проекте удаленно, общаются по телефону или при помощи звукопердающих мессенджеров и обсуждают «горящий» проект. Все уже искрит и накалено до предела. Еще не страшно? Тогда усугубим. В дискуссии участвуют и аналитики, и тестировщики и разработчики, и менеджеры проекта. По началу, как не крути тема одна – кто виноват? Представили?
Ну допустим, первый вопрос обсудили, прокричались, открыли друг другу глаза, на то кем они являются на самом деле. Пора переходить ко второму — что делать? Вот тут как раз и может пригодиться заранее подготовленный список вопросов, а еще лучше — список подготовленных к нему проектов решений, которые все участники обсуждения видят на своих экранах. А теперь представьте, что прямо из вопроса любой может перейти, например, в требование или задачу по его реализации. Увидеть комментарии, отчеты. Ткнуть кого-то носом в цифры и факты. И так же легко и непринужденно вернуться обратно к страничке с вопросами. Удобно?
Но это еще не все. После обсуждения вопроса, можно сразу сформировать решения по нему, зафиксировав план дальнейших действий, который в последующем может трансформироваться в задачи исполнителям. И все, все участники оперативно это все сразу видят и молча соглашаются, или же громко возмущаются. А главное, что все это зафиксировано в системе и топором это уже не вырубишь. И теперь уже не надо прикладывать фоточки с рукописными каракулями. Такие блиц митинги очень продуктивны и эффективны в плане исправления ситуации в лучшую сторону.
В системе по спискам совещаний проекта, можно легко освежить в памяти былые баталии и возгордиться оперативно и эффективно принятыми мерами, устранившими все препятствия возникшие на пути к созданию продукта.
