Я такого никогда не делал, но как мне кажется, чисто по ощущениям, для начала надо, чтобы у вас был какой-нибудь чувак с презентационными скилами чтобы продать изменения бизнесу. То есть в какие проблемы для бизеса выливаются проблемы разработки и какими изменениями их достичь.
Например, одинаковый приоритет задач — все равно, что отсутствие приоритета. Внедрение единого беклога и единого PO может сделать разработку более предсказуемой — как электронная очередь в сбербанке. Дыры в безопасности — риски потерь денег (тут чувак красочно расписывает какие-нибудь примеры точно такого же бизнеса как ваш) и т.д.
Дальше надо понять с кем можно говорить, кто может менять процесс и какие части трудно изменить, какие нет.
У вас есть люди которые говорят ярко и доступно и умеют договариваться и в курсе ваших проблем?
Ктоме вас лично кто-то понимает ситуцию и также недоволен происодящим?
А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :)
В скраме команда самоуправляема, и встроенны механизмы обратной связи от разработчиков — каждый день задается вопрос, не мешает ли что разработке, по окончанию спринта устраивают ретроспективу.
Development Team Size
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
Как часто допускается вносит изменения в ТЗ?
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team
У скрама есть автор, автор написал Scrum guide и книжки. То есть, по крайне мере, можно понять, что вкладывает в это понятие автор, а что является дополнением.
Так же это "что-то организовано" может быть набором вариантов, из которых можно выбрать подходящий вам.
Ну вот для вас и ваших менеджеров из учета следует давление. А это не везде так. Когда понимают, что если давят по времени падает качество некоторые не давят
Мне кажется, khim и VolCh, во-первых, находятся в режиме спора (то есть для них главное скорее переспорить или выразить эмоции от принятого у них стиля менеджемента, чем узнать, как в Scrum что-то организовано). Во-вторых, не хотят слышать что бывает по другому и что подход к работе меняется :)
Там не написано про противоположности, а про то, что нужно стать уникальным. И за счет глобализации получить достаточную востребованность — среди семи миллиардов человек найдется достаточно большая толпа кому нужет садовник-визажист :)
Будьте уникальны. Есть два пути. Первый — это гиперспециализация. Вы можете стать экспертом по особому виду экземы, тесту, спорту, музыкальному инструменту или еще чему-нибудь. Фокус, фокус, фокус, а затем становитесь глобальным. Второй — вы добиваетесь успеха путем дефисирования, написания через дефис, то есть комбинирования противоположностей. Настройщики-технологи, визуальный-эргономист, психо-лингвисты уже ходят по земле.
Немного не так — если то, что вы делаете дополняет скрам или ему противоречит, то есть вероятность, что в провале проекта виноват не скрам, а ваши дополнения и противоречия
И еще. Для искажённого скрама есть отдельное название "scrumbut" ("скрамно") https://www.scrum.org/scrumbut так, что наверное стоит использовать его. "у нас внедрили скрамно, в результате все уводились"
Я???
Я такого никогда не делал, но как мне кажется, чисто по ощущениям, для начала надо, чтобы у вас был какой-нибудь чувак с презентационными скилами чтобы продать изменения бизнесу. То есть в какие проблемы для бизеса выливаются проблемы разработки и какими изменениями их достичь.
Например, одинаковый приоритет задач — все равно, что отсутствие приоритета. Внедрение единого беклога и единого PO может сделать разработку более предсказуемой — как электронная очередь в сбербанке. Дыры в безопасности — риски потерь денег (тут чувак красочно расписывает какие-нибудь примеры точно такого же бизнеса как ваш) и т.д.
Дальше надо понять с кем можно говорить, кто может менять процесс и какие части трудно изменить, какие нет.
У вас есть люди которые говорят ярко и доступно и умеют договариваться и в курсе ваших проблем?
Ктоме вас лично кто-то понимает ситуцию и также недоволен происодящим?
Удалось ли вам прочитать хотя бы те цитаты, которые я привел? Хотя бы выделенное жирным ;)
Там есть про рекомендуемый размер комаднды.
Посмотрите в скрам гайд.
Задача SM — чтобы процесс соблюдался, а не писать ТЗ.
Задача PO — чтобы продукт был клёвый — управление беклогом и приоритетами.
Никаких ТЗ в скраме нет, как собирать требования, в какой форме их представлять — не ограничивается. Скрам про управление процессом разработки.
В Agile духе писать User Stories.
Если вы хотите разобраться — читайте гайд — он написан понятным языком и хорошо структурирован.
В скраме команда самоуправляема, и встроенны механизмы обратной связи от разработчиков — каждый день задается вопрос, не мешает ли что разработке, по окончанию спринта устраивают ретроспективу.
Никаких менеджеров в скраме нет.
http://www.scrumguides.org/scrum-guide.html#team
Development Team Size
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team
Еще можно архивы grammar challenge
У скрама есть автор, автор написал Scrum guide и книжки. То есть, по крайне мере, можно понять, что вкладывает в это понятие автор, а что является дополнением.
Так же это "что-то организовано" может быть набором вариантов, из которых можно выбрать подходящий вам.
Ну вот для вас и ваших менеджеров из учета следует давление. А это не везде так. Когда понимают, что если давят по времени падает качество некоторые не давят
кто знает, кто знает
Мне кажется, khim и VolCh, во-первых, находятся в режиме спора (то есть для них главное скорее переспорить или выразить эмоции от принятого у них стиля менеджемента, чем узнать, как в Scrum что-то организовано). Во-вторых, не хотят слышать что бывает по другому и что подход к работе меняется :)
Эффект воздействия описан здесь извините, это видео :), но зато ссылка воспроизведет нужный кусочек
Наверное, об этом было бы написано в книжке "Лень в стиле фанк", но потенциальным авторам было лень ее написать.
Там не написано про противоположности, а про то, что нужно стать уникальным. И за счет глобализации получить достаточную востребованность — среди семи миллиардов человек найдется достаточно большая толпа кому нужет садовник-визажист :)
https://www.mountaingoatsoftware.com/blog/estimating-with-tee-shirt-sizes
Я думаю, никакая методология не даст хорошего результата на ваших "типичных менеджерах". Надо им развиваться в нетипичных.
Бизнес в стиле фанк:
Вы просто привыкли к таким менеджерам и вам кажется, что других не бывает :)
Немного не так — если то, что вы делаете дополняет скрам или ему противоречит, то есть вероятность, что в провале проекта виноват не скрам, а ваши дополнения и противоречия
Я этот термин уже видел, да и искать его проще https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=%D1%81%D0%BA%D1%80%D0%B0%D0%BC%D0%BD%D0%BE
И еще. Для искажённого скрама есть отдельное название "scrumbut" ("скрамно") https://www.scrum.org/scrumbut так, что наверное стоит использовать его. "у нас внедрили скрамно, в результате все уводились"