Sergey
Есть понятие Элемент Бэклога
Alex
"В Scrum эти хотелки называются user stories." Нет в Скрам-гайде понятия User Story. Зачем это писать? Это как Скрам-доска. нет никакой Скрам-доски. Даже если Сазерленд в своей книге РЕКОМЕНДУЕТ доску использовать.
В скрам гайде нет. Но имхо юзер сториз очень органично смотрятся в скраме (наверное потому Сазерленд и акцентирует на этом внимание).
Konstantin
Суть моего несогласия в том, что в "ванильном" мире не должно существовать энтерпрайзов.
Слишком большая концентрация людей в одном продукте, ИМХО, свидетельствует о том, что либо в компании не уделяют должного внимания автоматизации производства, либо продукт (который уже скорее не "продукт", а "комплекс") нуждается в распиливании на несколько продуктов.
Вероятно в будущем, если еще и GE накроется с очередным пузырем, то отношение к монстрам сильно пересмотрят.
Konstantin
GE general elektrik ?
Mikhail
Про GE накроется - это как?
Vladimir
http://metrolog.net.ua/download/Poster_TMForum_TAM_ru.jpg
Вот наши домены...
Выглядит сложным, но в то же самое время хорошо поделенным на поддомены.
В итоге нужен постоянный архитектор?
Sergey
В скрам гайде нет. Но имхо юзер сториз очень органично смотрятся в скраме (наверное потому Сазерленд и акцентирует на этом внимание).
Так я об этом выше и написал. Почему я акцентирую внимание на этом .... бывают ситуации, когда работающий Скрам (который вытаскивает проблемы как хороший экскаватор) пытаются обгадить, акцентируя внимание на вещах, которые к Скраму не имеют никакого отношения. Ну те же юзер Стори или оценку в относительных единицах. В этом случае я всегда аппелирую, что эти практики не имеют отношения к Скраму и их можно поменять. В отличии от тех элементов, событий и артефактов Скрама , которые менять или удалять никак нельзя и которые как раз и позволяют видеть проблемы. А чтобы поменять надо этого захотеть и придумать что-то новое, вместо того, чтобы ныть и рушить уже созданное. И таких проблем,которые люди списывают на Скрам - 99% И не зная Скрам-гайда можно очень легко впасть в общее настроение. А это плохо для Скрам-мастера.
Konstantin
Про GE накроется - это как?
Ну газет не читаете? ;) Пишут что их банкротство может быть спусковым крючком следующей петли кризиса. А там как вопрос в качестве управления солянкой активов на падающем рынке.
Konstantin
да ))) выдумывать всякие фразы - это прям
Konstantin
спусковой крючок )))
Konstantin
Так я об этом выше и написал. Почему я акцентирую внимание на этом .... бывают ситуации, когда работающий Скрам (который вытаскивает проблемы как хороший экскаватор) пытаются обгадить, акцентируя внимание на вещах, которые к Скраму не имеют никакого отношения. Ну те же юзер Стори или оценку в относительных единицах. В этом случае я всегда аппелирую, что эти практики не имеют отношения к Скраму и их можно поменять. В отличии от тех элементов, событий и артефактов Скрама , которые менять или удалять никак нельзя и которые как раз и позволяют видеть проблемы. А чтобы поменять надо этого захотеть и придумать что-то новое, вместо того, чтобы ныть и рушить уже созданное. И таких проблем,которые люди списывают на Скрам - 99% И не зная Скрам-гайда можно очень легко впасть в общее настроение. А это плохо для Скрам-мастера.
Классная мысль. Подумалось тут, что все откопанные проблемы и решать нужно в рамках фреймворка (скрамгайда), ну или в духе его как максимальное отступление. А когда "решение" (а реально это не решение) берется из другой оперы, это ослабляет фреймворк и размывает фокус.
Sergey
Выглядит сложным, но в то же самое время хорошо поделенным на поддомены.
В итоге нужен постоянный архитектор?
Нужна группа архитектоов, опрд домены кажутся небольшими :) но в реальности там бездна :)
Vladimir
Нужна группа архитектоов, опрд домены кажутся небольшими :) но в реальности там бездна :)
Группа архитекторов на каждый поддомен?
Vladimir
Если достаточно одного архитектора на поддомен, то это просто член команды поддомена. Причем это не обязательно должна быть позиция "архитектор", а просто прокаченный скил проектирования.
Sergey
Группа архитекторов на каждый поддомен?
Да. И надо понимать что в поддомене не один продукт и не одна команда.
Sergey
Vladimir
Да. И надо понимать что в поддомене не один продукт и не одна команда.
Ладно, в таких масштабах я не бывал.
Alex
Pavel
Konstantin
Мне тоже интересен ответ на тот вопрос. ☝️
Artem
Архитектуру нельзя предусмотреть. Это грабли на которые все наступают из раза в раз. Вы тратите месяц на проработку архитектуры, начинаете разработку, и уже через 3 месяца хочется что-то кардинально поменять
Artem
Так что даже в книжках пишут - лучшая архитектура создаётся в процессе работы, а не до
Artem
Так что никаких отдельных спринтов.
Konstantin
это вы настоящих архитекторов не видели
Konstantin
как я скрам
Artem
А вот отдельные pbi да
Artem
Оверкиллят очень сильно
Konstantin
повезло
Konstantin
я только одного видел
Artem
Могут помочь на полгода
Konstantin
все остальные просто программисты
Artem
Но потом все равно начинается шатание
Sergey
А чем архитектор от программиста отличается?
Artem
Ну я видел 4х
Konstantin
)
Sergey
Ну вот и я так думаю.
Artem
"давайте все предусмотрим заранее, чтобы быть готовыми"
Konstantin
нет
Artem
Это просто не работает на дальнюю перспективу
Sergey
У нас архитектуру в сообществах обсуждают. Вполне себе успешно
Konstantin
если есть требования по быстродействию или нагрзуке или инфрастуктуре
Artem
Но! Архитектор нужен
Konstantin
то это можно просчитать
Konstantin
и заранее знать бюджет
Sergey
Там есть менторы компонентов. Это как раз очень опытные люди. Сообща все и делают. Ни от кого не зависят.
Konstantin
что бы все это запустить
Artem
то это можно просчитать
Можно, и это делать надо. Я ж не сказал, что архитекторы не нужны. Не нужно перезакладываться на потенциальное будущее
Konstantin
да - сделать отлично решение что бы на демо работал
Konstantin
вылодить в прод
Konstantin
дать рекламу
Konstantin
и лечь
Konstantin
на месяц другой
Artem
Ты очень максималист, это не помогает. И не читаешь, что я пишу. Зачем так обсуждать вопросы я не понимаю
Artem
Я ведь с тобой даже во всем согласился. Но нет, нужно обязательно сострить )
Konstantin
Давайте вопрос изменим и переформулируем не про архитектуру, а про дизайн интерфейса, например. Когда в явном виде напрашивается вариант подготовительного спринта. какие будут бест практис в том случае? Начинают все одновременно.
Artem
Что вы хотите сделать на подготовительном спринте?
Artem
Который напрашивается
Konstantin
я бы хотел послушать как вы порекомендуете поступить.
Artem
я бы хотел послушать как вы порекомендуете поступить.
Для этого мне надо понять, что подразумевается под подготовительным спринтом, чем он отличается от обычного и почему вам это кажется не соответствующим скраму.
Konstantin
Под словами напрашивается - типа начальник говорит. А мы ему - у нас есть более удобное решение ... ;)
Artem
В скраме нет запрета сделать целью спринта "Разработать дизайн макет приложения"
Artem
Это ценно. После спринта вы сможете показать макет юзерам и собрать фидбэк
Konstantin
И вот оно ... Перефразирую еще раз вопрос - как мы организуем первый спринт. Ну это типа художники рисуют, остальным что? ;)
Artem
Все рисуют. Вы не поверите, но приложения на телефоне все видели. Кто-то рисует в индизайне, кто-то пилит это сразу в приложу, пусть на моках, но это уже приложение, с какой-то первой архитектурой (!) и которое можно потыкать на тесте
Artem
А если ваши художники не способны вместе с командой делать дизайн, то это повод их научить
Artem
Они тоже любят "давайте мы ща тут на месяц уйдем и придем с готовым дизайном который все предусмотрит"
Artem
Дальше можно повторить мои посты про архитектуру, заменив это слово на дизайн )
Jane
Pavel
Вообще лучший подход к архитектуре - это нанять человека, способного предусмотреть всё и разработать архитектуру, которая всегда все будущие кейсы покроет без изменений.
Akkedis
а чо, такие бывают? чтобы все предусмотреть
Pavel
Но, к сожалению, его уже наняли.
Pavel
Так что придется смириться с тем, что архитектуру придется делать не идеальной
Pavel
А чтобы жить с неидеальной архитектурой, нужно делать ее гибкой и пригодной к измененеиям.
Pavel
Собственно все, что я думаю про архитектуру в agile :)
Artem
Не, если такие люди есть, то это однозначно лучший подход. )) Ещё нанять того, кто может беклог весь заранее предусмотреть, и все. Остаётся только сделать - никакой скрам уже и не нужен
Artem
А пока приходится изгаляться да )