Нужна ли новая методология разработки?

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

Я взял на себя наглость и попробовал объединить полезные вещи от известных методологий, а также добавил своего опыта и советы друзей. В любом случае, оставлю это здесь, может быть кому-то это принесет пользу.

Предпосылки к созданию методологии

Рассуждения о современных методологиях и человеческой природе

У современных методологий, в порядке их возникновения, есть множество недостатков:

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

• Проектная структура ведет к зависимости группы людей от одного проектного менеджера, который в 95% случаев из 100% некомпетентен. Нацеленность на короткие “проекты”, приводит к удорожанию продуктов с течением времени

• В матричную структуру (все три вида), по определению, заложен конфликт, что изначально неэффективно

• В проектной и матричной структуре также наблюдается большое недооценивание тестирования

• В SCRUM (agile) методологии зачастую есть Product Owner, который стремится стать проектным менеджером, для чего ему могут отдать в подчинение аналитика, чтобы повысить его значимость. Ровно также, если есть амбициозный или конфликтный сотрудник команды, то это все разрушает

• Низкая роль аналитики и тестирования в agile также не идет на пользу продуктам компании

• В agile методологиях практически отсутствует возможность заключать контракты по фиксированной цене при старте проекта

Рассуждение о человеческой природе. Если задуматься, то людей можно разместить на шкале желания работать следующим образом:

• Хотят работать и мотивированы

• Хотят работать без видимой причины, просто потому, что должны

• Хотят работать, потому что считают что получают за это деньги

• Не хотят работать, но боятся осуждения и наказания

• Не хотят работать и работают меньше, но скрывают это

• Не хотят работать и работают сильно меньше, скрывают это

• Не работают, сидят тихо, боятся, что их поймают

• Не работают и открыто это декларируют, осуждают работающих сотрудников

Первые “лидерские” методологии направлены на то, чтобы заставить немотивированных и ленивых сотрудников работать. Agile методологии направлены на поощрение работоспособных и мотивированных сотрудников. А что вам делать, если у вас появился весь спектр сотрудников?

Что мы хотим получить:

1. Методологию, которая ориентирована не на идеальных сотрудников, а на всех подряд. К сожалению, квалифицированных людей мало. Вы все равно наймете неквалифицированных сотрудников, у вас выхода нет

2. Методологию, в которой максимально минимизирована роль руководства настолько насколько это вообще возможно. Где есть защитные механизмы от появления руководителей там, где их быть не должно

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

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

5. Методологию, в которой можно заключать договоры с фиксированной ценой

6. Не универсальную методологию, которую можно применять на полях марса, на северном полюсе и в лесах латинской Америки, а конкретную методологию для разработки именно комплекса программного обеспечения

7. Методологию, которая включается в себя последние современные методологии и технологии, например, DevOps, автоматизированное построение любой отчетности по проектам и продуктам и т.п.

8. Методологию, в которой, по аналогии с agile методологиями, усилия направлены на похвалу и мотивацию команды

9. Методологию, которая защищается “ядовитых” сотрудников, оставляя в командах только сотрудников, которые готовы работать

10. Методологию с высоким взаимодействием сотрудников различных ролей

11. Методологию, в которой у команды есть лидер, с высокими soft skills и эмпатией,, которому можно пожаловаться или у которого можно отпроситься, который защищает и мотивирует команду

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

13. Методологию, где правильно понимается роль аналитики и тестирования

Зачем нужна аналитика?

Аналитика нужна, чтобы понять ЧТО вы хотите сделать и КАК с точки зрения бизнеса.

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

Если у вас нет аналитики, то у меня к вам вопросы:

1. Ваше приложение решает какую-то потребность бизнеса? Уверены ли вы, что кнопка, которую ваша команда разработки делала несколько месяцев, будет когда-либо нажата пользователями?

2. Как вы понимаете, что нужно в приложении проверить, перед передачей приложения пользователям? А если пользователь заполнит форму немного с другими данными и нажмет вон на ту кнопку, приложение будет работать? Точно?

3. Вашему проекту более 2 лет, я хотел бы узнать обо всех функциях, которые есть в вашем проекте, можете рассказать?

4. Сколько должно пройти времени и проведено встреч, чтобы новый сотрудник узнал ваш проект?

5. Вы хотите сотрудничать с новым крупным заказчиком, сколько сотрудников и с каким опытом вы должны послать к заказчику, чтобы рассказать про проект?

6. Если случится кризис, который заденет вашу компанию, и часть опытных сотрудников уйдет, за сколько времени вы восстановите экспертизу по проекту?

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

Зачем нужно тестирование?

1. Unit тестирование (внутреннее качество)

Основная цель - это пройти по максимальному количеству ветвлений кода при разделении кода на модули. Косвенно достигается улучшенное понимание кода за счет разделения на “модули”, на самом деле это просто снижает когнитивную нагрузку на разработчика (количество вычислений, которые необходимо произвести в голове при решении любой задачи). Также косвенно мы получаем ослабление связанности между модулями, то есть если вы возьмете отдельный модуль, то вы, с высокой долей вероятности, сможете его использовать в другом проекте или заменить на другой модуль.

Как видно из описания, это тестирование делается разработчиками.

2. Интеграционное тестирование (внутреннее качество)

Основная цель - это вызвать внешнее API так, чтобы вызов прошел через все модули начиная от пользовательского интерфейса (если есть) и заканчивая записью/чтением из БД, с правами доступа как на продуктовой среде. Может выявлять ошибки на стыке модулей, например, ошибки передачи данных с backend кода и ожидаемого набора данных в БД. Позволяет отследить ошибки в настройке routing, ошибки при использовании IoC-контейнеров и т.п. Сильно ускоряют разработку, минимизируя ручные проверки разработчиком

Как видно из описания, это тестирование делается разработчиками.

3. Функциональное тестирование (внешнее качество)

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

Важно понимать, что принцип этого тестирования другой. Например, вот один из возможных алгоритмов:

• На основе требований вы создаете классы эквивалентности (Equivalence Classes)

• На основе классов эквивалентности вы определяете количество и сценарий тесте кейсов (test cases)

• Далее вручную (уже реже) или автоматизированно проводится проверка в уже реализованного функционала, в соответствии с тест кейсами

Как видно из описания, это тестирование делается тестировщиками.

4. Регрессионное тестирование (внешнее качество)

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

Как видно из описания, это тестирование делается тестировщиками.

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

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

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

В отсутствии тестирования у компании растут расходы на поддержку проектов. Вместо реализации нового функционала, разработчики тратят время на выявление и исправление уже выпущенного функционала. Соотношение может даже достигать 10% времени на выпуск нового функционала и 90% времени на исправление багов или доказательство, что ПО работает как надо (а иногда и 0%/100%). Компания несет убытки, сотрудники злятся и увольняются.

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

Общее описание

Принципы методологии:

1. Отсутствие менеджеров или их замен под другими названиями

2. Автоматизация управленческих активностей

3. Объединение в команду максимально возможного количества компетенций

4. Наличие строго определенного шаблона требований с заданной структурой, обязательной для заполнения по каждому продукту

5. Наличие ролей и четкое описание обязанностей ролей. Все роли должны быть назначены, даже если в команде один сотрудник. Один сотрудник может разделять множество ролей

6. Продукт на поддержке воспринимается как пассив и на него всегда должны быть траты, вне зависимости от того есть по продукту новые доработки или нет

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

8. Работа вне проекта не ведется

Работа методологии обеспечивается следующими ключевыми моментами:

1. Уменьшение количества страха неудачи, благодаря прозрачности выдачи результата и уменьшения влияния личности людей на ключевые факторы 

2. Так как план перестраивается автоматически, вы в любой момент получаете актуальный план по запросу

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

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

5. Отсутствие людей, который работают на несколько команд. Задания поручаются не людям, а командам. Если есть свободный аналитик или архитектор в одной из команд и его хотят привлечь к этой активности, то эта активность целиком передается в команду

6. Максимальное возможное заимствование хороших вещей из agile методологий, а именно:

• наличие беклогов

• наличие спринтов

• командное планирование

• проведение demo

• проведение ретроспективы

• оценка в story points

7. Важные отличия от agile (SCRUM):

• отделенный от команд product owner заменен аналитиком внутри команды, который ведет как часть требований, так и беклог проектов

• отсутствие работы по методике times & materials

• наличие team leader

8. Существуют две должности генерального и технического директора. Генеральный директор является прямым руководителем всех сотрудников и контролирует финансы, в случае если требуется его вмешательство.  Технический директор решает технические задачи, которые не могут быть решены в рамках команд

9. Если что-то не охвачено методологией, то любой сотрудник может это вынести на обсуждение и решить как поступить в вашей компании, если оно не противоречит принципам

10. У всех user story есть поле «проект», с которого определяется финансирование

11. Методология поощряет использование infrastructure as code

Важность обратной связи в сторону сотрудников:

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

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

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

4. В компании раз в квартал проводится опрос на удовлетворенность тимлидом и техническим директором

Термины и определения

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

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

Команда – базовая единица для планирования в компании. Сотрудники компании объединяются в команды. Вся работа в компании подстраивается под этот факт. В силу разных причин, часть сотрудников нельзя объединить в команду, для таких сотрудников можно сделать исключение

Роль – в компании есть набор «ролей», за которыми закреплены определенные права и обязанности. Роль обязательно должна быть кому-то назначена, даже если в компании один человек. Если одному человеку назначено несколько ролей, то он должен обязанности каждой роли отдельно, для чего есть определенные инструменты позволяющие сотруднику переключаться между ролями

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

Беклога продукта – беклог куда заводятся задачи, относящиеся к развитию системы, но не являющиеся необходимыми для выполнения проекта. Беклог служит для исправления определенных видов технического долга, который будет появляться (инкрементально накапливаемая архитектурная ошибка, замедление производительности и т.п.). Наполняется командой. Контролируется тимлидом

Беклога проекта – беклог, который наполняется задачами необходимыми для реализации конкретного проекта. беклог наполняется аналитиком или командой. Контролируется аналитиком

Беклог команды - беклог, отображающий все user story команды в порядке приоритета. Общий беклог команды отображающий любые активности команды в порядке их приоритета

Примечание: по факту, любой беклог представляет собой срез данных компании в виде user stories. Все эти user story существуют в компании, просто в разное время нужно анализировать разное их подмножество

Роли и обязанности

• Тимлид (внутри команды)

Основная цель:

• Отвечает за то, чтобы производительность продуктовой (feature) разработки всегда была на максимальном уровне

Полномочия:

• Контролирует, что в требованиях отсутствуют части, которые могут в будущем замедлить выпуск нового функционала. Факторы, которые могут замедлить новый функционал: возможное увеличение количества инцидентов от заказчиков; необходимость ручных операций; необходимость привлекать разработку к получению информации в случае проблем и т.п. Может остановить взятие требований в работу, если они нарушают эту метрику

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

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

• Инициирует обсуждение с архитектором о выделении части проекта в отдельный проект, если поддержка одного проекта стала сложна в поддержке и развертывании

Обязанности:

• Смотрит задачи на доске в статусе «усложнение поддержки», где:

  • контролирует, что изменения по задаче не увеличивает затраты на поддержку проекта

  • проверяется достаточное логирование по задаче

  • можно ли уменьшить кодовую базу воспользовавшись сторонней библиотекой

• Выносит на генерального директора рекомендации по повышению должности или зарплаты сотрудников команды

• Хвалит сотрудников на регулярной, ежеспринтовой основе. Отчитывается за это перед генеральным директором

• Ведет беклог продукта

• Контролирует, что никто не выходит за рамки полномочий назначенных ролей

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

• Транслирует в команду информацию о значимости сотрудников и их влияние на решения компании

• Отвечает за старт итерации и за поведение итогов итерации

• Согласует новые технологии с техническим директором, если это приводит к усложнению тестового контура от стандартного контура для компании (например, есть контур разворачивающий код на C#, а команда хочет программировать на Go и это потребует доработки тестового контура, в сторону увеличения поддержки и времени деплоя проекта)

• Если технологии стоят дополнительных денег, они вносятся в план проекта и согласуются генеральным директором. При необходимости дополнительно согласуется с генеральным директором

• Выслушивает жалобы от команды, организует команду на решение проблем или ищет того, кто может это решить

• Отпускает сотрудников, если им нужно отпроситься

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

Ограничения:

• Не является руководителем команды

• Командный архитектор (внутри команды)

Обязанности:

• Смотрит задачи на доске в статусе «Архитектура», где:

  • контролирует, какие методы действительно должны быть публичными в любых классах на всех уровнях

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

  • Контролирует single responsibility principle по всем крупным частям системы

  • Контролирует ослабление связанности между библиотеками/компонентами

  • Отслеживает появление условных ветвлений в коде и, если они неуместны, то рекомендует паттерны состояния или стратегии

  • Проверяет, что в БД в столбцах хранится именно то, что следует из названия

  • Смотрит должно ли значение быть вынесено в настройки для изменения в отсутствии пересборки проекта или быть помещено в код для уменьшения роста количества настроек

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

• Ведет секцию в общем документе требований по секции архитектуры

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

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

Ограничения:

• Не является руководителем команды

• Разработчик

Обязанности:

• Смотрит задачи на доске в статусе «code review»

• Участвует в выработке требований

• Разрабатывает программу

• Пишет unit тесты и интеграционные тесты

• Участвует в доработке тестового фреймворка для тестировщиков, упрощая автоматизацию тестирования

• Добавляют задачи для user stories при планировании или user stories в технический беклог

Тестировщик (внутри команды)

Обязанности:

• Участвует в выработке требований

• Пишет тест кейсы

• Автоматизирует тест кейсы на основе тестового фреймворка, который пишут разработчики

• Отвечает за контроль, что ПО удовлетворяет минимальному внешнему качеству

• Аналитик (внутри команды)

Обязанности:

• Общается с заказчиком

• Привлекает команду к выработке решения по требованиям заказчика, если в этом есть необходимость

• Участвует в выработке требований

• Отвечает за систематизацию того чего на самом деле хочет заказчик (не с тем, что говорит заказчик) в виде части секций требований

• Ведёт беклог проекта

• Делает приоритезацию

• Устанавливает на user stroy признаки required, desired, optional

• Фиксирует всю информацию при общении с заказчиком  или в требованиях или в скоупе проекта

• Определяет стейкхолдеров со стороны заказчика (кто на самом деле влияет на проект со стороны заказчика)

Ограничения:

• Не является руководителем команды

• Документалист (внутри команды)

Обязанности:

• Пишет выходную документацию по проекту, цель которой снизить возможную поддержку проекта со стороны разработки

• Отвечает за перевод документации на разные языки

• Технический директор (вне команд)

Обязанности:

• Отвечает за отсутствие дублирования решений в проектах

• Наделяется функцией enterprise архитектора

• Инициирует поднятие версий сборок по проектам, а также отвечает за беклог на выделение части системы

• Формирует задачи по плану обновления, которые включаются в беклог активностей компании

• Утверждает новые технологии в перспективе усложнения работы тестового контура

• Проводит отчет перед сотрудниками раз в квартал

Ограничения:

• Не является руководителем команды

• Не отвечает за найм и не участвует в этой активности

• Генеральный директор (вне команд)

Обязанности:

• Отвечает за финансовые показатели компании

• Отвечает за прибыльность

• Принимает решение о повышении должности или зарплаты сотрудника на основе рекомендаций тимлида, если это сотрудник команды

• Для сотрудников вне команд, решения принимаются непосредственно генеральным директором, при индексации зарплат, например раз в полгода или год

• Отвечает за финальное собеседование. На собеседовании определяется соответствие statements компании и определение роли по DISC. В случае занятости может делегировать эту роль компетентному сотруднику HR

• Принимает решение в случае, если после изменения скоупа показатели проекта нарушились, и план не был исправлен командой вовремя

• Опрашивает тимлида на предмет появления “ядовитых” сотрудников, выводит их за пределы команд и позже за пределы компании, основываясь на результатах полугодовых аттестаций или используя другие методы, в соответствии с законодательством конкретных стран

• По возможности, находится в одном пространстве с сотрудниками или в кабинете, из которого можно наблюдать “курилку”

• Контролирует по отчетам, что задачи тех.долгов не превышают заложенный процент в продукте

• Проводит отчет перед сотрудниками раз в квартал

• Команда

Обязанности:

• Отвечает за сроки, которые фиксируются после составления плана

• Организует процессы DevOps в соответствии с требованиями

• Производится командная оценка задач

• Команда следит за тестовой инфраструктурой (мониторит делаются ли бекабы баз, есть ли свободное место на дисках, достаточно ли ресурсов на тестовых контурах)

• Оценка работы технического директора на основе запрашиваемого опроса раз в квартал

• Оценка работы тимлида на основе запрашиваемого опроса раз в квартал

• Вне ролевые должности

Есть ряд должностей, которые находятся вне ролевой модели. Например, системный администратор (администрирование багтрекенга, настройка электронной почты)

Работа над проектным беклогом. Планирование проекта

1. Определение потребности создать проект. Для этого можно использовать разные подходы:

• выдвигаем гипотезу, которая требует проверки

• получили запрос от заказчика на реализацию проекта

• получили пожелание по доработке существующего проекта

• вышли с идеей создание нового внутреннего проекта в компании

2. Проект начинает планироваться в отдельной итерации

3. Создается карточка проекта, которая свяжет все user stories одним проектом

4. После создания карточки проекта, выставляется признак начала работы над новым проектом. При этом уходит нотификация к генеральному директору

5. Генеральный директор ставит разрешение на начало аналитических работ

6. Определяются команды, которые будут задействованы в проекте. На каждую вовлеченную команду создаются user story на сбор первичных данных по новому проекту и user story на получение экспертной оценке работ. Для любого продукта создаются требования. Шаблон требований можно посмотреть в Приложении 1.

7. Создаются user stories на заполнение специальных секций требований архитектором и тимлидом

8. Требования будут меняться, поэтому нет смысла их прорабатывать до совсем мелких деталей. Однако детализация должна быть на достаточном уровне, чтобы можно было посмотреть общий объем работ

9. User stories по аналитике  и первичной оценке оцениваются командой в SP, в соответствии с Приложением 2, и переводятся в итерацию команд

10. При помещении задач в итерацию команд, будет пересчитан отчет по milestone в соответствии с Приложением 3. В случае если генерального директора не устраивают сроки работ, он может сделать новую приоритезацию user stories в беклогах команд

11. После завершения аналитики по проекту, принимаются решения:

• Проект признается нереализуемым, противоречащим стратегии развития продукта, не рентабельным и т.п. В этом случае проект на этой фазе закрывается

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

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

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

13. Аналитик создает user story по реализации функционала на основе требований

14. Требования и user story не обязаны соответствовать друг другу. Не нужно создавать отдельные разделы в требованиях, которые соответствуют один в один user story. Требования курируются аналитиком, им же и контролируется, что аналитическая информация полностью отражена в user story. Требования и user story все равно в какой-то момент разойдутся. Важно понять, что требования нужны для хранения информации о последнем статусе продукта в удобном для восприятия и хранения информации для человека виде. А user story нужны для разработки части функционала. Попытка тут сэкономить и объединить эти два понятия позже приведет к более сложному пониманию аналитического документа

15. После создания аналитиком user stories, они оценивается в соответствии с Приложением 2.

16. Если после создания и оценки user story в вас есть user story, превышающие 40 story points, то такие story должны будут разделены в будущем, перед взятием в работу

17. По факту завершения разбиения проекта на продуктовый беклог из user stories выставляется признак завершения создания скоупа задач. Так как в команду входят аналитики, командные архитекторы, разработчики, тестировщики, DevOps, документалисты, то подразумевается, что участники команды следят за тем, чтобы трудоемкость их работ была отражена в оценке

18. При выставлении в карточки проекта признака завершения создания скоупа, происходит автоматический расчет пиковой стоимости проекта в соответствии с Приложением 3.

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

20. Если проект оценен в более 4 месяца работ, то проект делится на части и для каждой части создается своя карточка

21. После этого созданные user story смотрятся в разрезе командного беклога

22. При рассмотрении задач в командном беклоге, они размещаются их в соответствии с приоритетом, определенным командой (если не определен приоритет, то user story по новому проекту размещаются в конце беклога).

23. После изменения приоритезации задач или выставления новым задачам итерации командного беклога, происходит перерасчет отчета в соответствии с Приложением 4.

24. После получения первой стоимости проекта, они фиксируется в отчете как максимальная. В дальнейшем при разбиении user story, переоценке или добавлении новых user story будет делаться переоценка работ в соответствии с Приложением 3.

25. Если в будущем, при работе с user stories, при построении автоматизированного отчета, будет обнаружено, что оценка скоупа user stories по проекту превысила изначальную оценку проекта, то команда будет оповещена о необходимости уменьшить скоуп проекта. В случае если команда не сделала это в течении заданного периода (по умолчанию 2 недели), будет выслано сообщение генеральному директору о необходимости вмешаться

Планирование спринта

Планирование нового спринта в целом происходит так же как и в методологии SCRUM

Закупка оборудования

1. Генеральный директор может запросить данные по закупке нового оборудования

2. Далее должна быть выполнена автоматическая рассылка тимлидам для сбора этой информации по командам

3. При создании нового проекта генеральный директор также запрашивает информацию о необходимых закупках

Приложение 1. Шаблон требований

Описание продукта

Примечание раздела: в данном разделе указывается общая бизнес цель продукта

Внимание: если есть дизайн графической части, то он делается отдельно от требований, без ссылок на страницы прототипа. Связка требований и прототипа делается в рамках user stories.

Функциональные требования

Бизнес цель “<Название первой цели>”

Примечание раздела: тут описываются части продукта имеющие отдельную бизнес цель. Это может быть отдельный раздел пользовательского интерфейса или выставление публичного API. В разделе также описываются бизнес ветвления, например, ожидается, что вы получаете данные из источника А, проводите проверку данных и записываете данные в БД. Логично предположить, что есть успешный путь, когда все хорошо, и есть неудачные кейсы именно с точки зрения бизнеса, например, когда валидация не прошла. Все это описывается в требованиях к бизнес цели. Если есть повторяющиеся в других целях моменты, то они должны быть заново описаны в каждой цели.

Используемые сочетания клавиш

…

Архитектурные детали

Примечание подраздела: тут архитектор описывает верхнеуровневые детали, относящиеся к бизнес цели. Например, как будет выглядеть внешний API или как именно будет реализовываться безопасность передачи данных. Если можно сделать какую-то схему, вместо текста, то лучше разместить схему. Statefull или stateless система, как масштабируется и ведёт себя в многопоточный среде. Как система реагирует на новые изменения?

Особенности поддержки функционала

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

Бизнес цель “Название второй цели”

<тут должно быть описание бизнес цели>

Бизнес цель “Название третьей цели”

<тут должно быть описание бизнес цели>

Личности согласно Алану Куперу

…

Нефункциональные требования

Требования к производительности

…

Требования к безопасности

…

Поддерживаемые устройства

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

Мониторинг

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

Развертывание и обновление системы

Примечание раздела: тут описывается как система должна разворачиваться на тестовых и продуктовой среде. Разворачивается система копированием БД или у системы есть полноценный установщик, или система разворачивается набором скриптов с дополнительными ручными действиями. Если система развертывается с нуля, то какие данные должны быть предзаведены в БД.

Continuous integration

Примечание раздела: данный раздел ведется архитектором или тимлидом. Раздел описывает какие шаги есть при развертывании системы на тестовых средах, какие тесты и как выполняются, как происходит разворачивание системы.

Нефинансовые показатели

Примечание раздела: в этом разделе описываются нефинансовые показатели, которые должны достигаться, например:

• Удовлетворенность пользователей

• Eptda

• Конверсия

• Воронка продаж. Сколько людей заходили на сайт для просмотра ПО и сколько купили

• Сколько одна подписка прожила (сколько людей ушли)

Тестирование пользователями

История изменений документа

Приложение 2. Соответствие SP и часов

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

В данном случае перевод SP в часы, позволяет связать беклог команды с календарем, а значит строить автоматизированные отчеты с планами поставок.

Первая user story выбирается из расчета того, что она будет делаться 4 часа. Таким образом происходит настройка под систему. Далее задачи оцениваются в story points, в зависимости от того насколько они более трудоемкие по прогнозам команды.

Приложение 3. Расчет стоимости проекта

Алгоритм:

1. За основу расчета берутся оценки feature в story point, которые конвертируются в часы согласно Приложению 2.

2. По всем user story проекта считается общее количество часов, если в карточке проекта есть признак начала расчета проекта

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

4. После получения первой оценки от нее берется процент для беклога продукта (15%) и беклога активностей компании (10%). Проценты могут варьироваться, но стоимость беклогов техдолга не может приближаться к цене зачал заказчика и, тем более, превышать его

5. Таким образом получается итоговая стоимость всего проекта, которая фиксируется как максимальная и далее будет фигурировать в отчете

6. Позже user story беклога проекта, превышающие определенное число story point будут разбиваться на более мелкие. Также возможно будут добавляться новые user story. В случае превышения максимальной оценки, при построении отчете будет зафиксировано превышение максимальной цены

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

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

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

10. К стоимости проекта добавляется бюджет на правку ошибок

11. Если нужно купить оборудование или ПО для выполнения проекта, то оно тоже включается в бюджет

12. Кроме того нужно установить коэффициенты для выделения денег на аренду офиса, возможные повышения зарплат, премию и чистую прибыль

Приложение 4. Отчет по milestones

Алгоритм:

1. За основу расчета берутся оценки user stories в story point, которые конвертируются в часы согласно Приложению 2.

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

3. Беклог команды считается приоритизированным

4. Беря за основу производительность команды и оценку в story point можно автоматически рассчитать дату завершения проекта

5. При первом построении отчета, фиксируется определенная дата завершения проекта

6. В случае, если дата завершения проекта сдвигается, высылается уведомление генеральному директору

7. Если генеральный директор не согласен со сдвигом даты, генеральный директор может инициировать изменение приоритетов user story в командном беклоге