Встреча Вальчук&Балакерский


5 года 7 мес. назад - 5 года 7 мес. назад #49296 от Роман Пантелеев
Игорь, с чего Вы взяли что ССРМ разбазаривает время и практикует поздний запуск задач? Ничего такого нет - Вы что то недопоняли в решении.

Про Product Backlog я написал. Не знал что он преобразуется в количество спринтов. Все упоминания Agile были как раз как противопоставления водопаду с его сложностью в планировании. Если мы планируем все сроки - в чем же выигрышь? Все равно надо учитывать зависимости, загрузку ресурсов - считай к тому же водопаду и критической цепи вернулись. Или количество спринтов пальцем в небо считается?

По поводу советов: мне Дима Егоров рассказывал как исполнял спринты с помощью ССРМ. Все здорово - у меня одно непонимание: как надежно срок и бюджет в SCRUM для проектов рассчитать. Увижу такую же надежность как в ТОС - всеми руками за буду.

Виктор, пожалуйста поподробнее как можно справиться с задачей без содержания за планируемый срок и бюджет? Прочитал что Вы утверждаете что SCRUM решает такие задачи, а СС - нет. Может Вы подменяете «потратить на задачу определенное время и определенные деньги и насколько то ее по-решать»?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


5 года 7 мес. назад #49301 от Александр Запорожцев

Роман Пантелеев пишет: мне Дима Егоров рассказывал как исполнял спринты с помощью ССРМ. Все здорово

А можно уточнить, как конкретно?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


5 года 7 мес. назад #49302 от Александр Запорожцев

Игорь Балакерский пишет: В SCRUM есть два набора задач:
1. Product Backlog - список задач на весь проект. На его основе рассчитывается по специальной методике оценки производительности команды количество необходимых спринтов, и это количество требуемых спринтов буферизируется
2. Sprint Backlog - список задач на ближайший спринт

В SCRUM Product Backlog понимается как список требований к продукту, а вот Sprint Backlog - это именно те задачи, которые нужно выполнить. Что является продуктом в проектах улучшений, которые выполняются бизнес - консультантом - за что конкретно ему платят деньги?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


5 года 7 мес. назад - 5 года 7 мес. назад #49303 от Вальчук Виктор Васильевич

Роман Пантелеев пишет:
Виктор, пожалуйста поподробнее как можно справиться с задачей без содержания за планируемый срок и бюджет? Прочитал что Вы утверждаете что SCRUM решает такие задачи, а СС - нет. Может Вы подменяете «потратить на задачу определенное время и определенные деньги и насколько то ее по-решать»?


Роман, во - первых, я такого не говорил. Я сказал, что SCRUM делает проекты, у которых изначально не было окончательно определено содержание. При этом проекты укладываются в ограниченный срок и бюджет (они не становятся бесконечными). Но это не означает, что когда проект уже выполнен, у него нет законченного содержания. Оно есть.

Такие задачи есть. От них никуда не уйти. Значит, должны существовать и методы управления выполнеия таких задач (проектов).

Но это не означает, что в scrum нет управления сроками, бюджетом и содержанием. Первоначально содержание определяется набором пользовательских историй. По мере работы они корректируются - просто изменяется понимание конечного продукта как у команды, так и у заказчика. И это нормально. От этого не уйти.
Через два - три спринта становится понятна скорость работы команды - скорость, с которой она выполняет пользовательские истории (вернее задачи, которые формулируются из них на спринт). Эта скорость сравнивается с оценкой оставшихся пользовательских историй и получают оценку сроков. Соответственно, и оценку бюджета. То есть через 2-3 недели после начала проекта вы имеете оценку всех параметров.

Понятно, что если изменится содерание (пользовательские истории), изменится и оценка сроков и бюджетов. Но то же самое происходит и в обычном управлении проектами. Иначе там бы не было раздела "Управление изменениями". Просто в scrum эти изменения приветствуются, а в PMBOK скорее наоборот.
Спасибо сказали: Игорь Балакерский

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


5 года 7 мес. назад - 5 года 7 мес. назад #49304 от Игорь Балакерский

Роман Пантелеев пишет: Игорь, с чего Вы взяли что ССРМ разбазаривает время ...


... покажите мне, пожалуйста, где выше в моём тексте написано: "ССРМ разбазаривает время". Вот, покажите, где именно это я написАл

Александр Запорожцев пишет: ... В SCRUM Product Backlog понимается как список требований к продукту,...


... вы наверное перепутали с Project backlog? Project backlog — это "список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации". Мы придерживаемся понимания, что Product Backlog - "содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности)."

ЗЫ... а, вообще, детский сад какой-то! Один участник за меня что-то придумывает и начинает объяснять какую-то хрень себе придуманную. Второй начинает в категоричной форме "профессионально" поправлять и давать определения неизвестно откуда взятые, тут же пытаясь выяснить коммерческое содержание консалтинговых проектов. Точно - отвык я от этого форумного общения, совсем отвык. Думаю и наново привыкать не стоит

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


5 года 7 мес. назад - 5 года 7 мес. назад #49314 от Александр Запорожцев

Игорь Балакерский пишет: ... вы наверное перепутали с Project backlog?

В разных источниках Scrum может быть описан по разному. Я основывался на описании, которое дано в стандарте OMG Essence.

Здесь даны следующие элементы:
Product Backlog

Sprint Backlog

User Story

Жизненный цикл Scrum
Вложения:

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


5 года 7 мес. назад #49315 от Александр Запорожцев

Игорь Балакерский пишет: тут же пытаясь выяснить коммерческое содержание консалтинговых проектов.

Мой интерес к организации консалтинговых проектов объясняется очень просто - хочется разобраться в специфики таких проектов и определения возможных направлений повышения их успешности. Тема возникла на последней встрече линзоны.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


5 года 7 мес. назад - 5 года 7 мес. назад #49316 от Роман Пантелеев

Игорь Балакерский пишет:

Роман Пантелеев пишет: Игорь, с чего Вы взяли что ССРМ разбазаривает время ...


... покажите мне, пожалуйста, где выше в моём тексте написано: "ССРМ разбазаривает время". Вот, покажите, где именно это я написАл

Ваши слова:
«При этом, в отличие от ТОС, где борьба со "студенческим синдромом" , в том числе, идёт поздним стартом задач, здесь всё наоборот - применяется ранний старт и предельно плотный набор задач в спринте.»

Подумал. Вы отчасти правы - для питающих ветвей ССРМ скорее будет использовать поздний запуск (т.е. разбазаривать время). Но не из-за студенческого синдрома, а для экономии ресурсов. Зачем вкладывать деньги и место в окраску стропил защитой, если мы на этапе фундамента. В большинстве случаев это бессмысленно. Но ССРМ не запрещает ранний запуск. Если среда позволяет - у построителей критической цепи есть настройка «ранний запуск».

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


5 года 7 мес. назад #49317 от Роман Пантелеев
Виктор, в итоге SCRUM предлагает начать с несколькими командами, а через 2-3 недели выбирать? Понятно что в этом случае оценка будет заниженная. Мне сложно называть проектом фактически производство по выполнению задач. Проект появляется у заказчика, который планирует его, и лишь исполняет потом с помощью «производственной», а не «проектной» организации. Аналог проекта - это спринт. Поэтому спринтом можно с помощью CCPM управлять.

Ну представьте Заказчик организует конференцию. Для него это проект. Исполнитель печатает для Заказчика материалы для конференции некоторыми партиями - по мере заключения договоров с участниками. Что мы производство материалов проектом и проектной средой будем что ли называть?! Нет - обычное производство. А тут назвали умными словами SCRUM и уже проектом это стало?! Да с какой такой радости?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


5 года 7 мес. назад - 5 года 7 мес. назад #49318 от Вальчук Виктор Васильевич

Роман Пантелеев пишет: Виктор, в итоге SCRUM предлагает начать с несколькими командами, а через 2-3 недели выбирать? Понятно что в этом случае оценка будет заниженная. Мне сложно называть проектом фактически производство по выполнению задач. Проект появляется у заказчика, который планирует его, и лишь исполняет потом с помощью «производственной», а не «проектной» организации. Аналог проекта - это спринт. Поэтому спринтом можно с помощью CCPM управлять.

Ну представьте Заказчик организует конференцию. Для него это проект. Исполнитель печатает для Заказчика материалы для конференции некоторыми партиями - по мере заключения договоров с участниками. Что мы производство материалов проектом и проектной средой будем что ли называть?! Нет - обычное производство. А тут назвали умными словами SCRUM и уже проектом это стало?! Да с какой такой радости?


Нет, Роман. Скрам начинается с того, что "Сотрудничество с заказчиком важнее согласования условий контракта". Сотрудничество - это когда ты делаешь все возможное, чтобы заказчику было лучше. Понимаешь, это просто другое измерение контрактных отношений. Без понимания его нечего и обсуждать скрам. И исполнитель, и заказчик хотят выполнить проект как можно лучше. Желательно и быстрее. Желательно и дешевле. При этом приоритеты постоянно обсуждаются.

Конференция - неподходящий пример. Возьми лучше стартап. Какой нибудь интернет сервис. Заказчик - ты сам. Если ты точно знаешь, какой он будет, твой сервис в конце концов - ты скорее всего будешь банкротом. Тебе лучше всего создавать его шаг за шагом, постоянно проверяя очередные фичи на потенциальных клиентах. И постоянно реагировать на обратную связь, то есть делать уже не то, что представлял изначально.

Ты кончно мог изначально составить критическую цепь и упорствовать с тем, что точто знаешь, какой будет бизнес в конце. Тогда это был бы проект, верно? Но скорее всего неудачный, поскольку не попал бы в ожидания клиентов. А мог бы тоже самое сделать с помощью скрам. Может быть бы потратил больше денег, может быть запустил бы чуть позже (но не факт). Зато вероятность успеха намного выше. С какой стати я теперь должен назвать такой подход производством? Налицо все характеристики проекта: я сделал уникальный продукт, за ограниченное время, за ограниченные деньги.
Спасибо сказали: Дмитрий Стукалов

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Работает на Kunena форум