В этом уроке мы рассмотрим основные методологии и инструменты командной разработки.

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

/**/

Цели занятия

• после занятия вы сможете: производить код коллективно.

Краткое содержание

• методология разработки ПО;

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

• SCRUM.

Результаты

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

Преподаватель

• Александр Пряхин

Дата и время

• 24 февраля, четверг в 20:00

• Длительность занятия: 90 минут

Тезисы из вебинара

Встречи/митинги

надо ходить на те митинги, где ты реально нужен (а не просто так)

Протокол встречи, ответственный и дедлайны — важны:

Процессы разработки

Разработка начинается с Проектирования/Дизайна

Жизненные циклы и фрейиворки

Водопад

Agile

Экстримальное программирование

Схема XP

Scrum

Burndown chart

Бэклог

Роли и планирование

Анализ спринта по Scrum

Canban

RUP ~Rational Unified Process

Инструменты

Метод Planning poker

Сложность задач д.б. оценена коллективно, например через покер-планирвание:

Где цифры ~StoryPoints (или м.б. часы, в упрощенном виде)

StoryPoints- усл. мера времени выполнения задачи, с учетом того, что за единицу времени/день допустим джун решает 1 поинта, миддл — 2, сениор — 3 … единица измерения сложности

Velocity — продуктивность команды

Метод MoSCoW

• Must — делаем в любом случае; то, что необходимо сделать в любом случае. Без выполнения этих задач продукт не будет работать в принципе.

• Should — делаем если это возможно; не самые важные требования, но они тоже должны быть выполнены. Естественно, после реализации «must».

• Could — хотелось бы сделать ; желательные требования, которые можно сделать, если останется время и будут ресурсы.

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

Видео по теме:

Подробнее: https://vc.ru/hr/63226-metod-moscow-kak-sfokusirovatsya-na-glavnom-i-stat-effektivnee

Метод PDCA

Как работает цикл PDCA?

Цикл PDCA включает в себя 4 этапа: «планирование», «выполнение», «проверка» и «действие». Процесс выполняется линейно, при этом завершение одного цикла связано с началом следующего цикла.

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

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

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

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

Подробнее: https://www.dropbox.com/ru/business/resources/pdca

Контроль версий

CI предполагает выполненеие тестов после каждого коммита

Подробнее о Gitflow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Дополнительные материалы

• Книга Дэвид Аллен: Как привести дела в порядок. Искусство продуктивности без стресса Подробнее: https://www.labirint.ru/books/507367/

• Книга Максим Дорофеев: Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо Подробнее: https://www.labirint.ru/books/580693/

• Книга Глеб Архангельский: Тайм-драйв. Как успевать жить и работать Подробнее: https://www.labirint.ru/books/321833/

• Книга Даниэль Канеман: Думай медленно… решай быстро https://www.labirint.ru/books/414866/

• см. также видео по теме: Сине зелёный деплой // Бесплатный урок OTUS https://www.youtube.com/watch?v=52w6l_XwSKI

• см. также видео: Тимлид не нужен? Трансформация роли Тимлида в Agile фреймворках // Бесплатный урок OTUS https://www.youtube.com/watch?v=feSi2WIMkH8