Статья посвящена трудным/трудовым обстоятельствам работы аналитиков на проектах, которые выполняются по некому варианту «Scrum + Аналитик», эти обстоятельства являются причиной стресса. Если вы думаете, что я дам вам какие-то решения, то увы, нет. Трудности эти в обозримом будущем никуда не денутся, можете считать, что вы ходите по кругу Сансары аналитика. Знайте, что вы не одни по нему ходите, может вам психологически станет легче.
Стоит ли команде тратить время на постановку цели спринта при работе по Scrum, и какой в этом вообще смысл?
Перевод статьи Лукаса Ф. Косты "Why your daily stand-ups don't work and how to fix them" с некоторыми размышлениями переводчика (выделены курсивом).
Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.
Scrum методология решает значительное количество типичных проблем разработки ПО, однако, во многих компаниях отмечают, что ускорение разработки связано не просто с применением какой-то организационной парадигмы, но и с тем, что в Scrum часто пренебрегают какими-либо аспектами софверной инженерии, и, в частности, параметрами долгосрочного качества программного продукта. Однако, такая «экономия» редко может найти себе оправдание в значительной части отраслей экономики, где долгосрочное качество ПО лежит в основе конкурентных возможностей компаний. Технологическое развитие программных продуктов, и, например, учет и списание технического долга положительно влияют на значительное число параметров долгосрочного качества ПО.
Сложные истории — это те, которые нельзя разделить. Они по своей природе большие и/или сложные, и в них нет частей, которые можно было бы разделить на отдельные истории. Что делать с такими историями?
Пользовательские истории часто поначалу преднамеренно расплывчаты, если работа над историей не начнется в течение нескольких будущих спринтов. Agile-команды поняли, что добавлять детали в историю заблаговременно нецелесообразно. Но в жизни любой пользовательской истории наступает время, когда нужно добавлять детали. И есть два способа, которыми команда может добавить детали в пользовательскую историю: разделить ее или добавить критерии приемки (Acceptance criteria). Рассмотрим подробнее оба метода.
Именно этой строкой начинается Agile манифест. И вроде бы это очевидно: сотрудники - главный ресурс любой компании. Однако на практике очень часто приоритеты сдвигаются в другую сторону и на первое место выходят: метрики, релизы, цели, задачи, события.
А как же люди? Ведь именно их отношение к работе, их мотивация и определяет итоговый результат.
Связь мотивации и эффективности очевидна: мотивированный сотрудник способен более длительное время удерживать фокус внимания на объекте своей деятельности. Он проявляет больше упорства в преодолении различных трудностей, более охотно принимает ответственность за результаты своей деятельности.
Поэтому один из пунктов Agile манифеста и гласить: над продуктом должна работать команда замотивированных профессионалов.
Окей, уровень профессиональных компетенций можно определить путем различных видов тестирования. И развивать их за счет внутреннего и внешнего обучения. А как быть с мотивацией? Много ли компаний оценивают на входе мотивационных профиль своих сотрудников?
Забегая немного вперед, сразу хочу сказать, что мотивация, по сравнению с другими различными профессиональными характеристиками, - структура весьма динамичная. И перемены ее уровня могут происходить скачкообразно как вверх, так и вниз. Как и изменение самой структуры мотивации.
Как правило, при устройстве на работу, мотивация сотрудника сильно детерминирована материальными факторами: уровнем зарплаты, социальным обеспечением, стабильностью, перспективами роста и т.д.
И тут вроде все понятно: есть ДМС, инструменты премирования по ключевым показателям эффективности, карьерный гайд, печеньки к кофе. Чего еще надо? Однако все это относится к инструментам мотивирования (стимулирования), а не к мотивации.
В этом году я получил очень специфический опыт тимлидерства. Мало того, что это был мой первый опыт тимлидерства, так еще и проекты нужно было стартовать с нуля, и команды были собраны ровно под эти проекты. Никто из нас до этого вместе не работал и не имел четкого представления об опыте, знаниях и возможностях друг-друга.
Современные парадигмы разработки ПО всегда являются итерационными. В методологии Scrum такими итерациями являются спринты, в классической версии Scrum каждый спринт начинается с планирования и завершается демо, ретроспективой и «инженерным» днем. Оценка успешности каждого спринта – это довольно субъективная вещь, формализация которой важна и может быть реализована с помощью следующих стандартных действий:
• Определить достижение целей спринта;
• Оценить краткосрочное влияние разработки ПО на удовлетворённость заказчиков и пользователей в развитии продуктов;
• Провести формализацию и учет параметров спринтов.
Определять для каждого спринта собственные цели несложно: необходимо сопрягать довольно точно измеряемые и формулируемые сущности: бизнес-цели разрабатываемых продуктов, приоритет функциональных и нефункциональных требований в беклогах различного уровня, логическую очередность этапов развития софтверных проектов.
Я хотел бы прояснить взаимосвязь между двумя важными понятиями: командным определением Критериев готовности (Definition of done) и Условий удовлетворенности (Conditions of Satisfaction) для пользовательской истории.
В рамках своей работы и ведения подкаста по бизнес-анализу (ссылка на подкаст), я часто получаю вопросы от бизнес-аналитиков. И один из самых частых - как задокументировать нефункциональные требования, если на проекте принят стандарт написания пользовательских историй? Сегодня, я хотела бы поделиться переводом статьи Майка Кона, о том, как описать нефункциональные требования с помощью пользовательских историй.
Пришло время структурировать и осмыслить очередную порцию профессионального опыта. Изложу несколько ситуаций, участником или наблюдателем которых я являлся, с позиции тимлида. Каждая по своему забавна или печальна, и надеюсь, может быть поучительна, если вы узнаете в ней какие-то мешающие вам моменты.
В нашей компании продуктовая структура представляет из себя 9 продуктовых end-to-end команд общей численностью ~130 человек, работающих над развитием одного продукта. Каждая из команд укомплектована всеми необходимыми компетенциями. Все живут в одном релизном процессе, делают задачи из одного бэклога (и проекта в Jira), и следят за одними метриками в Amplitude.
В условиях такого тесного взаимодействия естественным образом возникает вопрос: А как оценивать их эффективность?
Об этом мы и поговорим.
Всем привет! Уже более 3 лет я анализирую разные системы управления проектами, делаю обзоры, сравниваю функционал. Сама я из команды YouGile.
Сейчас мы наблюдаем, как западные системы одна за другой уходят из России. Пользователи ищут аналоги, которые точно не заблокируют. Самое страшное в смене системы – переезд, иногда он может занимать несколько месяцев. Это чревато потерями и разорванными бизнес-процессами.
В этом обзоре я собрала 15 систем управления без риска блокировки, на которые легко «переехать». Отдельно рассмотрела возможности для переноса данных.
Привет, Хабр! Я Екатерина Колесникова, Agile Coach в inDriver. Когда я пришла в команду, заметила проблемы в процессе Product Backlog Refinement. Я предложила новый сценарий этой церемонии — и он сработал. В этой статье поделюсь опытом проведения PBR без скучной теории о «правильном» планировании.
Все мы с вами так или иначе сталкиваемся с требованиями, когда мы что-то от кого то хотим, когда кому то что то объясняем. И так или иначе, когда мы с вами доносим определенные требования наша цель передать полную картину, чтобы наш запрос был выполнен.
Как быстро подготовиться к вопросам по Скрам на собеседовании? Предлагаю свою шпаргалку, которой пользовалась на протяжении многих лет, и готовила по ней многих аналитиков.
Большинство компаний из ИТ, банковской, страховой и телекоммуникационной сфер в России и в мире уже активно применяют либо находятся в стадии внедрения различных гибких, или, другими словами, Agile-подходов в управлении командами и продуктами. Однако на пути пилотирования и становления таких способов менеджмент и сами сотрудники часто встречают множество проблем, которые мешают внедрению Agile и снижают удовлетворённость команды рабочими процессами.
В этой статье я, Сергей Селезнёв, менеджер проектов GlowByte, попробую консолидировать свой опыт и экспертизу GlowByte и разобраться, почему так может происходить в подразделениях и командах, которые занимаются развитием CRM-систем, какие есть особенности у этих команд и как можно попробовать решить эту проблему. Описанные случаи и подходы могут быть узнаваемы и применимы и к другим направлениям.
