Agile Q&A – вопросы, которые заданы много раз

Уважаемые коллеги, 28го мы провели свой первый тренинг. Несмотря на сессии вопросов и ответов на кофе-брейках и обеде и дополнительную сессию после тренинга, осталось много неотвеченных вопросов.

Многие просочились в анкеты и в почту. Я решил ответить на них здесь, потому что ответы (по моему мнению) будут интересны всему сообществу. Итак, по порядку.

«А когда же agile таки неприменим?»

Когда или Заказчик, или команда на самом деле не хотят выпустить продукт. Потому что в таком случае открываются безграничные возможности, чтобы прикидываться шлангом.

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

«При постоянных изменениях и реприоритизациях код очень быстро начнет напоминать помойку».

При незнании или несоблюдении основных принципов ООП и неследовании лучшим практикам любое приложение начнет быстро напоминать помойку, и изменчивость в данном случае не является причиной – она всего лишь раньше проявит проблемы с дизайном и архитектурой приложения, которые один фиг вылезут. Что делать? Учиться делать OOD, учиться делать архитектуру.

«Вот-все таки я не понял – можно ли использовать agile в проектах с фиксированным бюджетом?».

Ответ такой – зависит от задач проекта. Если мы выпускаем свой продукт и наша задача – сделать максимум для наших пользователей за имеющееся время и бюджет, то однозначно стоит. Если же мы делаем проект на аутсорсе и наша задача сделать минимум фич за максимум денег – то однозначно не стоит. Если же нас «подписали» делать проект из серии «русская рулетка» – сделай то не знаю что но за полгода, и соответственно наша цель попробовать угадать – то опять-таки стоит попробовать agile. Алгоритм примерно такой – если ты хочшь рабочий продукт, у тебя вменяемый заказчик, требования будут меняться и их набор не очень понятен – выбирай agile. Если хоть один из компонентов отсутствует – уже крепко думай.

«Необходимо лучше планировать тренинг. Задержка 30 минут при 2-ух невыполненных спринтах – это много».

Самое забавное, что ровно вот эту самую программу многие команды пробегают за 50-70 минут – то есть остается лишнее время. И дело здесь – не в планировании тренинга. Дело – в способности конкретного коллектива самоорганизоваться. Даже если смотреть на наши тренировочные спринты – Velocity разных команд была сильно разная, вспомните: одна из команд всегда кричала «давайте начинать уже!» в то время как остальные еще вовсю обсуждали.

Строго в этом и заключался смысл упражнения – чтоб все команды попробовали себя в самоорганизации и совместной работе, и посравнивали свой velocity с чужим velocity, и сделали соотв. Выводы.

«Надо давать больше времени. Не успели сделать, что планировали».

Надо думать, почему так. Опытная сработавшаяся команда пробегает эти упражнения менее чем за час. Неопытная, но сильно желающая успеть – за полтора. Определенно есть возможности для улучшения, см. выше.

Если будут еще вопросы – пишите. Презентация с тренинга будет выложена на моем блоге, там же будет линк на Office Live! Workspace с документами, доступ туда по emailам регистрантов тренинга.

Tags:

Post Author

This post was written by who has written 29 posts on Agile.by.

  • victor.yakunin

    Денис, спасибо, очень классный был тренинг. Многое стало на свои места в голове. Уже активно обкатываем некоторые нововведения.

  • http://thetorch.ru/ Денис Петелин

    Всегда пожалуйста :)))