Изучайте одну новую вещь каждый день
LeSS – это легкая Agile-система для масштабирования Scrum на более чем одну команду. В 2005 году Бас Водде и Крейг Ларман разработали структуру LeSS после использования принципов и правил Scrum в крупномасштабных проектах. Их целью было успешно развивать крупномасштабные проекты, оставаясь при этом в рамках ограничений Scrum.
Продолжить чтение
Большинство учебных курсов по Agile и Scrum ссылаются на правило 7 +/- 2, то есть команды Agile или Scrum должны состоять из 5-9 человек. Энтузиасты Scrum могут вспомнить, что в руководстве по Scrum говорится, что Scrum-команды не должны быть меньше 3 или больше 9. Откуда взялось это правило большого пальца и почему?
Продолжить чтение
Компания LeSS была создана Басом Водде и Крейгом Ларманом на основе практического опыта масштабирования Scrum и основана как LeSS Company в 2014 году. Принцип “Больше с LeSS” лежит в основе LeSS (Large Scale Scrum). Разработка сложных продуктов не требует сложных решений. Она требует глубокого понимания сути проблем, которые затем могут быть решены с помощью более простых решений.
Продолжить чтение
Мы постоянно сталкиваемся с этими терминами при разработке программного обеспечения. Иногда люди называют часть программного продукта – требование/случай использования, элементы бэклога ….. Что принято использовать в программном обеспечении: “это” или “что”?
Продолжить чтение
В разработке программного обеспечения обычная “оценка” включает количественную оценку работы, необходимой для выполнения данной задачи разработки; она обычно выражается в терминах продолжительности (час / день) или расчетной единицы (сюжетная точка). Цель состоит в том, чтобы объединить ряд таких индивидуальных оценок, чтобы получить представление об общей продолжительности, работе или стоимости проекта программного обеспечения.
Продолжить чтение
Летом 2011 года Кен Швабер и Джефф Сазерленд пересмотрели свое руководство по Scrum. В нем они убрали одно давно установленное поведение, известное в Scrum, – обязательство, которое команда берет на себя перед владельцем продукта и клиентами. Обязательство было заменено прогнозом. Они говорят, что команды могут прогнозировать свою работу, но не брать на себя обязательства.
Продолжить чтение
Definition of Done (DoD) – это список требований, которым должна соответствовать история пользователя, чтобы команда могла назвать ее завершенной. В то время как критерии приемки пользовательской истории состоят из набора тестовых сценариев, которые должны быть выполнены для подтверждения того, что программное обеспечение работает так, как ожидалось.
Продолжить чтение
Каждый спринт заканчивается собранием по обзору спринта, состоящим из двух частей. Такая встреча начинается с обзора и демонстрации заказчику и заканчивается ретроспективой команды. Оба этих компонента проводятся в последний день спринта. Обзор спринта фокусируется на “проверке” и “адаптации” инкрементов (потенциально отгружаемых), в то время как ретроспектива спринта уделяет больше внимания “проверке” и “адаптации” процесса спринта.
Продолжить чтение
INVEST как напоминание о характеристиках качественного элемента бэклога продукта (PBI) (или истории пользователя), обычно написанной в формате истории пользователя. Но что такое характеристики хорошей пользовательской истории? Акроним “INVEST” может напомнить вам о том, что хорошие истории должны быть
Продолжить чтение
Что оказалось сильной стороной Scrum за последние 20 лет? Что должно быть в центре внимания Scrum в ближайшие 20 лет? Что из Scrum разочаровало вас больше всего на данный момент? Что связывает вас со Scrum? Какое небольшое улучшение можно было бы добавить в Scrum?
Продолжить чтение