Живой пример применения гибкого подхода к разработке ПО в российском стартапе


    Привет, хабрадруг. Считаешь ли ты, что waterfall (каскад) при разработке ПО — это единственный расово-верный подход? Да или нет — спеши под кат.
    Мы, например, для разработки своего web-сервиса SmartNut используем scrum с техническими практиками eXteme Programming внутри. Как иначе мы бы смогли доставлять клиентам бизнес-ценности каждые 2 недели (релизный цикл). Считаю, что нас можно отнести к ребятам, делающим Lean Startup.

    Scrum c XP использовались и в моей прошлой команде, но здесь мы развиваем тему более продуктивно.
    Постараюсь коротко рассказать вам основные техники scrum и XP, которые мы сумели внедрить, поддерживаем, изменяем и улучшаем для увеличения эффективности.

    0. Наша команда


    Product owner (PO), team, scrum master, всё как в книжке. PO — владелец продукта, ответственный за истории и приоритезацию задач. В нашу команду, реализующую требования PO, входят разработчики и тестировщики. Scrum master является членом команды и кроме функций scum master’а является ещё и разработчиком продукта.

    1. Итерации


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

    Насколько же мы гибки на каждом из этапов реализации проекта?

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


    У нас есть product vision, на основании него периодически создаются планы на релиз. Релизом считается некоторый набор функций, которые могут быть реализованы за какое-то конечное время, и имеющих наивысший приоритет для доставки клиентам на данный момент.
    Планирование таких релизов позволяет видеть «генеральную линию» развития нашего продукта. Не все задачи из этого релиза будут реализованы, главное — это направление.

    Микрорелизы выпускаются каждые 2 недели.
    Product owner пишет истории к началу итерации. Чтобы они были гладкими и шелковистыми, PO должен посвятить обсуждению историй с командой некоторое количество времени в предыдущей итерации, что он и делает. Некоторые постановки принимаются, в некоторые вносятся изменения, а некоторые откладываются до появления реальной необходимости в их выполнении.
    Например, есть две задачи: первая добавляет новую функциональность, а вторая — развивает её или улучшает юзабилити.
    Если мы сомневаемся, что первая задача «выстрелит», т.е. принесёт какую-то ощутимую пользу нашим клиентам, то мы можем отложить вторую задачу — до сбора статистики и получения обратной связи.

    2.5 Оценка



    Мы убедились на собственном опыте и знаем, что индивидуальная оценка в днях и часах очень неточна. Поэтому мы оцениваем в баллах и очках с использованием Planning Poker для обеспечения независимости оценок. Это, кстати, ещё и весело!
    Из интересного: раньше мы всегда пытались прийти к единой оценке. Но Jeff Sutherland (на фото) предлагает решение с расчётом среднего арифметического, если все игроки выбросили карты, которые идут подряд в ряде Фибоначчи.

    3. Условия труда


    Для нашей команды выделен отдельный большой и светлый кабинет. Ничего не мешает нам обсуждать задачи, проводить митинги, искать и ликвидировать препятствия. Каждое утро в 11-30 мы проводим стендап митинг, который в лучших традициях длится 15 минут. Мы считаем скорость и стараемся, чтобы она всё время росла, не считая рост самоцелью.
    Посидеть рядом с программирующим коллегой не считается преступлением. Помощь в решении инфраструктурных задач и проблем с окружением считается почётной работой.

    4. Дизайн системы


    Самое сложное — вести разработку так, чтобы система была простой и понятной как для конечного пользователя, так и для всех программистов команды. Если фича не очевидна, если 2 человека из коридора не могут, сев за компьютер, раскусить, что же задумал PO или разработчики, значит нужно что-то менять. Мы, как команда, двигаемся в направлении простоты, не всегда это получается, но мы стараемся.
    То же относится и к функциям, потребности в которых рынок ещё не показал. Очень хочется добавить их, вроде бы это и просто и нужно, но кто ими будет пользоваться?

    5. В процессе разработки


    Если возникают вопросы по постановкам, то сидящий в нашем кабинете Product owner может ответить на все из них.
    У нас есть стандарты написания кода, что позволяет смотреть на чужой код как на свой без лишних эмоций.
    TDD мы не используем. Тесты пишутся после написания кода, а так же — на найденные ошибки.
    Мы используем Jenkins для Continious integration процесса. Если Jenkins получает сигнал, что код в svn обновился, то проходит автоматическая сборка проекта. Запускаются тесты, запускается статический анализатор кода. О негативных результатах, если они имеют место быть, оповещаются люди, чьи изменения попали в сборку.
    В связи с отсутствием парного программирования в явном виде, мы проводим процедуру code review. Проведение CR является критерием готовности задачи.
    Каждый имеет право вносить изменения во все части системы, что повышает ответственность и уменьшает вероятность пропуска недочетов.
    Кроме unit-тестов, у нас есть и приёмочные тесты на основные функции системы, которые так же проходят после обновления кода в репозитории.

    Ещё один критерий готовности задачи — протестированность и проверка на соответствие постановке до коммита. Когда разработчик считает, что задача готова, он отдаёт её на тестирование. Тестировщик проверяет задачу и только после того, как он удовлетворён качеством и полнотой, задача может считаться выполненной. Это позволяет экономить время на переключении между задачами и заливать код в репозиторий уже в оттестированном виде.
    Эта процедура не исключает приёмочного тестирования перед выкатыванием релиза тестировщиком и Product owner’ом после завершения каждой истории, которая может состоять из нескольких задач.

    Для достижения максимальной продуктивности в команде разработки должно использоваться максимальное количество практик XP, к чему мы стремимся. Но нельзя забывать и о полном наборе практик командного framework’а Scrum.
    Scrum говорит, что одной из задач scrum master’а является выяснение и ликвидация препятствий. До последнего времени мы мало задумывались о коренном улучшении процесса. Хотя в техниках scrum для этого предусмотрен специальный митинг — ретроспектива, на которой нужно смотреть назад, искать препятствия и закреплять использованные положительные практики. Сейчас мы проводим ретроспективу каждую итерацию и используем листы A3 (а три) для выявления узких мест в процессе.

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

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

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


    P.S. Если ты, хабрадруг, ещё считаешь, что то, что мы делаем идеологически неверно или наоборот хочешь похвалить, то добро пожаловать в комментарии.
    ITSM 365
    0,00
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

      0
      Два вопроса:
      1. Основной язык (фреймворк) разработки.
      2. Почему не используете TDD/BDD?
        +3
        1. Мы пишем на Java (Spring, GWT).
        2. На этот вопрос трудно ответить. Наверное потому же, почему мы в полной мере не используем парное программирование, о чем я писал в предыдущей статье habrahabr.ru/company/itarena/blog/133016/. Но и здесь мы движемся — пишем тесты, хотя и не перед кодированием.
          0
          disclaimer: «Я еще не волшебник, я только учусь». И скрам мы только думаем вводить.

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

          Так что я думаю, что с TDD начинать не надо. Есть множество более простых техник, которые быстрее дают ощутимый результат. Ну а потом можно и TDD вводить, для того и ретроспективы придуманы, чтоб все процессы можно было переделывать если надо.
            0
            Поделитесь, пожалуйста, какие книги Вы читали по TDD и более простые и эффективные методики. Мне было бы интересно тоже ознакомиться.
              +2
              ну, конкретно вот это — где рассматривается не «скрам» как единое нечто, а именно набор отдельных практик — «Patterns of Agile Practice Adoption» by Amr Elssamadisy.

              есть бесплатная pdf-ка и более полная книжка на амазоне:

              www.infoq.com/minibooks/agile-patterns
              www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521

              например, вместо TDD (что там называется «Test-First Development») можно применять «Test-Last Development» (не так тру как TDD, но лучше, чем вообще без юнит-тестов). Скорее всего вы так и делаете уже.
              0
              TDD — одна из самых сложных техник? Да что вы, ровно наоборот, TDD — это просто и весело.
              Конечно, бывают сложные тесты, в которых приходится эмулировать поведение внешних объектов, но сложности есть в любом деле. Но в целом TDD — это клёва, в первую очередь для самого разработчика.
            +3
            Меня лично stand-up митинги задолбали через полгода, некоторых коллег еще раньше.
            Стресс с выходом нового релиза (у нас был каждый месяц) — создавал ощущение никому не нужной суеты (все пытались закончить свои задачи вовремя). Через год скрама решили вернуться к обычному планированию — все снова вздохнули с облегчением. Решили просто использовать jpeg-модель с каскадным планированием. Скрам, в этом есть что-то от белки в колесе — невидимое давление на головы людей, которые должны этой головой работать.

              –2
              Скрам хорош на поздних стадиях выполнения проекта — дабы отдать заказчику именно то что он хотел, дав возможность поиграться с недельными-двухнедельными релизами.
                +1
                Мы наоборот считаем, что scrum хорош для нашего проекта именно сейчас (мы ещё в бете) — когда не каждый раз с точностью можно сказать, что именно нужно пользователям.
                При этом, сами пользователи далеко не всегда могут ответить, что им требуется именно сейчас. На словах они могут высказывать какие-то свои фантазии, а после получения функциональности — никогда не пользоваться.

                Т.е. scrum — это защита от ненужной функциональности, неважно от чьих фантазий эта функциональность родилась — от наших или от пользовательских.
                +3
                А был ли у Вас scrum-мастер, пытающийся выяснить причины недовольств? А то, что задачи не были выполнены, возможно, вы, как команда брали на себя непосильные обязательства. Ведь скрам, с ежеитеративным расчётом velocity для того и нужен, чтобы помогать правильно прогнозировать и не бегать с очумелыми глазами перед релизом.
                Не поделитесь, как часто теперь у Вас выходит релиз?
                  0
                  Как человек только что перешедший с релизов 2 раза в неделю на раз в неделю, считаю еженедельные релизы идеальными :-Р Зато не нужно потом выпускать пяток патчей для «того что не успело войти» или «это нужно срочно, следующего релиза ждать слишком долго».

                  При этом ничто не мешает в отдельной ветке работать над проектом 4 месяца, и отправлять его в пре-релизный билд когда практически все готово.
                  +1
                  А как вы боритесь со следующей проблемой?

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

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

                      У нас всё вышеперечисленное гарантировано даёт несколько ошибок, с которыми, как бы это помягче сказать, версию выпускать не хочется.
                        0
                        Во время демо иногда всплывает, но как правило тогда, когда трудоемкость задачи / сроки были определены неправильно. Оно при этом не само всплывает, а как правило человек уже тестировавший этот код показывает где чего. Потому что если демо будет проводить девелопер, они могут аккуратно обойти гиблые места в надежде что дофиксят позже.
                        Если же критичные баги всплывают в последний момент постоянно, то осмелюсь предположить, что тестеры у вас так себе либо требования не расписаны. Потому что обычно все же тестируются самые критичные модули, самая важная функциональность. У нас четко видна закономерность: в начале тестирования вносятся P1-P2 баги, а в конце в основном P3-P4 находятся.
                          0
                          Мы, похоже, не понимаем друг друга.
                          Ситуация предельно проста. Разработчики закончили свои последние в итерации задачи. Это происходит в последние дни итерации. После этого тестер берёт результат и проверяет. Находит критические ошибки. Т.е. появляются критические ошибки в последние дни. Каким образом эти баги могут НЕ всплывать?

                          Или у вас итерация на программирование, а следующая на тестирование? Тогда, конечно, легко сначала смотреть и править критичные модули, а потом другие.
                            0
                            А сколько у вас длится итерация и какого размера средняя задача? И как организовано тестирование — в какой момент и как быстро задача переходит от разработчика к тестировщику?

                            Как описано в статье, у нас задача попадает к тестировщику ещё до коммита. Поэтому в последние дни итерации количество непротестированных задач невелико — только те, что на данный момент в разработке.
                              0
                              А, я поняла. У нас просто когда учитывается задача, которая может быть выполнена в итерацию, выставляются рамки когда должен быть готов код. То есть если релиз в среду, то код должен пройти демо в понедельник, а тестер иметь возможность начать тестирование еще раньше — в четверг минимум (если это не просто изменение дизайна интерфейса). И если программист говорит, что у него написание кода займет всю итерацию, то тогда эту задачу дробят либо релиз переносят в следующую итерацию после выполнения тестирования и баг фиксов.
                        0
                        В интересной книге «Lean Software Development» от идеи до прибыли Тома и Мери Поппендик есть ответ на этот вопрос. Ошибки, как и задачи на разработку чего-то нового нужно приоритезировать. Некоторые ошибки могут быть очень минорными и вообще не попадать в разряд ошибок, а относиться к «хотелкам».
                        В итоге на production практически с нулевой вероятностью попадают высокоприоритетные, критичные дефекты, а на минорные мало кто обращает внимание. Главное — регулярность обновлений с новыми функциями.
                          +1
                          Ну это всё теория. А на практике тестер в последние пару дней может найти пяток ошибок (и находит, зараза), с которыми нельзя выпускать релиз. Как вы решаете эту проблему?
                            0
                            Позволю себе ответить за коллегу.

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

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

                            Ну и сейчас мы стараемся спланировать итерацию так, чтобы на её конец приходились не самые «тяжёлые» задачи, как по времени разработки, так и по количеству изменений. Пока ещё рано делать выводы, но надеемся, что это нам поможет отлавливать критичные ошибки чуть раньше, чем в последние пару дней.
                              0
                              Если быть до конца честными — то ситуации, конечно, бывают всякие.
                              Иногда приходится выпускать «технические обновления» или патчи для исправления супер-критичных ошибок, которые могли существовать в коде уже давно, но вот только сейчас проявиться. Пока что такие ситуации возникали только пару раз и в целом на релизный цикл, итерации, планирования и всё такое прочее не сильно повлияли. Т.е. это именно исключения.
                                0
                                Как раз исключения меня не очень волнуют. Меня беспокоит, когда это происходит систематически. А у нас это происходит регулярно :( И у меня ощущение, что проблема эта методологическая. см. habrahabr.ru/company/itarena/blog/134235/?reply_to=4469150#comment_4469213

                                А то, что можно выкрутится с помощью, например, «субботника» по чистке ошибок — это я знаю. Продукт-то мы всё ж таки выпускаем как-то :)
                                  0
                                  Субботники по исправлению ошибок, слава богу, остались где-то в прошлой жизни :)

                                  Возможно, не все ошибки у вас настолько критичны? Может, стоит попытаться стать чуть меньшими перфекционистами? :)
                                  У нас решение «исправлять / не исправлять» в конце итерации проходит при достаточно жарких дискуссиях. Чаще всего побеждает позиция «лучше обновить сейчас и выкатить новые функции».

                                  Всё-таки, появление очень критичных дефектов перед обновлением — это пока редкость. Вероятно, в этом помогает двойное тестирование: перед коммитом и перед выпуском релизов.
                                    0
                                    Вопрос у меня был методологический.

                                    Методы работы с ошибкой, найденной в начале итерации могут сильно отличаться от тех, что используются в конце. Т.е. бегунок на шкале исправить______похерить к концу итерации начинает смещаться вправо. Не видел, чтобы это как-то учитывалось в методологиях управления проектами.
                                    0
                                    ну, если строго по теории, то в конце спринта проводится ретроспектива. Там обсуждаются причины, почему опять всплывают критические ошибки в последние дни. И, например, может решиться, что проблема с качеством кода, и надо работать в этом направлении — упрощать дизайн и функциональность, code review, парное программирование, TDD, и так далее. Или, может, проблема в другом — velocity не считается каждый день или stand-up meetings не работают, и получается в конце каждого спринта мини-аврал, когда все лезут из кожи вон чтоб успеть. Или еще что-нибудь, вам видней.
                            0
                            И ещё в догонку. Вы бы послали этот пост в категорию Управление проектом или Agile. Может народу больше бы ознакомилось и обсудило.
                              0
                              как быть с читом, когда люди оценивая задачи завышают сроки, а потом спокойно полдня решают свои задачи. Спринт получается заполнен, но по факту загрузка максимум 50%.
                                0
                                А это чисто теоретический вопрос или Вы с этим сталкиваетесь?

                                По моему опыту, программисты, если речь идёт о них, не склонны завышать объёмы работ, с целью выделить время для попинания балды. Я встречался с тем, что они ещё где-то подрабатывают. Но это, если ты в плотном контакте с группой, довольно быстро становится понятно. А дальше оргвыводы, которые зависят от традиций Вашей организации ;)
                                  0
                                  Наблюдаю такую картину время от времени. Понятно что они не всегда пинают балду, иногда занимаются своими делами. Проблема тут еще кроется в том, что даже если ты сделаешь соответствующие выводы, то в белой компании расстаться таким человеком тяжело. (ну или 2 ЗП при увольнении) А на фоне катастрофической нехватки людей на рынке поведение некоторых вообще попахивает чуть ли не шантажом.
                                    0
                                    В таком случае, это не вопрос к методологии :)
                                    По моему мнению, с людьми, которые не хотят работать, надо расставаться. Один такой человек может демотивировать всю остальную команду.
                                  0
                                  уважаемый коллега, одним из способов исключения описанных ситуаций может стать оценка не в реальных промежутках времени, а в относительных (часы, дни -> баллы, очки, story points). таким образом не нужно считать никаких фокус факторов и загрузки, а только velocity. после пары итераций Вы увидите реальную скорость, velocity и в дальнейшем смолжете отслеживать отклонения в ту или иную сторону и делать какие-то выводы.

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

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

                                      тут стучать никому не надо. всё будет видно. команда будет видеть кто, как и что делает. если это действительно команда, то ещё и пытаться помочь. если человек не хочет участвовать в командной работе, то и ему будет некомфортно с командой и команде с ним. тут уже что-то да произойдёт само собой.
                                        0
                                        Хм, похоже я этот момент не совсем понимаю. Вот есть задача А, и задача Б. Задачу Б оценили в 4 балла а задачу А в 7 баллов. Как это ложится на доску с планированием по дням?
                                          0
                                          Вам же нужно планирование по итерациям, а не по дням. Со временем вы поймёте, что выполняете за итерацию задач на 100 баллов, например.
                                          Понятно, что сначала будет переходный период, когда оценивая будете думать «так, наверное задача на 4 балла — это примерно 4 часа». Но со временем это уйдёт.

                                          Одно из преимуществ, например: если разработчик берёт задачу на 8 часов, делает её с утра и заканчивает где-то после обеда, то подсознательно он думает: «окей, на сегодня я план выполнил!». А если он делает задачу в 10 баллов за то же время… то так думать уже просто не получится :)
                                            0
                                            а где можно более подробно почитать про оценку в баллах и как это все организовано?
                                  0
                                  У нас трудоемкость задачи оценивается группой. Разумеется, если это фронт-енд задача, то слово фронт-ендщика имеет решающий вес, но он должен аргументировать почему эта задача сложнее аналогичных в предыдущих проектах. Или наоборот, изменение может быть небольшим, но тут тестер поднимет вопрос, что оно затрагивает всю систему, а автоматизировано недостаточно, чтобы регрешн прошел быстро, и повышает трудоемкость.
                                  Халтурщики обычно хорошо видны, и первый этап — микроменеджмент таких товарищей, второй — увольнение.

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

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