Методология Разработки ПО

Попросили меня на фирме выступить с докладом и рассказать о методологии по которой мы работаем, разрабатываем наше приложение. Я сразу же сказал — «У нас Scrum», и сел составлять презентацию. Но я остановился на первом же слайде, и вот почему.

Agile содержит в себе множество методологий — XP, Scrum, Lean, Kanban, ScrumBut (СкрамНО). Сев разбирать методики, я понял, что не могу сказать, что моя команда работает по какой-то одной из них. В целом наш рабочий процесс можно изобразить так:

image


Как видите, мы используем, множество пунктов из разных методологий, множество — но не все. Мы адаптировали методологии под свой процесс разработки, под свою команду.
Мы используем множество рекомендаций из XP практики, что-то схожее в нашем процессе разработки нашли в методологии Kanban, часть пунктов взяли из Scrum-методологии.Еще, я решил выделить отдельную ось и назвал ее Conferences. Потому, что много полезных идей было взято именно из конференций. Могу сказать, что начинающему Project Manager(y), Team Lead(y) стоит начать с конференций, но не просто прийти и послушать, а подойти к докладчику после выступления и постараться задать интересующие тебя вопросы. Именно так в моей команде появилась страница релиза, командная и личная цель, мои QA-специалисты привезли с конференции такую полезную вещь как импакт-анализ и понятие «тестер-аналитик». Но не будем отвлекаться от главной темы и вернемся к методологиям разработки программного обеспечения.

В основе ведения проекта лежит понятие Sprint и Product backlog, кто знаком со Scrum(ом), тот сразу скажет, что это его главные артефакты. Но в нашей команде нет Product Owner(a), у User Story нет приоритета и нет Story Point(ов). У нас нет Scrum карт для игры в Planning Poker и мы не рисуем Burn down диаграммы, а вместо Scrum-доски мы ведем страницу релиза.
И все это мы не используем не потому, что нам лень или мы не понимаем как это делать, просто в процессе разработки приложения некоторые артефакты отпали. Заказчик не захотел выставлять приоритеты, т.к. для него все задачи важные, мы не стали «заморачиваться» со Story Point(ами), т.к. в спринт могли впихнуть новые задачи. И диаграмму мы не строили, потому, она оказалась не наглядной. Когда нас спрашивают, в процессе разработки, как обстоят дела, мы показываем страницу релиза, которая выглядит примерно так:

image


Когда-то мне посоветовал ее вести Алексей Лупан, он выступал на конференции и показывал, что-то подобное для своего проекта. Я внедрил это в свой проект и это оказалось удобно. На этой странице видно сколько features мы включили в релиз, кто отвечает за каждую feature, в каком она состоянии. Также указывается срок сдачи в тестирование и в Production. Самое важное тут виден список всех критических и очень важных ошибок, на которые нужно обратить внимание перед сдачей новой версии продукта. Такая страница мне нравится тем, что если в проекте больше одного тестера, то я говорю всем — «Тестируйте важные ошибки, и не важно, что они оформлены на кого-то другого, лучше пройтись свежим взглядом. Так можно найти что-то новое». И это работает. Сколько раз у меня были такие ситуации, когда один тестер находил ошибки у другого тестера. Это реально спасает. Конечно, не всегда получается делать двойное тестирование, но по возможности старюсь это практиковать. Тут хорошо срабатывает поговорка одна голова хорошо, а две лучше.

И так, я рассказал, чем мы не пользуемся в Scrum. Ах да, чуть не забыл, мы не проводим каждодневные standup митинги. Мы сидим рядом, на расстоянии вытянутой руки, все что обсуждается — обсуждается рядом с командой, а значит — слышат все. Поэтому митинги проводятся по необходимости. В основном когда этого требует заказчик. Тогда мы печатаем страницу релиза, и печатаем разбитые на подзадачи задачи, со статусом напротив каждой подзадачи и с комментариями в колонке Problems, если таковые имеются.

Вообще, в процессе работы я усвоил для себя две истины:
1. заказчику все равно по какой методологии Вы работаете, на самом деле его интересует конечный результат;
2. если давать заказчику больше, чем он ожидает, он становится счастливее.

Это тоже проверялось не однократно, особенно первая истина, ведь когда в конце релиза обнаруживаются ошибки, то заказчик забывает, что вы работаете, например, по Scrum. У него в голове крутятся такие вопросы: «Когда будет исправлено?», «Кто виноват?», «Почему так получилось?». И заметьте, именно в таком порядке. Вряд ли в этот момент заказчик ждет от вас, что вы начнете играть в Planning Poker, расставлять Story Point и планировать спринт. И velocity его не интересует, даже если оно выросло в два раза по сравнению с предыдущим спринтом. И на графики он тоже не будет смотреть. Поэтому если Вам мешают некоторые артефакты в Scrum или Вы считаете их не очень полезными именно в вашем проекте, не бойтесь их выкинуть, ничего в этом страшного нет. Главное, чтобы Ваша команда продолжала двигаться вперед и была гибкой в плане изменений. Scrum — это своего рода framework, состоящий из отдельных частей. Можно использовать все его части, можно подключать постепенно, а можно и изменить что-то под ваши нужды. В этом мне кажется и есть смысл гибкой (agile) методологии, когда не Вы прогибаетесь под методологию, а методология прогибается под Вас.

Еще одна истина, которая мне нравится, и которая приносит свои плоды — это выделяйте тестерам как можно больше времени на тестирование готового продукта, а также давайте тестерам тестировать промежуточные результаты Ваших трудов. Наверное вторая часть предыдущего предложения является главной. Я всегда даю своим тестерам пощупать сырую версию приложения. Зачем? Для того, чтобы они начали критиковать, сказали, что что-то не удобно, внесли идеи, начали писать тесты для тестирования того, что будет, начали продумывать узкие места в логике, интерфейсе. Это немного достает, но тем не менее приносит свои плоды. Главное не допускайте одной ошибки, о которой я слышал во многих проектах. Ошибка заключается в том, что тестеры и программисты сидят отдельно, а самое главное не общаются на прямую. Т.е. образовывается два вражеских лагеря. Это не правильно, помните, Вы — команда, Вы работаете над одним продуктам, Ваши цели совпадают. Помогайте друг другу, сидите вместе, задавайте вопросы, общайтесь.
Поделиться публикацией

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

    +2
    Зачем вести отдельный документ с добавленными фичами, если есть отчеты в JIRA?
      0
      Мы файл с фичами периодически показываем заказчику. Также файл ведется в Excel и на дополнительных страницах я еще виду разбиение фич на подзадачи, + там же и импакт анализ делается на каждую фичу в спринте, а его в JIRA нормально не нарисуешь. Если б не импакт анализ, то в общем-то можно было все делать и в JIRA или поставить, например VersionOne — как раз для работы по Scrum предназначен. Но JIRA и VersionOne — вещи платные, а заказчику просто удобно смотреть все в Excel, а на треккер он вообще не заходит, ему это не интересно.
        0
        Так ведь не нужно заказчику в JIRA — я же говорю про отчеты, т.е. экспорт. Платная, верно, но есть и бесплатные аналоги. Про импакт анализ ничего сказать не могу — не знаком с этим понятием.
          0
          Про импакт анализ собирался подготовить статью, т.к. не все с ним знакомы. Я и сам узнал о нем недавно, можно сказать, что он у нас в «сыром» виде еще, но определенно работает, и смысл есть.
        0
        Отчеты в JIRA ситуационные.

        Если нужно видеть историю работы, то есть смысл складировать подобные данные в wiki.
        +4
        Иными словами, у вас все как у людей — про методологии слышали, внедряли, что-то прижилось, что-то нет. Одним словом это называется Agile. Хотя найдутся умники, кричащие, будто это lean. И другие умники, отвечающие, что lean — одно из течений agile

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

        Больше всего добивают те горе-специалисты, которые вцепляются в одну методологию, а потом начинают орать на команду всякий раз, когда кто-то хоть чуть-чуть отклоняется от заданного процесса. Насмотрелся я на таких скрам-храм-трам-барам-мастеров! Обычно такие вырастают из неинженерных направлений (BA, QA, HR), а вчерашние инженеры наоборот часто тяготеют к таким вот lean-подходам, т.к. часто воспринимают задачи, связанные с управлением, как оверхед — необходимое зло, которое нужно свести к минимому. Истина, как всегда, где-то посередине и зависит от конкретного случая.

        А еще я автора знаю, поэтому обижать не хочется, но если притвориться, что мы не знакомы (ага?), то я бы добавил:

        Уважаемый, во-первых одно капитанство. Львиная доля написанного очевидна даже для тех, кто не то, чтобы проектами не управлял, а вообще не тимлидил ни разу. Много воды и статья ни о чем.

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

        Попробуйте наоборот поступить — не показывайте «источники вдохновения», а покажите сами практики, которые вы переняли. Например, канбан славен тем, что ограничивает объем задач, находящихся в процессе. Если много задач находятся в стадии work-in-progress, то новую задачу начинать запрещено. У вас такой лимит есть? Если да — отображайте. Нет — выбрасывайте. Или, например, стендапы из скрама: есть они у вас — пишите, нет — не пишите. И в результате будут не круги, а список практик, соответствующий разным аспектам ведения проекта.

        По списку практик уже можно сравнивать подходы в управлении. А то выходит такое, что один говорит:
        — У нас скрам, поэтому мы делаем A!
        А другой ему отвечает:
        — И у нас скрам, именно поэтому мы A не делаем!
        А вы сидите и думаете: «кому из них верить?»
          0
          Спасибо за столь длинный комментарий, статью написал, чтобы отзывы послушать. так что какие уж тут обиды? а вот по поводу знакомства… что-то не припоминаю я…

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

          Львиная доля написанного очевидна даже для тех, кто не то, чтобы проектами не управлял, а вообще не тимлидил ни разу. Много воды и статья ни о чем


          Может быть очевидна для тех, кто уже читал хоть что-то про методологии, согласен.

          Какие-то круги-круги-круги


          Извините, вспомнил универ, графики. Был вариант со списком под каждой из методологий, но он показался мне не красивым.
          0
          Порекомендуйте, какую литературу стоит почитать, чтобы ознакомиться с понятиями, используемыми в статье.
            0
            Для начала почитайте вот эти:

            1. Хенрик Книберг. Scum и XP: заметки с передовой как мы делаем Scrum.
            2. Мартин Фаулер. Экстремальное программирование.
            +2
            Это все потому что пиши-код-блять.рф/
            0
            почитал — обзавидовался. У нас типа скрама и даже пытаемся выдержать побольше его практик, НО при этом тестировщиков нет, архитектора нет, тим и тех-лидов у бэкенда тоже нет. И вроде бы заказчик понимает, что архитектор и тестировщик нужны и даже менеджера тестировщиков наняли (сидеть рядом? Ха, да они вообще в другой стране будут), но уже много месяцев всё делают девелоперы. А в знак признательности (видимо) нас заставляют переписывать систему на Друпал, несмотря на негативное отношение всех разработчиков к этой идее.
              0
              есть примеры команд, их не много, но есть, в которых нет тестировщиков. В таких командах все покрывается TDD, BDD, ATDD, DDD и всякими другими ...DD (и придумали же)
              Не стоит выдерживать все практики в скраме, если не получается, значит откажитесь от какой-то из практик. Есть еще понятие ScrumBat(или СкармНо по нашему). Это когда вы говорите, мы используем скрам, но не используем…, потому что… Можно почитать здесь scrumbat

              Покажите заказчику Тест Джоэла: 12 шагов к лучшему коду может он проникнется и попытается создать вам все условия. Если заказчик заинтересован в улучшении процесса разработки, то шагов 10 (а может и 11) он вам постарается сделать, это не дорого и не очень сложно.
              0
              спасибо за интересные ссылки. По тесту Джоэла у нас 5, но будет 4, т.к. нас переселят в другую комнату, к другому проекту. Однако над некоторыми пунктами мы работаем (2 и 3), но 10 — это нереально в нашем проекте, на мой взгляд.
              Надо взять на вооружение идею про БД ошибок. Что-то такое витало в моих мыслях, но тут неплохо описано.
                0
                Если будет 10 или 9, то это уже хорошо. у нас на проекте год назад было 5, сейчас 10, собираемся поднять планку еще выше. Если у вас появятся тестировщики, то это уже +2 пунка, они без БД ошибок не работают, ну а все остальное — дело наживное.
                0
                Какую методологию посоветуете, если разработчик — «человек-оркестр»?
                  0
                  Так не от разработчика зависит, а от заказчика. Разработчик может быть и «человек-оркестр», а играть должен все равно по правилам заказчика. Заказчику в основном нужны релизы и как можно чаще, и чтоб по-больше новой функциональности было. Выбирая методологию разработки нужно смотреть на то, как вы работаете с заказчиком, если он любит, чтоб все сначала было спланированно, взвешенно, диаграмма нарисована, дизайн продуман, а потом только к коду приступать, то тут лучше водопадную модель использовать. Если заказчику все равно, то я бы за основу взял Scrum, т.к. здесь вы себя страхуете практически со всех сторон. Вы часто выпускаете релизы, заказчик может посмотреть на функциональность и внести изменения, когда еще не так много спроектированно и есть возможность легко что-то поменять. Плюс вы можете, на основании нескольких релизов, просчитать среднюю производительность команды и более точно спланировать следующий релиз. Еще у вас в Product backlog будет куча заданий с приоритетами и со Story Points, так что сможете распланировать на несколько релизов вперед.

                  Например, в нашем проекте, я не могу сказать, что использую Scrum, т.к. половина из него не прижилась, но за основу мы взяли Product BackLog, и внутренние релизы мы планируем сроком на 1-4 недели, заказчик же получает релиз раз в 2-3 месяца. Т.е. у нас получается такое понятие как спринт в спринте. Пробуйте из разных методологий выбрать то, что подходит для вашего проекта. Ведь все еще зависит от количества человек в команде, соотношения тестеров и программистов, сложности задач и др. факторов.
                    0
                    Спасибо.
                      0
                      Так же советую вам сделать следующие вещи (тут наверняка накапитаню). Если у вас нет времени сделать их самому, попросите кого-то другого (закажите и заплатите, если никто просто так не берется). Вам нужно следующее:

                      1. Система контроля версий, разрешающая создание быстрых бранчей. Операции «создать бранч» и «слить бранч» должны быть мгновенными — это самое главное. Git или Hg вполне подойдут. Это важно, т.к. вам как человеку-оркестру очень важно в любой момент, не теряя времени, иметь возможность переключиться с задачи на задачу. Клиет позвонил, что-то попросил, вы тем временем работали над чем-то. Быстро создали бранч, стали работать над более приоритетной задачей. Сделали, показали мклиенту, он доволен, переключились в старый бранч, продолжили работать над предыдущей задачей. Без ожиданий, проволочек и проблем с мерджем. SVN, CVS, TFS так не умеют.

                      2. Настройте Continuous Integration. Каждый раз, когда коммитите изменения, должен прогоняться билд с тестами: что-то сломалось — вы об этом уже знаете. CI-сервер должен деплоить приложение. Например, заказчик попросил, что-то сделать, вы сделали и закоммитили, билд тут же прошел — вы можете показать сделанную работу заказчику.

                      3. Имейте кроме системы управления проектатми отдельный to-do-лист. Например, есть у вас с заказчиком в Гуглодоксах таблица с беклогом, таблица с багами, отдельные таблицы на каждую итерацию, мб бактреккер какой-то использовать будете — не важно! Все равно сделайте отдельный тудулист на день. С утра прежде чем начать работу, решите, что вы будете делать, в каком порядке и т.п. Для вас это будет заменой традиционного ежедневного стендапа. Да и в течение дня поможет вам оставаться сфокусированным. Обязательно ставьте отметки, когда вы завершили ту или иную задачу — будет чувствовать себя классным парнем, а в работе это очень важно. Вечером оставляйте список открытым, чтобы утром первым, что вы видели на экране, был ваш список. Он должен стать для вас основным рабочим инструментом наравне со средой разработки.

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

                          Когда человек работает в одиночку, то какой ему прок от Joel-теста? Тестеров у него нет, спека при каждодневном и итеративном общении с заказчиком не очень-то и нужна, средства разработки у него тоже свои, а не «самы лучшие, какие только можно купить», ну и т.д.

                          Joel Test — это не панацея. Почитайте вопросы на сайтах StackExchange по соответствующему тегу, например. Большинство людей принимают его, но с оговорками.
                            0
                            вот про спеку не соглашусь. сколько уже было ситуаций типа "… а помните год назад я заказывал..." или "… я не то совсем имел ввиду, вы сделали не правильно.." И докажи потом, что ты прав. Иногда спасают письма в таких ситуациях, если, конечно, их никто не поудалял. Но лучше всего после обсуждения какой-то функциональности нарисовать пару скринов, хотябы в том же Paint, оформить в презентацию с комментариями и еще раз зааппрувить, а потом выложить на треккер, чтоб не потерялось. Спека — идеальный вариант вообще будет.

                            И то что не панацея, соглашусь, наверное, но все зависит от специфики проектов. Могу сказать только, что год назад без пары пунктов из теста Джоэла было все таки сложновато. И сидели в разных местах, например, и работали в openspace, где шумно было, и спек небыло и тестеров, и т.д… Пока пришел к выводу, что чем больше пунктов из этого теста есть, тем лучше. Хотя вот есть команды которые работают, например без тестеров вообще, можно послушать Николая Алименкова, например, он рассказывает про один такой случай, и вроде все у них в порядке.

                            человек спросил о методологии, думаю, чем больше он почитает о скраме, хр, 12-и шагах, тем проще ему будет к чему-то прийти.
                              0
                              Спасибо вам за вашу дискуссию — много почерпнул!
                  0
                  Как думаете, в какие сроки можно комфортно перевести группу разработчиков из 5 человек на Agile?
                  Сейчас в работе не используется ничего, кроме mercurial. Задачи формулируются устно каждому разработчику отдельно от 3-ёх человек, иногда задачи пересекаются.
                    0
                    Наш переход происходил в несколько этапов. Сначала мы добавили ведение спецификаций. Спецификации приживались у нас месяца 2, потом это вошло в норму. Далее мы начали играться с длиной релизов, выпускали сначала два раза в неделю, раз в неделю, раз в две недели, раз в месяц, раз в два месяца, раз в три месяца… Определили, что раз в 3-4 недели таки оптимальный вариант, где все довольны: клиент с релизом без ошибок, команда в конце релиза бодрячком. Ввели standup митинги два раза в неделю. Потом ввели Product Backlog поигрались с важностью и Story Points… и… убрали их через два релиза. Потом добавили ретроспективу, которая стала проводиться раза два в неделю с фразами «А давайте ка сделаем/улучшим/поменяем/добавим… ». В общем можно сказать, что уложились мы где-то в пол года, когда уже наигрались с длинами спринта. И это был наш первый опыт перехода на Agile. Для перехода мне хватило прочитать эту книгу

                    Хенрик Книберг. Scum и XP: заметки с передовой как мы делаем Scrum.

                    и сходить на парочку конференций, чтобы задать вопросы.

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

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