Scrum/ru

From JazzTeamWiki
Jump to: navigation, search
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, если вы только проводите ежедневные встречи. Ну пожалуйста, будьте честны с собой.

Лекция Сергея Валуя, пересказанная Константином Слисенко

  1. Scrum-команда небольшого размера (обычно 8-15 человек)
  2. При scrum-e разработка делиться на небольшие (примерно до двух недель) спритны, в конце спринта заказчик видит часть готового функционала.
  3. Задачи очениваются идеальными часами (т.е. покушать, выйти покурить – не учитывается)
  4. Для спринта на команду берётся заданное количество идеальных часов. Эти часы – это просто статистика качества команды, она собирается, по неё ведётся постоянный анализ.
  5. Первые часы (обычно день) каждого спринта вся команда планирует, что будет делать за спринт.
  6. Заказчику можно показывать идеальные часы, но платит всё равно он за реальные.
  7. В конце каждого дня команда собирается и обсуждает, какие у кого случились затыки, те, кто в этих вопросах разбирается помогают тем, у кого они случились.
  8. Для заказчика scrum – хороший вариант, т.е. качество и сплоченность команды растёт (все друг другу помогают) + он каждый спринт видит готовый функционал (в случае водопадной модели , он видит результат только по прошествии например нескольких месяцев, когда будут завершено несколько фаз)
  9. В любой момент заказчик может сказать “ребята, я понял – мне нужен немного другой продукт”, и ничего страшного не случиться, т.к. теряется только один спринт, потраченный на “ненужный” функционал.
  10. Разработка больших проектов (сотни человеколет) с применением scrum – это больше вопрос декомпозиции проекта.
  11. Вся команда друг друга знает.
  12. Во главе команды стоит scrum master – его задача направлять команду, т.е. следить, чтобы например решение проблем не перерастало в холивары, чтобы соблюдались правила scrum-а