Перед вами перевод статьи автора Doug Bridgens, в которой он рефлексирует свой опыт и критически отзывается о Agile. В его статье совсем нет анализа и аргументации, это личные размышления на тему конкретного разработчика.
Это мой второй перевод и я позволю себе в этом предисловии пару предложений о том, зачем я потратил свое время на этот перевод:
Вариант построения системы управления задачами небольшой команды разработки. Без вовлечения руководства, на возможностях имеющегося трекера.
Полезные борды и другие приёмы из личной практики.
Привет, Хаброжители!
Эта публикация вдохновлена одной из многочисленных презентаций о том, как планировать спринт в разработке, коих за свою жизнь я видел очень немало. И все они похожи одна на другую, как однояйцевые близнецы - всегда очень красивые рисунки и выверенный текст типа «тут у нас аналитика, вот разработка и тестирование, двухнедельный спринт, в конце спринта все задачи закрыты, руководство в восторге, заказчик счастлив». Я же хотел бы показать реальность такой, какая она есть.
В команде продукта не проводят исследования и действуют «по ощущениям»? Не понятно как создавать продукты, которые соответствовали бы ожиданиям клиентов или превышали их? Как встроить исследования в регулярные процессы своими силами, не нанимая новых сотрудников и без большого бюджета?
В кейсе вы найдете ответы на все эти вопросы!
Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть1, Часть2, Часть 3, Часть 4. Сегодня мы обсудим совмещение нескольких подходов для управления сквозным бэклогом команды.
Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.
Всем привет! Меня зовут Дмитрий. Я работаю senior Agile‑коучем в ОТП Банке. Использую практики Канбан‑метода в своей работе с 2019 года и хочу поделиться с вами своим опытом. В статье используются данные, собранные при работе с сервисной IT‑платформой, состоящей из 8 команд (общая численностью около 70 человек).
Привет, Я Бохан Дмитрий — руководитель отдела инновационных проектов компании ПГК Диджитал. Сегодня поговорим про ретроспективу, зачем проводить ретро, а самое главное посмотрим с помощью каких игр, можно сделать ретро ярким и незабываемым.
Зачем проводить ретроспективы с командой?
Ретроспективы служат важным механизмом для команд, чтобы задуматься о своей недавней работе и выявлять области для улучшения. Создавая безопасное пространство для открытого обсуждения, ретроспективы побуждают членов команды свободно делиться своими мыслями, проблемами и идеями. Это способствует культуре прозрачности, доверия и сотрудничества в команде. Кроме того, ретроспективы помогают в следующих направлениях:
1. Непрерывное улучшение: определение того, что прошло хорошо, и что можно было бы сделать лучше, позволяет команде постоянно совершенствовать свои процессы и практики.
2. Вовлечение команды: с участие членов команды в процессе принятия решений дает им новые возможности и увеличивает их чувство владения проектом.
3. Решение проблем: выявление проблем и препятствий своевременно не позволяет им расти и сорвать проект.
Инструменты для ретро
Подготовка и проведение эффективных ретроспектив требует некоторых важных инструментов и методов:
Если для вас проблема долгих Review такая же боль, как и моя, то после прочтения данной статьи вы будете на шаг ближе к решению данной проблемы.
Подарите 25 час в день и 8 день в неделю. Да еще одну неделечку к отпуску... Знакомо? Вот и я долгое время грустно смотрела в свой календарь и не понимала, куда все время уходит время и почему задачи закрываются в последний, самый горящий момент.
Привет, я Аня, и я решила расправиться с этим вопросом раз и навесгда. Понять, как разложить дела по полочкам и выделить время на то, что действительно важно, — это не просто каприз, это основа, которая толкает к целям и раскрашивает жизнь яркими красками. А если ты во главе коллектива, это ещё и прямой путь к успеху всей конторы.
Принципы личной эффективности, которые я применила в своей жизни, также работают и в бизнесе. Четкая ответственность, соблюдение сроков, прямая коммуникация, и обратная связь — это фундамент моих рабочих процессов. Agile и Kanban помогли мне организовать работу так, что каждый час на счету, а моя команда постоянно развивается и достигает новых высот.
Итак, путь к личной эффективности начнем с небольшого аудита.
Сначала я анализирую, куда уходит моё время. Это даёт чёткое понимание, сколько времени у меня на самом деле есть и на что оно тратится. Такой аудит помогает выявить "воров времени" и переосмыслить приоритеты.
Менее важные задачи составляют около 65% общего списка. Хотя их вклад в достижение конечных целей минимален — примерно 15%, они несут в себе риск стать "ворами времени". Для эффективного управления временем критично научиться отличать эти задачи от ключевых и при необходимости делегировать их или же вообще исключить из списка приоритетов.
