Для работы проектов iXBT.com нужны файлы cookie и сервисы аналитики.
Продолжая посещать сайты проектов вы соглашаетесь с нашей
Политикой в отношении файлов cookie
Apocalypse
Комментатор
Apocalypse
Рейтинг
+63.20
Автор не входит в состав редакции iXBT.com (подробнее »)
- ← предыдущая
- 1
- 2
- последняя
- следующая →
В рамках планирования спринта предлагается ответить на вопрос «что может быть сделано в рамках спринта» (причём «может быть» — это не обязательство). Используйте любой удобный вам подход, с попугаями, без попугаев или ещё как — дело ваше, скраму без разницы.
Да просто обратил внимание, что в заголовке указано Scrum Framework, но по факту в заметке про что угодно, кроме скрама.
Это зависит от вашего определения слова «продукт».
Теперь что касается того, что заказчик получает не то, что ожидал. Вообще требования должны быть в бэклоге продукта (кроме некоторых отдельных моментов) и как раз заказчик, в лице PO, управляет бэклогом продукта, в т.ч. участвует и в груминге. Если требования представлены в формате пользовательских историй, то кроме краткого описания, там часто пишут критерии приёмки, а к ним приёмочные тесты, которые проясняют, как что должно работать. Но это всё, опять же, не про скрам. От скрама здесь требуется только предоставить событие — ретроспективу — где могут обсуждаться подобные проблемы. Он и предоставляет.
Скрам основан на эмпирицизме — сделал, измерил, улучшил. АЭС по такому подходу действительно не строят, но большинство людей их и так не строят. Кроме того, многие заказчики хотят как можно раньше выйти на рынок. Кроме того, не все заказчики могут заранее сформулировать то, чего они хотят (или чего хочет рынок) и создать полный и точный перечень требований. Кроме того, рынок может поменяться, пока идёт разработка и приходится реагировать.
ВОВЛЕЧЕННОСТЬ ЗАКАЗЧИКА
Иногда PO может быть не от бизнеса. Будет вовлекать заказчика в виде стейкхолдера по мере необходимости. Но нужно понимать недостатки.
ОЦЕНКА ЗАДАЧ
В скрам гайде нет ни слова про оценку задач. Он про другое.
Декомпозиция это только один из методов оценки. Оценка нужна и разработчикам, и бизнесу. Оценку делают и в классических подходах (см. иерархическую структуру работ в PMBoK). Отличие в том, что в Agile учитывают конус неопределенности и оценка уточняется по мере необходимости, не перезакладываясь на лишние риски.
ОЦЕНКА СРОКОВ
В скрам гайде нет ни слова про оценку сроков. Он про другое.
Agile команды не делают вид, будто бы они знают, если на самом деле они не знают. Стараются не тыкать пальцем в небо. Они просто обеспечивают прозрачность.
КРОССФУНКЦИОНАЛЬНОСТЬ КОМАНДЫ
Там написано «The members have all skills», а не «Each member has all skills».
КАЧЕСТВО РЕЗУЛЬТАТА
1. Процитируйте точную фразу, с чем вы спорите. Продукт один и тот же, даже если инкрементов несколько.
2. Можно написать, чтобы росло, но только вы потянете такое? Ну и суть в том, что если регулярно ослаблять DoD, то ни разрабы, ни заказчик не будут понимать что же они делают и на что можно рассчитывать. Ценность такого продукта будет не очень высокой.
АРХИТЕКТУРА ПРОДУКТА
В скрам гайде про это нет. Он про другое.
Если не производится предварительный детальный дизайн всей системы, то это не значит, что архитектуры нет. Просто такая работа часто считается потерями. А вообще команда всегда видит весь бэклог продукта и может проектировать систему так, как считает необходимым.
КАЧЕСТВО КОДА
Про качество кода в скрам гайде нет ничего. Он про другое.
В agile командах качеству кода уделяется огромное внимание, потому что иначе вы не сможете адекватно реагировать на изменения. Например множество практик описано в XP.
ЛЮБИТЕ МИТИНГИ?
В скрам гайде в рамках спринта есть 4 события — планирование, дейли, обзор и ретро. Для каждого события есть таймбокс, место/время и свое четкое предназначение. Это позволяет наладить обратную связь, определить, когда решаются те или иные вопросы и сократить лишние совещания в произвольные моменты времени.
РЕШЕНИЕ
К сожалению, все подряд сейчас пытаются пролезть в айти в погоне за легкими деньгами. При этом умеют только болтать языком, поэтому идут скрам-мастерами и всякими коучами, не понимая, что они делают. После этого у многих айтишников появляется крайне плохой опыт и рождаются такие вот статьи. Решение — учиться. Ну или избегать нынешнюю реальность, но вряд ли это хорошее решение.
Что касается библиотек, то насколько я знаю, они «в пьянстве замечены не были», в отличие от компилятора, который, как известно, ориентировался на строку вендора, игнорируя флаги поддержки наборов инструкций. Делает ли наличие библиотек от интел проект автоматически заточенным под интел? Скандалов на этот счёт вроде пока не было, исходники того же TBB есть на github под Apache 2.0 — бери, изучай, модифицируй.