12. Основы Agile

Question 1

Какие роли в разработке вы знаете? Опишите их обязанности?

Answer 1

0. Заказчик
1. Программист
   a. Team Lead (сеньор + менеджер команды)
   b. Senior/Middle/Junior Developer (условная разбивка, скорее по опыту)
2. Бизнес аналитик
3. Системный аналитик
4. Архитектор (выстраивает архитектуру всей системы, чтобы все работало ОК)
5. Тестировщик (тест п/о, приложения по кейсам) - ручное, атотесты
6. Менеджер проекта
7. UI/UX Дизайнер (юзер интерфейс,юзер экспериенс)
8. Системный администратор

Все работают в связке, но как правило 1-3+5, + 6+ 8

Question 2

Расскажите про метод “Водопад”? Какие его минусы?

Answer 2

Это методология разработки (или то, как можно разрабатывать/поддерживать ПО).
Методологий много.

Waterfall (водопад) состоит из:

1. Сбор требований (что от нас хочет заказчик)
2. Проектирование (основное ТЗ)
3. Реализация
4. Тестирование
5. Внедрение
6. Поддержка.

В чем +: это удобно, когда все по “накатанной”, напрмиер в госконтрактах/госпроектах, где все прцоессы и проект выверены и не подвергаются изменениям.

В чем минус: как правило, требования меняются, и меняются чуть ли не постоянно. А мы получаем фидбек не после 1 этапа, а ближек к концу - 5, например. А время/ресурсы уже упущены.
Короче, негибкий подход, хотя вполне имеющий право на жизнь.

Question 3

Чем отличается итеративный от инкрементального подхода?

Answer 3

Суть Водопада: “увижу цель - иду к ней”. Он негибок и хотя прост в идеале, весьма сильно зависит от первончального сбора требований - или насколько полно мы выяснили заранее что от нас хочет заказчик.
Цена изменений - очень высока (ясно не подходит например для стартапа).
Это инкрементальный подход.

Но есть такое понятие как итеративный подход - мы имеем цель (набор требований), но на начальном этапе она абсолютно точно не ясна. Мы далаем шаг и после него получаем фидбек (сразу же, а не после 5-6 этапа!). Мы корректируем цель, получая более ясные требования. И т.д. В итоге мы движемся к смещенной целе, сверяясь по пути “а это ли нужно заказчику” - тем самым мы намного гибче двигаемся к целе и данный подход позволяет получить более нужный, качественный подход.

Аналогия - мона лиза или например автомобиль. В 1 подходе ну очень много зависит от грамотного и очень продуманного сбора требований, во 2 сбор требований (или фидбек) нам доступен в начале каждого этапа.

Question 4

Что такое Agile и скажите его основной манифест?

Answer 4

Это - тоже подход.
Гибкий. Основан на итеративном подходе в том числе.

Принципов больше, но вот основные:
1. Люди и взаимодействие важнее процессов и инструментов
(проще и быстрее спросить сразу, чем например работа по регламенту)
2. Работающий продукт важнее исчерпывающей документации
(описалово и все остальное можно сделать потом, в том плане что важнее отдать продукт пользователю)
3. Сотрудничество с заказчиком важнее согласования условий контракта
(человеческий фактор и бизнес – важней сделать Хороший продукт, что win-win)
4. Готовность к изменениям важнее следования первоначальному плану
(собственно, эджайл)

Question 5

Что такое Srcum? Опишите роли, действия, основные понятия?

Answer 5

Реализаций Эджайл - много.
В разработке это например Скрам (Scrum).

Есть продукт оунер (бизнес-заказчик, product ownder), он ведет бэклог (backlog)
Это - список задач, отсортированный по приоритету (в самом верху те задачи, которые “кровь из носу” надо выполнить).

Например, соцсеть:
1. Авторизация
2. Создание/редактирование профиля
3. Загрузить изображение
...

“я такой-то-то-такой-то (напримимер, пользователь системы), хочу сделать то-и-то-то (например зайти на сайт и залогиниться”.
Это - юзер стори (user story)

Т.е. собирается вся команда, в т.ч. заказчик и начинают оценивать задачи…
На планировании. Оценивают по времени, в человекоднях. Все эти оценки согласовываются с ПО и идут в спринт.
А спринт - это некий отрезок времени на команду (1, 2, реже 3/4 недели).
Мы говорим, что берем наши задачи в некий спринт (куда вошли 1, 2 и 4 задача).

Ежедневно (т.н. daily) команда фокусируется только на тех задачах, которая взяла и встречается на мини-планерке (называется meet-up), отвечая на вопрос:
1. что было сделано
2. что мешает (и не сделано)
3. что предстоит сделать
Собирает и ведет встречу Скрам-мастер, тем самым синхронизируются данные команды (тем самым к концу спринта проще сделать данные задачи).

А к концу спринта происходит Ревью (на ней уже точно есть заказчик) - где команда отчитывается по задачам по спринта, где происходит очередная итерация с заказиком.

А уже после спринта и ревью есть ретро, которая дает еще фидбек, уже от команды, где обсуждаются процессы/проблемы в команде.

На самом деле полезная штука!

Question 6

Что такое Planning Poker?

Answer 6

Это карты с цифрами. Большинство похожи на числа фибонначчи.

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

Крч., позволяет договориться по срокам, которые +- подойдут по задаче всем.

Вместо карт можно использовать что угодно :)

Question 7

Что такое Burndown Chart?

Answer 7

Burndown Chart - это тулза (график), кот. используется в спринте. (оценивается на daily!).

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

Позволяет:
планировать
прогнозировать
определять
делать выводы

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