Pavel
Конечным все равно является кастомер авто для которого софт
Но софт не решает проблем кастомера - софт решает "проблемы" автомобиля :)
Антон
Паша, мы об одном и том же в разных плоскостях
Pavel
Да.
Pavel
Мне в этом отношении больше формулировка SAFe нравится, хотя она и цинична :)
Pavel
Bring value to the enterprise
Антон
Но софт не решает проблем кастомера - софт решает "проблемы" автомобиля :)
Ага))) чего-то вспомнил смешную подачу юзерстори.))) GPS для собак: Я собака, хочу...и т.д))) Про машину: Я машина, хочу....)))))
Антон
Bring value to the enterprise
Хм))) ага цинизмом попахивает)))
D.
Но софт не решает проблем кастомера - софт решает "проблемы" автомобиля :)
Надо только вынести за скобки Tesla с обновлениями "по воздуху"))
Pavel
Тесла это компьютер, который умеет до сотни за 4 секунды разгоняться, я не машина :)
D.
вроде даже быстрее 4х
Антон
Я все-равно останусь в концепции ориентира на кастомера. Даже если это софт для зубной щётки - ей пользуется кто-то. И если софт для щётки не решит запрос зубочиста - зачем этот софт щетке)
Pavel
вроде даже быстрее 4х
Я, честно говоря, не замерял :) Не впечатлила, хотя и прикольно.
Антон
ОК, я не настаиваю :)
)))) просто важны все варианты. И как мы уже приняли - это не спор а несколько реальных фактов. И все зависит от Продукта
Pavel
https://docs.google.com/forms/d/e/1FAIpQLSfb1k5CIN20y6PnqtLrRawzjmB3pi_mWPqLDutKTLpNNHLzHw/viewform
Sergey
Не правильно понял. Я писал о том что у нас весь набор функциональных команд. Так вот, не думали вы к примеру: сейл, маркетолог, бек, фронт, тестировщик, дизайнер, девопс.
Так не думали. Такое у меня в голове не лодится. Сейчас хочу провести эксперимент и подсадить одной из команд инженера третьей линии на один Спринт. Команда получит эксперта, Инженер получит возможнтсть консультации. Но сейлза или маркетолога туда сажать смсла не вижу. Подумаю.
Yuriy
@ysmirnov1 может в топик приколоть?
это вообще лучше перенести в @agilegames), если пойдёт
d
Есть ли аджайл сертификейшен?
Yuriy
https://icagile.com/ например)
d
Я про канал в телеге
Pavel
это вообще лучше перенести в @agilegames), если пойдёт
Много спама, мало модерации, к сожалению
Yuriy
Много спама, мало модерации, к сожалению
😄, уже наоборот или движется в сторону улучшения
Yuriy
Серьезное пополнение чата), новые участники, кто вы, откуда? См. прикрепленное сообщение 😉
Evgeniya
Прикрепленное не кликабельно с мобильного
Yuriy
🔵 В группе есть традиция - представляться при входе: ▫️Какой у вас проект или где работаете? ▫️В чём вы специалист? ▫️Чем можете быть интересны или полезны сообществу? ▫️Чем интересно сообщество вам? Что вы ищете? ▫️Откуда вы? ▫️Как узнали про группу? В сообщении нужно указать тэг #whois 🔵 Правила чата: 🚫 Реклама запрещена 🚫 Политика запрещена 🚫 Публикация вакансий запрещена 🚫 Флуд и оффтопик запрещены За несоблюдение правил - одно предупреждение, далее следует бан. Здесь мы общаемся на темы, посвященные Agile, Scrum, Lean, XP, Kanban, инструментам повышения эффективности. Отвечаем на вопросы. Делимся идеями, новостями, а также публикуем анонсы. 📣 Заметили нарушение? Обратитесь, пожалуйста, к модераторам: 🔸@dmitriyabr 🔸@d_dzhafarov 🔸@NikolayKrupiy 🔸@thegreatbender 🔸@DenisIzmaylov 🔵 Параллельно с этой группой развиваются: 🔸@agile_jobs 🔸@projects_ru 🔸@products_ru 🌎 Возможно, вам также будут интересны группы: @selfdev_ru, @projects_jobs, @products_jobs, @devops_ru, @devops_jobs, @qa_ru, @qa_jobs, @mobile_jobs, @javascript_jobs, @uiux_ru, @uiux_jobs. Приятного общения!
так лучше? 😉
Alex
Прикрепленное не кликабельно с мобильного
А вроде вполне себе кликабельно :)
Evgeniya
А вроде вполне себе кликабельно :)
Да, возможно, проблема моего приложения
Evgeniya
#whois 1. СИГМА. Проект в энергетике. 2. PM, SM, proxy-PO + почти уже коуч 3. Обмен опытом, мнениями, источниками, спарринги, нэтворкинг 4. См.п.3 зеркально 5. Питер 6. Поисковая строки Tg по слову 'Scrum'
Sergey
Proxy-PO это как?
Sergey
Привет!
Evgeniya
Proxy-PO это как?
Прив. ) Это когда у заказчика нет своего РО.
Evgeniya
Когда он просто стейкхолдер, а кто-то должен собой закрывать вопрос
Sergey
Странная роль :)
Jane
У нас такое тоже есть, типа когда есть ПО но он не может быть полностью посвящен и погружен в ежедневные обязанности ПО, он дает направление, в общем описывает фичи и всю дальнейшую работу делает прокси. Потом основной ПО принимает результаты
Jane
Звучит странно, но се ля ви
Arman
У нас тоже самое :) клиенты режиссеры и они не могут исполнять роль ПО :)
Arman
Хороший термин, унесу к себе:)
Sergey
Или эта роль описана в каком-то фреймворке?
Evgeniya
Не описана. Это необходимость быть "врагом народа". Когда ты не можешь быть ни на стороне своей команды, ибо защищаешь интересы заказчика. Ни на стороне заказчика, так как работаешь у исполнителя )))
Jane
Ну почему сразу самообман. Название не важно, просто удобно так. Конечно не описано, но жизнь диктует свои суровые законы :) А вы бы как решали такую ситуацию?Мы же по сути сервисная компания, не продуктовая
Sergey
Ну а вы бы как сделали?)
Назвал бы вещи своими именами
Sergey
А как бы Вы ответили на такой каверзный вопрос? 3) You are a Scrum Master for a Development Team and one of the developers approaches you and says: Every Sprint we are not completing regression testing tor all at the selected Product Backlog items in the Sprint. Regression testing is part of the definition of "Done". We have discussed with the Product Owner and decided to change the definition of "Done" to remove regression testing. Which two actions are appropriate in this situation? A)Ask the Development Team and the Product Owner what problem they are going to solve by altering the definition of "Done" and removrng regression testing from it. Will this raise transparency or improve quality? B) Disagree With the decision and tell them that having a stringent definition oi "Done" is important for the quality of the product, and they need to follow it. C)Agree With altering the definition or "Done" as both the Development Team and Product Owner are in agreement D)Ask the Development Team and Product Owner, “Does removing regression testing from the defination of ”Done" allow the team to produce potentially releasable increments at the end or every Sprint?
Sergey
С одной стороны DoD принадлежит Scrum-команде. И она может решить его изменить. С другой стороны это ухудшает качество.
Sergey
Мой ответ А и D, но с другой стороны ...
Jane
C & D? Задача же скрам мастера организовать работу команды и не допускать всяких препятствий на ее пути. Если оунер и команда решили, вроде как нет задачи вмешиваться, если инкремент будет доставлен.
Pavel
Две стратегии пояснения: 1. Ответ B протеворечит ролям, SM не менеджер и его disagreement не имеет практического смысла и ведет к конфликту. Ответ C противоречит необходимости принимать решения всей scrum командой. В итоге остается только A и D. Стратегия пригодня для сдачи теста :) 2. Ответ A прямо задает вопрос: повышается ли transparency (ценность) + включает команду в обсуждение (не директивное управление, servant leadership, коллегиальное принятие решений) Ответ D то же самое про коллегиальность + направление в сторону potentially shippable increment, что явно противоречит желанию пропустить регрессию.
Pavel
Странная роль :)
Очень распространенная в аутсорсе :)
Ilya
В аутсорсе вообще много разных видов прокси:)
Ilya
Но чаще всего конечно разрабы:)
Pavel
Аутсорс весь "прокси".
Pavel
НО конкретно с ролью PO - PO именно прокси, потому что полностью за бэклог не отвечает, полной информацией о приоритетах не владеет и полномочй принимать решения часто в полном объеме не имеет :)
Pavel
+ обычно еще и называется Project manager :)
Pavel
И в голове у него сидит "я тут главный" :)
Sergey
А и D.
Спасибо. Значит я на правильном пути :)
Sergey
Да. Первый раз 73% сделал, чуток не добрал.
Sergey
Sergey
Самое интересное, что во всем Скрам-гайде ни слова про разрабоику ПО. НИ ОДНОГО
Pavel
Да :)
Pavel
Чет сохранил куда-то свои результаты и найти не могу
Pavel
Нашел, в PDF сохранил :)
Алекс
Ответы на вопросы?
Pavel
Нет, сводные результаты.
Pavel
Чтоб знать, что исправлять :)
Sergey
Да вот писали бы они еще темы к вопросам