Как мы поставили процесс разработки на проекте длиной в 2 года

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

    Основное:
    • Численность команды разработчиков — 7 человек;
    • Длительность спринта — примерно две недели;
    • Стендапы каждый день;
    • Организацонные вещи хранятся в Acunote, google docs и MindMap;
    • Код хранится в SVN, новая фича — новая ветка, над одной фичей трудятся несколько разработчиков;
    • Тестирование — через unit-tests.

    Два года — это очень длинный марафон, поэтому каждому важно правильно получать задачи и видеть конкретные результаты их выполнения. Для этого мы ввели систему коротких периодов, различения целей и задач плюс предельной конкретизации последних. Самая короткая ставящаяся задача — 2 минуты, самая длинная — 3 часа.

    Планирование


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

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

    Цель — это некое изменение в работе сервиса, которое мы хотим сделать. Например — «добавить механизм рекомендации друзей». Задача — это часть цели, которую может выполнить один человек в команде. Например «нарисовать дизайн для рекомендаций друзей на мобильном сайте».

    Задач без вышестоящих целей в идеале быть не должно. Практика от идеала сильно отличается, так что у нас в каждом спринте есть две мета-задачи — «разные мелочи» и «тестирование», которые, похоже, неискоренимы.

    В нашем случае планирование достаточно четко бьется на три части:
    • Выполненные задачи;
    • Постановка целей;
    • Конкретизация и обсуждение задач.

    1. Что не выполнено?


    Часть задач всегда остается невыполненной. Если всё выполнено — то, вероятно, задач на команду попросту не хватает. Я верю в то, что существуют люди, которые способны планировать спринты со 100% точностью, но мы так ещё не умеем.

    Причины не выполнения обычно следующие:
    • Обнаружились объективные трудности (документация по API Facebook устарела, партнеры не прислали вовремя XML, дизайн три раза ходил на утверждение) и задачу не успели сделать;
    • В процессе спринта были добавлены задачи с более высоким приоритетом и задача была отложена;
    • Задача сама была добавлена в процессе спринта и за неё ещё никто не взялся;
    • Кто-то из команды заболел или взял отгул — такое тоже случается.

    Невыполненная задача — это не страшно. Намного важнее понимать, почему она была не сделана и смотреть на общий процент провала по спринту. Если сделано только 70-80%, мы ищем ответ на вопрос, что случилось и почему. Второй раз такой косяк не нужен. Важно: мы ищем не виноватых, а корень проблемы.

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

    Эта часть планирования при правильной организации проводится без команды — данных от ежедневных стендапов вполне достаточно.

    2. Что мы хотим сделать в этом спринте?


    На этом этапе речь идет о постановке целей (не задач!) на спринт. Цели ставит отдельный человек — Product Owner или PO (замполит продукта). От него требуется, в общем-то, одно — понимать как проект должен развиваться дальше. Он собирает требования и пожелания третьих лиц (отдела маркетинга, отдела связи с клиентами, программистов), тщательно просеивает их, добавляет свои идеи и, в результате, выдает список вещей, которые мы хотим осуществить.

    На спринт у нас планируется 4-5 крупных целей. Примеры — «редизайн мобильного сайта под концепцию Q», «внедрение алгоритма N выборки мест для отметок на сайте», «добавление оплаты через Я.Деньги без посредников».

    Цель должна быть сформулирована понятно, рекомендуется использовать правило "{глагол} {существительное} {дополнения}" — на двухнедельном спринте забыть, что именно имелось в виду при формулировке пары целей достаточно просто.

    Кроме этого, на этом этапе мы решаем, какие именно несделанные задачи из прошлого спринта мы переносим в текущий, а какие — в бэклог.



    3. Расписывание и обсуждение


    Расписывание ведется всем коллективом — то есть PO и командой разработчиков. Цели надо превратить в задачи, проставить по каждой задаче предположительное время и, в ряде случаев, исполнителя. В нашем случае отдельно выделяются дизайн и верстка — ими всегда занимаются конкретные люди. Исполнителя на задачи программистов, напротив, стараемся сразу не назначать — они выполняются по приоритетам в режиме «кто задачу доделал, тот берет себе следующую».

    Время выполнения задачи оценивается всей командой вместе — в том числе и теми, кто к этому участку кода отношения никогда не имел. По загруженности мы исходим уровня шесть часов задач в день на человека. С учетом стендапов и переговоров с коллегами это вполне разумно. Главное — это не мотивирует специалистов пытаться завысить время выполнения задачи, чтобы уложиться в «план».

    Если какая-то задача занимает больше 2-3 часов — значит её надо разбивать на несколько мелких подзадач. Это не только улучшает точность оценивания времени и вносит ясность в процесс, но и облегчает работу программистам — психологически проще выполнить четыре мелких и четко поставленных задачи, ведущих к цели, чем одну крупную и аморфную.

    На этом этапе часть целей может уйти в бэклог или вообще отсеяться — так бывает, если выясняется, что на выполнение цели уйдет сильно больше времени, нежели рассчитывал PO.

    Итоги


    Полный цикл планирования занимает около двух дней. Большая часть времени уходит на то, чтобы PO понял, какие именно цели он поставит перед командой. Расписывание задач у нас обычно проходит во вторник около двенадцати часов — понедельник отводится команде для исправления найденных недочетов и доделки мелких задач из текущего спринта. Идею проводить расписывание (равно как и стендапы) с самого утра мы сочли неудачной — на утро всегда находится какая-то срочная работа.

    P.S. Если интересно, могу рассказать про конкретные механики работы с Acunote и построение процесса с точки зрения разработчика, а не тимлида.
    AlterGeo
    24,88
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +4
      Спасибо. Что делаете с задачами дольше пары минут, которые стоят с низким приоритетом — просто забываете по факту?
        +3
        Уходят в бэклог. Перед планированием бэклог перетрясается на предмет низкоприоритетных задач, которые там давно висят. О части просто забываем, у части поднимаем приоритет и выносим в спринт.
        +4
        Почему svn, а не hg/git? Особенно если нужны ветки?
          +3
          Во многом исторически сложилось — проект начали писать с SVN-репозиторием. Смысла в переезде особо не видим. По веткам — проблем с мержем не имеем, так как большая часть веток короткоживущие, да и разработчиков не так много.
          +1
          Интересная статья, только вот в большинстве случаев, к сожалению, по плану одно, а на деле другое.
            +2
            Для этого у нас и проводятся ежедневные стендапы — они позволяют понять, где пошло расхождение с планом. Стендап проходит за 15-30 минут, основные вопросы всё те же:
            — что за вчера было сделано;
            — что за вчера не было сделано из запланированного и почему, какие проблемы возникли;
            — что планируется сделать сегодня.
            Разработчику понимание того, что завтра днем придется рассказывать, на что ушел сегодняшний день, очень хорошо помогает удерживаться в рамках плана. Тимлиду — уловить момент, когда пошло отклонение от плана и его скорректировать.
              0
              30 минут стоя получается или у вас сидячий стенд-ап митинг?
              Мне кажется очень долго. Детальные вопросы можно позже обсудить, а чтобы понять картину происходящего 5-10 минут должно хватать. У меня был опыт, когда каждому давали минуту-две по секундомеру, и вполне укладывались.
                0
                Митинги сейчас сидячие.
                Да, если все в порядке — то у каждого около двух минут на рассказ, как раз около 15 минут и получается. Если появляются новые задачи, либо возникают проблемы — то стендап затягивается. Мы считаем, что выгодно, когда вся команда (включая дизайнера и верстальщика) в курсе возникающих трудностей.
            +7
            > Если какая-то задача занимает больше 2-3 часов — значит её надо разбивать на несколько мелких подзадач.

            Для 7 разрабочиков, работающих хотябы по 6 часов в день 2 недели подобных задач нужно порядка 200. Вы действительно создаете по 200 задач на каждый 2-х недельный спринт?
              0
              Тоже по ходу чтения прикинул цифры и недоверчиво ухмыльнулся :)
                +3
                Примерно так и получается — 3-5 задач на разработчика в день. Расписывать задачи по целям на деле не сложно при наличии у команды опыта.
              0
              Интересная статья, но было бы интересно почитать не только про планирование, но и про финальные стадии процесса.

              Как оцениваются результаты по итогам?

              Как делается релиз или CI?

              Что происходит если задача не укладывается в запланированный срок по времени (например, нашелся фатальный баг в используемой библиотеке или что-то такое)?

              Как планируются зависимости (по порядку и slack) задач? Например, процент «провала» посчитанный по количеству может быть высок, а из-за slack это на текущую итерацию не влияет на самом деле, что тогда?
                0
                Сколько времени у вас занимает детализация задач спринта? Какими обязательными характеристиками должна обладать каждая из задач?
                  +2
                  Сейчас детализация занимает 2-4 часа. Когда мы начинали использовать эту методику — уходил почти весь рабочий день.

                  Формулировка задачи должна быть понятна всем разработчикам. Если есть какие-то важные для выполнения и не следующие из формулировки моменты, они выносятся в комментарии к задаче.

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

                  Кроме того, в нашей практике мы пришли к выводу, что задача не должна подразумевать переключения между разными частями проекта. Задача «изменить структуру БД для N» — хорошая, её можно писать в спринт. Задачу «изменить структуру БД и добавить поля ввода для новых атрибутов» надо разбивать на две части перед добавлением.
                  +2
                  Вы видимо немного лукавите, когда пишите такие легкие тексты.
                  Возможно сейчас все так как написано, но когда-то было все не так.

                  Хочется почитать как раз про сложности.
                  Что например делаете, когда у программиста теряется заинтересованность/стимул?
                  Во-первых, как такие ситуации отслеживаете?
                  Во-вторых, как стимулируете?

                  Были ли случаи, когда программист по показателям из месяца в месяц падал. Что тогда?

                  Оцениваете всей командой? Или каждый разработчик оценивает свои задачи, чтобы он потом за нее отвечал (за нее и за сроки)?

                  У каждого разработчика своя скорость разработки — как оцениваете задачи в таком случае?

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

                    Оценивание задачи идет всей командой. На первых спринтах оценки от реальности отличались порой в два-три раза в обе стороны. Сейчас получается достаточно точно, но на получение опыта у нас ушло около четырех недельных спринтов. Скорость разработки может служить основанием для пропорционального увеличения времени выполнения задачи. Напоминаю — команда небольшая и такие вещи легко держать в голове. Когда имеем дело с новыми разработчиками, ставится дополнительная задача вида «изучение архитектуры».

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

                    Провалов по показателям из месяца в месяц у нас пока что не было, команда подобралась хорошая. Если будет — постараемся разобраться, почему так происходит. При небольшом количестве людей мне кажется намного более эффективным с каждым таким случаем разобраться отдельно.
                      +2
                      Мне иногда кажется, что глубоко разбираться в причинах фейла вообще вредно (польза только одна — удовлетворенное самолюбие). Ну докопался я, допустим, узнал, что программист не справился с задачей, т.к. любит читать Хабрахабр по утрам и тратит на это драгоценное время. А дальше не факт, что лечение пройдет успешно. Чем больше я знаю — тем меньше я знаю :-). На каждой следующей итерации копать надо глубже. Проще — есть результат/нет результата. Если нет — банально либо не хватает времени, либо навыков. Говоря на языке физики, Работа = Мощность × Время. Неизвестных всего две.
                        +1
                        Согласен, пока затраченное время окупается, есть смысл копаться дальше. А вот на какой итерации остановиться, уже зависит от здравого смысла тимлида.
                        0
                        Можно я позадаю несколько вопросов, которые интересуют меня и по которым мне интересен чужой опыт?

                        Например, ваша проблема «люди не хотели подниматься на стендапы каждый день» кажется очень знакомой. Интересует одно из ее проявлений, когда разработчик старше PM'а и успел поучаствовать в большем количестве проектов. Отсюда у него убежденность что тот способ работы, по которому он работает — лучший. Что он существенно опытнее PM'а и т.д.
                        При этом у этого же разработчика наблюдаются самые банальные проблемы: плохая координация своего времени, постоянная отвлеченность, в общем далеко не идеальная производительность. Нежелание планировать и давать оценки.

                        Были подобные проблемы? Как решались?
                      0
                      >В процессе спринта были добавлены задачи с более высоким приоритетом и задача была отложена

                      ~14 дней спринт, 2 дня на планирование. <=12 дней не потерпеть?
                        +1
                        Да, большая часть новых задач уходит в бэклог и, в будущем, в следующий спринт.
                        Но некоторые задачи очень не хочется откладывать даже на пару дней. Обычно это или критические баги, которые нашлись посреди спринта, или задачи, связанные со взаимодействием с нашими партнерами.
                        +1
                        Ребята, вы систематический фейл спринта объявили нормой и даже прямо-таки включили в методологию…
                          0
                          Кстати, отличный вопрос. Если средняя длина спринта, скажем, 100 рабочих единиц, и делают в среднем по 100 рабочих единиц за это время, что лучше: поставить спринт на 95 и знать, что его выполнят (фактор победы) или поставить его на 105 как сейчас и, по факту, дать знать всем, что его не сделают до конца? В первом случае есть желание завысить время задачи, во втором, по факту, тоже — ведь задач-то явно больше, чем нужно, верно?

                          Точнее даже так: можно объяснить простыми словами, почему именно вы считаете это более эффективным?
                            +2
                            Нагружать задачи «с горкой» — это, по сути, акт недоверия команде.
                            Типа, «я знаю, что вы меня, манагера, на… ываете с оценками, поэтому я нагружу вам заведомо больше».
                            И, в результате, команда не только лишена радости («Ура!!! DONE!!!»), но и привыкает, что постоянные долги — это норма.

                            Некоторые почему-то думают, что «перегрузка» будет оказывать какое-то давление на разработчиков. На самом же деле, все ровно наоборот. Если результат заведомо недостижим, то «копаем от забора до обеда».
                              +2
                              Задачи с горкой мы стараемся не нагружать — это действительно плохо влияет на разработчиков. Мы предпочтем поставить спринт на 90-95 часов, но при этом с самого начала понимать, что могут и будут возникать проблемы и незапланированные задачи посреди спринта.
                              Причины:
                              — разработчики не находятся под стрессом невыполнимых сроков и видят, что результат достижим;
                              — у нас есть запас прочности на случай возникающих проблем;
                              — в случае если задачи закончатся, у нас всегда есть бэклог и PO.
                              Желание завысить время работы может возникнуть в любом случае. Решается проставлением времени задачи всей командой при планировании — когда никто лично не заинтересован в завышении оценки — и стендапами. Если разработчик увеличивает время задачи во время выполнения, он должен объяснить, почему так произошло.
                            0
                            Проект велется лва года двухнедельными спринтами. Будет ли верным предположить, что описания функциональности готового продукта и, тем более, ТЗ на него у вас нет?
                              0
                              Готового — это финальной версии? Тогда документации на готовый продукт у нас нет, причину смотрите чуть ниже.

                              Документация по текущему состоянию проекта ведется одновременно с разработкой. Необходимое ТЗ на спринт создается до спринта.
                                +1
                                Вы правда думаете, что можно написать ТЗ на разработку социальной сети, потом сделать все по ТЗ и получить не УГ? :)
                                +4
                                Как вы поймёте что проект готов?
                                  +1
                                  Когда проект помрет, тогда и будет готов судя по всему.
                                    +2
                                    Ответ выше был, в общем-то, правильным. Мы делаем социальную сеть. Пока она живет, мы её развиваем, правим найденные баги и добавляем новый функционал. Если «готов» читать как «закончена работа над проектом», то готовым проект станет только в момент закрытия.
                                    +1
                                    Давно хочу понять, где в вашем проекте выхлоп? В вас вкладывают деньги, а отдача? Можете не отвечать, если это секрет.
                                      +2
                                      Не секрет, конечно же)

                                      Основная часть прибыли идет от совместных программ с заведениями. Мы им — рекламу и посетителей через специальные акции, они нам выхлоп. Кроме того, мы постепенно расширяемся на рынок купонов.
                                        0
                                        Спасибо, довольно любопытная информация.

                                        Успехов вам!
                                      0
                                      «Практика от идеала сильно отличается, так что у нас в каждом спринте есть две мета-задачи — «разные мелочи» и «тестирование», которые, похоже, неискоренимы.» — следует ли из этих слов, что работа QA в вашей команде относится к «неискоренимым» ненужностям.
                                        0
                                        Просто к «неискоренимым». Действительно написал непонятно, поясняю.
                                        Работа QA достаточно плохо вписывается в концепцию «цели — задачи». Когда тестировщикам ставится новая задача — например «протестировать добавление друзей по фидбеку от пользователя», ставить для неё цель достаточно глупо. Вместе с тем:
                                        — мы хотим, чтобы работа QA была частью спринта;
                                        — мы хотим уметь прогресс по ней наравне с другими задачами.
                                        Потому мы договорились о выделении метацели, которая кочует из спринта в спринт. Всё незапланированное тестирование уходит подзадачами в неё. Это не более чем удобный организаторский приём.

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

                                      Самое читаемое