Встреча Вальчук&Балакерский
- Роман Пантелеев
- Не в сети
- Живу я здесь
- Сообщений: 2397
- Спасибо получено: 238
Про Product Backlog я написал. Не знал что он преобразуется в количество спринтов. Все упоминания Agile были как раз как противопоставления водопаду с его сложностью в планировании. Если мы планируем все сроки - в чем же выигрышь? Все равно надо учитывать зависимости, загрузку ресурсов - считай к тому же водопаду и критической цепи вернулись. Или количество спринтов пальцем в небо считается?
По поводу советов: мне Дима Егоров рассказывал как исполнял спринты с помощью ССРМ. Все здорово - у меня одно непонимание: как надежно срок и бюджет в SCRUM для проектов рассчитать. Увижу такую же надежность как в ТОС - всеми руками за буду.
Виктор, пожалуйста поподробнее как можно справиться с задачей без содержания за планируемый срок и бюджет? Прочитал что Вы утверждаете что SCRUM решает такие задачи, а СС - нет. Может Вы подменяете «потратить на задачу определенное время и определенные деньги и насколько то ее по-решать»?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
А можно уточнить, как конкретно?Роман Пантелеев пишет: мне Дима Егоров рассказывал как исполнял спринты с помощью ССРМ. Все здорово
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
В SCRUM Product Backlog понимается как список требований к продукту, а вот Sprint Backlog - это именно те задачи, которые нужно выполнить. Что является продуктом в проектах улучшений, которые выполняются бизнес - консультантом - за что конкретно ему платят деньги?Игорь Балакерский пишет: В SCRUM есть два набора задач:
1. Product Backlog - список задач на весь проект. На его основе рассчитывается по специальной методике оценки производительности команды количество необходимых спринтов, и это количество требуемых спринтов буферизируется
2. Sprint Backlog - список задач на ближайший спринт
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Роман Пантелеев пишет:
Виктор, пожалуйста поподробнее как можно справиться с задачей без содержания за планируемый срок и бюджет? Прочитал что Вы утверждаете что SCRUM решает такие задачи, а СС - нет. Может Вы подменяете «потратить на задачу определенное время и определенные деньги и насколько то ее по-решать»?
Роман, во - первых, я такого не говорил. Я сказал, что SCRUM делает проекты, у которых изначально не было окончательно определено содержание. При этом проекты укладываются в ограниченный срок и бюджет (они не становятся бесконечными). Но это не означает, что когда проект уже выполнен, у него нет законченного содержания. Оно есть.
Такие задачи есть. От них никуда не уйти. Значит, должны существовать и методы управления выполнеия таких задач (проектов).
Но это не означает, что в scrum нет управления сроками, бюджетом и содержанием. Первоначально содержание определяется набором пользовательских историй. По мере работы они корректируются - просто изменяется понимание конечного продукта как у команды, так и у заказчика. И это нормально. От этого не уйти.
Через два - три спринта становится понятна скорость работы команды - скорость, с которой она выполняет пользовательские истории (вернее задачи, которые формулируются из них на спринт). Эта скорость сравнивается с оценкой оставшихся пользовательских историй и получают оценку сроков. Соответственно, и оценку бюджета. То есть через 2-3 недели после начала проекта вы имеете оценку всех параметров.
Понятно, что если изменится содерание (пользовательские истории), изменится и оценка сроков и бюджетов. Но то же самое происходит и в обычном управлении проектами. Иначе там бы не было раздела "Управление изменениями". Просто в scrum эти изменения приветствуются, а в PMBOK скорее наоборот.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Игорь Балакерский
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 816
- Спасибо получено: 177
Роман Пантелеев пишет: Игорь, с чего Вы взяли что ССРМ разбазаривает время ...
... покажите мне, пожалуйста, где выше в моём тексте написано: "ССРМ разбазаривает время". Вот, покажите, где именно это я написАл
Александр Запорожцев пишет: ... В SCRUM Product Backlog понимается как список требований к продукту,...
... вы наверное перепутали с Project backlog? Project backlog — это "список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации". Мы придерживаемся понимания, что Product Backlog - "содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности)."
ЗЫ... а, вообще, детский сад какой-то! Один участник за меня что-то придумывает и начинает объяснять какую-то хрень себе придуманную. Второй начинает в категоричной форме "профессионально" поправлять и давать определения неизвестно откуда взятые, тут же пытаясь выяснить коммерческое содержание консалтинговых проектов. Точно - отвык я от этого форумного общения, совсем отвык. Думаю и наново привыкать не стоит
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
Мой интерес к организации консалтинговых проектов объясняется очень просто - хочется разобраться в специфики таких проектов и определения возможных направлений повышения их успешности. Тема возникла на последней встрече линзоны.Игорь Балакерский пишет: тут же пытаясь выяснить коммерческое содержание консалтинговых проектов.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Роман Пантелеев
- Не в сети
- Живу я здесь
- Сообщений: 2397
- Спасибо получено: 238
Ваши слова:Игорь Балакерский пишет:
Роман Пантелеев пишет: Игорь, с чего Вы взяли что ССРМ разбазаривает время ...
... покажите мне, пожалуйста, где выше в моём тексте написано: "ССРМ разбазаривает время". Вот, покажите, где именно это я написАл
«При этом, в отличие от ТОС, где борьба со "студенческим синдромом" , в том числе, идёт поздним стартом задач, здесь всё наоборот - применяется ранний старт и предельно плотный набор задач в спринте.»
Подумал. Вы отчасти правы - для питающих ветвей ССРМ скорее будет использовать поздний запуск (т.е. разбазаривать время). Но не из-за студенческого синдрома, а для экономии ресурсов. Зачем вкладывать деньги и место в окраску стропил защитой, если мы на этапе фундамента. В большинстве случаев это бессмысленно. Но ССРМ не запрещает ранний запуск. Если среда позволяет - у построителей критической цепи есть настройка «ранний запуск».
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Роман Пантелеев
- Не в сети
- Живу я здесь
- Сообщений: 2397
- Спасибо получено: 238
Ну представьте Заказчик организует конференцию. Для него это проект. Исполнитель печатает для Заказчика материалы для конференции некоторыми партиями - по мере заключения договоров с участниками. Что мы производство материалов проектом и проектной средой будем что ли называть?! Нет - обычное производство. А тут назвали умными словами SCRUM и уже проектом это стало?! Да с какой такой радости?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Роман Пантелеев пишет: Виктор, в итоге SCRUM предлагает начать с несколькими командами, а через 2-3 недели выбирать? Понятно что в этом случае оценка будет заниженная. Мне сложно называть проектом фактически производство по выполнению задач. Проект появляется у заказчика, который планирует его, и лишь исполняет потом с помощью «производственной», а не «проектной» организации. Аналог проекта - это спринт. Поэтому спринтом можно с помощью CCPM управлять.
Ну представьте Заказчик организует конференцию. Для него это проект. Исполнитель печатает для Заказчика материалы для конференции некоторыми партиями - по мере заключения договоров с участниками. Что мы производство материалов проектом и проектной средой будем что ли называть?! Нет - обычное производство. А тут назвали умными словами SCRUM и уже проектом это стало?! Да с какой такой радости?
Нет, Роман. Скрам начинается с того, что "Сотрудничество с заказчиком важнее согласования условий контракта". Сотрудничество - это когда ты делаешь все возможное, чтобы заказчику было лучше. Понимаешь, это просто другое измерение контрактных отношений. Без понимания его нечего и обсуждать скрам. И исполнитель, и заказчик хотят выполнить проект как можно лучше. Желательно и быстрее. Желательно и дешевле. При этом приоритеты постоянно обсуждаются.
Конференция - неподходящий пример. Возьми лучше стартап. Какой нибудь интернет сервис. Заказчик - ты сам. Если ты точно знаешь, какой он будет, твой сервис в конце концов - ты скорее всего будешь банкротом. Тебе лучше всего создавать его шаг за шагом, постоянно проверяя очередные фичи на потенциальных клиентах. И постоянно реагировать на обратную связь, то есть делать уже не то, что представлял изначально.
Ты кончно мог изначально составить критическую цепь и упорствовать с тем, что точто знаешь, какой будет бизнес в конце. Тогда это был бы проект, верно? Но скорее всего неудачный, поскольку не попал бы в ожидания клиентов. А мог бы тоже самое сделать с помощью скрам. Может быть бы потратил больше денег, может быть запустил бы чуть позже (но не факт). Зато вероятность успеха намного выше. С какой стати я теперь должен назвать такой подход производством? Налицо все характеристики проекта: я сделал уникальный продукт, за ограниченное время, за ограниченные деньги.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.