Статья посвящена трудным/трудовым обстоятельствам работы аналитиков на проектах, которые выполняются по некому варианту «Scrum + Аналитик», эти обстоятельства являются причиной стресса. Если вы думаете, что я дам вам какие-то решения, то увы, нет. Трудности эти в обозримом будущем никуда не денутся, можете считать, что вы ходите по кругу Сансары аналитика. Знайте, что вы не одни по нему ходите, может вам психологически станет легче.
Agile *
Гибкая методология разработки
Новости
Нужна ли команде Цель спринта в Scrum?
Стоит ли команде тратить время на постановку цели спринта при работе по Scrum, и какой в этом вообще смысл?
Почему ваши ежедневные стендапы не работают и как это исправить
Перевод статьи Лукаса Ф. Косты "Why your daily stand-ups don't work and how to fix them" с некоторыми размышлениями переводчика (выделены курсивом).
Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.
Управление техническим долгом в Scrum-разработке
Scrum методология решает значительное количество типичных проблем разработки ПО, однако, во многих компаниях отмечают, что ускорение разработки связано не просто с применением какой-то организационной парадигмы, но и с тем, что в Scrum часто пренебрегают какими-либо аспектами софверной инженерии, и, в частности, параметрами долгосрочного качества программного продукта. Однако, такая «экономия» редко может найти себе оправдание в значительной части отраслей экономики, где долгосрочное качество ПО лежит в основе конкурентных возможностей компаний. Технологическое развитие программных продуктов, и, например, учет и списание технического долга положительно влияют на значительное число параметров долгосрочного качества ПО.
Как работать со сложными пользовательскими историями, которые нельзя разделить
Сложные истории — это те, которые нельзя разделить. Они по своей природе большие и/или сложные, и в них нет частей, которые можно было бы разделить на отдельные истории. Что делать с такими историями?
Два способа добавлять детали в пользовательские истории
Пользовательские истории часто поначалу преднамеренно расплывчаты, если работа над историей не начнется в течение нескольких будущих спринтов. Agile-команды поняли, что добавлять детали в историю заблаговременно нецелесообразно. Но в жизни любой пользовательской истории наступает время, когда нужно добавлять детали. И есть два способа, которыми команда может добавить детали в пользовательскую историю: разделить ее или добавить критерии приемки (Acceptance criteria). Рассмотрим подробнее оба метода.
Проблемы мотивации команд и их решения в Scrum
Именно этой строкой начинается Agile манифест. И вроде бы это очевидно: сотрудники - главный ресурс любой компании. Однако на практике очень часто приоритеты сдвигаются в другую сторону и на первое место выходят: метрики, релизы, цели, задачи, события.
А как же люди? Ведь именно их отношение к работе, их мотивация и определяет итоговый результат.
Связь мотивации и эффективности очевидна: мотивированный сотрудник способен более длительное время удерживать фокус внимания на объекте своей деятельности. Он проявляет больше упорства в преодолении различных трудностей, более охотно принимает ответственность за результаты своей деятельности.
Поэтому один из пунктов Agile манифеста и гласить: над продуктом должна работать команда замотивированных профессионалов.
Окей, уровень профессиональных компетенций можно определить путем различных видов тестирования. И развивать их за счет внутреннего и внешнего обучения. А как быть с мотивацией? Много ли компаний оценивают на входе мотивационных профиль своих сотрудников?
Забегая немного вперед, сразу хочу сказать, что мотивация, по сравнению с другими различными профессиональными характеристиками, - структура весьма динамичная. И перемены ее уровня могут происходить скачкообразно как вверх, так и вниз. Как и изменение самой структуры мотивации.
Как правило, при устройстве на работу, мотивация сотрудника сильно детерминирована материальными факторами: уровнем зарплаты, социальным обеспечением, стабильностью, перспективами роста и т.д.
И тут вроде все понятно: есть ДМС, инструменты премирования по ключевым показателям эффективности, карьерный гайд, печеньки к кофе. Чего еще надо? Однако все это относится к инструментам мотивирования (стимулирования), а не к мотивации.
Опыт неопытного тимлида
В этом году я получил очень специфический опыт тимлидерства. Мало того, что это был мой первый опыт тимлидерства, так еще и проекты нужно было стартовать с нуля, и команды были собраны ровно под эти проекты. Никто из нас до этого вместе не работал и не имел четкого представления об опыте, знаниях и возможностях друг-друга.
Параметры спринтов как качественный показатель Scrum разработки
Современные парадигмы разработки ПО всегда являются итерационными. В методологии Scrum такими итерациями являются спринты, в классической версии Scrum каждый спринт начинается с планирования и завершается демо, ретроспективой и «инженерным» днем. Оценка успешности каждого спринта – это довольно субъективная вещь, формализация которой важна и может быть реализована с помощью следующих стандартных действий:
• Определить достижение целей спринта;
• Оценить краткосрочное влияние разработки ПО на удовлетворённость заказчиков и пользователей в развитии продуктов;
• Провести формализацию и учет параметров спринтов.
Определять для каждого спринта собственные цели несложно: необходимо сопрягать довольно точно измеряемые и формулируемые сущности: бизнес-цели разрабатываемых продуктов, приоритет функциональных и нефункциональных требований в беклогах различного уровня, логическую очередность этапов развития софтверных проектов.
Чуть больше о связи Критериев готовности (Definition of done) и Условий удовлетворенности (Conditions of Satisfaction)
Я хотел бы прояснить взаимосвязь между двумя важными понятиями: командным определением Критериев готовности (Definition of done) и Условий удовлетворенности (Conditions of Satisfaction) для пользовательской истории.
Нефункциональные требования как пользовательские истории (Non-functional Requirements as User Stories)
В рамках своей работы и ведения подкаста по бизнес-анализу (ссылка на подкаст), я часто получаю вопросы от бизнес-аналитиков. И один из самых частых - как задокументировать нефункциональные требования, если на проекте принят стандарт написания пользовательских историй? Сегодня, я хотела бы поделиться переводом статьи Майка Кона, о том, как описать нефункциональные требования с помощью пользовательских историй.
Пара тимлидовских побасёнок
Пришло время структурировать и осмыслить очередную порцию профессионального опыта. Изложу несколько ситуаций, участником или наблюдателем которых я являлся, с позиции тимлида. Каждая по своему забавна или печальна, и надеюсь, может быть поучительна, если вы узнаете в ней какие-то мешающие вам моменты.
Как оценивать эффективность продуктовых команд. Часть 1: процессные метрики
В нашей компании продуктовая структура представляет из себя 9 продуктовых end-to-end команд общей численностью ~130 человек, работающих над развитием одного продукта. Каждая из команд укомплектована всеми необходимыми компетенциями. Все живут в одном релизном процессе, делают задачи из одного бэклога (и проекта в Jira), и следят за одними метриками в Amplitude.
В условиях такого тесного взаимодействия естественным образом возникает вопрос: А как оценивать их эффективность?
Об этом мы и поговорим.
15 систем управления проектами 2022: легкий переезд, нет риска блокировки
Всем привет! Уже более 3 лет я анализирую разные системы управления проектами, делаю обзоры, сравниваю функционал. Сама я из команды YouGile.
Сейчас мы наблюдаем, как западные системы одна за другой уходят из России. Пользователи ищут аналоги, которые точно не заблокируют. Самое страшное в смене системы – переезд, иногда он может занимать несколько месяцев. Это чревато потерями и разорванными бизнес-процессами.
В этом обзоре я собрала 15 систем управления без риска блокировки, на которые легко «переехать». Отдельно рассмотрела возможности для переноса данных.
Настоящий Product Backlog Refinement: 4 этапа правильной работы над фичами
Привет, Хабр! Я Екатерина Колесникова, Agile Coach в inDriver. Когда я пришла в команду, заметила проблемы в процессе Product Backlog Refinement. Я предложила новый сценарий этой церемонии — и он сработал. В этой статье поделюсь опытом проведения PBR без скучной теории о «правильном» планировании.
Agile подход к разработке и управлению требованиями
Все мы с вами так или иначе сталкиваемся с требованиями, когда мы что-то от кого то хотим, когда кому то что то объясняем. И так или иначе, когда мы с вами доносим определенные требования наша цель передать полную картину, чтобы наш запрос был выполнен.
Моя шпаргалка по Скраму для подготовки к интервью. Часть 1
Как быстро подготовиться к вопросам по Скрам на собеседовании? Предлагаю свою шпаргалку, которой пользовалась на протяжении многих лет, и готовила по ней многих аналитиков.
Насильно мил не будешь, или Зачем мы дисциплинировали Agile?
Большинство компаний из ИТ, банковской, страховой и телекоммуникационной сфер в России и в мире уже активно применяют либо находятся в стадии внедрения различных гибких, или, другими словами, Agile-подходов в управлении командами и продуктами. Однако на пути пилотирования и становления таких способов менеджмент и сами сотрудники часто встречают множество проблем, которые мешают внедрению Agile и снижают удовлетворённость команды рабочими процессами.
В этой статье я, Сергей Селезнёв, менеджер проектов GlowByte, попробую консолидировать свой опыт и экспертизу GlowByte и разобраться, почему так может происходить в подразделениях и командах, которые занимаются развитием CRM-систем, какие есть особенности у этих команд и как можно попробовать решить эту проблему. Описанные случаи и подходы могут быть узнаваемы и применимы и к другим направлениям.
Вклад авторов
-
nmivan 524.0 -
AgileChange 258.0 -
Shapelez 206.0 -
zevvssibirix 204.0 -
romas1982 156.0 -
Superslon 145.0 -
AlexanderByndyu 140.0 -
vryashentsev 132.0 -
grumbler70 127.0 -
bevzuk 127.0