Agile *

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

Что в статье:

✔ Опыт организации работы параллельной работы 10+ бэкенд-разработчиков

✔ Ролевая модель и бизнес процесс создания продукта

✔ Почему junior-разработчики могут быть продуктивнее middle’ов

✔ Метрики помогающие контролировать эффективность команды

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

Дизайн Agile-организаций: создайте свою уникальную модель гибкости

Поиск «серебряной пули»

В этой статье я расскажу, как я работаю, когда «подгорает» на примере модуля планирования рабочего времени в нашем корпоративном портале.

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

Фреймворк SAFe (Scaled Agile Framework) помогает решить эту проблему, организовывая команды вокруг value streams (потоков создания ценности), что упрощает управление и повышает предсказуемость работы. Давайте разберемся, как именно SAFe позволяет выстроить ритм поставки ценности.

Когда я начинал свой путь junior PM, мне казалось, что ключ к успеху — это найти ту самую «волшебную» методологию. Scrum там, Kanban или, симпатичный, p3express. Но потом я понял одну штуку (спойлер: я еще в процессе понимания) — пока не разберёшься в пяти классических функциях менеджмента, любые модные фреймворки/методы/методологии будут лишь «пляской с бубном». При том что ты еще не стал шаманом.

Когда компании начинают планировать внедрение информационной системы или автоматизацию нового процесса, перед ними встает важный вопрос – как это реализовать? Выбор подходов зависит от многих факторов: есть ли сформулированные цели, объем неопределенности в бизнес-процессах, принятые в компании стандарты и ряд других факторов. Чтобы внедрение прошло максимально эффективно, и результат проекта удовлетворил заказчика можно, и даже нужно, выбирать разный подход, методологию, свой набор необходимых шагов. 

В этой статье мы на основе своего опыта реализации проектов расскажем о вариантах и шагах для достижения цели на примере внедрения решений на платформе ELMA365.

В этой статье поговорим о том, как правильно формулировать цели спринтов. Они позволяют команде сфокусироваться, синхронизировать усилия и двигаться в одном направлении, поддерживая понимания и фокус всей команды. Почему цели спринта критически важны?

Цель спринта — это ключевой элемент планирования, который помогает команде понимать образ результата, а не просто делать разрозненный набор задач. Даже если на планировании вы не учли все задачи, цель поможет понять, как адаптировать план. Хорошие команды ставят цель на планировании спринта и далее на дейли, каждый день уточняют его.

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

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

Давайте разберем некоторые принципы и инструменты, которые могут помочь.

Привет, Хабр! Меня зовут Антон, я — тимлид в Ozon. За более чем 20 лет работы в IT, где свыше 15 из них выпало на управленческие должности, меня покидало по разным проектам разработки ПО. Познавая управленческое мастерство, я нередко замечал, как на проектах игнорировали самую важную часть — ориентированность на Клиентов, то есть для кого мы, собственно, эти проекты и продукты реализуем.

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

Проблемы Agile отмечают не только рядовые пользователи, но и такие мастера, как Роберт С. Мартин и Кент Бек — двое из тех, кто составил Agile Manifesto. Как отмечает Ален Холуб, Agile в последнее время стал означать: делать половину задач (активностей) из Scrum плохо с использованием Jira.

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

Проблемы я стараюсь рассматривать равнозначно как со стороны бизнеса, так и со стороны IT, поэтому надеюсь, что данная статья будет полезна не только техническим менеджерам, но и представителям бизнес-подразделений.

Итак, подслушано в баре об Agile: некомедия в пяти актах...

Уже 15 лет я помогаю организациям перейти на agile. И вот что я заметил: в компаниях, которые пытаются внедрить гибкие подходы самостоятельно, неизбежно повторяются одни и те же ошибки. Причём больше всего от них страдают именно сотрудники.

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

Разные люди ведут дейли по‑разному:

Кто‑то быстро и активно проходится по людям, ожидая от них бодрого и активного отчета. В этом случае ведущий «сидит сверху», а команда находится в положении подчиненных и рапортует о состоянии своих дел. При этом люди стрессуют в разной степени тяжести.

Кто‑то душнит и впадает в детали. Тогда команда «плывет» и теряет фокус на встрече, занимаясь своими делами.

Кто‑то несется потоком слов вскачь, много тараторит сам с собой и команда превращается в зрителей, кому изредка дают слово.

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

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

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

Дожди не планировали останавливаться, и нашей группе нельзя было ждать, поэтому было принято решение идти вброд. Мы разбились на 2 группы по 6 человек, встали в круг и крепко-накрепко ухватились за лямки рюкзаков тех, кто стоял справа и слева. За пару дней до этого у меня случилась травма руки (я неудачно упала) , рука распухла, пальцы были как сосиски, и я несла её на перевязи. Но тут, откинув повязку в сторону я ухватилась за лямку соседа так, что не отцепишь. Жить, как говорится, захочется, не так раскорячишься.

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

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

Срочность или важность? Что поможет команде достичь максимального результата?

Перевели для вас статью и вместе с beeline cloud предлагаем порассуждать о том, в чем все-таки состоит секрет плодотворной работы над проектом.

Есть такая старая аксиома: чем сильнее вы спешите, тем выше вероятность того, что вы потерпите поражение. Не могу с ней не согласиться. Срочность — это не самоцель. Попытки апеллировать к срочности — суть вековая путаница между спешкой и скоростью. Когнитивное заблуждение, согласно которому если вы не спешите, то уже отстали.

Привет, Хабр! Я Данила, проджект‑менеджер в EvApps. Сегодня поговорим о том, как не стать заложником дедлайнов, своих же обещаний и как не превратить проект в бесконечный марафон с кофе по ночам.

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

Недавно мы наткнулись на пост в одном популярном телеграмм-канале с интригующей подписью. Смотрите сами.

Всем хорошо знакомы проектные менеджеры, также широкое распространение получили менеджеры по продажам. Менее распространены, но тоже достаточно известны менеджеры по продуктам. Однако немногие слышали о Delivery Manager, и в этой статье мы рассмотрим, что это за специалисты и какие требования к ним предъявляются.

Мы - брокерская платформа. Что мы имеем? С одной стороны сложную предметную область, высокую вариативность сценариев и потенциально огромные риски от ошибок. С другой - короткие итерации разработки и частые циклы доставки. Я расскажу о том, как при таких вводных на данный момент выглядят процессы обеспечения качества множества бэкенд-сервисов, которые поставляют всю необходимую информацию нашим торговым терминалам.

Всем привет! Я Дима Солодов, инженер по тестированию в Авито. За свой почти десятилетний опыт в тестировании я успел поработать в разных методологиях – от классического «водопада» до современного и эффективного Agile, а именно – по Scrum. 

У автоматизации тестирования в Scrum-командах есть ряд особенностей, с которыми приходится сталкиваться или же вовсе преодолевать их при работе над улучшением продукта. Об этом и идёт речь в данной статье.

Никогда не понимал хейт со стороны некоторых разработчиков в сторону Scrum!  

Особенно его много здесь, на Habr. Казалось бы, этот фреймворк придуман разработчиками для разработчиков в противовес классическим многовековым иерархичным ступенчатым подходам к организации труда. В основе Scrum лежат самоорганизация, эмпиризм, бережливое производство. Взрослый подход для взрослых людей. Что здесь может не нравится? 

И опирается это всё на Agile манифест, который тоже был создан разработчиками для разработчиков: Роберт Мартин, Кент Бек, Роберт Фаулер и т.д. Знакомые фамилии?

Можно конечно сказать, что тут есть определенное ограничение: Agilе говорит нам, что «над продуктам должны работать мотивированные профессионалы». Так значит всю волну хейта поднимают только зелёные джуны, которых лишили няньки и заставили разделать командную ответственность?

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

Так что позиция «я хочу кодить, а не невотэтовотвсё» совершенно не зависит от опыта. А тогда от чего? 

Давайте разбираться.

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

При этом команда была, проактивная и выпускала один MVP за другим проверяя разные бизнес гипотезы. Увидели потенциал идеи, взяли сделали, записали, что нужно доработать в будущем в техдолг, и пошли смотреть эффект ориентируясь на бизнес показатели. Тех долг постепенно решался, бизнес показатели росли. Вроде все хорошо. Но новый технический лидер трайба постоянно, как заезженную пластинку твердил «У вас все сделано на коленке».