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

    Наша компания разрабатывает систему управления 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 разработчика, и крутой тестер.
    Taucraft Limited
    35,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 17

      0
      Рад, что вы развиваетесь.
      TargetProcess один из лучших решения для agile процесса.
      Все же хотелось бы узнать поподробнее про «Оценки» — как вам все же удается делать estimates для фич, исли вы не делаете planning game и не используете итерации?
        0
        Мы не делаем эстимейты.
        +1
        выпустить любой бакфикс в течение дня

        Если «бакфикс» от слов бак или бакс, то это здорово — прямо онлайн-монетизация получается :)
        А если от слова баг, то чуть по другому пишется
          0
          :) хорошее замечание
          0
          Как долго вы работали по SCRUM и какие проблемы вынудили от него отказаться?
            +1
            У нас был XP сначала, но в принципе процесс планирования там и в Scrum практически одинаковые. Итерации у нас были года 3. Отказались по разным причинам. Во-первых, частенько не успевали сделать все, что запланированно. Как мы ни старались улучшить эстимейты, все равно бывали ошибки и в полтора и в два раза. Во-вторых, хотелось иметь возможность выпускать релизы в любое удобное время, без итераций это делать гораздо проще. В-третьих, легче совмещать длинные и сложные фичи с небольшими улучшениями. Можно часто выпускать небольшие улучшения, параллельно работая над серьезными фичами.

            Я думаю, что Scrum хорош для начала проекта и разработки с нуля. Но для матерых продуктов лучше Kanban.
              0
              Не совсем понятно ваше стремление делать релизы в любое удобное время, на что это может повлиять?
                +1
                Ну например пофиксили 10 багов за неделю. Почему бы не выпустить? Людям польза.
                  0
                  ну только если с этой позиции, и если люди слишком нетерпеливы, чтобы подождать 1-2 недели до очередного выпуска :)
                    0
                    Ну во-первых в скраме не обязательно после каждого спринта происходит релиз. Во-вторых что делать, если фича занимает 2 спринта?
                      0
                      Так и в Канбане у вас продукт релизится не через неделю после начала работ над ним, верно? И фича, занимающая 2 спринта, это нечто :) Такие вещи декомпозируются на более мелкие в обязательном порядке и делаются в порядке приоритета. Прошу понять меня правильно, я не противник канбана, просто я сторонник правильного использования практик и инструментов, так, как это и было задумано создателями :)
                        0
                        Это все хорошо звучит в теории, но так себе реализуемо на практике. Единственный способ реализовать это — сделать механизм выключения фич, что требует дополнительных затрат.

                        Просто пример. Вот есть у вас система плагинов. Понадобилось ее полностью переписать (например, хотите SOA внедрить для нее) Ну как ни крути нельзя ее разбить на маленькие стори сначала. Пока не готов фреймворк, вы не сможете переписывать отдельные плагины. Можно поставлять старые плагины вместе с новыми. Но зачем? А можно просто делать их в отдельном бранче и выпустить, когда все будет готово.
                        +1
                        разбить на 2 фичи
              0
              отличный рабочий процесс
                0
                Мы разрабатываем каждую фичу и фиксим каждый баг в отдельном бранче. Мастер всегда готов к релизу.

                А в какой момент вливаете фикс в основную ветку?
                  0
                  Непосредственно перед релизом. Тогда на основной ветке запускаются тесты и все проверяется еще раз.
                  +1
                  Спасибо за статью. Приятно осознавать, что мы не одни во вселенной.

                  Пришли почти к тому же. Было 2 года экспериментов с XP и Scrum. За это время адаптировали все под себя. Теперь уже 4 месяца вырисовывается Kanban.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.