Введите лучше метрику, оценивающую насколько сознательно и последовательно команды работают над архитектурой системы.
Есть такое понятие, как эмерджентная разработка программного обеспечения (emergent software development), характеризующее принцип, при котором нет необходимости разрабатывать детализированный дизайн архитектуры для того чтобы начать производство и отгрузку инкремента. Архитектура становится неотделимой частью существования продукта, изменение которой обусловлено дополнительной ценностью для стекйхолдеров.
Соответственно, я не считаю, что целесообразно вводить отдельную метрику для оценки команды в части работы над архитектурой, так как она находится полностью в их зоне компетенций и ответственности.
В данной статье архитектура рассматривается с точки зрения влияния на организацию производства в контексте масштабирования. Монолитная архитектура накладывает такие ограничения:
1. Горизонтальное масштабирование осуществляется с помощью дополнительного экземпляра. Что предъявляет требование к созданию новой команды для поддержки и развития;
2. Жесткая зависимость из-за единой кодовой базы в репозитории, что накладывает ограничения на релизный цикл и его зависимость, если мы захотим разбить монолит на логические блоки.
В общем, архитектура полностью повторяет принцип организации процессов.
Организации, проектирующие системы, …производят их, копируя структуры коммуникации, сложившиеся в этих организациях
adboldyrev, данная статья и является методикой. Она слегка ограничена в части детализации информации, так как требует базовых представлений и опыта в части процесса разработки программного обеспечения.
ngekht, спасибо за обратную связь! Данная статья является одной из четырёх запланированных к выпуску, которые входят в общую программу.
В свою очередь, идея написания программы обусловлена бизнес задачами:
1. Рассмотреть готовность к трансформации
2. Создать общее видение
3. Сформировать набор метрик для оценки наличия атрибутов SCRUM
Соответственно, эмпиризм является важным атрибутом SCRUM со своими метриками. Но другой вопрос, как мы можем его измерить и оценить? Думая над этим вопросом, я выделил две понятные и простые метрики:
1. Декомпозиция — характеризует способность разбивать сложные проблемы на более простые.
2. Отношение к проблеме — характеризует мировоззрение (mindset), при котором сотрудник или команда не испытывает тревожность и раздражение при появлении новой проблемы.
Петля обратной связи есть и характеризуется набором следующих атрибутов:
1. Философия эмпиризма
2. События
3. Критерии завершенности
Сценарий:
1. Нажать на кнопку «Ответить» на комментарий статьи;
2. Ввести текст ответа на комментарий;
3. Из текущего окна браузера перейти по любой другой ссылке;
4. Вернуться обратно на страницу статьи используя функцию браузера;
Actual result:
1. Раннее введённый текст отображается в строке ввода «Комментария»
2. При нажатии на кнопку «Отправить», отправляется «Комментарий»
Expected result:
1. Введённый текст отображается в строке ввода «Ответа на комментарий» ранее выбранного комментария;
2. При нажатии на кнопку «Отправить», отправлять «Ответ на комментарий»
Опыт оказался самым простым: сотрудники разбежались по своим функциональным подразделениям, так как компания имеет матричную структуру управления в рамках проекта и развитие продукта заморожено до выделения инвестиций.
Неопределенность всегда будет, так как является частью нашего сложного мира. Мы никогда заведомо не знаем к чему может привести неопределённость: будь то заморозка продукта (как в нашем случае), либо к рождению «Черного Лебедя» (отсылка к Талеб Нассим). Однако, можно попробовать научиться работать с неопределенностью на уровне всей компании и на уровне отдельного сотрудника. Компания со свей стороны управляет неопределенностью в разрезе клиентской базы, маркетинговых каналов, R&D активностей. Управление неопределенностью отдельно взятого сотрудника происходит на уровне осознания им ценности инкремента продукта, который появляется при его участии. Вот это то самое место, где срабатывает принцип синергии и случается магия — компания думает о рынке, сотрудник думает о продукте и его ценности.
Продолжая, если мы говорим про разморозку, то в новую команды маловероятно попадут прежние ее участники по той же самой причине матричного управления. Сразу появляется интересный вопрос для исследования, сколько времени понадобится новой команде для достижения коллективного интеллекта предыдущей команды.
Специфичные нужды и добавочная ценность создания стартапа никак не связанны между собой. Специфичные нужды были удовлетворены, но остался контейнер под названием стартап и его добавочная ценность заключается в том, что его можно масштабировать на рынке для других клиентов.
SCRUM: Гибкое управление продуктовыми направлениями.
Данная статья выход на этой неделе.
Есть такое понятие, как эмерджентная разработка программного обеспечения (emergent software development), характеризующее принцип, при котором нет необходимости разрабатывать детализированный дизайн архитектуры для того чтобы начать производство и отгрузку инкремента. Архитектура становится неотделимой частью существования продукта, изменение которой обусловлено дополнительной ценностью для стекйхолдеров.
Соответственно, я не считаю, что целесообразно вводить отдельную метрику для оценки команды в части работы над архитектурой, так как она находится полностью в их зоне компетенций и ответственности.
1. Горизонтальное масштабирование осуществляется с помощью дополнительного экземпляра. Что предъявляет требование к созданию новой команды для поддержки и развития;
2. Жесткая зависимость из-за единой кодовой базы в репозитории, что накладывает ограничения на релизный цикл и его зависимость, если мы захотим разбить монолит на логические блоки.
В общем, архитектура полностью повторяет принцип организации процессов.
(Конвей, 1968)
В свою очередь, идея написания программы обусловлена бизнес задачами:
1. Рассмотреть готовность к трансформации
2. Создать общее видение
3. Сформировать набор метрик для оценки наличия атрибутов SCRUM
Соответственно, эмпиризм является важным атрибутом SCRUM со своими метриками. Но другой вопрос, как мы можем его измерить и оценить? Думая над этим вопросом, я выделил две понятные и простые метрики:
1. Декомпозиция — характеризует способность разбивать сложные проблемы на более простые.
2. Отношение к проблеме — характеризует мировоззрение (mindset), при котором сотрудник или команда не испытывает тревожность и раздражение при появлении новой проблемы.
Петля обратной связи есть и характеризуется набором следующих атрибутов:
1. Философия эмпиризма
2. События
3. Критерии завершенности
Сценарий:
1. Нажать на кнопку «Ответить» на комментарий статьи;
2. Ввести текст ответа на комментарий;
3. Из текущего окна браузера перейти по любой другой ссылке;
4. Вернуться обратно на страницу статьи используя функцию браузера;
Actual result:
1. Раннее введённый текст отображается в строке ввода «Комментария»
2. При нажатии на кнопку «Отправить», отправляется «Комментарий»
Expected result:
1. Введённый текст отображается в строке ввода «Ответа на комментарий» ранее выбранного комментария;
2. При нажатии на кнопку «Отправить», отправлять «Ответ на комментарий»
p.s.: ответ получился ниже из-за баги (фичи))
Неопределенность всегда будет, так как является частью нашего сложного мира. Мы никогда заведомо не знаем к чему может привести неопределённость: будь то заморозка продукта (как в нашем случае), либо к рождению «Черного Лебедя» (отсылка к Талеб Нассим). Однако, можно попробовать научиться работать с неопределенностью на уровне всей компании и на уровне отдельного сотрудника. Компания со свей стороны управляет неопределенностью в разрезе клиентской базы, маркетинговых каналов, R&D активностей. Управление неопределенностью отдельно взятого сотрудника происходит на уровне осознания им ценности инкремента продукта, который появляется при его участии. Вот это то самое место, где срабатывает принцип синергии и случается магия — компания думает о рынке, сотрудник думает о продукте и его ценности.
Продолжая, если мы говорим про разморозку, то в новую команды маловероятно попадут прежние ее участники по той же самой причине матричного управления. Сразу появляется интересный вопрос для исследования, сколько времени понадобится новой команде для достижения коллективного интеллекта предыдущей команды.