Pull to refresh
0

Наш рабочий процесс

Reading time 2 min
Views 11K
Наша компания разрабатывает систему управления agile проектами TargetProcess. За несколько лет разработки мы попробовали очень много самых разных практик, и пришли к своему процессу, которому успешно следуем и особо не меняем уже полгода.

Так как всякий процесс имеет границы применения, начнем с контекста.

Контекст


  • Разработка одного большого веб-приложения силами 10-20 человек;
  • Продукту уже 6 лет;
  • Используемые технологии: С#, ASP.NET, NHibernate, ExtJS;

Весь процесс описывать долго и нудно, так что вот самые главные практики.

Не очень технические практики


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

Оценки.
Мы не оцениваем фичи и юзер стори. Раньше мы проводили planning poker и оценивали истории в абстрактных поинтах, однако сейчас стараемся просто фокусироваться на самых важных вещах. Если вещь самая важная, оценка не так принципиальна, хотя product owner иногда очень хочет знать, когда же наконец будет выпущена вот эта новая и важная фича.

Митинги.
Когда-то у нас было много митингов: ретроспектива, планирование релиза, планирование итерации, daily standup. Сейчас из регулярных остался только daily, все остальные собрания проходят исключительно по мере необходимости для решения конкретных задач. Например, при начале работы над фичей собираются разработчики, тестировщики и product owner, чтобы обсудить все детали этой фичи. То есть собираются все, кто будет с ней иметь дело.

Рабочее время.
Раньше мы отслеживали все потраченное время, сейчас перестали это делать. Люди работают сколько хотят. Осталось только одно правило — на работе надо быть не позже 11, в это время проводится дейли митинг.

Мини-команды.
Для решения каждой проблемы формируется отдельная мини-команда. Обычно она состоит из 3-4 человек и работает вместе от 1 до 6 месяцев (в зависимости от сложности задачи). Люди из мини-команды сидят вместе (так что случаются переезды из одной комнаты в другую). Это позволяет фокусировать людей на одной задаче и убрать многозадачность практически полностью.

Технические практики


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

Контроль версий.
Мы разрабатываем каждую фичу и фиксим каждый баг в отдельном бранче. Для контроля версий используется Git. Мастер всегда готов к релизу.

Автоматические тесты.
Мы яростно используем TDD, а в последнее время и BDD. Менее ревностно автоматизируются регрессионные/функциональные тесты. Для этого используется ядреная смесь Selenium и самописный фреймворк на .NET. Покрытие тестами неплохое, а для ускорения их работы используется 12 виртуальных серверов, которые запускают тесты параллельно. И да, разработчики сами пишут все тесты.

С удовольствием поделимся и другими особенностями нашего процесса. Только попросите.

Кстати, в Минске нам очень нужны 2 .NET разработчика, 2 javascript разработчика, и крутой тестер.
Tags:
Hubs:
+18
Comments 17
Comments Comments 17

Articles

Information

Website
crew.taucraft.com
Registered
Founded
2010
Employees
31–50 employees
Location
Кипр