Scrum/ru
| Language: | English • русский |
|---|
Как agile разрушил мою жизнь. Интересно узнать различные позиции
Как эстимировать в относительных единицах
Agile, Scrum, MyScrum
По материалам статьи Тимофея Евграшина http://tim.com.ua/2010/11/agile-ruined-my-life-article/
Agile – это интерфейс. У него есть описание каких-то констант (ценностей) и возможно даже намёк на методы (принципы). Но никакой информации об их реализации. Вы пользуетесь этими ценностями и принципами, когда принимаете решение, как будет работать ваша команда. Какие-то из них вы вообще пропускаете, поставив заглушку, а какие-то становятся самыми используемыми.
Scrum – это абстрактный класс. В нем уже есть конкретные роли и методы – это и есть методология. И в тоже время, Scrum по-прежнему абстрактен – это лишь каркас (framework).
MyScrum – это то, что вы строите в своей команде, основываясь на базе Scrum. А по дороге ещё наследуете или используете другие «хорошие практики». И если вы выкинули все родительские методы, то просто не называйте это Scrum . Во всяком случае, не говорите, что вы работаете по Scrum, если вы только проводите ежедневные встречи. Ну пожалуйста, будьте честны с собой.
Лекция Сергея Валуя, пересказанная Константином Слисенко
- Scrum-команда небольшого размера (обычно 8-15 человек)
- При scrum-e разработка делиться на небольшие (примерно до двух недель) спритны, в конце спринта заказчик видит часть готового функционала.
- Задачи очениваются идеальными часами (т.е. покушать, выйти покурить – не учитывается)
- Для спринта на команду берётся заданное количество идеальных часов. Эти часы – это просто статистика качества команды, она собирается, по неё ведётся постоянный анализ.
- Первые часы (обычно день) каждого спринта вся команда планирует, что будет делать за спринт.
- Заказчику можно показывать идеальные часы, но платит всё равно он за реальные.
- В конце каждого дня команда собирается и обсуждает, какие у кого случились затыки, те, кто в этих вопросах разбирается помогают тем, у кого они случились.
- Для заказчика scrum – хороший вариант, т.е. качество и сплоченность команды растёт (все друг другу помогают) + он каждый спринт видит готовый функционал (в случае водопадной модели , он видит результат только по прошествии например нескольких месяцев, когда будут завершено несколько фаз)
- В любой момент заказчик может сказать “ребята, я понял – мне нужен немного другой продукт”, и ничего страшного не случиться, т.к. теряется только один спринт, потраченный на “ненужный” функционал.
- Разработка больших проектов (сотни человеколет) с применением scrum – это больше вопрос декомпозиции проекта.
- Вся команда друг друга знает.
- Во главе команды стоит scrum master – его задача направлять команду, т.е. следить, чтобы например решение проблем не перерастало в холивары, чтобы соблюдались правила scrum-а
