« Rev
@agile_ru   809
Fwd »


Konstantin
Класс
Jane
Константин скептически настроен 😆
Konstantin
Это да, но это у меня ко всему такое
Jane
Critical thinking
Ivan
Порекомендуйте, пожалуйста, литературу/подходы по созданию бэклога продукта. Как я понял вот неплохой вариант: http://www.jpattonassociates.com/the-new-backlog/ , может что-то ещё?
Konstantin
Это все сильно зависит от продукта Общие рекомендации на дальние общими словами, ближние поподробнее Ну ещё помогут вехи
Ivan
Это все сильно зависит от продукта Общие рекомендации на дальние общими словами, ближние поподробнее Ну ещё помогут вехи
Эти слова уже слышал, но, что говорится, за душу не берут. Мне этого совсем недостаточно для понимания =( Может знаете про это пару - тройку хороших книг?
🦠
Скрам мастера букинга пожаловали
Pavel
Скрам мастера букинга пожаловали
Это хорошо или замечательно?
Konstantin
Будут хантить
Sergey
Будут хантить
Ура! Грузовик с пряниками перевернулся!
Sergey
Jane
Даждалась!
Jane
Наконец-то)
🦠
🦠
Сорри
🦠
Вырвалось
Ivan
но это не точно....
🦠
Седня интересный разговор зашел
🦠
Про то, нужна ли роль архитектора в скраме
🦠
Мол, если перекладывать ответственность — команда сама не заскейлится выдавать результат
Sergey
По опыту архитектор нужен
🦠
Но это же вне компетенций
🦠
Команда сама решает как делает
Sergey
Другое дело он обычно общественный, один на четыре команды
Sergey
Команда сама решает как делает
Нет. Конда проект большой нет
Sergey
Команда сама решает как делает
Кто в лес, кто по дрова
🦠
Ну обычно в энтерпрайзе это политика
Sergey
Ну обычно в энтерпрайзе это политика
Он самый. Но нужна экспертиза
Nikita
Очень интересно вас слушать, посоветуйте где почитать полезные вещи что бы ваш язык понимать.
🦠
Пара лет в кровавом энтерпрайзе, если кто останется живой, пусть выключит свет и закроет двери
Sergey
Я там 15 лет работаю :)
Sergey
Причем только в кровавом.
🦠
Ну свет он для новеньких, бывалые двигаются на шум
Sergey
Какие претензии? Да у нас всегда гигантомания... Что не продукт, 200 человек только разработчиков
Sergey
И весьма жесткие требования.
🦠
Бюджееет
Sergey
Бюджееет
Ну началось....
🦠
Я пошутил, в конце концов конечно люди
Yuriy
но лучше в начале)
🦠
@Cyberdyne_Systems_bot есть мелочь?
Vladimir
Нет. Конда проект большой нет
Микросервисы и больше не надо всем ноги подрезать чтоб ростом одинаковым вышли
Sergey
Проповедуешь неофиту?:)
Выпей кофе и приходи снова!
James
Кстати Panel Ozolin, ты до клавы добрался? :) Меня всетаки интересует твое мнение о архитектуре и как реализована её проработка в проектах которых ты участвовал. Это отдельный спринт или предпроектное что-то.
James
Это если у Вас продукт сам по себе или интеграции мало , а если он встраивается в экосистему где уже более 5000 сервисов, то Вам как минимум надо понимать как Ваш продукт будет взаимодействовать с другими и какие архитектурные особенности надо учитывать , чтобы потом не получить колоса на глиняных ногах
Sergey
Надо учитывать, кто же против. В первый спринт берется любая небольшая фича и пилится все вместе с архитектурой все командой. Примерно так.
James
Ну как вариант. Хотя все равно немного притянуто, как по мне.
Sergey
У Pavel опыта больше, думаю подскажет. Как кофе допьет и подобреет ;)
Sergey
Микросервисы и больше не надо всем ноги подрезать чтоб ростом одинаковым вышли
Хорошо звучит в теории, на практике... В кровавом энтерпрайзе успешных примеров не видел. В энтерайзе пару... Микросервисы могу решить ряд архитектурных проблем. Но проблему деклмпозиции домена знаний, они решают плохо.
Konstantin
Ну как вариант. Хотя все равно немного притянуто, как по мне.
У нас это решается работой с требованиями, но так мало кто делает
Konstantin
Короче не по скраму
Ivan
Писал уже. Роман Пихлер, Управление Продуктом в Скрам
Ага, спасибо, наверное раньше было, но за всем самом тяжело угнаться... или я сейчас с просонья проглядел? Если так, то прошу прощения.
Vladimir
Хорошо звучит в теории, на практике... В кровавом энтерпрайзе успешных примеров не видел. В энтерайзе пару... Микросервисы могу решить ряд архитектурных проблем. Но проблему деклмпозиции домена знаний, они решают плохо.
Делить домен на поддомены не так уж и сложно Отдельно все что связано с утентификацией Отдельно авторизация Отдельно склад Отдельно магазин Отдельно ... Был такой опыт, работает хорошо, но тут, да, надо выработать архитектуру как это всё будет взаимодействовать. Но дальше - команды могут работать независимо.
Vladimir
Может даже архитектор для этого пригодится )
Vladimir
Правда придется пару книжек по DDD проштудировать )
Sergey
Архитектуру должны делать разработчики. Тут много, но по делу. https://less.works/less/technical-excellence/architecture-design.html
Vladimir
А вобще для меня "энтерпрайз" это синомим "кучи антепаттернов". Поэтому для меня то что в энтерпрайзе что-то не далется, вовсе не означает, что чего-то делать не стоит
Sergey
Архитектуру должны делать разработчики. Тут много, но по делу. https://less.works/less/technical-excellence/architecture-design.html
Если у них хватит знаний в предметной области. Помню даже спрашивал на собеседование чем отличается классификатор от справочника. Сейчас уже не спрашиваю...
Alex
Хорошая статья. Несколько замечаний: 1. "В Scrum эти хотелки называются user stories." Нет в Скрам понятия user story. Это практика экстремального программирования. 2. "Владелец продукта подтверждает состав спринта и обязательно определяет его цель". Цель Спринта в Скраме формирует не Владелец Продукта, а Скрам команда. Это важно. 3. " В Scrum задачи рассчитываются не в часах, а в относительных единицах." Нет в Скраме про это, Это практика экстремального программирования. 4. "Скрам-мастер ... обеспечивает команду маркерами и пиццей". Тут без комментариев. Даже не буду вспоминать Скрам-гайд. Но это я придираюсь. Очень правильная статья про нарушение одного принципа Аджайл разработки - "На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе".
1. А в книге Сазерленда про скрам как раз рекомендуется юзер сториз использовать
Sergey
Если у них хватит знаний в предметной области. Помню даже спрашивал на собеседование чем отличается классификатор от справочника. Сейчас уже не спрашиваю...
"Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. " Если этого нет - смогут ли они тогда разрабатывать такое приложение?
Dеfault
А вобще для меня "энтерпрайз" это синомим "кучи антепаттернов". Поэтому для меня то что в энтерпрайзе что-то не далется, вовсе не означает, что чего-то делать не стоит
тоже не совсем сбалансированно звучит)) Энтерпрайзы работают как работают не просто так. Эти паттерны помогают им выжить. Поэтому для энтерпрайзов одни паттерны, для небольших компаний - другие, для стартапов - третьи
Sergey
тоже не совсем сбалансированно звучит)) Энтерпрайзы работают как работают не просто так. Эти паттерны помогают им выжить. Поэтому для энтерпрайзов одни паттерны, для небольших компаний - другие, для стартапов - третьи
Абсолютно верно. То что работает в стартапе не работает в Энтерпрайзе и наоборот. Какой бы ни был мотивированный проффесионал, что бы ему разобраться в Томе с Тамом потребуется несколько лет.... Энтерпрайз это в первую очередь сложность предметной области, а потом уже все остальное
Dеfault
Суть моего несогласия в том, что в "ванильном" мире не должно существовать энтерпрайзов. Слишком большая концентрация людей в одном продукте, ИМХО, свидетельствует о том, что либо в компании не уделяют должного внимания автоматизации производства, либо продукт (который уже скорее не "продукт", а "комплекс") нуждается в распиливании на несколько продуктов.
Alex
Ну все и используют. Это удобно.
Тогда не понимаю вашего замечания)
Sergey
Тогда не понимаю вашего замечания)
"В Scrum эти хотелки называются user stories." Нет в Скрам-гайде понятия User Story. Зачем это писать? Это как Скрам-доска. нет никакой Скрам-доски. Даже если Сазерленд в своей книге РЕКОМЕНДУЕТ доску использовать.
« Rev
@agile_ru   809
Fwd »