Comments 7
>Релизный выход версий системы.
Чем отсуствие scrum'а мешает настроить релиз процесс именно под ваши условия? Найдите тех, кто готов взять на себя работу релиз инженера.
>Водопадная модель управления жизненным циклом ПО.
Даже в водопаде была итеративность, водопад это была первая попытка формализаци процесса разработки, в котором просто были выделены этапы разработки, на сегоднячний день кардинально ничего не поменялось, только циклы стали быстрее и многое автоматизировано.
> Невозможность жесткого планирования, так как задачи от заказчика приходят в любое время.
Это задача PM, Product Owner или любого другого, который умеет общаться с заказчиком на его языке, а главное у заказчика есть доверие к нему.
Вход>Неравномерность загруженности аналитиков.
получить>В любой момент времени аналитик знает, чем ему заняться.
Проблема руководителя аналитиков, скрам не поможет.
>Функциональная распределенность зон экспертизы аналитиков.
Тут вообще непонятно то ли это плохо то ли хорошо. Экспертиза нужна с каким-то разумным перекрытием (bus factor)
>Возможность действовать только в рамках команды аналитиков.
Почему аналитик не может дойти до тестировщика, разработчика, бизнеса, почему есть эти ограничения?
>Учитывать и назначать приоритетность задач в работу
Работа лида команды и менеджера
>Короткие спринты могут позволить отслеживать, фиксировать и выполнять задачи и точнее прогнозировать попадание задач в релиз.
Почему ваше руководство не может договориться с заказчиком что и когда релизят: фиксированные сроки — плавающий scope или наоборот, плавающие сроки, фиксированный scope, при чем каждый релиз может релизиться по своей схеме.
>Создавать беклог задач аналитикам.
А что backlog без скрама уже отменили?
>Попробовать новое, повысить командный дух.
Это явно не скрам, есть более интересные способы :)
А где тут про скрам собственно? Где факты того, что текущая модель плоха или не оптимальна, где аргументы что надо менять процесс, а не людей, например?
Такое чувство что вы пытаетесь «натянуть» сову на глобус.
Если ситуация выше истинная, то надо сменить руководителя над аналитиками или вообще руководителя департамента. Классическая попытка слабого и неопытного руководства прикрытся процессом.
Чем отсуствие scrum'а мешает настроить релиз процесс именно под ваши условия? Найдите тех, кто готов взять на себя работу релиз инженера.
>Водопадная модель управления жизненным циклом ПО.
Даже в водопаде была итеративность, водопад это была первая попытка формализаци процесса разработки, в котором просто были выделены этапы разработки, на сегоднячний день кардинально ничего не поменялось, только циклы стали быстрее и многое автоматизировано.
> Невозможность жесткого планирования, так как задачи от заказчика приходят в любое время.
Это задача PM, Product Owner или любого другого, который умеет общаться с заказчиком на его языке, а главное у заказчика есть доверие к нему.
Вход>Неравномерность загруженности аналитиков.
получить>В любой момент времени аналитик знает, чем ему заняться.
Проблема руководителя аналитиков, скрам не поможет.
>Функциональная распределенность зон экспертизы аналитиков.
Тут вообще непонятно то ли это плохо то ли хорошо. Экспертиза нужна с каким-то разумным перекрытием (bus factor)
>Возможность действовать только в рамках команды аналитиков.
Почему аналитик не может дойти до тестировщика, разработчика, бизнеса, почему есть эти ограничения?
>Учитывать и назначать приоритетность задач в работу
Работа лида команды и менеджера
>Короткие спринты могут позволить отслеживать, фиксировать и выполнять задачи и точнее прогнозировать попадание задач в релиз.
Почему ваше руководство не может договориться с заказчиком что и когда релизят: фиксированные сроки — плавающий scope или наоборот, плавающие сроки, фиксированный scope, при чем каждый релиз может релизиться по своей схеме.
>Создавать беклог задач аналитикам.
А что backlog без скрама уже отменили?
>Попробовать новое, повысить командный дух.
Это явно не скрам, есть более интересные способы :)
А где тут про скрам собственно? Где факты того, что текущая модель плоха или не оптимальна, где аргументы что надо менять процесс, а не людей, например?
Такое чувство что вы пытаетесь «натянуть» сову на глобус.
Если ситуация выше истинная, то надо сменить руководителя над аналитиками или вообще руководителя департамента. Классическая попытка слабого и неопытного руководства прикрытся процессом.
>>Релизный выход версий системы.
>Чем отсуствие scrum'а мешает настроить релиз процесс именно под ваши условия? Найдите тех, кто готов взять на себя работу релиз инженера.
В данном случае это константа, от которой мы отталкиваемся, как и большинство пунктов из списка «что на входе».
>>Водопадная модель управления жизненным циклом ПО.
>Даже в водопаде была итеративность, водопад это была первая попытка формализаци процесса разработки, в котором просто были выделены этапы разработки, на сегоднячний день кардинально ничего не поменялось, только циклы стали быстрее и многое автоматизировано.
Интересно. В нашем случае, итеративность тоже была на стыке команд. Но с помощью ScrumBut мы формализуем внутреннюю работу команды, создав итеративность внутри команды и сохранив при этом межкомандное взаимодействие по передаче отработанных рабочих элементов.
>> Невозможность жесткого планирования, так как задачи от заказчика приходят в любое время.
>Это задача PM, Product Owner или любого другого, который умеет общаться с заказчиком на его языке, а главное у заказчика есть доверие к нему.
А зачем нам влиять на заказчика? Мы с радостью готовы делать все задачи в любое время, надо только организовать процесс внутри. Чем скорее начнем, тем скорее закончим и наш продукт будет прокачан. Все счастливы.
>>Вход>Неравномерность загруженности аналитиков.
получить>В любой момент времени аналитик знает, чем ему заняться.
>>Учитывать и назначать приоритетность задач в работу
>Проблема руководителя аналитиков, скрам не поможет.
>Работа лида команды и менеджера
Руководитель тут не при чем. Scrum как раз ее и отвечает на этот вопрос. Есть такой принцип, что команда сама решает, чем заняться каждому в каждый момент времени из бэклога, который готовит и приоритезирует product owner. Как раз метод кнута или еще какие-то методы силового воздействия тут совсем вне концепции. Благодаря прозрачности процесса в целом и каждого участника между собой, каждый активно стремиться включаться в рабочий процесс. Нагрузка фактически закладывается путем подготовки и приоритизации бэклога.
>>Функциональная распределенность зон экспертизы аналитиков.
>Тут вообще непонятно то ли это плохо то ли хорошо. Экспертиза нужна с каким-то разумным перекрытием (bus factor)
Я бы не стала говорить в градациях хорошо/плохо. Это не всегда удобно. Так как создает неравномерность нагрузки в том числе. Бывают проектные ситуации, когда по одному направлению сразу много задач, а по другим мало или нет совсем. В таком случае, одни могут зашиваться, а других будет тяжело подключать, т.к. пользы от них немного. Кроме того, взаимное обогащение экспертизой в последствии полезно для командной работы — всяких brain storm'ов, например, в рамках какой-нибудь большой интересной амбициозной задачки.
>>Возможность действовать только в рамках команды аналитиков.
>Почему аналитик не может дойти до тестировщика, разработчика, бизнеса, почему есть эти ограничения?
Аналитик может и с радостью это делает. Я тут про реорганзиацию процесса работы над задачами — реорганизовывать мы могли только свой участок работы.
>А где тут про скрам собственно? Где факты того, что текущая модель плоха или не оптимальна, где аргументы что надо менять процесс, а не людей, например?
я скрам-мастер :) у меня есть команда и я не меняю людей :)
Подробнее про скрам я напишу в след статье. Но тут хочу добавить, что скрам позволяет команде ощущать самоорганизацию своей деятельности, ответственность за результат команды, имея при этом полезное регулярное командное взаимодействие, позволяет нам учиться друг у друга, быть действительно командой и выдавать результат.
>Чем отсуствие scrum'а мешает настроить релиз процесс именно под ваши условия? Найдите тех, кто готов взять на себя работу релиз инженера.
В данном случае это константа, от которой мы отталкиваемся, как и большинство пунктов из списка «что на входе».
>>Водопадная модель управления жизненным циклом ПО.
>Даже в водопаде была итеративность, водопад это была первая попытка формализаци процесса разработки, в котором просто были выделены этапы разработки, на сегоднячний день кардинально ничего не поменялось, только циклы стали быстрее и многое автоматизировано.
Интересно. В нашем случае, итеративность тоже была на стыке команд. Но с помощью ScrumBut мы формализуем внутреннюю работу команды, создав итеративность внутри команды и сохранив при этом межкомандное взаимодействие по передаче отработанных рабочих элементов.
>> Невозможность жесткого планирования, так как задачи от заказчика приходят в любое время.
>Это задача PM, Product Owner или любого другого, который умеет общаться с заказчиком на его языке, а главное у заказчика есть доверие к нему.
А зачем нам влиять на заказчика? Мы с радостью готовы делать все задачи в любое время, надо только организовать процесс внутри. Чем скорее начнем, тем скорее закончим и наш продукт будет прокачан. Все счастливы.
>>Вход>Неравномерность загруженности аналитиков.
получить>В любой момент времени аналитик знает, чем ему заняться.
>>Учитывать и назначать приоритетность задач в работу
>Проблема руководителя аналитиков, скрам не поможет.
>Работа лида команды и менеджера
Руководитель тут не при чем. Scrum как раз ее и отвечает на этот вопрос. Есть такой принцип, что команда сама решает, чем заняться каждому в каждый момент времени из бэклога, который готовит и приоритезирует product owner. Как раз метод кнута или еще какие-то методы силового воздействия тут совсем вне концепции. Благодаря прозрачности процесса в целом и каждого участника между собой, каждый активно стремиться включаться в рабочий процесс. Нагрузка фактически закладывается путем подготовки и приоритизации бэклога.
>>Функциональная распределенность зон экспертизы аналитиков.
>Тут вообще непонятно то ли это плохо то ли хорошо. Экспертиза нужна с каким-то разумным перекрытием (bus factor)
Я бы не стала говорить в градациях хорошо/плохо. Это не всегда удобно. Так как создает неравномерность нагрузки в том числе. Бывают проектные ситуации, когда по одному направлению сразу много задач, а по другим мало или нет совсем. В таком случае, одни могут зашиваться, а других будет тяжело подключать, т.к. пользы от них немного. Кроме того, взаимное обогащение экспертизой в последствии полезно для командной работы — всяких brain storm'ов, например, в рамках какой-нибудь большой интересной амбициозной задачки.
>>Возможность действовать только в рамках команды аналитиков.
>Почему аналитик не может дойти до тестировщика, разработчика, бизнеса, почему есть эти ограничения?
Аналитик может и с радостью это делает. Я тут про реорганзиацию процесса работы над задачами — реорганизовывать мы могли только свой участок работы.
>А где тут про скрам собственно? Где факты того, что текущая модель плоха или не оптимальна, где аргументы что надо менять процесс, а не людей, например?
я скрам-мастер :) у меня есть команда и я не меняю людей :)
Подробнее про скрам я напишу в след статье. Но тут хочу добавить, что скрам позволяет команде ощущать самоорганизацию своей деятельности, ответственность за результат команды, имея при этом полезное регулярное командное взаимодействие, позволяет нам учиться друг у друга, быть действительно командой и выдавать результат.
Подробнее про скрам я напишу в след статье. Но тут хочу добавить, что скрам позволяет команде ощущать самоорганизацию своей деятельности, ответственность за результат команды, имея при этом полезное регулярное командное взаимодействие, позволяет нам учиться друг у друга, быть действительно командой и выдавать результат.
Большего заблуждения о Скраме сложно и придумать.
Конкретная польза скрама это увеличение продуктивности команды в 3-8 раз по сравнению с работой по водопаду либо большенству старых методологий или самоклёпок.
Увеличение продуктивности достигается за счет насыщения команды информацией. То есть, улучшается коммуникация которая приводит к:
- Уменьшению потерь на переделки, благодаря частым сессиям по выявлению ожиданий (Планинги, Демо);
- Уменьшение потерь на стыковку и синхронизацию команды за счет регулярного выявления зависимостей и планированию на местах (Дейлики, Планинги);
- Сокращение ошибок, и увеличение производительности труда за счет регулярной рефлексии и анализа проделанной работы (Ретроспектива, Демо)
В принципе, это всё про скрам. И этого достаточно что бы он работал и делал свою работу прекрасно. Главная беда это тренеры которые интерпретируют скрам не так, и применяют его не туда.
>Конкретная польза скрама это увеличение продуктивности команды в 3-8 раз по сравнению с работой по водопаду либо большинству старых методологий или самоклёпок.
Согласна и еще расскажу об этом на нашем примере.
Здесь речь об этом и идет:
>быть действительно командой и выдавать результат.
и выше указала про управление загруженностью и подготовку и приоретизацию бэклога.
Согласна и еще расскажу об этом на нашем примере.
Здесь речь об этом и идет:
>быть действительно командой и выдавать результат.
и выше указала про управление загруженностью и подготовку и приоретизацию бэклога.
Вы и вправду верите, что скрап может увеличить производительность в 3-8 раз? Мне искренне жаль людей, которые работают под таким руководством.
С заказчиком надо взаимодействовать. Заказчик и исполнитель это одна команда, идущая к одной цели, а не так, что заказчик там что-то сказал и вы бросились делать. Ему плевать что у вас там, скрам, срам или трам. Ему надо чтобы его задачи были решены вчера и полностью.
Задача руководителя выбрать те задачи, которые наиболее дёшевы в реализации и приносят максимальный эффект для бизнеса.
Я рассказываю о внутренней командной работе аналитиков и применении в ней фреймворка. О нашем опыте запуска.
Совершенно не о взаимодействии заказчика и исполнителя.
>Вы и вправду верите, что скрап может увеличить производительность в 3-8 раз?
Тут не в вере дело, а планировании. Было бы странно запускать что-либо не просчитав план реализации и последствий.
Совершенно не о взаимодействии заказчика и исполнителя.
>Вы и вправду верите, что скрап может увеличить производительность в 3-8 раз?
Тут не в вере дело, а планировании. Было бы странно запускать что-либо не просчитав план реализации и последствий.
Sign up to leave a comment.
ScrumBut в команде аналитиков: перед взлётом