​​Методы сбора требований
#сбортребований

Коллективные - участвуют заинтересованные лица (Стейкхолдеры):
° анкетирование
° интервью
° семинары, совещания
° мозговой штурм
° наблюдение (пассивное/интерактивное)
° представитель заказчика в компании разработчика

Независимые - самостоятельная работа:
° изучение существующей документации
° повторное использование спецификации
° анализ системных интерфейсов
° анализ пользовательского интерфейса

Наиболее эффективным при сборе требований будет комбинирование нескольких методов, как тех, что перечислены выше, так и тех, которые в список не попали (если знаете такие, поделитесь, пожалуйста, в комментариях)

​​Анкетирование как один из методов сбора требований
#сбортребований #анкетирование

Анкетирование заключается в составлении листа-опросника, который может состоять из двух видов вопросов:
• Открытые –  свободная форма
ответа;
• Закрытые – выбор варианта ответа из предложенных.

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

Минусы:
° невозможно учесть все вопросы
° невозможно понять все «проблемы» заказчика
° неправильно сформулированные вопросы ведут за собой неоднозначные ответы.

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

Рекомендации по составлению листа-опросника - Открыть

Примером листа-опросника может быть Бриф на создание сайта.

​​​​Мозговой штурм
#сбортребований #мш

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

Принципы и правила применения:
° определить цель
° генерировать как можно больше идей, даже самые нестандартные
° должен выступить каждый участник
° НЕТ - критики, плохих идей, споров

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

Пару статей по данной теме:
° Мозговой штурм и 10 правил его эффективного проведения

° 15 полезных техник мозгового штурма

​​Сбор требований: метод наблюдения.
#сбортребований #наблюдение

Метод наблюдения или работа " в поле" - заключается в наблюдении за тем, как работают пользователи.
Чаще применяется там, где необходимо отследить текущий процесс.

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

Данный метод позволяет:
° мгновенно выявить требования;
° наглядно увидеть проблему;
° сравнить реально выполняемый процесс с имеющимся регламентом;
° изучить процесс более детально, вплоть до отдельных операций;
° определить наиболее трудоемкие операции;
° избежать проблем, связанных с трудностями ЗЛ в описании и выражении своих потребностей.

Недостатки:
° могут быть упущены альтернативные ситуации;
° большие затраты по времени;
° трудно применим на секретных предприятиях или опасных (вредных) производствах;
° пользователь в отсутствие наблюдателя может работать иначе. (Т.о. собранная информация может быть недостоверной)

Пример применения метода Наблюдения на практике

​​Методы сбора требований: изучение существующей документации
#сбортребований #документация

Анализ документов позволяет:
°  быстро освоить текущую систему или новую предметную область;
° сократить время и ресурсы, затрачиваемые заказчиком на передачу знаний и информации;
° выявить возможные требования к ПО, например, при автоматизации устоявшихся в организации регламентированных бизнес-процессов;
° получить информацию,  которой люди не обладают;
° поможет при создании документации процесса as-is

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

Важно! перед анализом документации оценить ее релевантность - соответствует ли она действительности.

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

​​Методы сбора требований: Анализ системных интерфейсов.
#сбортребований #интерфейс

"Анализ интерфейсов — независимый метод выявления требований, который подразумевает анализ систем, с которыми взаимодействует ваша система. Анализ системных интерфейсов выявляет функциональные требования к сервисам и обмену данными между системами (IIBA, 2009). ..

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

Источник:  К. Вигерс "Разработка требований к программному обеспечению"

#собеседование #логическая #задача

На столе лежат девять монет. Одна из них — фаль­шивая. Как при помощи двух взвешиваний можно найти фальшивую монету? (Фальшивая монета легче настоящих.)

‐-------‐----------------------
Посмотреть ответ

​​Рекомендации по проведению интервью при сборе требований.
#сбортребований #интервью

Интервью - беседа с заказчиком или его предсиавителем в офлайн или онлайн режиме.
Чаще применяется  для получения информации по какой-либо конкретной теме или уточнения требований.

Этапы и рекомендации по проведению интервью
Подготовка:
° Определите цели интервью
° Выберите для беседы "подходящего" человека
° Заранее подготовте вопросы, вспомогательные материалы
° Поделитесь повесткой с будущим собеседником

Проведение:
° Установите контакт с собеседником
° Больше спрашивайте, а не предлагайте
° Чередуйте открытые (для получения информации) и закрытые (для уточнения, подтверждения) вопросы.
° Проговаривайте альтернативные ситуации
° Используйте активное слушание
° Старайтесь выяснять "что" и "зачем" хочет получить заказчик, а не "как" это должно быть реализовано.
° Обращайте внимание на неявные/предполагаемые требования
° Придерживайтесь границ проекта
° Фиксируйте информацию
° Не затягивайте время

Завершение:
° Проговорите итоги встречи
° Договоритесь о дальнейших действиях
° Подготовте и разошлите протокол встречи всем заинтересованным лицам

Более подробно познакомиться  с тем, как провести интервью с заказчиком, можно в статье

​​Прототипирование как метод сбора требований.
#сбортребований #прототипирование

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

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

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

Использование метода прототипирования позволяет:
° лучше понять/уточнить требования;
° вовлечь заказчика в процесс разработки;
° минимизировать ошибки проектирования, обнаружить недостаточность или несоответствие требованиям на начальных этапах, за счёт чего сократить  время и стоимости разработки;
° уменьшить расхождения в представлении о программе между разработчиками и пользователями.

-------------
° Почему стоит включить в разработку прототипирование

° Инструменты для прототипирования

° Как использовать бумажные прототипы в интерфейсах: практическое руководство

​​Кто такие стейкхолдеры?
#стейкхолдер #теория

Стейкхолдеры (заинтересованные стороны) - лица или организации, которые:
° Заинтересованы в результате и/или особенностях процесса разработки и развития вашего проекта или продукта
° Могут оказывать влияние на процессы, цели и результаты вашей работы

Стейкхолдер - это носитель определённой роли, а не конкретный человек или организация.

Классифицировать стейкхолдеров можно:
1.По принципу взаимодействия
° Внутренние - все, кто непосредственно работает над результатом и финансирует проект (владельцы компании, основатели проекта, акционеры,  сотрудники..)
° Внешние - те, кто могут каким-то образом повлиять на компанию или на конкретный продукт (госорганы, банки, СМИ, конкуренты, посредники..)

2.По уровню влияния
° Первичные - активно влияют на деятельность организации или выполнение проекта (владельцы, команда проекта, партнёры, клиенты).
° Вторичные - воздействуют на компанию или проект опосредованно (инвесторы, конкуренты, органы власти, СМИ)

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

° Анализ стейкхолдеров проекта

° Кто такие стейкхолдеры: Таблица интересов стейкхолдеров, Карта заинтересованных сторон, Матрица стейкхолдеров

​​Видеокурс Погружение в SQL + VBA
#sql #excel #vba #видеоуроки

В данном видеокурсе рассматривается вариант взаимодействия SQL и Excel через vba на примере проекта "Магазинчик"

Содержание курса:
Введение
1. Хранимые процедуры
2. Соединяем SQL и Excel
3. Получаем данные в Recordset из БД
4. Получаем данные на форму Form в Excel из Recordset
5. Проектирует таблицы БД
6. Продолжаем получать данные
7. Хранимая процедура для Склада
8. Из формы Excel в БД
9. Рефакторинг кода VBA
10. OUTPUT и SCOPE_IDENTITY
11. IF - ELSE
12. Удаление товаров и функция REPLACE
13. Циклический оператор WHILE
14. Выгружаем данные из БД в Excel
15. SELECT CASE и OUTPUT
16. Права доступа для БД
17. Вызов хранимой процедуры из другой хранимой процедуры
18. Скалярные функции. Возврат значения из функции
19. Временные таблицы
20. Курсор CURSOR. Обработка таблицы циклом
21. MERGE оператор слияния таблиц

Перейти к видеоурокам

​​Уровни требований к ПО.
#требования #уровни #теория

Обычно выделяют три уровня требований.

1. Бизнес-требования - описывают цели, которых хочет достичь заказчик (организация) с помощью разрабатываемой системы.
-- Отвечают на вопрос: "Зачем", "Для достижения каких целей" нужна система;
-- Источники требований: акционеры, покупатели системы, управляющий реальными пользователями, топ-менеджер или ответственный за концепцию продукта.
-- Данные требования можно отразить: в документе о концепции и границах, в уставе проекта, в положении о бизнес-задачах, в документе основных рыночных требований ..
-- Пример: авиакомпания хочет на 20% снизить затраты на сотрудников у стойки в аэропорту;

2. Пользовательские требования  - описывают задачи, которые пользователь сможет (должен иметь возможность) выполнять с помощью разрабатываемой системы.
-- Отвечают на вопрос: "Что" пользователь должен иметь возможность делать с помощью системы;
-- Данные требования можно представить в виде: вариантов использования, пользовательских историй.
-- Источник требований: представители пользователей;
-- Пример: Как пассажир я хочу зарегистрироваться на рейс, чтобы можно было сесть на самолет

3. Функциональные требования (требования к реализации) - описывают поведение системы, при тех или иных условиях.
Т. е. что "должна" делать система, чтобы пользователи могли выполнить свои задачи в рамках установленных бизнес-требованиями.
-- ФТ отражают в спецификации требований к ПО.
-- Пример: • Система должна по электронной почте отправлять пользователю подтверждение о регистрации.
• У пользователя (пассажира) должна быть возможность распечатать посадочный талон на зарегистрированный рейс.
------------

​​Что такое Бизнес-правила и почему стоит обратить на них внимание при сборе требований к ПО?
#бизнесправила #сбортребований #теория

Бизнес-правила (БП) - представляют описания применяемых в конкретной компании алгоритмов, нормативов, законов, ограничений, проверок, постановлений и политик.

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

Пример:
БП - регистрация на авиарейс заканчивается за 40 мин. до времени вылета;
ФТ - система не должна позволить пользователю (пассажиру) пройти регистрацию, менее чем за 40 мин до времени вылета.

Приведем один из вариантов классификации БП:
° Факты  — верные утверждения о бизнесе на определенный момент времени. (Оплачивается доставка каждого заказа);
° Ограничения - определяют, какие операции не может выполнять система и ее пользователи. (Постоянный посетитель библиотеки может отложить для себя до 10 книг);
° Активаторы операций - при определенных условиях инициируют выполнение определенных действий - «Если <некоторое условие верно или наступило определенное событие>, то <действие>». (Если срок хранения заказа истек, то об этом необходимо уведомить лицо, оформившее данный заказ);
° Выводы - формируют новый факт на основе имеющегося - «Если <некоторое условие верно или наступило определенное событие>, то <факт>». (Если платеж не поступил в течение 30 календарных дней с момента отправки счета, то счет считается просроченным);
° Вычисления - преобразуют существующие данные в новую информацию с использованием математических формул и алгоритмов. (Цена единицы товара снижается на 10% при заказе от 6 до 10 единиц, на 20% — при заказе от 11 до 20 единиц и на 30% — при заказе свыше 20 единиц.)

Источниками БП могут быть:
° Документация - нормативные документы, отраслевые стандарты, документы корпоративных политик, контракты и бизнес-планы, спецификации требований из предыдущих проектов;
° Сотрудники организации;
° Другие системы, в требованиях и коде которых реализованы БП.

Примеры вопросов, которые могут помочь выявить БП при сборе требований, представлены на рисунке ⬇️

#собеседование #вопросы #статья

Редакция MC. today изучила, о чем спрашивают на собеседовании в Google, Ford, General Motors, Facebook, Microsoft и других..
Список вопросов привели в статье:
"Эти 15 вопросов задают на собеседованиях в Google, Facebook, Microsoft и других компаниях"

​​Атрибуты качества ПО
#сбортребований #атрибуты #качество #ак #нфт #теория

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

АК можно разделить на две группы:
° Внешние - проявляются в период взаимодействия с системой (напр., доступность, удобство использования, надежность...). Наиболее значимы для пользователей системы.
° Внутренние - характеристики, которые нельзя наблюдать напрямую при работе с системой (напр., возможность модификации, масштабируемость..). Имеют значение для разработчиков и службы тех. поддержки.

Перечень некоторых АК привели в таб. "Атрибуты качества ПО "

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

Этапы выявления АК:
1. Составьте список всех возможных атрибутов (характеристик);
2. Совместно с заинтересованными лицами (пользователи, заказчики, разработчики) определите какие из характеристик наиболее важны для проекта;
3. Определите приоритеты выбранных атрибутов;
4. Выявите конкретные ожидания по каждому атрибуту (т.е. что же именно подразумевают заинтересованные лица под тем, что система, напр.,  должна быть простой в обращении, быстрой, надежной)
5. Создайте конкретные и поддающиеся проверке требования на основе информации, собранной по каждому атрибуту качества.

Важно! При написании требований к качеству следуйте "правилу SMART", то есть они должны быть:
° конкретными (Specific);
° измеримыми (Measurable);
° достижимыми (Attainable);
° актуальными (Relevant);
° ограниченными во времени (Time-sensitive).

​​Критерии качества требований / характеристики требований
#характеристики #требований #анализтребований

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

К таким характеристикам можно отнести:
° Корректность в описании;
° Понятность всем заинтересованным лицам;
° Полнота изложения;
° Однозначность понимания;
° Модифицируемость в случае изменения;
° Прослеживаемость отношения между требованиями;
° Возможность проверки с помощью тестирования;
° Ранжируемость по важности;
° Непротиворечивость в отношении к другим требованиям

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

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

--------------
Чуть подробнее разобраться в критериях качества требований помогут статьи:

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

° Характеристики качества требований - в статье более подробно рассматриваются некоторые критерии качества

​​Модели разработки ПО
#модель #разработки

Модель разработки ПО - представляет  описание того, какие и в какой последовательности проходит продукт стадии жизненного цикла и что происходит на каждой из них.

Модели разработки ПО разделяют на классические и гибкие.

Классические модели делают акцент на последовательности, сроках и конечных требованиях к продукту.
К ним относят:
° Code and Fix - только пишем код, проверяем и устраняем ошибки;
° Waterfall /каскадная модель - последовательный переход от одного этапа разработки на другой без пропусков и возвращений на предыдущие стадии.
° V-Model - упор на тестирование в ходе разработки.Тесты проводятся параллельно с самим процессом создания продукта. 
° Инкрементная модель - разработка по частям. Проект делится на составные компоненты, команда по очереди готовит каждый из них, затем происходит финальная сборка;
° Спиральная модель представляет повторяющуюся последовательность циклов разработки с непрерывным контролем рисков.  
° Итеративная модель - сначала делается базовая модель продукта, затем следуют итерации по ее усовершенствованию;
° RAD-Model (скоростная разработка продукта) - все этапы создания продукта делятся не несколько отдельных блоков, с каждым из которых работает отдельная команда разработчиков.

Гибкая модель разработки - Agile model, представляет итеративный подход, позволяет вносить изменения на каждом этапе проекта, м.б. не ограничена во времени.

Agile model имеет множество вариаций и фреймворков, среди которых выделяют: Scrum, Kanban, Экстремальное программирование (XP), Lean.
----------

Подробнее о применении основных моделей разработки ПО расскажем в следующих постах

​​Waterfall / Каскадная модель: особенности, преимущества и недостатки применения.
#waterfall #каскадная #модель

Waterfall — это работа по заранее написанному и согласованному ТЗ, заключающаяся в последовательном прохождении всех этапов разработки ПО.

Особенности приминения Waterfall:
° все этапы создания ПО идут в строгой последовательности друг за другом;
° переход на следующий этап осуществляется только после завершения предыдущего;
° после завершения этапа возвращаться к нему нельзя;
° все требования, задачи, планы фиксируются в документах;
° требования к проекту после утверждения не меняются;
° Заказчик не участвует в создании продукта после постановки ТЗ.

Основные этапы(стадии) разработки:
° Анализ
° Проектирование
° Разработка
° Тестирование
° Эксплуатация и поддержка

Преимущества и недостатки модели:
+ все процессы зарегламентированы и описаны;
+ сроки и бюджет зафиксированы;
+ требования не меняются во время работ;
+ прозрачность процессов для заказчика;
+ ход выполнения проекта легко проследить с помощью использования временной шкалы (или диаграммы Ганта);
+ участники знают свои задачи и в какой последовательности их выполнять;

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

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

Заметки Аналитика | @notes_analyst

#собеседование #вопросы #статья

Автор статьи "Как подготовиться к собеседованию на позицию системного аналитика. ТОП-5 тем", опираясь на личный опыт, выделяет 5 основных тем с примерными вопросами, которым стоит уделить внимание при подготовке к собеседованию:
1. Требования к ПО
2. Процесс разработки ПО
3. Документация к системе
4. Проектирование решения
5. Интеграция

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

Заметки Аналитика | @notes_analyst

​​Agile-подходы гибкой разработки ПО: Scrum и Kanban.
#agile #scrum #kanban 

Суть  Agile описана в Agile-манифесте, в котором на первое место выходят:  взаимодействие, работающий продукт, сотрудничество с заказчиком и готовность к изменениям.
Подробнее:"Ценности и принципы Agile-манифеста"

К отдельным Аgile-подходам (методологиям) относятся Scrum и Kanban. 
Данные подходы гибкой разработки ориентированы на итеративный и инкрементальный процесс программирования, в котором:
 ° разработка ПО разбивается на короткие циклы - итерации (в Scrum - спринты);
 ° формируется автономная и самоорганизующаяся команда;
 ° клиенты или представляющий их владелец продукта участвуют на всех стадиях проекта;
 ° требования могут документироваться менее подробно, чем в традиционных проектах;
 ° формируется Резерв  (backlog) проекта, содержащий список задач, которые должна выполнить команда;
 °  каждая задача должна быть актуальна (разрешается добавлять/удалять задачи), иметь вес (время, которое необходимо на её реализацию) и приоритет (может пересматриваться в ходе работы);
 ° для визуализации  данных подходов используют доски: физические или электронные, которые позволяют сделать рабочий процесс открытым и понятным для всех специалистов.

Особенности и принципы Scrum:
 ° над каждым проектом работает универсальная команда специалистов;
 ° выделяют спец.роли: Владелец продукта и Scrum-мастер;
 ° время работы делят на Спринты - одинаковые по длительности отрезки времени (напр.  2 недели);
 ° перед спринтом формируются задачи на данный спринт, в конце – обсуждаются и презентуются  результаты: выполненные задачи заливаются на продакшн, а невыполненные — переносятся в другой спринт;
 ° число задач в работе ограничивается их общим весом;
 ° приоритеты задач расставляет Владелец продукта;
 ° нельзя добавлять задачи в текущий спринт (новая важная и срочная задача -  только со следующего спринта);
° основная цель - закончить спринт;
° проведение ежедневных встреч для оценки результатов проделанной работы - основа процесса разработки.

Особенности и принципы Kanban:
 ° над задачей может работать несколько узкопрофильных команд (дизайнеры, аналитики, разработчики…);
 ° внутри команды нет выделенных ролей;
 ° проект делят на итерации, длина которых может различаться;
 ° рабочие задачи располагаются на доске, поделенной на колонки, каждая из которых отражает текущее состояние работ (стадии) - например: «Планируется», «Разрабатывается», «Тестируется», «Завершено»; 
° каждая задача представляется в виде отдельной карточки;
° основная цель - закончить задачу, т.е. пройти все стадии выполнения (когда задача завершает определённый этап, карточку с её описанием переносят в соответствующую колонку);
° над задачей трудятся столько времени, сколько это необходимо до её завершения или утраты актуальности и отмены;
° главный показатель эффективности -
среднее время прохождения задачи по доске;
° приоритеты задач расставляет команда;
° добавление новых задач - в любое время;
° проводить ежедневные встречи не обязательно.

---------
Подробнее о принципах работы по Scrum  и Kanban можно прочитать в статьях:
° Scrum
° Kanban: принципы и возможности в управлении проектами
° Разбираемся в Scrum и Kanban

Заметки Аналитика | @notes_analyst

​​"Разработка требований к программному обеспечению". Карл Вигерс и Джой Битти
#литература

"Эта книга — подробное руководство по разработке качественных требований к программному обеспечению. Здесь описаны десятки проверенных на практике приемов выявления, формулирования, разработки, проверки, утверждения и тестирования требований, которые помогут разработчикам, менеджерам и маркетологам создать эффективное ПО"

Найти электронную версию можно тут (2014г.)

Обзоры на книгу:
° Рецензия на книгу «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти

° Стоит прочитать: обзор книги Карла Вигерса «Разработка требований к программному обеспечению»


Заметки Аналитика | @notes_analyst