{"id":13502,"url":"\/distributions\/13502\/click?bit=1&hash=a81ed6f897d123d854b91b907b479be2ea058a6a8ec03bd6f76bfc8a24665263","title":"\u0425\u043e\u0447\u0443 \u043d\u0430\u0440\u0438\u0441\u043e\u0432\u0430\u0442\u044c \u0438 \u0430\u043d\u0438\u043c\u0438\u0440\u043e\u0432\u0430\u0442\u044c 3D-\u043c\u0443\u043b\u044c\u0442\u0444\u0438\u043b\u044c\u043c. \u0413\u0434\u0435 \u0443\u0447\u0438\u0442\u044c\u0441\u044f?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"7eb01878-f5ab-5bdb-ae26-b8e9a900dfa1","isPaidAndBannersEnabled":false}
Карьера
CRTWEB

Ретроспектива проектной команды или как жить по аджайлу в IT

Всем привет! Сейчас никого не удивишь такими методологиями работы, как Agile или Scrum. Но всегда интересно «подглядеть», как работают другие, и что-то перенести на свой опыт. В этой статье предлагаем нашим читателям побывать на ретроспективе одной из проектных команд. Ребята собираются на такие митапы раз в две недели, а раз в месяц Head of PM проводит общее ретро по всем проектам – с обсуждениям, вопросами и обработкой фидбека. Мы послушали – рассказываем вам и предлагаем обсудить тему в комментариях к статье.

Проект, на котором работает одна из наших команд, – это крупный маркетплейс. Бекенд-разработка, как это часто бывает, находится на стороне клиента, а мы отвечаем за фронтенд и тестирование. Есть и особенность – мы пришли на проект не с нуля. Статья будет полезна всем, кто хочет поближе познакомиться с атрибутами методологии Agile, и понять, в чём её польза для проектных команд.

С чем мы стартовали

Для начала расскажем о нашем проекте. Он был не совсем типовым, но от этого его интереснее разбирать. В чём заключалась специфика? Мы стали его вторыми исполнителями и на момент нашего старта готовность проекта уже составляла 30%.

В самом начале работы клиент сразу обозначил свои ожидания и поделился «мечтами». Главной из них было – довести проект до ума, сделать его современным и в дизайне, и в логике фронтенда. Ещё нам нужно было реализовать несколько фич – как у конкурентов или лучше. Ожидания клиента уже слегка затянулись, потому что предыдущая команда не смогла сделать всё «по красоте». Поэтому он хотел получить именно тот финальный результат, который первоначально закладывал в свой проект – причём быстро.

Вся коммуникация велась удалённо – через созвоны. Проектная команда также работала в разных форматах – кто-то в офисе нашей компании, кто-то – из других городов и даже стран. То есть, с организационной точки зрения, нам нужно было создать и продумать механику общего воркфлоу для всех ребят, установить дедлайны по выполнению задач, наладить коммуникацию внутри команды и с клиентом.

Как нам помогла методология Agile

1) Наследственные проекты отличаются от нулевых тем, что на них уже сформирована некая схема работы. Она не всегда понятна и удобна, поэтому когда мы заходили на такой проект, принесли «свой самовар». Точнее – методологию :)

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

2) Вся работа строилась по спринтам – коротким периодам, продолжительностью в две недели. Этого времени было достаточно, чтобы закрывать намеченные таски и двигаться дальше.

3) Ретро с клиентом помогло наладить процесс формирования бэклога задач (первоначально его не было) для будущей работы и рассчитать дедлайны. Также на таких онлайн-встречах мы могли обсудить весь актуал и иметь возможность быстро адаптироваться ко всем изменениям.

4) Ежедневные дейли стали крутым инструментом самоорганизации каждого из спецов внутри проектной команды. На них быстро и без воды чекали выполнение задач, собирали фидбек от всех участников проектной группы – независимо от того, сидят они за соседним столом в офисе или находятся за 1000 км от своих коллег.

5) Все задачи ставились и проводились в gitlab – им пользовались все участники проектной группы и лица на стороне клиента. Этот инструмент помог структурировать этапы работы и в режиме реального времени наблюдать за выполнением тасков.

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

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

А теперь вопросы к обсуждению:

1) вы пробовали жить по аджайлу? Расскажите о своих впечатлениях.

2) в чём вы видите плюсы или минусы этой методологии?

Будем рады познакомиться с вашими мнениями в комментариях к статье. Всем хороших выходных!

0
Комментарии
Читать все 0 комментариев
null