Если запланированный для реализации элемент бэклога требует анализа, то мы в планируемую итерацию включаем задачу «Анализ ...». А реализуем в следующей итерация, когда трудоёмкость более-менее понятна стала.
Мы, похоже, не понимаем друг друга.
Ситуация предельно проста. Разработчики закончили свои последние в итерации задачи. Это происходит в последние дни итерации. После этого тестер берёт результат и проверяет. Находит критические ошибки. Т.е. появляются критические ошибки в последние дни. Каким образом эти баги могут НЕ всплывать?
Или у вас итерация на программирование, а следующая на тестирование? Тогда, конечно, легко сначала смотреть и править критичные модули, а потом другие.
Методы работы с ошибкой, найденной в начале итерации могут сильно отличаться от тех, что используются в конце. Т.е. бегунок на шкале исправить______похерить к концу итерации начинает смещаться вправо. Не видел, чтобы это как-то учитывалось в методологиях управления проектами.
А это чисто теоретический вопрос или Вы с этим сталкиваетесь?
По моему опыту, программисты, если речь идёт о них, не склонны завышать объёмы работ, с целью выделить время для попинания балды. Я встречался с тем, что они ещё где-то подрабатывают. Но это, если ты в плотном контакте с группой, довольно быстро становится понятно. А дальше оргвыводы, которые зависят от традиций Вашей организации ;)
А у вас тестер(ы) в последние дни вдруг прерстаёт находить критические ошибки? Или программисты, сделав за полинтерации все свои задачи, сидят и ждут, а не найдёт ли тестер у них ошибку? Или во время демонстрации по окончанию итерации ничего серьёзного никогда не всплывает?
У нас всё вышеперечисленное гарантировано даёт несколько ошибок, с которыми, как бы это помягче сказать, версию выпускать не хочется.
Ну это всё теория. А на практике тестер в последние пару дней может найти пяток ошибок (и находит, зараза), с которыми нельзя выпускать релиз. Как вы решаете эту проблему?
Тестер тестирует, а значит и находит ошибки, до самого конца итерации. Т.е. получается, что какие-то ошибки на конец итерации не поправлены. Просто физически на это не остаётся времени. Получается, что какие-то задачи, запланированные на итерацию, всегда остаются не выполнены. И релиза не получается.
Понятно, что варианты решения этой проблемы могут быть разные. А как у вас?
Я работаю приблизительно в такой же компании, как Ваша. Правда основные доходы мы имеем с заказов. Вы, как я понимаю, наоборот, зарабатываете прежде всего с продаж своих продуктов.
Мне любопытно, Ваше руководство действительно учитывает результаты анализа портфеля, как Вы описали. Или только должно делать так в теории? И на вашей фирме есть люди, которые реально оценивают (а не высасывают из пальца за 5 минут) предполагаемый доход от изменения старого или выпуска нового продукта (про заказы понятно, тут оценить легко :))?
Давно хотел спросить специалистов, имеющих дело с портфелями проектов. А как чаcто эта вся наука используется в IT-индустрии? Мне кажется, что обычно такие фирмы не имеют переизбытка предложений. И редко отказываются от нового проекта из-за того, что он как-то не сопрягается с другими предложениями (если они вообще есть). Речь идёт, естественно, не о монстрах типа Микрософт, IBM, Oracle и т.п., а об обычных фирмах, которых в нашей отрасли подавляющее большинство.
Вот что странно, в том время, как Яндекс (а скорее, как было написано выше, какой-то Вася Пупкин из Яндекса) выёживается, Гугл спокойно рекламирует как свободное, так и коммерческое ПО. Видимо Яндекс не справляется с потоком заказов на рекламу и готов поделиться с конкурентом :)
Вон Алистер Коберн цельную книжку про use case-ы написал. И никакого УМЛ там нет.
Ситуация предельно проста. Разработчики закончили свои последние в итерации задачи. Это происходит в последние дни итерации. После этого тестер берёт результат и проверяет. Находит критические ошибки. Т.е. появляются критические ошибки в последние дни. Каким образом эти баги могут НЕ всплывать?
Или у вас итерация на программирование, а следующая на тестирование? Тогда, конечно, легко сначала смотреть и править критичные модули, а потом другие.
Про story points на стр. 19. И дальше читаем, как использовать. Книга небольшая, найти будет легко.
Методы работы с ошибкой, найденной в начале итерации могут сильно отличаться от тех, что используются в конце. Т.е. бегунок на шкале исправить______похерить к концу итерации начинает смещаться вправо. Не видел, чтобы это как-то учитывалось в методологиях управления проектами.
А то, что можно выкрутится с помощью, например, «субботника» по чистке ошибок — это я знаю. Продукт-то мы всё ж таки выпускаем как-то :)
По моему опыту, программисты, если речь идёт о них, не склонны завышать объёмы работ, с целью выделить время для попинания балды. Я встречался с тем, что они ещё где-то подрабатывают. Но это, если ты в плотном контакте с группой, довольно быстро становится понятно. А дальше оргвыводы, которые зависят от традиций Вашей организации ;)
У нас всё вышеперечисленное гарантировано даёт несколько ошибок, с которыми, как бы это помягче сказать, версию выпускать не хочется.
Тестер тестирует, а значит и находит ошибки, до самого конца итерации. Т.е. получается, что какие-то ошибки на конец итерации не поправлены. Просто физически на это не остаётся времени. Получается, что какие-то задачи, запланированные на итерацию, всегда остаются не выполнены. И релиза не получается.
Понятно, что варианты решения этой проблемы могут быть разные. А как у вас?
Впрочем, желаю, чтобы ваш сервис дорос до такой популярности.
Агитации за советскую власть, т.е., что CMMI полезна, и так много. Жизненных примеров мало.
Мне любопытно, Ваше руководство действительно учитывает результаты анализа портфеля, как Вы описали. Или только должно делать так в теории? И на вашей фирме есть люди, которые реально оценивают (а не высасывают из пальца за 5 минут) предполагаемый доход от изменения старого или выпуска нового продукта (про заказы понятно, тут оценить легко :))?
P.S. Это не сарказм, мне действительно интересно.