Аннотация
- Докладчик
- Анна Обухова
Scrum давно используется для разработки программного обеспечения в распределенном режиме и когда речь заходит о проекте с участием нескольких распределенных команд, то понятно что проект будет непростым. Но насколько непростым и как четко и грамотно построить взаимодействие между заказчиком, командами и руководством проекта? Каков на самом деле уровень риска такого проекта?
Проанализировав личный опыт разработки распределенных Agile проектов и опыте Exigen Services, я выделила несколько факторов, влияющих на такие проекты, что позволило сформулировать Agile Distribution Risk Score, как четкую метрику сложности распределенного проекта. Пользуясь этой формулой любой руководитель проекта сможет наглядно, в цифрах, увидеть сложность проекта и, работая над факторами входящими в расчет Distribution Risk Score, сделать проект более грамотно организованным. Этот подход позволяет рассчитать, когда распределенная команда будет эффективна, а когда стоит настаивать, чтобы проект не был распределенным.
Видео
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
Вместо Тимофея рассказывала Анна Обухова.. Как и все доклады Exigen Services. Очень скучно :(.
Опять про проблемы распределенности.
Выводы: Скучно и не интересно
- Agile Distribution Risk Score — планируйте распределенность осознанно (Анна Обухова, AgileDays-2011)
Презентация на английском - рассказ на русском. ЗАЧЕМ? Предлагала способ оценивания команд по рискам, связанным с распределенными командами. Ничего интересного для нас.
Слушал примерно вторую половину доклада. Как-то скучновато: кейсы команда может быть распределена по-разному — в разных офисах, городах и странах. То есть просто набор кейсов, некоторые детали для каждого, которые, с моей точки зрения, достаточно очевидны. В общем-то еще на середине доклада была разборка, что и как бывает. Впечатление, что в компании умеют организовывать распределенную разработку, причем в разных вариантах, однако вербализация и проявление принципов, которые лежат за этим — не удалась.
Заметки.
- Варианты: isolated scrum/distributed/totaly integrated/flexible (все очень гибко)
- Надо пытаться снижать сложность.
- Между 1 и 2 команды разница принципиальная, между 3 и 4 — нет.
- Надо упрощать всячески пытаться. Кейсы — если продукт разваливается — разваливайте. И т.п.
- И большое многообразие по разным факторам.
- Но можно определить сложность проекта и риски из коэффициентов.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
