Pavel
С практической имплементацией есть очень много проблем
Pavel
Сергей, у тебя много разработчиков, которые кодеры, умеют в user interviews?
Pavel
Т.е. попробовать можно, не вопрос.
Sergey
Нет конечно.
Pavel
Всей командой делать user research.
Pavel
Только софрмировать аткоую команду...
Sergey
Чем больше я знаю, тем больше мне нужно узнать ...
Pavel
Просто те же прототипы сами по себе - waste
Sergey
Давно меня так не штырило.
Pavel
Ценности не несут :)
Sergey
Просто те же прототипы сами по себе - waste
Я понимаю. Но как быть в моей ситуации с этим? Все в командах
Pavel
Они нужны только по результатам исследования, при сформированных гипотезах и строго для верификации этих гипотез.
Sergey
Аутсорс?
Pavel
ЗАчем?
Pavel
Ну вот мое решение - PO Team
Sergey
А как?
Pavel
Т.е. цикл, строго нацеленный на поиск и валидацию.
Sergey
Такие задачи не каждый день.
Pavel
А это уже вопрос к процессу.
Pavel
"такие задачи", по сути, бесконечный цикл.
Pavel
Должны быть, по крайней мере.
🦠
The mom test рулит для lsc interviews
Sergey
Рука отваливается, я спать :( Мне осталось пять чаов до подъема.
Sergey
Было приятно пообщаться.
Pavel
Спокойной ночи :)
Pavel
И, кстати, чтоб еще, вдогонку, мозг возрвать - есть еще уровень стратегии предприятия :)
Sergey
Спс
Sergey
Угу. У меня диплом MBA
Sergey
Я догадываюсь :)
Pavel
Который в LeSS вообще проигнорировали начисто :)
Sergey
Ага. Операционный и функциональный уровень управления схлопнуты.
Pavel
Это by design, кстати.
Sergey
Я спать. С удовольствием обсужу в другой раз. Мне вообще интересен Скрам вне ИТ. Мозг хочет :)
Pavel
Спокойной ночи
Pavel
https://www.designbetter.co/designops-handbook/introducing-designops
Pavel
Но сразу скажу, DesignOps это новый модный термин, который хз сколько проживет.
Pavel
Что не делает "книгу" бесполезной для понимания сложностей процесса дизайна и задач, котоыре перед дизайном стоят.
Yuriy
Jeff Sutherland and Scrum Inc
Pavel
Юра, то что я писал про PO Team имеет немного не тот контекст, что Product Owner Cycle Сазерленда.
Yuriy
ну ок, мне показалось, что такой или близкий)
Pavel
Близкий. Я говорил в первую очередь о несовместимости scope и неполной совместимости процесса у PO Team и обычной scrum team
Pavel
У PO Team в бэклоге будут доминировать spike-like айтемы, которым нельзя задать эстимейт, только таймбокс. + конкретно UX Research вообще тяжело будет уложить в спринт - неполный user flow бесполезен, его не посплитишь на части вертикально, а верификация будет напрямую зависеть от длинны этого flow
Pavel
+ опции :)
Pavel
А у сазерленда PO cycle это подразумевающаяся, но не описанная формально часть scrum cycle, Управление бэклогом, приоритетами, содержимым айтемов и т.п.
Yuriy
каким образом PO готовит бэклог, я считаю неважно, с точки зрения Scrum, он отвечает за максимизацию ценности для стейкходеров
Pavel
Ну да, совершенно верно.
Yuriy
так что не вижу противоречия, просто описали вторую часть 😉
Pavel
Противоречие в "команда самоорганизована и кросс-функциональна, потому способна самостоятельно разобраться с входящими требованиями" против "анализ и подготовка требований для команды выполняется другой командой".
Pavel
Проитворечие со scrum действительно есть :)
Pavel
Т.е. в скраме подразумевается наличие мета-цикла между поставкой ценности и приходом новых айтемов в бэклог. Про него рассказывают на тренингах, например.
Pavel
Но он не описан :)
Pavel
И из-за этого любая его имплементация вызывает холивар про "трушность".
Yuriy
дочитаю утром)
Pavel
Но я вообще еретик и SAFeовец, мне можно что угодно :)
Антон
Ага. Операционный и функциональный уровень управления схлопнуты.
Хороший вопрос. Погружусь и маякну.
Max
An item considered to be "Done" only if:
- Code passed through a code review process
- Test cases covering the item are in the test management platform
- Test cases were executed against the item and no bugs were found
- All related code is integrated and deployed on a staging environment
- Regression and Integration testing did not expose any new bugs
- Product Owner confirmed that all acceptance criteria met
Как тестер ответственно заявляю что в вашем DoD проблема в пунктах 3 и 5. В худшем случае такие формулировки приведут к отсутствию тестирования продукта в принципе.
🦠
есть еще мутационное тестирование для конферма, что юнит-тесты обладают хорошим покрытием, но это уже следующий уровень)
🦠
и неплохо бы иметь MSI в районе 75% как минимум
Pavel
Как тестер ответственно заявляю что в вашем DoD проблема в пунктах 3 и 5. В худшем случае такие формулировки приведут к отсутствию тестирования продукта в принципе.
Когда придет тестер взамен ушедшего - поменяем формулировки.
Pavel
Опять же, не вполне верно считать, что команда обязательно захочет game the system и не проводить тестирование, чтобы не найти багов :)
V
Всем привет! Есть опыт таких гибких прдходов в промышленности? Поделитесь успешными кейсами
Pavel
В каком контексте?
Pavel
Есть огромный опыт применения Lean в промышленности.
Pavel
Он, собственно, и вышел из промышлености :)
V
Управление производством. Газовое производство. Европейская компания. Матричная структура. Множество задач, разные команды и цели проектов. Моя позиция - руководитель подразделения. На мне сосредоточены собственно практически все цели и проекты компании
V
То что дало реальный толчок вперед сейчас- самая простая канбан доска. Огромный плюс- появляется полная картинка задач, можно группировать и дозировать задачи
V
Интересно, как гибкий подход применить к опасному производственному объекту
Sergey
Канбан он как бы из промышленности и вышел
Sergey
Интересно, как гибкий подход применить к опасному производственному объекту
А что хотите?
В чем проблема?
V
А что хотите?
В чем проблема?
Перейти от директивного подхода, который у сотрудников сформировался ранее, к более гибкому- поставить в систему реализацию проектов, сбор обратной связи, идей, и т.д. При этом остаться в рамках опасного объекта+ система контроля задач, возможно есть какие наработки, кроме доски
Sergey
Перейти от директивного подхода, который у сотрудников сформировался ранее, к более гибкому- поставить в систему реализацию проектов, сбор обратной связи, идей, и т.д. При этом остаться в рамках опасного объекта+ система контроля задач, возможно есть какие наработки, кроме доски
Я понимаю, вы хотите, что бы сотрудники проявляли инициативу, улучшали производство, но при этом неукоснительно соблюдали инструкции потому как производство опасное?
Sergey
Если да, то лиин для вас.
Sergey
Павел выше писал
Pavel
Перейти от директивного подхода, который у сотрудников сформировался ранее, к более гибкому- поставить в систему реализацию проектов, сбор обратной связи, идей, и т.д. При этом остаться в рамках опасного объекта+ система контроля задач, возможно есть какие наработки, кроме доски
Попробуйте посмотреть в сторону Toyota Production System в ключе организации работы и TOC в контексте организации потока задач
Pavel
Комбинация очень эффективна.
V
Область технологии-изменения крайне осторожно, операционка- заказать, получить, позвонить- уже более гибко. А также интересна реализация проектов и глобальных директив- гибко, с адаптацией к реалиям и обратной связью
Pavel
В чате в основном айтишники, я не уверен, что тут есть люди, способные дать практические советы в контексте производства.