Среди сотен различных Agile-практик разработки программного обеспечения есть несколько совершенно бесполезных, но, как ни странно, они все еще очень популярны среди многих организаций и Scrum-команд.

Вот мой список 5-ти лучших Agile-практик, на которые уходит много времени и которые бесполезны:

1. Оценка пользовательских историй в Story Points по конечным результатам.

Единственная причина оценки в Story Points - проверить, есть ли у команды одинаковое понимание того, что и как нужно сделать для завершения User Story. Оценка любой работы методом от обратного контрпродуктивна и не приносит никакой пользы: Какой смысл проверять, одинаково ли мы понимаем то, что уже сделано? Кроме того, это подрывает правильное использование Story Points на сессиях планирования.

https://habr.com/ru/post/692134/?utm_source=habrahabr&utm_medium=rss&utm_campaign=692134

Людям свойственно со временем забывать откуда все пошло, поэтому нужно вспоминать. Публикация навеяна статьей "Почему Scrum не надо применять там, где не надо — ограничения и допущения фреймворка".

Конечно, это моя интерпретация, но она основана на огромном количестве времени обучения, самообучения и опыта в индустрии.

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

Честный и понятный Agile-манифест:

https://habr.com/ru/post/691800/?utm_source=habrahabr&utm_medium=rss&utm_campaign=691800

Планирование спринта является ключевым элементом работы в Scrum. Тем не менее, это все еще проблематичное и часто поверхностное событие для многих групп. Основываясь на своем опыте, я подготовил пять советов, которые помогут вам лучше спланировать свой следующий спринт.

https://habr.com/ru/post/691764/?utm_source=habrahabr&utm_medium=rss&utm_campaign=691764

Статья посвящена трудным/трудовым обстоятельствам работы аналитиков на проектах, которые выполняются по некому варианту «Scrum + Аналитик», эти обстоятельства являются причиной стресса. Если вы думаете, что я дам вам какие-то решения, то увы, нет. Трудности эти в обозримом будущем никуда не денутся, можете считать, что вы ходите по кругу Сансары аналитика. Знайте, что вы не одни по нему ходите, может вам психологически станет легче.

https://habr.com/ru/post/689518/?utm_source=habrahabr&utm_medium=rss&utm_campaign=689518

Стоит ли команде тратить время на постановку цели спринта при работе по Scrum, и какой в этом вообще смысл?

https://habr.com/ru/post/688830/?utm_source=habrahabr&utm_medium=rss&utm_campaign=688830

Привет, Хабр! Меня зовут Дмитрий, работаю Руководителем проектов 1С в IT-компании Lad и сегодня хочу рассказать о том, как наша команда переводила небольшой завод с Infor M3 ERP на “1C:ERP Управление предприятием 2”. Ну переводили и переводили, скажете вы, все переводят. Мы это сделали за два месяца. How was it? Делюсь опытом в статье.

https://habr.com/ru/post/688782/?utm_source=habrahabr&utm_medium=rss&utm_campaign=688782

Делимся лайфхаком, который упростил жизнь продакт-менеджерам и сделал продукт удобнее для пользователей.

https://habr.com/ru/post/686920/?utm_source=habrahabr&utm_medium=rss&utm_campaign=686920

Именно этой строкой начинается Agile манифест. И вроде бы это очевидно: сотрудники - главный ресурс любой компании. Однако на практике очень часто приоритеты сдвигаются в другую сторону и на первое место выходят: метрики, релизы, цели, задачи, события.

А как же люди? Ведь именно их отношение к работе, их мотивация и определяет итоговый результат.

Связь мотивации и эффективности очевидна: мотивированный сотрудник способен более длительное время удерживать фокус внимания на объекте своей деятельности. Он проявляет больше упорства в преодолении различных трудностей, более охотно принимает ответственность за результаты своей деятельности.

Поэтому один из пунктов Agile манифеста и гласить: над продуктом должна работать команда замотивированных профессионалов.

Окей, уровень профессиональных компетенций можно определить путем различных видов тестирования. И развивать их за счет внутреннего и внешнего обучения. А как быть с мотивацией? Много ли компаний оценивают на входе мотивационных профиль своих сотрудников?

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

Как правило, при устройстве на работу, мотивация сотрудника сильно детерминирована материальными факторами: уровнем зарплаты, социальным обеспечением, стабильностью, перспективами роста и т.д.

И тут вроде все понятно: есть ДМС, инструменты премирования по ключевым показателям эффективности, карьерный гайд, печеньки к кофе. Чего еще надо? Однако все это относится к инструментам мотивирования (стимулирования), а не к мотивации.

https://habr.com/ru/post/686510/?utm_source=habrahabr&utm_medium=rss&utm_campaign=686510

Современные парадигмы разработки ПО всегда являются итерационными. В методологии Scrum такими итерациями являются спринты, в классической версии Scrum каждый спринт начинается с планирования и завершается демо, ретроспективой и «инженерным» днем. Оценка успешности каждого спринта – это довольно субъективная вещь, формализация которой важна и может быть реализована с помощью следующих стандартных действий:

• Определить достижение целей спринта;

• Оценить краткосрочное влияние разработки ПО на удовлетворённость заказчиков и пользователей в развитии продуктов;

• Провести формализацию и учет параметров спринтов.

Определять для каждого спринта собственные цели несложно: необходимо сопрягать довольно точно измеряемые и формулируемые сущности: бизнес-цели разрабатываемых продуктов, приоритет функциональных и нефункциональных требований в беклогах различного уровня, логическую очередность этапов развития софтверных проектов.

https://habr.com/ru/post/684992/?utm_source=habrahabr&utm_medium=rss&utm_campaign=684992

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

https://habr.com/ru/post/682874/?utm_source=habrahabr&utm_medium=rss&utm_campaign=682874

Как быстро подготовиться к вопросам по Скрам на собеседовании? Предлагаю свою шпаргалку, которой пользовалась на протяжении многих лет, и готовила по ней многих аналитиков.

https://habr.com/ru/post/681516/?utm_source=habrahabr&utm_medium=rss&utm_campaign=681516

Большинство компаний из ИТ, банковской, страховой и телекоммуникационной сфер в России и в мире уже активно применяют либо находятся в стадии внедрения различных гибких, или, другими словами, Agile-подходов в управлении командами и продуктами. Однако на пути пилотирования и становления таких способов менеджмент и сами сотрудники часто встречают множество проблем, которые мешают внедрению Agile и снижают удовлетворённость команды рабочими процессами.

В этой статье я, Сергей Селезнёв, менеджер проектов GlowByte, попробую консолидировать свой опыт и экспертизу GlowByte и разобраться, почему так может происходить в подразделениях и командах, которые занимаются развитием CRM-систем, какие есть особенности у этих команд и как можно попробовать решить эту проблему. Описанные случаи и подходы могут быть узнаваемы и применимы и к другим направлениям.

https://habr.com/ru/post/680600/?utm_source=habrahabr&utm_medium=rss&utm_campaign=680600