Многие, говоря про Скрам в первую очередь вспоминают про добавление событий в процессы работы команды (дейлик, планирование, обзор, ретроспектива и сам спринт). Но это лишь является верхушкой айсберга всего фреймворка.
Данные события часто проводятся как механические упражнения и ритуалы, что является одной из дисфункций фреймворка. Дают ли такие события пользу без других важных основ? Ответ очевиден. Давайте разберёмся, что должно стоять за событиями.
Мир тестирования постоянно меняется. Тенденции, заметные в этом году и позволяющие бизнесу добиться успеха в эпоху “новой нормальности”, хорошо отражены в статье, которую я взялась перевести - Stepping into the future: QA and software testing trends to thrive in 2022. Год подходит к концу и хочется посмотреть насколько тенденции актуальны. Но в моей компании тренды далеко не всегда могут быть применимы, по крайней мере пока.
Поэтому попытаюсь к переводу добавить и отношение со стороны своего опыта.
Пандемия COVID-19 ускорила внедрение цифровых технологий. Компании были вынуждены быстро перенести свой бизнес в онлайн и продолжать работу, несмотря на то, что пришлось внедрять прорывные технологические новинки — от искусственного интеллекта и IoT, до блокчейна и дополненной реальности. Однако путь в цифру оказался непростым. По оценкам экспертов BCG 70% крупномасштабных трансформаций потерпели неудачу, так и не достигнув своих целей (детали можно найти тут)
Учитывая такую высокую долю провалов, напрашивается вопрос - как бизнесу обеспечить успех этого процесса и окупить все свои усилия?
Зачастую при построении процессов разработки возникает вопрос: "Что использовать — Scrum или Kanban? Что подойдет нашей команде?" Давайте разбираться, можно ли их вообще сравнивать.
Среди сотен различных Agile-практик разработки программного обеспечения есть несколько совершенно бесполезных, но, как ни странно, они все еще очень популярны среди многих организаций и Scrum-команд.
Вот мой список 5-ти лучших Agile-практик, на которые уходит много времени и которые бесполезны:
1. Оценка пользовательских историй в Story Points по конечным результатам.
Единственная причина оценки в Story Points - проверить, есть ли у команды одинаковое понимание того, что и как нужно сделать для завершения User Story. Оценка любой работы методом от обратного контрпродуктивна и не приносит никакой пользы: Какой смысл проверять, одинаково ли мы понимаем то, что уже сделано? Кроме того, это подрывает правильное использование Story Points на сессиях планирования.
Привет, это Илья, CTO 2people IT. Бэклог – ваша кухня, а рейфайнмент (груминг) – генеральная уборка. Как бы тщательно вы за ним не следили, периодически необходимо его чистить и адаптировать к планируемым спринтам. Если вы склонны обдумывать задачи на ходу и перетаскивать их из бэклога продукта в спринт по наитию, то эта статья для вас.
Дисклеймер: пока сам Shape up в боевых условиях не довелось попробовать, но на бумаге оно решает многие проблемы, которые меня бесят в организации процессов разработки.
Некоторое время назад я мониторил забугорный рынок труда, на предмет удвоить а то и утроить свою ЗП на тот момент. В итоге я эту затею забросил через какое-то время, зато по ходу обогатился знаниями. В частности я наткнулся на компанию Process street, в блоге которой был описана методология Shape up. Там был описан очень заманчивый крючок для меня как для разработчика, так называемый 2х недельный cooldown после 6 недельного цикла. "В эти 2 недели наши разработчики занимаются на проекте всем чем захотят!" Прям так и было написано, возможно без восклицательного знака.
Людям свойственно со временем забывать откуда все пошло, поэтому нужно вспоминать. Публикация навеяна статьей "Почему Scrum не надо применять там, где не надо — ограничения и допущения фреймворка".
Конечно, это моя интерпретация, но она основана на огромном количестве времени обучения, самообучения и опыта в индустрии.
Понятно, что тут только про разработку ПО. И разработку длительную (в коротких проектах есть много возможностей где-то срезать углы).
Честный и понятный Agile-манифест:
Планирование спринта является ключевым элементом работы в Scrum. Тем не менее, это все еще проблематичное и часто поверхностное событие для многих групп. Основываясь на своем опыте, я подготовил пять советов, которые помогут вам лучше спланировать свой следующий спринт.
Фрейморк Scrum в представлении не нуждается, и его преимущества многократно описаны. Однако о недостатках подхода говорят реже, и успешно применять его получается далеко не у всех. Зачастую после первых неудач команда разочаровывается в подходе и начинает считать его полностью бесполезной пустышкой. Но может быть дело не в самом Скраме, а в том, где и как его применили?
Попробуем рассмотреть, какие есть ограничения и допущения в применимости этого подхода, какие риски и предварительные условия нужно учесть.
Статья посвящена трудным/трудовым обстоятельствам работы аналитиков на проектах, которые выполняются по некому варианту «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) для пользовательской истории.
