Agile: что надо знать аналитику, чтобы действовать? (AnalystDays осень 2017 в Минске) — различия между версиями

Материал из MaksWiki
Перейти к: навигация, поиск
м (MaksTsepkov переименовал страницу Agile: что надо знать аналитику, чтобы действовать? в [[Agile: что надо знать аналитику, чтобы действовать? (AnalystDay…)
м
 
Строка 5: Строка 5:
  
 
Это - не доклад, а мастер-класс, на котором после короткого введения я разбирал кейсы от участников. За полтора часа получилось разобрать 6 кейсов, и удовлетворены были не только их авторы, но и другие участники, которые с интересом слушали происходящее.
 
Это - не доклад, а мастер-класс, на котором после короткого введения я разбирал кейсы от участников. За полтора часа получилось разобрать 6 кейсов, и удовлетворены были не только их авторы, но и другие участники, которые с интересом слушали происходящее.
 +
 +
Кейсы, которые разбирали (с доски):
 +
* Продукт ведут 4 команды: бэкенд и три фронтенда для Web, iOS и Android. Как синхронизовать разработку и поставку фич
 +
* ERP-разработка, 5 разработчиков, 3 тестировщика, 1 аналитик, который сильно перегружен. Какие есть варианты решений?
 +
* Web-сервис продажи билетов, более 4 лет с релизами раз в квартал. Внутренний заказчик все время меняет требования, что делать? При этом многие фичи - экспериментальные
 +
* Продукт разрабатывает команда 150 человек в 10 локациях, группы разделены по stream, 6 аналитиков в разных локациях. Как построить коммуникации? Как держать общее видение?
 +
* Команда - 8 человек в разных городах, 1.5 аналитика. Где границы детального проектирования?
 +
* У нас типичная ситуация: заканчиваем спринт, часть задач сделано. но не протестировано. Как с ними быть, как организовать Agile-процесс?
 +
Отмечу, что большинство кейсов касалось сложной организации работы команд, а не проблем начального уровня. Обсуждение было интересное.
  
 
<html><iframe src="https://player.vimeo.com/video/242024568" width="640" height="213" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
 
<html><iframe src="https://player.vimeo.com/video/242024568" width="640" height="213" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>

Текущая версия на 14:26, 21 июля 2019

Мастер-класс на сайте конференции
Видео на vimeo

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

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

Кейсы, которые разбирали (с доски):

  • Продукт ведут 4 команды: бэкенд и три фронтенда для Web, iOS и Android. Как синхронизовать разработку и поставку фич
  • ERP-разработка, 5 разработчиков, 3 тестировщика, 1 аналитик, который сильно перегружен. Какие есть варианты решений?
  • Web-сервис продажи билетов, более 4 лет с релизами раз в квартал. Внутренний заказчик все время меняет требования, что делать? При этом многие фичи - экспериментальные
  • Продукт разрабатывает команда 150 человек в 10 локациях, группы разделены по stream, 6 аналитиков в разных локациях. Как построить коммуникации? Как держать общее видение?
  • Команда - 8 человек в разных городах, 1.5 аналитика. Где границы детального проектирования?
  • У нас типичная ситуация: заканчиваем спринт, часть задач сделано. но не протестировано. Как с ними быть, как организовать Agile-процесс?

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

Agile: что надо знать аналитику, чтобы действовать? from Vlad Orlikov on Vimeo.

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


Скачать весь pdf
Agile basic - AnalystDays-2017-2.pdf Agile basic - AnalystDays-2017-2.pdf Agile basic - AnalystDays-2017-2.pdf Agile basic - AnalystDays-2017-2.pdf Agile basic - AnalystDays-2017-2.pdf Agile basic - AnalystDays-2017-2.pdf Agile basic - AnalystDays-2017-2.pdf