04Aug

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

Agile software development

Scrum

Гибкая методология разработки (Agile) описывает набор принципов для разработки программного обеспечения в соответствии с которым требования и решения развиваются за счет совместных усилий самоорганизующихся кросс-функциональных команд.
Agile разработка — это общий термин для набора методов и практик, основанных на ценностях и принципах, отраженных в Agile Manifesto.

История

  • В феврале 2001 в штате Юта США был выпущен «Манифест гибкой методологии разработки программного обеспечения». Он являлся альтернативой управляемым документацией, «тяжеловесным» практикам разработки программного обеспечения, таким как «Waterfall model», являвшимся золотым стандартом разработки в то время.
  • Манифест был одобрен и подписан представителями методологий: экстремального программирования, Crystal Clear, DSDM,Feature driven development,Scrum, Adaptive software development, Pragmatic Programming.
  • Гибкая методология разработки использовалась многими компаниями и до принятия манифеста, однако вхождение Agile-разработки в массы произошло именно после этого события.

Манифест

Люди и взаимодействие важнее процессов и инструментов;
Работающий продукт важнее исчерпывающей документации;
Сотрудничество с заказчиком важнее согласования условий контракта;
Готовность к изменениям важнее следования первоначальному плану;

То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что
слева

12 принципов которые разъясняют Agile Manifesto:

  • Главный приоритет — это удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
  • приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
  • частая поставка рабочего программного обеспечения (каждый месяц или неделю, или ещё чаще);
  • тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
  • cоздавайте проект вокруг заинтересованных/мотивированные личностей, Обеспечьте им необходимую среду и необходимую поддержку, и доверяйте им чтобы работа была выполнена.
  • рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
  • работающее программное обеспечение — лучший измеритель прогресса;
  • спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
  • постоянное внимание улучшению технического мастерства и удобному дизайну;
  • простота — искусство не делать лишней работы;
  • лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
  • Через равные промежутки времени, команда размышляет о том, как стать более эффективными, потом настраивается и регулирует свое поведение соответствующим образом.

Scrum

История

Джефф Сазерленд и Кен Швабер в 1995 году представили Scrum (как системное знание)  на конференции OOPSLA в Остине, штат Техас и опубликовали статью “SCRUM Software Development Process”.
Кен и Джефф взяли  название “Scrum” из  статьи 1986 года  «The New Product Development Game»  Хиротака Такэути и Икудзиро Нонака.

Рисунок1

 

[row][col_half]Термин «Scrum» взят из регби, проводя некие аналогии между разработкой и командной игрой.
В феврале 2001 года, Джефф и Кен были среди тех 17 лидеров по разработке программного обеспечения, создали Манифест гибкой разработки программного обеспечения.

[/col_half][col_half]Рисунок2[/col_half][/row]

Определение

Scrum ( англ. scrum «схватка») — методология управления проектами, применяющаяся при необходимости гибкой разработки. Методология делает акцент на качественном контроле процесса разработки.
Это Фреймворк, используемый для комплексного управления процессом разработки продукта с начала 90-х годов. Скрам не является процессом или техникой разработки продуктов;
Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Рисунок3

Scrum Команда

[row][col_half]

Скрам Команда состоит из:

  • Владельца Продукта;
  • Команды Разработки;
  • Скрам Мастера

[/col_half][col_half]Рисунок4[/col_half][/row]

Владелец Продукта

[row][col_half]

Функции:

Четкое определение элементов Беклога Продукта

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

[/col_half][col_half]Рисунок5[/col_half][/row]

Беклог Продукта

[row][col_half]

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

[/col_half][col_half]Рисунок6[/col_half][/row]Требования никогда не перестают меняться, поэтому Беклог Продукта является живым артефактом.

Команда Разработки

[row][col_half]

Команда Разработки  состоит из профессионалов, выполняющих работу по разработке потенциально «Готового» к выпуску Инкремента продукта.
Инкремент создают только члены Команды Разработки.
Команда состоит из не более 8 и не менее 3 человек.

[/col_half][col_half]Рисунок7[/col_half][/row]

Команды обладают следующими характеристиками:

  • Они самоорганизованные. Никто (даже Скрам Мастер) не может указывать Команде, каким образом создавать готовые версии продукта.
  • Команды Разработки – кросс-функциональны, обладают всеми навыками, необходимыми для разработки Инкремента продукта.
  • Скрам не признает никаких других должностей в Команде Разработки, кроме как Разработчик, невзирая на вид работы, выполняемой человеком; у этого правила нет исключений.
  • У Команды Разработки нет подкоманд, которые бы выполняли отдельные функции, как, к примеру, команда тестирования или бизнес-анализа.
  • Отдельные члены Команды Разработки могут владеть специализированными знаниями в различных областях, однако ответственность лежит на всей Команде Разработки в целом.

Рисунок8

[row][col_half]

Скрам Мастер

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

Обязанности Скрам Мастера по отношению к Владельцу Продукта:

  • Находит методы эффективного управления Беклогом Продукта.
  • Помогает Скрам Команде создавать лаконичные и понятные элементы Беклога Продукта.
  • Понимает долгосрочное планирование в эмпирической среде.
  • Убеждается в том, что Владелец Продукта знает, как упорядочить Беклог Продукта, чтобы максимизировать Ценность.
  • Понимает и практикует гибкие методы разработки и управления.[/col_half][col_half]

Рисунок9

Обязанности Скрам Мастера по отношению к команде разработки

  • Проводит Коучинг команды разработки для улучшения самоорганизации и кросс-функциональности.
  • Помогает Команде создавать продукты высокой̆ ценности.
  • Устраняет помехи, препятствующие работе Команды.
  • При необходимости способствует (облегчает) мероприятия Скрама.

[/col_half][/row]

Sprint

[row][col_half]

Сердцем Скрама является Спринт длительностью в один месяц или менее , в течение которого создается потенциально готовый̆ к выпуску и использованию продукт (рабочая версия).Следующий̆ Спринт начинается сразу же по окончании предыдущего.Спринты состоят из:

  • Планирования Спринта;
  • Ежедневных Скрамов;
  • Разработки;
  • Обзора Спринта;
  • Ретроспективы Спринта.

[/col_half][col_half]Рисунок10[/col_half][/row]

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

[row][col_half]

План действий создается при совместной работе всей Скрам Команды. Планирование Спринта отвечает на следующие вопросы:

  • Что может быть сделано в Инкременте продукта следующего Спринта?
  • Как будет выполняться работа, необходимая для создания Инкремента Продукта?

[/col_half][col_half]Рисунок11[/col_half][/row]

Ежедневные Скрамы

[row][col_half]

Ежедневные Скрамы – это 15-минутные мероприятия для Команды Разработки с целью синхронизации действий и создания плана работы на ближайшие 24 часа.

  • Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта?
  • Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта?
  • Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта?

[/col_half][col_half]Рисунок12[/col_half][/row]

Обзор Спринта

[row][col_half]

Встреча по Обзору Спринта проводится в конце Спринта для проверки Инкремента.
Во время Обзора Спринта Скрам Команда и заинтересованные лица обсуждают выполненную во время Спринта работу.
В Обзор Спринта включены:

  • Команда Разработки обсуждает, что во время Спринта прошло гладко и с чем возникли трудности, а также то, как она с ними справилась;
  • Владелец Продукта объясняет, что является “Готовым”, а что нет;
  • Участники, в том числе Скрам Команда и заинтересованные ключевые лица, приглашенные Владельцем Продукта;
  • Команда Разработки проводит демонстрацию того, что было сделано, и отвечает на вопросы по Инкременту;
  • Владелец Продукта обсуждает состояние Беклога Продукта. Он делает предположения касательно возможной даты завершения, принимая во внимание скорость продвижения к дате;
  • Обзор возможного изменения рынка, потенциального применения продукта и наиболее ценных задач;
  •  Обзор сроков, бюджета, потенциальных возможностей и состояния рынка к моменту ожидаемого релиза продукта

[/col_half][col_half]Рисунок13[/col_half][/row]Результатом Обзора Спринта служит пересмотренный Беклог Продукта

Ретроспектива Спринта

[row][col_half]

Проводится в конце спринта.
Члены команды высказывают своё мнение о прошедшем спринте.
Отвечают на два основных вопроса:

  • Что было сделано хорошо в прошедшем спринте?
  • Что надо улучшить в следующем?
  • Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).

[/col_half][col_half]Рисунок14[/col_half][/row]

Беклог Спринта

[row][col_half]

Беклог Спринта – это набор Элементов Беклога Продукта, выбранных для выполнения в текущем Спринте, а также план разработки Инкремента продукта и достижения Цели Спринта.
Беклог Спринта – это прогноз Команды Разработки относительно функциональности, которая станет частью следующего Инкремента. Беклог Спринта определяет объем работы, которую Команда Разработки должна выполнить, чтобы превратить Беклог Продукта в “Готовый” Инкремент.

[/col_half][col_half]Рисунок15[/col_half][/row]

Определение Готовности

Когда элемент Беклога Продукта или же Инкремент называется «Готовым», все должны понимать, что означает «Готовность».
Имея общее понимание о готовности продукта можно объявить о его готовности и поставить продукт на рынок, не имея противоречий внутри Скрам команды. Владелец будет доволен результатами, а команда удовлетворена разработкой.

Рисунок16

 

Рисунок17

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

We are looking forward to meeting you on our website soshace.com

18. Уроки Node.js. Работа с Файлами, Модуль fs

Всем привет! Цель этого занятия – научиться работать с бинарными данными и с файловой системой. В Node.js для работы с файлами существует модуль fs, и в нем есть множество функций для самых различных операций с файлами и директориями.

Уроки React . Урок 8

В сегодняшнем уроке мы займемся уже более сложные вещи. Мы уйдем от ручного описания всех этих “closure”, subscriptions, все это конечно же не делается вручную. Мы научимся делать все значительно проще и элегантнее. Первое что хотелось бы сделать, это избавиться от всех этих подписок, оборачиваний, как например в app.js. Для этого существует библиотека react-redux, установим ее:

npm i react-redux –S

Сам по себе Redux можно использовать где угодно, а наша библиотека помогает подружить React с Redux и писать меньше кода.

23. Уроки Node.js. Домены, “асинхронный try..catch”. Часть 3.

Итак, из чего состоит app.js?

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

Leave a Reply