3 заметки с тегом

Scrum

Черная книга Скрам

Рекомендую новую книгу Ивана Селиховкина «Черная книга скрам»

Эта книга квинтэссенция и моей боли как управленца и причина по которой Скрам не использую ни в одном из своих проектов.

В целом это подтверждается и самой аджайловой индустрией: посмотрите сколько процессов в проектном управлении организации по SAFe бегут по Канбан методу, и сколько отведено под scrum (https://www.agilest.org/scaled-agile/safe-framework/)

Подсказка: только один, да и тот опционально

http://scrumblackbook.pmlead.ru

Спасибо, Иван!

2018   Scrum   Книги   Полезное

Про скрам

Возни много, все потеют, а к забитым голам отношения никакого.

2017   Scrum

Про SCRUM

Крайние два месяца работаю в проекте, в котором используется методолгия разработки SCRUM. Это мой первый опыт использования SCRUM как dev, внутри команды. Один раз довелось принять участие в качестве «продукт оунера» в проекте, ну так меня тамошние программеры называли, а в особенности их процесса я не вникал. :-)

Судя по описаниям, у нас в проекте прямо самый настоящий скрам, почти в максимальном его проявлении. Сейчас перечислю все характеристики, которые мне заметны изнутри, как разрабочику.

  1. Спринты по 2 недели.
  2. Каждую неделю вносятся изменения в changelog.
  3. Каждый день ровно в 17 проводится meeting, каждому отводится 2-3 минуты на рассказ о том, что за сегодня сделал, какие проблемы возникли.
  4. В конце спринта проект показывают product owner-у, в конце каждого второго спринта — заказчику.
  5. В конце «вехи» разработки проводится ретроспектива.

Как видно, под описание «скрам» наш процесс очень даже подходит. И мне очень нравится этот режим разработки. Вроде как бы процесс идет нон-стоп, и временные рамки очень четко заданы. Привчка с времен фриланса — в жестких временных рамках работается гораздо проще, чем когда известно, что проект нужно выкатить через 3 месяца. Ну и постоянный контроль от product-owner и заказчиков — в случае, если команда начинает делать что-то не то, что нужно, быстро приходит обратная связь с требованием коррекции функционала проекта.

Еще одним достоинством могу назвать ротацию разработчиков по частям проекта. Каждый разработчик время от времени работает над разными частями проекта, и имеет представление о системе в целом, а не только о своем «куске, который он месяцами пилит». Это же касается и тестирования, у нас на каждого девелопера приходится по одному тестеру, но это не значит, что они «приставлены» к dev-ам, какой тикет придет на тестирование, тот и проверяют.

В целом, полностью поддерживаю мнение Ханка Рейнвотера («Как пасти котов»), в том, что Agile это скорее всего единственная действенная «философия» разработки ПО, к которой должны, в конечном итоге, сводиться все остальные методологии. Методология позволяет сохранять ритм, увеличивать или замедлять темп разработки, позволяет команде быть довольно гибкой, ротация задач по разработчикам позволяет dev-aм не засиживаться над скучными задачами, а работодателю — иметь примеро одинаково осведомленных о проекете сотрудников, что защищает его от неожиданностей — любой дев из команды сможет подхватить работу другого разработчика. Мастхевная технология.