Agile *

Привет, Я Бохан Дмитрий — руководитель отдела инновационных проектов компании ПГК Диджитал. Сегодня поговорим про ретроспективу, зачем проводить ретро, а самое главное посмотрим с помощью каких игр, можно сделать ретро ярким и незабываемым.

Зачем проводить ретроспективы с командой? 

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

1. Непрерывное улучшение: определение того, что прошло хорошо, и что можно было бы сделать лучше, позволяет команде постоянно совершенствовать свои процессы и практики.

2. Вовлечение команды: с участие членов команды в процессе принятия решений  дает им новые возможности и увеличивает их чувство владения проектом.

3. Решение проблем: выявление проблем и препятствий своевременно не позволяет им расти и сорвать проект.

Инструменты для ретро

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

Если для вас проблема долгих Review такая же боль, как и моя, то после прочтения данной статьи вы будете на шаг ближе к решению данной проблемы.

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть1, Часть2, Часть 3, Часть 4. Сегодня мы обсудим совмещение нескольких подходов для управления сквозным бэклогом команды.

Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.

Перед вами перевод статьи автора Doug Bridgens, в которой он рефлексирует свой опыт и критически отзывается о Agile. В его статье совсем нет анализа и аргументации, это личные размышления на тему конкретного разработчика.

Это мой второй перевод и я позволю себе в этом предисловии пару предложений о том, зачем я потратил свое время на этот перевод:

Как живут IT-специалисты в сервисных подразделениях больших компаний, основной профиль которых напрямую не связан с IT? В этой статье, первой из серии — о том, как построена работа айтишников в Sminex, как мы применяем Agile-подход в повседневной работе, что у нас получается хорошо. Наша компания специализируется на строительстве дорогой недвижимости в центре Москвы — создаёт коллекцию домов вокруг Кремля в исторических районах города. Компания строит и проектирует более 460 тыс. кв. м элитной недвижимости.

Эта публикация вдохновлена одной из многочисленных презентаций о том, как планировать спринт в разработке, коих за свою жизнь я видел очень немало. И все они похожи одна на другую, как однояйцевые близнецы - всегда очень красивые рисунки и выверенный текст типа «тут у нас аналитика, вот разработка и тестирование, двухнедельный спринт, в конце спринта все задачи закрыты, руководство в восторге, заказчик счастлив». Я же хотел бы показать реальность такой, какая она есть.

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

Полезные борды и другие приёмы из личной практики.

Жизненный цикл (далее – ЖЦ) программного обеспечения (далее – ПО) состоит из ряда этапов, начинающихся стадией зарождения и заканчивающихся прекращением применения (рис. 1). Любая информационная система (далее – ИС) представляется совокупностью программных продуктов или ПО, тем самым определение жизненного цикла ПО и ИС тождественны. Вследствие того, что современные корпоративные информационные системы (далее – КИС) состоят из множества ИС, последнее применимо также и к КИС. 

Подарите 25 час в день и 8 день в неделю. Да еще одну неделечку к отпуску... Знакомо? Вот и я долгое время грустно смотрела в свой календарь и не понимала, куда все время уходит время и почему задачи закрываются в последний, самый горящий момент.

Привет, я Аня, и я решила расправиться с этим вопросом раз и навесгда. Понять, как разложить дела по полочкам и выделить время на то, что действительно важно, — это не просто каприз, это основа, которая толкает к целям и раскрашивает жизнь яркими красками. А если ты во главе коллектива, это ещё и прямой путь к успеху всей конторы.

Принципы личной эффективности, которые я применила в своей жизни, также работают и в бизнесе. Четкая ответственность, соблюдение сроков, прямая коммуникация, и обратная связь — это фундамент моих рабочих процессов. Agile и Kanban помогли мне организовать работу так, что каждый час на счету, а моя команда постоянно развивается и достигает новых высот.

Итак, путь к личной эффективности начнем с небольшого аудита.

Сначала я анализирую, куда уходит моё время. Это даёт чёткое понимание, сколько времени у меня на самом деле есть и на что оно тратится. Такой аудит помогает выявить "воров времени" и переосмыслить приоритеты.

Менее важные задачи составляют около 65% общего списка. Хотя их вклад в достижение конечных целей минимален — примерно 15%, они несут в себе риск стать "ворами времени". Для эффективного управления временем критично научиться отличать эти задачи от ключевых и при необходимости делегировать их или же вообще исключить из списка приоритетов.

В команде продукта не проводят исследования и действуют «по ощущениям»? Не понятно как создавать продукты, которые соответствовали бы ожиданиям клиентов или превышали их? Как встроить исследования в регулярные процессы своими силами, не нанимая новых сотрудников и без большого бюджета?

В кейсе вы найдете ответы на все эти вопросы!

Пожалуй, нет более популярной темы для обсуждения, чем применение Agile в проектах SAP. Несмотря на то, что принципы гибкой разработки были сформулированы ещё в 2001 году [1], их использование в настоящее время становится как никогда востребованным. Связано это в первую очередь с тем, что последнее десятилетие знаменуется массовым использованием информационных технологий (далее – ИТ) в повседневной жизни: порталы государственные услуг, интернет-магазины, электронное правительство и многое другое. Вышесказанное требует как грамотной разработки программного обеспечения (далее – ПО), так и не менее искусного его внедрения. 

Всем привет! Меня зовут Дмитрий. Я работаю senior Agile‑коучем в ОТП Банке. Использую практики Канбан‑метода в своей работе с 2019 года и хочу поделиться с вами своим опытом. В статье используются данные, собранные при работе с сервисной IT‑платформой, состоящей из 8 команд (общая численностью около 70 человек).

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

Вместо предисловия

Agile. Кругом Agile. Наверное не осталось людей, команд и организаций, которые работают не по Agile. Слово «SCRUM» прочно вошло в жизнь разработчика. Я уже и не помню, была ли разработка иной. А когда спрашиваешь, почему у вас в организации насаждается Agile, в ответ получаешь либо цитату из эпиграфа, либо, если человек более откровенен, слова "так все делают". Ну не может же быть, чтобы миллионы мух ошибались то, что делают все, было ошибочным?

Но, как известно, есть некоторые особенные люди, которые могут попытаться проверить, ошибаются ли мухи верно ли то, что делают все? Приятно, черт возьми, ощущать себя особенным!

Для начала попробуем подсчитать стоимость ритуалов SCRUM

Я, как руководитель команды разработки, имею возможность видеть время, затрачиваемое командой на все активности. Вообще-то это одна из обязанностей руководителя разработки – контролировать командные затраты времени. И я могу довольно точно посчитать, во что обходятся команде ритуалы SCRUM. Можем посчитать вместе:

- дейли митинг, он же стендап митинг. Вообще-то он должен занимать до 15 минут, но моя команда обычно хорошо если укладывается в 30 минут. Каждый день.

- планирование работ на будущий спринт. Тот самый процесс, где мы всей командой весело играем в карты. Обычно это занимает минимум 2 часа в спринт. Включает в себя декомпозицию задач из беклога, оценку и распределение. Да, в моей команде распределение проводится на планировании, нет такого, что на доске висят задачи, и сотрудники берут какую хотят.

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

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

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

Всем привет и добро пожаловать! Данная статья не является научной и не относится к разряду технических, она больше про коммуникации и командные процессы в IT. Это попытка систематизировать реальные практики по передаче контекста и знаний в IT команде, показать их актуальность и важность. Я уверен, что про что‑то из статьи вы уже слышали, видели, читали, или даже сами использовали. И для начала давайте определим основные понятия.

Контекст — совокупность различных факторов и/или сведений, необходимых для понимания или объяснения какого‑либо явления действительности.

Знание — проверенный практикой результат познания, то есть научные сведения, которые были проверены практикой и отражены в сознании человека.

В IT существует множество технологий, методологий, подходов, технических решений. Их комбинация определяет стек технологий компании, которых тоже оказывается множество. Найти специалиста с 100% совпадением по стеку технологий фактически очень сложно, да и знать всё на свете нереально. На самом деле это и не нужно, но статья немного про другое.

С контекстом, на мой взгляд, всё сложнее. Контекст — это не то, что вы можете изучить где‑то, прочитать статью, пройти курсы. Контекст плотно привязан к историческому наследию компанию. Это из разряда «так исторически сложилось». Я думаю, вам приходилось слышать эту фразу. Но даже в компании контекст от команды к команде может сильно отличаться, для каждой команды контекст тоже уникален.

Теперь представьте, у вас есть инфраструктура, проект, продукт, сервис, люди приходят и уходят, а вам нужно это сопровождать, чтобы всё работало стабильно, да ещё желательно, чтобы всё это не было завязано на одного человека. Именно поэтому важно делиться контекстом и знаниями в команде, а иногда даже и между командами.

Одной из важных стадий формирования UX (User experience) диджитал-продукта является релиз MVP (Minimal Viable Product, он же минимально жизнеспособный продукт). Эта такая версия вашего приложения или программы, которая подразумевает минимальное количество реализованных в продукте функций, достаточное при этом для формирования пользовательского опыта и фидбека. Это помогает понять, устраивают ли пользователей имеющиеся функции и как его улучшить.

Однако даже после выделения MVP оставшиеся функции могут оказаться многосоставными - раскладывающимися на более мелкие. Отличный метод декомпозиции функциональности — картирование пользовательских историй (User Story Mapping).