Ретро - это способ осознать какую работу проделала команда за время спринта. Благодаря Ретро всплывают вопросы и задачи, которые в ежедневной рутине откладываются на потом и игнорируются.
В этой рассказано из чего состоит Ретро и приведены практиками, которые помогают разнообразить Ретро, получить больший результат.
Story Point (иногда Scrum Point) — относительная мера сложности или трудоёмкости элементов бэклога продукта.
Используется в Agile управлении продуктами.
Если отвечать утилитарно — оценки(Estimate) нужны для быстрого и реалистичного планирования объема работы на спринт и построения BurnDown (BurnUP) диаграммы или Velocity Chart.
Договариваемся о ценностях в работе и о других правилах игры > Группа в Telegram на всех причастных > Lean Canvas > Решение технических моментов с инструментами > OKR сессия > Архитектурная сессия > Этап выработки операционного ритма и политики качества > Формирование бэклога и планирование 1 спринта > Подготовка к старту > Enjoy 🚀
Перевод статьи Shane Show. How Psychological Safety Actually Works
Примечание переводчика: психологическая безопасность (ПБ) – одно из понятий, крайне важных для организации работы команды Agile. К сожалению, как многое другое в Agile, ПБ часто реализуется на уровне где-то между “прочитали одну статью о…” до “просто нафантазировали по мотивам”. Эффект от таких “применений” получается обратным: псевдо-безопасность парализует тех участников команды, которые действительно вносят реальный вклад в достижение целей. Изобилие не очень грамотных статей по этой теме, и сложность для восприятия серьезных научных работ только усугубляют ситуацию. Ниже приведен перевод статьи, которая написана простым языком, не искажает суть в угоду моде и тому, что хотят слышать большинство читателей. Наоборот, эта статья объясняет, что такое психологическая безопасность и, самое главное, что не является психологической безопасностью. Итак, поехали.
Модное словечко
С тех пор как в компании Google провели свое исследование об эффективных командах (проект “Oxygen”), о психологической безопасности (ПБ) начали говорить из каждого утюга. А сейчас новая тема – удаленная работа – придает ПБ еще большую значимость. Но вот беда, ПБ – это понятие куда более сложное, чем можно себе представить. Само понятие стало известным в 1999 году после выхода в свет работы Эми Эдмондсон “Психологическая безопасность и обучение поведению в рабочих командах”...
Я завершу серию публикаций с видео и презентациями после конференции BeeTech 2.0 выступлениями и презентациями спикеров Agile-стрима. Поток Engineering тут, Management тут, BigData тут.
Сразу подготовила общую ссылку на плейлист с видео Agile-стрима, в дополнение — даем презентации спикеров в статье. Если хотите выступить на конференции в следующем году, напишите об этом в комментариях или мне в личные сообщения на Хабре.
Я почитал несколько статей про Agile, Scrum, Скрам мастеров и других, которые публикуются здесь, на Хабре. Они могут встретить разную реакцию, но есть достаточно четкая параллель между степенью восторженности в посте и градусом в комментариях, поэтому давайте попробуем без лишних розовых очков пройтись по роли Скрам мастер. Я попытался собрать самые интересные мнения на Хабре на этот счет и немного их раскрутить, вот что получилось.
Обзор программ: Zendesk, Slack, ClickUp, GitHub, LiveAgent, Freshservice, SolarWinds Service Desk, SysAid, Shortcut, HappyFox, Freshdesk, Wrike, TeamSupport, Jira, Spiceworks
Привет, меня зовут Паша, уже несколько лет я работаю QA-инженером. И всё чаще и чаще мне больно за индустрию QA, потому что не все понимают, чем QA-инженер отличается от тестировщика. Ведь настоящий QA-инженер может сделать продукт качественным разными путями, а не только проверяя конечную сборку на соответствие неким требованиям.
Этой статьёй я хочу ещё раз напомнить, как инструменты командного взаимодействия решают проблемы качественной разработки, что ответственность за качество лежит на всей команде и что agile-понятия «Прозрачность» и «Предсказуемость» часто теряются на фоне клепания тасок в Jira. Несмотря на свою очевидность, Agile-практики применяются не везде, где могли бы приносить пользу, либо применяются с ошибками и антипаттернами, противоречащими самой культуре Agile. Я расскажу, с какими сложностями столкнулся на разных этапах распространения этой культуры и что делал, чтобы их преодолеть.
Если вы готовы тащить такие практики или пробовали их, но не взлетело, тоже смело заходите под кат. Буду счастлив, если найдёте для себя что-то новое и интересное.
Всем привет! Меня зовут Иван Чечиков, я QA-инженер в МТС Digital, работаю над проектом WASD.TV. В этой статье я моделирую стратегию тестирования для Agile/Scrum-проекта. Она может быть полезна небольшим командам, работающим по такой методологии. Стратегия проста, но не универсальна, вы можете дополнить ее на свое усмотрение.
Подробности – под катом.
Сегодня организации сталкиваются с угрозами кибербезопасности, которые становятся все более разнообразными, сложными и изощренными. В тоже время, не каждая компания обладает отделом специалистов по кибербезопасности. Но любая современная IT-компания должна задумываться над безопасностью своих продуктов. Решением могут стать инструменты для автоматизации процессов обеспечения безопасности, чтобы развертывать решения безопасности быстрее и не держать большой отдел по кибербезопасности.
На практике основными причинами появления нарушений безопасности являются недостатки реализации механизмов защиты, уязвимости в коде приложения, недостатки конфигурации. Очень часто контроль со стороны службы информационной безопасности проводится на последних этапах жизненного цикла приложения. Такой сценарий несовместим с современными методиками DevOps и Agile, которые сокращают сроки циклов поставки ПО до нескольких недель.
Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …
Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.
Всем привет! Я Виталий Дощенко, ньюбиз-директор AGIMA. Обычно на Хабре мы рассказываем, как работаем над цифровыми продуктами. Над мобильными приложениями, высоконагруженными системами или чат-ботами. Но только не в этот раз. В этой статье я расскажу, как Канбан-метод помог нам устранить последствия пожара. Не того пожара, где куча задач и ты ничего не успеваешь, а самого настоящего пожара, который чуть не уничтожил дом моей семьи.
Это статей я крупно рискую быть затоптанным армией фанатов Scrum, Kanban, XP и других методик гибкого планирования. Мне придется привести аргументы в пользу того, что мир не черно-белый, и что стандартная диаграмма Ганта тоже полезна, а в некоторых случаях даже приоритетна для менеджмента проектов в IT.
Ладно, я знаю, что оправдания и водянистые введения никому не нравятся, но этот дисклеймер нужен для того, чтобы вы обратили внимание и на альтернативный опыт.
Некоторое время назад я обнаружила интересный и полезный метод для простого и эффективного разделения пользовательских историй на более легковесные. Agile-тренер и соучредитель Scrum Alliance Mike Cohn отметил, что "почти каждая история может быть разделена с помощью одной из пяти техник". Он обобщает эти пять техник под аббревиатурой "SPIDR".
Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки, сколько заявок приходит от какого филиала, сколько распределяется на какого специалиста поддержки, что чаще всего ломается и требует внимания. Понять объективно, а не в ощущениях. И понимать регулярно.
Нет, я не помешан на метриках и отчётах. Знаю много случаев, когда управленческие решения принимаются вовсе без данных, и оно срабатывает. Что уж там говорить, с 2009 года, когда появилась компания, мы в нашей компании принимаем сотни решений каждый год, и только часть из них основана на каких-либо измеримых показателях.
С другой стороны, всегда, когда речь идёт про часто повторяющийся процесс, опирающийся на труд персонала, я агитирую за наличие разумного набора метрик. Так можно убрать разрыв между «я думаю» и «на самом деле», так можно увидеть где теряются деньги и другие ресурсы, так можно проще запустить процесс и сделать его лучше. Вот почему в первых же консалтинговых проектах в 2005-м мы с клиентами проектировали для каждого процесса метрики его эффективности, производительности и прочего. Вот почему сейчас для каждой новой команды разработки ПО вопрос измерения я с клиентами начинаю обсуждать как только речь заходит об организации работы. Без фанатизма, а как один из инструментов наладки.
Кроме метрик, вторая моя любимая тема — поток создания ценности. Этой идеей я увлёкся намного позже, когда до меня, наконец-то, дошло, как можно построить работающий (а не декларируемый) поток в интеллектуальной работе по разработке программного обеспечения. Спасибо ребятам из IT Revolution, они (в числе прочих) помогли мне сложить для себя новую, понятную, непротиворечивую и весьма прикладную картину мира. Многое встало на свои места. Несколько десятков команд мы помогли организовать по принципам потока создания ценности и я вижу, насколько мощный это инструмент.
«Процесс разработки больших программных систем чрезвычайно сложен и непредсказуем. Программные проекты часто прерываются, выходят за рамки сроков и бюджета или приводят к некачественным результатам, отделяя технологию программирования от установившихся инженерных дисциплин».
Впервые прочитав эту цитату Кони Бюрера, который работал в Rational Software, я полагал, что корень всех проблем, возникающих при разработке ПО, кроется именно здесь. С тех пор я повзрослел, оброс шлейфом скепсиса и перестал писать код для продакшена. Я больше не несу ответственности за разработку, тестирование или поставку отдельных классов, компонентов и даже сервисов. Я отвечаю за максимально быструю и качественную поставку бизнес-ценности в рамках одного из ключевых бизнесов ЦФТ - сервиса денежных переводов Золотая корона.
Менеджеры обладают всеми возможностями, чтобы заставить команду страдать
Как менеджеры, мы находимся в наилучшем положении, чтобы погрузить в уныние наши команды. Если вы менеджер, стремящийся действительно максимально причинить боль своим людям, обратите внимание! Мы рассмотрим три самых популярных способа.
Правда, мы сфокусируемся только на антипаттернах управления проектами, при том, что есть много других возможностей сделать людей в вашей команде несчастными.
Три секретных антипаттерна
1. «Белка в колесе»
2. «Миллион Agile-встреч»
3. «Гантаголик»
И сразу ссылка:
С вами так бывало? Послушаешь новый альбом и так зацепит, что обязательно нужно со всеми поделиться. Примерно это случилось со мной и книжкой «Shape Up». У меня за плечами десяток лет работы продуктовым дизайнером, и я не раз видел, как проекты проваливаются, поскольку никто так и не смог точно понять, что нужно сделать.
Я также видел, как чёткое понимание цели и жёсткие решения на пути к ней позволяли команде добиться результатов. Хочу, чтобы этого добилось как можно больше людей. Мой посильный вклад — этот перевод.
Приятного чтения и успешных проектов!
Привет, Хабр! Меня зовут Артём Кротов, я работаю руководителем направления развития гибких практик в команде Мир Plat.Form. В статье хочу рассказать, на какое обучение и сертификацию стоит обратить внимание разработчикам и вообще ИТ-специалистам, которые уже понимают, как они хотели бы развиваться по треку hard skills, но в теме soft skills не разбирались.
Если про Scrum и Kanban вы слышали только в контексте типов досок в Jira, а под CI понимаете Bamboo, Jenkins или Gitlab, то моя статья будет для вас полезной. Итак, погнали!
Всем привет! Меня зовут Владимир Тутынин, я методолог продуктового подхода и сегодня расскажу о своем методе планирования. Вы увидите, какие шаги я выполняю и какими инструментами пользуюсь для достижения результата.
Нам понадобятся две программы:
1. Evernote – это система заметок, которые хранятся в блокнотах и помечаются метками. Очень похожа на Confluence.
2. Trello – это доска задач с определенными правилами, на которой мы отображаем движение задачи по этапам.
Представим, что наше движение к достижению цели – это движение ракеты. Сначала мы находимся на высоте 0 метров, далее 10 000м, через минуту 20 000м, далее 30 000м и 40 000м. Эти отметки мы будем использовать как ориентиры и начнем наш маршрут в «космос».
Формирование меток
Заходим в Evernote и создаем 4 метки так, как показано на рисунке. Этими метками мы будем ориентироваться в пространстве заметок. В скобках после названия метки показано количество заметок, имеющих такую метку. Например, у меня есть 36 заметок с меткой «20.000м Цели».
