Agile development

Термин бережливого производства (Lean) в настоящее время на слуху. Мы все знаем результаты применения данной идеи в компании Toyota, которые позволили выпускать малые партии комплектующих точно в срок (Just-In-Time, JIT).

В книге Microsoft Secrets (1995 года) авторы (Кузумано и Ричард Селби) описали подходы контроля качества схожие с Lean применяемым в Toyota.

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

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

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

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

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

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

Отправная точка

Изначально в команде применялась несколько упрощенная методология Scrum. Ниже приведу ее описание.

Набор артефактов:

1. Project backlog журнал требований, реализуемых в рамках проекта, обнаруженные в процессе эксплуатации инциденты. Обычно требования оформляются в виде User Story. В качестве инструмента для верхнеуровневого планирования использовали Excel. Там же, для удобства, чтобы все было в одном месте, на отдельной странице сделали диаграмму Ганта и диаграмму сгорания.

2. Sprint backlog журнал требований и инцидентов реализуемых за спринт.

3. Scrum-доска. В качестве инструмента использовали доску Trello с расширением Plus For Trello для контроля трудоемкости.

Роли в команде:

1. Руководитель проекта сотрудник, который планирует процесс реализации требований, координирует действия всех участников, вплоть до завершения проекта.

2. Scrum-мастер обычно тимлид группы разработки, занимается управлением процесса разработки, несет ответственность за конечный результат работы разработчиков.

3. Команда разработчиков состоит из опытных разработчиков и новичков, которые повышают свои компетенции в процессе участия на проекте.

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

Совещания:

1. Ежедневный митинг команды.

2. Ретроспектива в конце спринта.

3. Ежеквартальные ретроспективы.

Параметры спринта:

1. Продолжительность: 1 месяц.

2. Ежедневные обновления продуктивной системы по итогам завершения работ по блокам задач.

Данный подход использовался на большинстве проектов, динамика при использовании была положительная.

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

Хьюстон, у нас проблемы

Явные проблемы заметили на втором месяце этапа ОПЭ (опытно-промышленной эксплуатации), когда новые требования по дефектам начали закрывать время затраченное на запланированные дефекты и пожелания. Фактически мы стояли на месте. Вероятность успеха сделать все вовремя стремилась к 0.

Для исправления ситуации было решено провести экстренную ретроспективу и собрать все существующие проблемы.

Удалось выявить следующие точки улучшения:

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

2. Недостаточное качество итогового кода, требуется повысить контроль качества.

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

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

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

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

А что думает заказчик? Заказчик недоволен динамикой реализации требований. Но готов рассмотреть вариант с четким и прогнозируемым планом.

Именно в этот момент появилась идея использовать подход JIT для улучшения текущей ситуации.

Какие преимущества Agile-Lean мы попробуем использовать в нашем проекте

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

Сильные стороны:

1. Получение результата в ограниченное время.

2. Устранение ненужных действий, которые могут снизить стоимость.

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

4. Гибкость проекта, возможность его корректировки под требования заказчика.

Слабые стороны:

1. Большие требования к вовлеченности команды в процесс.

2. Строгая документация, что несколько противоречит принципам Agile, когда продукт важнее документации.

3. Необходимость детального планирования перед каждым спринтом.

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

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

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

Адаптируем 7 принципов Lean

Согласно методологии Lean для разработки программных продуктов, выделяется 7 основных принципов:

• Исключение потерь. Потерями считается все, что не добавляет ценности для потребителя: излишняя функциональность; ожидание (паузы) в процессе разработки; нечеткие требования; бюрократизация; медленное внутреннее сообщение.

• Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

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

• Предельно быстрая доставка заказчику. Короткие итерации.

• Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.

• Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

• Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. Мыслить широко, делать быстро, ошибаться мало; учиться стремительно.

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

1. Убрать ненужное

Под ненужным будем понимать следующее:

1. Все, что не приносит пользы конечным пользователям. Сюда относятся непонятные и несрочные требования, редко проявляющиеся дефекты. Мы их откладываем или отказываемся вовсе после согласования с заказчиком.

2. Ненужный код, дублирование кода.

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

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

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

Что мы сделали, чтобы решить задачу:

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

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

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

4. Формирование задач из набора требований в рамках одного реализуемого процесса. Расчет: разработчик загружен на одну задачу не менее 8 часов.

2. Создавать знания и обмениваться ими

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

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

3. Повышение качества кода

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

Для повышения качества были приняты следующие предложения:

1. Парное программирование. Непосредственное взаимодействие тимлида с разработчиками, совместный анализ требований, проектирование, решение сложных задач.

2. Степень готовности (Definition of Done, DoD). Задача считается завершенной только в том случае, когда разработчик обсудил реализацию с тимлидом и провел демонстрацию разработанной функциональности консультанту, который закреплен за данной задачей.

3. Максимальное количество задач в работе (Work In Progress, WIP) каждого разработчика. У разработчика в работе и в тестировании суммарно не может быть больше 3-ех задач. Если разработчик отправил на тестирование все 3 задачи, то он обязан довести эти задачи до публикации в продуктивную систему, для этого активно взаимодействует с консультантами, отвечает на возникающие вопросы, помогает в процессе тестирования.

4. Сокращение спринтов

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

Поэтому решили сделать ряд ограничений на спринт:

1. Спринт длится 1 рабочую неделю.

2. На спринт планируется трудоемкость, которую сможет закрыть команда разработки (на основе собранной статистики за предыдущие cпринты). Дополнительно закладывается время на устранение критических дефектов.

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

4. Публикация на продуктивный стенд выполняется только один раз в последний день спринта.

5. После каждого спринта собирается сокращенная ретроспектива на 30 минут для сбора фидбека с команды.

5. Расширение полномочий команды

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

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

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

6. Не торопиться с принятием решений

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

Решение принятое под воздействием эмоций может породить к большому числу проблем.

7. Регулярная оптимизация процесса

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

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

Для реализации данного принципа с тимлида команды разработки были сняты все задачи по разработке и переданы команде, объем задач на спринт был сокращен, т.к. команда разработки фактически ослабла.

Тимлид команды теперь выступает в качестве наставника:

1. Организует периодическое обучение, разбор сложных ситуаций.

2. Инициирует передачу опыта между разработчиками.

3. Помогает консультантам в формировании требований, а разработчикам в реализации этих требований.

4. Занимается развитием разработчиков и расширением их компетенций.

5. Занимается подбором и развитием инструментария, повышающего эффективность процесса разработки.

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

Основная проблема бережливого производства отодвигание сроков

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

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

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

Итоги

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

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

Но в любом случае необходимо взрастить эксперта среди ваших сотрудников. Он будет сосредоточен на улучшении процесса разработки и мотивирован в повышении своих навыков и навыков команды разработки.

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

1. Обеспечить единую общую среду общения и обмена знаниями.

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

3. Не пренебрегать неформальным общением.

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

По итогам внедрения Lean получили следующие количественные изменения:

1. Скорость разработки стала прогнозируемой и составила примерно 4 крупные задачи (до 6 часов на задачу в среднем) на сотрудника в неделю, ранее мощность команды в среднем составляла до 2-3 завершенных задач в неделю на сотрудника. Да, задачи крупные и это не совсем по Agile, но это помогло в нашей ситуации.

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

3. Уменьшилось вдвое количество задач, возвращаемых на доработку.

4. Еженедельно закрывалось по 3 крупные задачи из техдолга.

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

Данный опыт планируется транслировать на другие проекты компании.

Спасибо за внимание, коллеги! Хотелось бы увидеть в комментариях ваш опыт использования Agile-Lean (или их адаптации) на ваших проектах.

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

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

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

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

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

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

• Проектная структура ведет к зависимости группы людей от одного проектного менеджера, который в 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 в командном беклоге