Scrum — реальный опыт работы по методологии

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

    Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».


    Какие роли есть в Scrum


    С чего обычно начинается разработка программного обеспечения? С идеи: «Как было бы замечательно, если бы у меня было некое ПО, которое делало бы примерно вот это. Было бы просто супер!» Человека, который в команде будет представлять эту идею, называют Product Owner (PO) или Владелец продукта. Product Owner – это тот, кто видит цель продукта или кому кажется, что он видит цель продукта, но важно то, что он может ее сформулировать и начать процесс движения к ее достижению. Цель он формирует в виде списка своих пожеланий (хотелок). Этот список называется Product Backlog Items (PBI). Он постоянно модифицируется в зависимости ситуации на рынке или от разрастающегося аппетита Product Owner'a.

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

    Что такое спринт и зачем он нужен


    ProductOwner сформулировал свою цель в виде некого пункта B, который нужно достичь, начав движение с пункта A. Но пункт B – это не точка, в которую можно попасть, просто нарисовав прямую линию между ней и пунктом А. На самом деле пункт B это окрестность точки, и радиус ее может варьироваться.

    image

    Чтобы попасть в эту окрестность, лучше всего разрабатывать ПО короткими шагами (точнее забегами): спринтами. В конце спринта все оценивают, что получается, и корректируют направление движения. ProductOwner всегда в курсе того, что его идеи правильно поняты (а если нет, то это можно скорректировать уже на следующем спринте), и спокоен. Команда знает, что делает то, что нужно, и удовлетворена своей работой.

    Как формируется список задач на спринт


    В команде спринт длится 2 недели. За неделю ничего не успевается, за месяц все забывается. Поэтому 2 недели для нас самый оптимальный вариант. Первый день спринта уходит на планирование. На ранних этапах на планирование уходило даже 2 дня. Планирование – это процесс, при котором команда берет из списка требований наиболее приоритетные и разбивает на задачи, которые позволяют достичь результата. Каждая задача оценивается в часах. Желательно, чтобы задача не занимала времени больше, чем 4 часа. Если участник команды говорит, что сделает задачу за 5 дней, значит, он понятия не имеет, что нужно сделать.
    Общее количество часов в спринте на каждого человека рассчитывается из того, что спринт длится 2 недели или 10 рабочих дней. Это 80 часов минус один день на планирование. Итого 72 часа. Но это идеальные часы. Это значит, что человек ни на что не отвлекается, не ест, не пьет, с места не встает, а только работает и не устает. Во время планирования задача оцениваются в идеальных часах. Но набирается для человека не 72 часа, а 72 часа, умноженные на некий коэффициент, который называется производительностью команды. Обычно это 0.5. Удивительно, но это какое-то магическое число, именно при нем весь спринт сдается успешно. Кто-то из великих сказал: «Возьмите время, которые назвал вам разработчик, умножьте его на два и еще немного прибавьте и получите срок, за который вам программист выдаст результат». И это действительно так.
    В Scrum есть несколько рекомендаций в отношении того, как исполнителю оценивать время на задачу. Например, играть в покер. Но мы этим не грешим. Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт. И только он может оценить, сколько ему нужно времени на выполнение задачи. Единственные, кто ему может помешать завысить сроки, это его совесть (помните про самоорганизацию) и ScrumMaster.

    Как проверить, что требование ProductOwner’а выполнено


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

    image

    Главное требование – тесты должны быть очень подробными.

    Что происходит во время спринта


    Начинается процесс исполнения спринта. Главная его цель – добиться, чтобы тесты, предъявляемые к требованиям, к концу спринта выполнялись.
    Для сплоченного движения команды к цели Scrum предлагает делать ежедневные митинги. Митинг – это когда каждый, стоя у доски с маркером, вычеркивает то, что он сделал вчера и пишет то, что он собирается сделать сегодня.

    image

    Это очень мощная практика. Благодаря ей каждый знает, куда движется проект в целом. К тому же когда человек, рассказывает, что он будет делать сегодня, то он автоматически координирует свои действия с другими участниками. Другие участники могут тут же предложить лучшие решения задачи. А еще написанная на доске задача, а по сути — это обещание всем своим коллегам, очень хорошо мотивирует самого исполнителя. Единственное, ScrumMaster не должен забывать объявлять, что начался митинг.
    Митинги проводить желательно стоя и длительностью не более 15 минут. Мы начинаем митинги в 9 утра.

    Что происходит в конце спринта


    Наступает долгожданный конец спринта, обычно это пятница в 16:00, и команда сдает спринт Product Owner'у и всем-всем, кто заинтересован в продукте. Каждый отчитывается по задачам, которые выполнял и рассказывает о том, каких успехов достиг, а также объясняет причины, по которым не удалось достичь цели. Главное правило — никогда не переносите срок сдачи спринта.
    Иногда после сдачи спринта делается анализ того, почему что-то происходит или не происходит, и что нужно предпринять, чтобы исправить ситуацию.
    А в понедельник все повторяется сначала.

    Накопленный опыт


    Мы для себя выработали несколько правил, несоблюдение которых приводило к провалу спринта:
    • Спринт надо планировать детально, не жалея на это сил. Если что-то из требований непонятно, то надо прояснять требование. Если это не удается сделать, то не надо брать задачу в спринт, а требование отправлять на доработку.
    • Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.
    • Количество человек в команде не должно превышать 5-6 человек. Когда наша команда выросла до 16 человек, митинг начал затягиваться на 2 часа. Ввели фиксированное время выступления для каждого и стояли с секундомером. Но тогда человек не успевал донести свою мысль, и митинг превращался в формальность. Поэтому мы просто разделились. Сначала поделились на клиентщиков и ядерщиков, а потом начали делиться по задачам. Т.е. каждая команда делает свою фичу, и в этой подкоманде есть как клиентщики, так и ядерщики. Этот подход используется до сих пор, и для нас он наиболее эффективен.

    Вывод


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

    Кто мы?


    Команда, в которой я работаю, называется «Юниклауд Лабс». Это дружный коллектив интересных людей, реально болеющих за свое дело.

    Вариков Андрей VAndrey
    Технический директор ООО «Юниклауд Лабс»

    Если интересно что мы делаем — Welcome
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 50

      +10
      Мы начинаем митинги в 9 утра.

      Поразило до глубины души :)
        +1
        ага, 14.00 уже куда точнее
        +1
        А что есть в этой статье такого, что уже стопицот раз не было разжевано на хабре?
          +4
          Практический опыт всегда полезен. Вот у ребят успешно получается с двухнедельными забегами и без покера. Это довольно ценная информация.
            +2
            В этом практическом опыте нет ни одного нестандартного кейса.
            Очень много кто работает двухнедельными забегами, без покера и раздельными командами с общим циклом релизов (мы, например).

            И все это описано даже в «Scrum and XP from the Trenches».
          0
          Каждый опыт уникален, не так ли?
            +3
            Несмотря на то что статья про «реальный опыт» больше всего похоже на некий скрам в вакууме.
            Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт.

            И что будет если этот разработчик уволится или заболеет? Вы прекратите разработку этого модуля?

            Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.

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

            Резюмируя:
            Мне слабо верится что это действительно реальный опыт и у вас все так хорошо как вы описали.
            Но если это действительно так, то конечно завидую :)
              +1
              Ну это проблема уже команды, которая не может пояснить заказчику, что она не можеть взять в итерацию больше обещанного. У нас тоже такое правило есть, но оно не распространяется на хотфиксы, которые прилетают со статусом «аааа, всё упало» и команда не может их не взять, если это угрожает стабильности продукта. У каждой команды есть свой менеджер который отвечает за часть продукта и уже он заворачивает все «хотелки» выше стоящих людей, а если не заворачивает, то берёт ответственность на себя, за то что, его команда не выпустила обещанный функционал в срок. В остальном же, задачи по улучшению и не критическим багам легко двигаются в следующюю итерацию или вообще в беклог. Так что всё возможно.
                +1
                Заказчик вообще с разработчиками разговаривать не должен. Только с Product owner-ом. А там уж его задача объяснить, что «успеем мы либо это либо то»

                По поводу срочных багфиксов — лично товарищ Сазэрленд советовал всегда оставлять в спринте буфер 10-20% времени для таких вот случаев. Но все-равно, проходят они только через Product owner-а.
                  0
                  Напрямую заказчик с разработчиками и не общается, просто из моего опыта Product owner это человек который играет на стороне заказчика а не команды. И обычно он старается максимально выполнить хотелки заказчика иногда в ушерб команде. Хотя я надеюсь что просто мне не очень повезло попасть в такой проект.
                    0
                    Конечно Product owner играет на стороне заказчика. Дело в том, что никто не в праве давить на команду. Команда берет задачи у Product owner-а а не Product owner дает задачи. Кроме того очень важно, что это всегда один человек. Он хоть и на стороне заказчика, но будет глупо себя чувствовать сказав вчера, что фича А — суперважна, и придя сегодня с фичей Б ))

                    Но реальная жизнь конечно отличается от теории ))

                    Большинство проблем скрама от того, что руководство продолжает использовать иерархическую модель, микроменеджмент и т.д. Я бы вообще поставил это первым условием для внедрения скрама — «Руководство компании/подразделения действительно понимает что это такое».

                    Обычно то все думают, что это какая-то девелоперская фишка чтобы работать в 2 паза быстрее. А это ведь технология управления а не разработки.
                      0
                      Можно я задам вопрос: а что происходит, когда команда не хочет делать что-то, что хочет PO?
                        0
                        РО выстраивает бэк-лог, в нем задачи имеют приоритеты.

                        Если команда регулярно игнорирует самую приоритетную историю, и не дает внятного объяснения причины, значит команда не справляется со своими обязанностями )) Все-таки команда не решает что брать а что не брать, она решает сколько взять а сколько оставить для следующего спринта.

                        Если же причины на то есть, по РО их игнорирует — значит с ним что-то не так. В любом случае судить кому-то вышестоящему.
                          0
                          Не регулярно. Для того, чтобы запороть длинный и сложный эпик достаточно одного места (issue на 1 sp), в отношении которого будет «я его не успел сделать, у меня были более важные (читай, технически интересные) вещи, чем сидеть и уныло кодить 30 чекбоксов в JS».

                          Мы, собственно, от модели «каждый берёт себе на реализацию то, что хочет» и отходим, потому что оказывалось, что часть вещей из недели в неделю лежат несделанными.

                          Сейчас картинка другая: «кто хочет делать Х?». То есть хоть кто-то на митинге должен взяться. А дальше там уже команда сама решает кто будет, кто нет.
                            0
                            Хаа… начну из далека ))

                            В чем соль скрама? Почему он быстрее даже при разработке тех же самых фич теми же самыми девелоперами? Многие думают, что суть в митингах и совместном обсуждении, или в том, что команды наконец стали кросс-функциональными, некоторые вообще назовут девелоперские практики их ХР.

                            Мое мнение: соль, главная цель и суть — переключение сознания с индивидуального на командное. Нет больше ничего личного ни личных тасков, ни личных проблем ни личного успеха. Только командное. Команда берет себе юзер-стори, команда ответственна за ее выполнение.

                            Обосрался один девелопер — обосралась вся команда. С другой стороны, если обосралась твоя команда — обосрался и ты, даже если ты сделал «свои таски» супер быстро и качественно.

                            И как следствие — команда осталась без бонуса — ты тоже его не увидишь, даже если ты вообще теоретически не мог помочь Васе, т.к. он пишет на С++ а ты — РНР-шник.

                            Возвращаясь к вашему сообщению. Конечно не может быть «каждый берет» и «кто хочет делать». Вопрос звучит так (грубо говоря)
                            — Эй, команда!!! Мы успеем сделать истории А, В, С за это спринт?
                            — Успеем!
                            — Зашибись! Давайте теперь обсудим детали, как именно (и уже здесь распределяем кто что может делать)

                            Истории\команда должны быть такими, чтобы ВСЯ команда работала над одной историей одновременно и только по ее окончанию переключалась на следующую.
                              0
                              Совсем другое представление, да…

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

                              С другой стороны, PO имеет точные сроки реализации фичи, явный план разработки.

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

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

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

                                Но все же с моей точки зрения скрам это когда:
                                — девелоперы сами планируют свое время
                                — РО не имеет сроки а получает сроки от девелоперов. Если дедлайн ближе — значит нужно уменьшать функциональность (при неизменности команды)

                                Не зря одним из ярких пунктов в теории скрама — отсутствие тимлидера.

                                По поводу «послать любого» — для девелопера вообще никого не существует кроме РО и его коллег-девелоперов. Так что посылать просто должно быть некого ))

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

                                Хотя, даже «неправильные» реализации скрама по некоторым данным позволяют выполнять задачи на 50-70% быстрее. «Настоящий» скрам обещает как-бы 200-300%, но я пока не увижу — не поверю ))
                                  0
                                  Ну, в моём случае я просто спрашиваю «сколько вам нужно на то, чтобы сделать „вот это“». А дальше исходя из этого определяется, сколько issue из какого эпика делается в этот спринт.

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

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

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

                                  А учить всех программистов всем тонкостям проектов… И зачем нам столько сисадминов, да ещё без опыта работы (сисадмином)?
                                    0
                                    Ну про знания программистов, я не помню чтобы прям так жестко было. Наоборот постоянно упоминается о том, что нужно работать над распространением знаний между членами команд и разными командами.

                                    С другой стороны скрам говорит, что команда должна уметь справляться с задачей самостоятельно. Т.е. если для выполнения какой-то задачи вот реально нужен сисадмин — значит он должен быть в команде. Хотябы частично.

                                    Если для выполнения задачи требуются какие-то ресурсы или знания извне — я бы включал это в «definition of ready» для user-story. Например если в команде нету UI-дизайнеров, значит все необходимые элементы должны быть предоставлены вместе с задачей. Если требуется какая-то спецификация, разъяснение и т.д. о том, о чем команда понятия не имеет — значит задача не начинается до тех пор, пока соотв. люди эти артефакты не предоставят. Соотв. запрос команда может озвучить РО во время груминг-митинга.

                                    Ну и никто не отменял «пойти спросить» когда команда сталкивается с вопросом вне ее компетенции.
                                      0
                                      Ну тут такая проблема, что если сделать всю сисадминскую часть, то в большинстве задач программистам остаётся просто это всё вместе связать кодом.
                                        0
                                        Звучит так, как-будто у вас слишком много программистов и слишком мало сисадминов ))

                                        Если от сисадмина в задаче больше толку, чем от программиста — значит он там действительно главную роль играть должен.
                                          0
                                          В инфраструктрных проектах очень трудно определить, что и как важнее. Потому что часто решения диктуются не свободой «как бы нам написать», а необходимостью «как бы нам не сломать и учесть существующие решения».
                                          0
                                          Просто связать все вместе кодом — такая же работа, как и сделать всю сисадминскую часть.
                                            0
                                            Разумеется. Если это можно было с помощью парочки шелловых скриптов сделать, то так бы и сделали. Проблема в другом — можно ли такие задачи целиком делегировать программистам?
                                              0
                                              Разумеется. Но и зубы к патологоанатому никто не ходит лечить :)
                                              Я старюсь не браться за сисадминскую работу, это также неэффективно, как и сисадмину делать программерскую.
                                0
                                >потому что оказывалось, что часть вещей из недели в неделю лежат несделанными.

                                То есть PO ставил фичам приоритет все выше и выше, а команда упорно продолжлала делать менее приоритетные задачи? Жесть какая.
                                  0
                                  Так вот я и спрашиваю, как соотносятся желания команды что-то не делать с желанием PO что-то видеть сделанным.
                                    +1
                                    У вас есть скрам-мастер? Тогда он должен поймать момент «я сделал X, но беру Z, а не Y, потому что так хочу» и напомнить разработчику про приоритеты.
                                    Команда — наемные работники. Делать то, что на самом верху по приоритету — их прямая обязанность, они именно за это деньги получают. Иначе это не скрам, а анархия — каждый делает только то, что ему хочется.
                                      0
                                      Ок, хорошо, я попробую на следующем митинге воздействовать на людёв. Отдельно SM у нас нет.
                              0
                              Нам повезло, так получилось, что команда и PO не находятся по разные стороны баррикад. Они сражаются на одной стороне. Задачу обсуждают все и выигрывают, как правило, аргументы. Но у PO есть привилегия, бремя ответственности — выбирать решения между множеством предложенных.
                                0
                                В любом проекте есть гик-вкусное (то, что повышает самооценку) и нудятина, которую кто-то всё равно должен делать. Мне кажется, правильное планирование должно создавать такие условия, чтобы нудятину не оставляли «на потом». Потому что обычно «нудятина» это как раз техническая реализация бизнес-логики (которая не имеет никакого отношения ни к технике, ни к логике), и без которой самые офигенные технические решения не имеют никакого business value,
                      +6
                      Испольузем скрам. Я работаю (де-факто) как PO, но у меня несколько иная модель. Я пишу эпики и статьи к ним, а так же детально расписываю как их сделать (с высоты полёта epic'а). Это подвергается design review (неформальному обсуждению как это реально всё-таки делать будем) с командой.

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

                      При этом:
                      1) всё-таки не можем избавиться от дедлоков — это когда, например, серверная часть не готова, а человеку в JS больше делать нечего.
                      2) Плохо сочетается с code review, который может делаться дольше спринта. Что делать пока что думаем.
                      3) Т.к. issue завязаны в один эпик, то невыполнение хотя бы одного issue приводит к тому, что epic (читай, user story) не выполняется. Вроде бы «почти», но всё ещё нет. В результате у нас ни разу не было, чтобы эпик был выкачен в продакт за неделю работы.

                      Пока продолжаем отлаживать процесс…
                        0
                        А что происходит если из-за неверного планирования для некоторого сотрудника спринт по факту завершился раньше чем через две недели? Ему делают новый мини спринт? Или же он просто ждет остальных?
                          0
                          В скраме задачи не назначаются на конкретных людей на планировании, а разбираются по мере надобности. Если для одного сотрудника спринт завершился раньше" — значит задач не осталось совсем.
                          0
                          Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт. И только он может оценить, сколько ему нужно времени на выполнение задачи.

                          Это противоречит крайне полезному принципу коллективного владения кода.

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

                          Здесь речь идет о функциональных требованиях или об автоматизированных тестах? Расскажите подробнее.
                            0
                            Кодом владеют все и каждый может заменить другого. Но глубина владения кодом у каждого разная. И есть один, кто в данный момент владеет модулем. Его глубина погружения в детали выше всех. Значит он аргументированно может лучше оценить разработку. Если ему сильно кто — то возражает и говорит, что сделает быстрее, его ответ, как правило, простой:«Делай».

                            Выше речь шла, конечно о функциональных требованиях. Аналитики описывает их, и часто вместе с остальной командой и PO. В них описывается результат, который надо предъявить в конце спринта.
                            0
                            Обычно в конце спринта сдача происходит в виде демонстрации работающего кода, а не рассказа о том, кто что сделал/не сделал. Почему у вас только рассказы? Почему отказались от демо?
                              0
                              Видимо я не правильно выразился. Происходит демонстрация функциональных требований, которые были описаны аналитиками и взяты разработчиками в работу. И тут же происходит анализ и, если надо, корректировка требований на следующий спринт. Это все сопровождается рассказом программиста:«Я на этом спринте реализовывал вот эту задачу» Идет демонстрация и одновременное обсуждение.
                              –5
                              Митинги проводить желательно стоя...
                              Митинг? А как насчёт утренней забастовки?
                              –2
                              Поэтому 2 недели для нас самый оптимальный вариант. Первый день спринта уходит на планирование. На ранних этапах на планирование уходило даже 2 дня.

                              image

                              Слепое следование методологии разработки к добру не приводит. По личному опыту скажу, что два дня на планирование — это черезвычайный перебор. Один час — максимум.
                                +1
                                За час в понедельник можно успеть разве что проведенные выходные обсудить ;)
                                  0
                                  Сомнительно что за час можно хорошо детализировать и оценить задачи на всю команду на две недели
                                  0
                                  Кроме скрама что-то пробовали? Постоянно сталкиваюсь с тем, что скрам оказывается слишком тяжелым фреймворком для небольших команд, и с него радостно слезают на что-нибудь менее формальное.
                                    0
                                    Раньше работал по водопадной модели, тоже можно достигать результатов. Но скрам, лично для меня, оказался наиболее эффективной моделью. Правда она выжимает все соки.
                                    0
                                    — в конце спринта отдаете протестированный продук?
                                    — тестеры имеют возможность протестировать все разработанные фичи в рамках одного тестового цикла, а не по частям?
                                    — отдаете продукт в пятницу в 4, а когда начинаете последний тестовый цикл? У девелоперов есть возможность пофиксить баги, напйденные тестерами, до 4:00 вечера пятницы?
                                      0
                                      Тоже перехожу на scrum с водопада.
                                      Спасибо за интересную статью и не менее интересные комментарии.
                                      Теоретические моменты все понятны, но наблюдая за реальным опытом команд возникает ощущение «мой скрам лучше твоего».
                                      Пока не видел ни одной команды, которая работала бы в полном соответствии со «стандартом», поэтому можно говорить именно о выстраивании процесса на основе scrum и в данном случае, реальный опыт крайне полезен для сравнения и понимания.

                                      Некоторые вопросы (интересует именно реальный опыт команд), которые возникают, при попытке примерить процесс на себя:

                                      — Насколько плотно у вас заказчик вовлечен в процесс? Присутствует ли он при обсуждении и сдаче спринтов?

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

                                      — Есть ли у кого-то еще опыт разработки по TDD в рамках scum? Здесь говорится, что тесты пишут аналитики и до старта спринта. Мне кажется, что спринт — это целостная единица, в течении которой должны быть выполнены все работы по user story, а тесты должен писать сам разработчик. Или в рамках user story создается несколько задач (написать тест, запрограммировать, протестировать,..) и каждая из них может браться в разный спринт? Как же тогда демонстрировать такие задачи? Мне кажется, будут возникать те же проблемы, что и при водопаде — проблемы вслывают в самом конце, в результате чего и получаем 90% + еще 90% работы.

                                      — Есть ли у кого-то личный опыт ведения процесса через Redmine? Используются ли какие-то плагины (можете посоветовать) или процесс ведется на доске, а задачи в Redmine?

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

                                      — Как у вас реализуется тестирование? Тестируется весь спринт целиком по завершении или каждый таск отдельно?

                                      — Часто слышу, что брать в спринт больше задач, чем можно реально сделать — это нормально. В принципе, смысл в этом есть. Или же лучше брать меньше, но зато делать все в срок? Но как тогда быть с требованием не менять состав спринта в течение его разработки?
                                        0
                                        коэффициент, который называется производительностью команды

                                        У нас это коэффициент называется фокус фактор и туда учитывается не только производительность команды, так же учитывается время на устранение аварий по действующим проектам.
                                        Но, если вернуться к коэффициенту производительности команды, как вы его считаете?
                                          0
                                          По Scrum у нас есть подробный кейс, где мы говорим про наш опыт и фишки, вроде «Рыбного четверга». Предлагаю обсуждать в комментариях. www.carrotquest.io/blog/kak-organizovat-rabotu-komandy-opyt-metodologii-scrum-v-carrot-quest

                                          Only users with full accounts can post comments. Log in, please.