Daily standup — краткий устный отчет о проделанной работе перед скрамоводом.
Зачем?
Если фичекоманда маленькая и вы знаете, что такое прозрачность - вы все в контексте общей работы. Друг другу рассказывать про вчера будет бессмысленно, вы все и так знаете. Отчёт начальству о прогрессе или потраченных человеко-часах? Странный эджайл, хотя ведь вы его понимаете как мягкий менеджмент
удивляемся, почему всего 12% стартапов доживают до 5-летнего возраста?..
Удивляются те, кто иначе понимает слово «стартап».
Если стартап - компания, созданная для проверки гипотезы - то это здорово, что гипотезы проверяются быстрее; на те же деньги можно проверить больше гипотез или если гипотез мало - быстрее прекратить этим заниматься. Так что закрытие большинства стартапов - закономерный финал, можно сказать - основная цель. Цинично, да.
Спасибо за статью и структурированные мысли! Буду давать ссылку и экономить время на объяснении :)
Только вот с микросервисным монолитом непонятно; мне кажется, объясняется обратный случай — монолитный микросервис.
Если каждый микросервис обладает внутренней структурой, которая тесно связана друг с другом, то независимость обновлений, масштабирования и внесения изменений уходит на второй план.
«структура, которая тесно связана друг с другом» - отсюда я перестал понимать. Проблема в том, что каждый микросервис внутри - суть монолит? (А что тут плохого?) Вроде бы антипаттерн здесь - это высокая связность между сервисами, но это уже другой пункт, косметические микросервисы.
Не понимаю, почему столько копий ломается именно в попытках размежевать или поженить именно СА и БА. Есть ведь и другие роли, где правильным считается залезать в как-бы чужую зону ответственности. Тестировщик, пишущий автотесты или наоборот разработчик, пишущий себе юнит-тесты - почему здесь нет холиваров и никто не сравнивает QA-с-компетенцией-DEV и DEV-с-компетенцией-QA.
К кругу вопросов и задач, которые стоят перед EA можно отнести: Определение и решение об оборудовании, … Определение потоков данных, взаимодействие с другими информационными системами .. Разработка плана разворачивания … Разработка плана администрирования приложения и вопросов доступа\безопасности.
Судя по темам, он решает вопросы «как эту штуку запустить в сети предприятия и как подружить с другими».
В то же время абзацем выше написано
Enterprise – что делать Solution – как делать
Как я понимаю эту тонкую грань, «что делать» - это удел бизнес-аналитика (домен проблемы), а «как» (домен решения) - это уже сторона разработки, в т.ч. архитекторов и системы аналитиков.
Да, а про п.5, колеса фортуны и пр. - да, это выглядит как анимация в детском саду, испанский стыд, но эти чуднЫе техники фасилитация б.. работают! И интроверты разговаривают, сначала про кошек, потом про процессы.
Взрослые серьезные люди знают, что раз в две недели у них есть выделенные два часа, когда они могут поговорить и обсудить. Такая организованность настраивает. И снижает риск замалчивания, когда человек попытается сам разобраться и … и бросит, потому что так ему ещё потом нужно будет кого-то организовывать для обсуждения и решения.
И вот взрослые серьезные люди в течение спринта или двух в курилках или самостоятельно подумывают о найденной проблеме, самостоятельно или с кем-то накидывают варианты и копают причины. Зная, что потом будет (гарантированно будет! Этот слот не займут под текучку) время эти идеи рассказать, обсудить и возможно что-то решить.
Зачем?
Если фичекоманда маленькая и вы знаете, что такое прозрачность - вы все в контексте общей работы. Друг другу рассказывать про вчера будет бессмысленно, вы все и так знаете. Отчёт начальству о прогрессе или потраченных человеко-часах? Странный эджайл, хотя ведь вы его понимаете как мягкий менеджмент
Удивляются те, кто иначе понимает слово «стартап».
Если стартап - компания, созданная для проверки гипотезы - то это здорово, что гипотезы проверяются быстрее; на те же деньги можно проверить больше гипотез или если гипотез мало - быстрее прекратить этим заниматься. Так что закрытие большинства стартапов - закономерный финал, можно сказать - основная цель. Цинично, да.
Даже СКРАМ — не методология и не управления, а тоже фреймворк командной работы. Управления как такового в СКРАМе нет
ТТМ - это показатель уровня продукта и рынка, которым все равно на ваш блеклог, другие задачи, менеджмент и состав команд
Верно. Если на дейликах нужно рассказывать, что делал вчера - вопросы к прозрачности.
Почему год? Два ведь. Два календарных года
Спасибо за статью и структурированные мысли! Буду давать ссылку и экономить время на объяснении :)
Только вот с микросервисным монолитом непонятно; мне кажется, объясняется обратный случай — монолитный микросервис.
«структура, которая тесно связана друг с другом» - отсюда я перестал понимать. Проблема в том, что каждый микросервис внутри - суть монолит? (А что тут плохого?) Вроде бы антипаттерн здесь - это высокая связность между сервисами, но это уже другой пункт, косметические микросервисы.
СБПэй?
С точки зрения простого покупателя - это платёж. В терминах законодательства - перевод
Не понимаю, почему столько копий ломается именно в попытках размежевать или поженить именно СА и БА. Есть ведь и другие роли, где правильным считается залезать в как-бы чужую зону ответственности. Тестировщик, пишущий автотесты или наоборот разработчик, пишущий себе юнит-тесты - почему здесь нет холиваров и никто не сравнивает QA-с-компетенцией-DEV и DEV-с-компетенцией-QA.
И вообще, специализация - удел насекомых (с)
Менеджеры в Скраме не контролируют, там и менеджеров-то нет.
А вот в waterfall-процессах менеджеры как раз (считают, что) контролируют и управляют.
Непонятно по ЕА
Судя по темам, он решает вопросы «как эту штуку запустить в сети предприятия и как подружить с другими».
В то же время абзацем выше написано
Как я понимаю эту тонкую грань, «что делать» - это удел бизнес-аналитика (домен проблемы), а «как» (домен решения) - это уже сторона разработки, в т.ч. архитекторов и системы аналитиков.
Всевдо-MVP из второй картинки ещё не позволяет проверить гипотезу «автомобиль им решит вопрос поездки» на прототипе-самокате
прекрасные метафоры! Я всегда радуюсь умению объяснять сложные вещи простыми словами
Если менеджмент не купил идею - аджайл вам не построить. Аджайл - не метод управления, а другое мышление
Да, а про п.5, колеса фортуны и пр. - да, это выглядит как анимация в детском саду, испанский стыд, но эти чуднЫе техники фасилитация б.. работают! И интроверты разговаривают, сначала про кошек, потом про процессы.
Про п.1-3. Люто соглашусь, но не на 100%.
Взрослые серьезные люди знают, что раз в две недели у них есть выделенные два часа, когда они могут поговорить и обсудить. Такая организованность настраивает. И снижает риск замалчивания, когда человек попытается сам разобраться и … и бросит, потому что так ему ещё потом нужно будет кого-то организовывать для обсуждения и решения.
И вот взрослые серьезные люди в течение спринта или двух в курилках или самостоятельно подумывают о найденной проблеме, самостоятельно или с кем-то накидывают варианты и копают причины. Зная, что потом будет (гарантированно будет! Этот слот не займут под текучку) время эти идеи рассказать, обсудить и возможно что-то решить.
Кажется, это работает
https://blog.scrum.ru/servant_leadership
https://management30.com/blog/servant-leadership
Кадры действительно много решают!
Но только давайте не будем отождествлять скрам-мастера (сервис-слуга) и начальника отдела (линейного руководителя)
Спасибо за прекрасный комментарий, отличное резюме всей этой статьи
Прекрасное. Минимум шестнадцать раз рука поднималась написать комментарий "а у меня был похожий случай..." :))
Подписался, жду продолжения про имена