Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > УП: Методологии > Плюсы и минусы agile методологий: Scrum


Автор: Royan 3.4.2009, 11:28
Я решил провести опрос общественного мнения на предмент отношения к agile методологиям. В этом топике я бы хотел коснуться Scrum'а. Вопрос очень простой, в чем вы видите плюсы этой методолгии и в чем минусы. Хотелось бы, чтобы каждый высказывающийся говорил только о том варианте Scrum который был реализован в его/её команде. Пишите обо всем, что вы считаете правильным и неправильным, что напрягало, а что доставляло удовольствие? Также было бы интересно узнать были ли вы менеджером или подчиненным?

Автор: Wowa 1.5.2009, 00:29
Royan, че-то народ неактивен. Можешь сам начнешь, тогда и народ подтянется.

Автор: arilou 2.5.2009, 01:40
Я бы даже сказал, "а почеми ви сгашиваете". Т.е. какая цель топика?

Автор: Jey_k 9.9.2010, 21:54
SCRUM зиждется на ценностях, а не настрогих определениях, он тем и хорош что его можно вертеть по разному, потому напрягать там что-то не может

сам настраиваешь итерации, управляешь планированием и обсуждением все просто и эффективно

да, я в роли управленца

Автор: surlac 16.2.2011, 22:45
Цитата(Jey_k @ 9.9.2010,  21:54)
SCRUM зиждется на ценностях, а не настрогих определениях, он тем и хорош что его можно вертеть по разному.

То есть это теоретический каркас для управления проектами. Скажите, можно ли дополнить его практической методологией, например XP? Будет ли эффективно?

Автор: bilbobagginz 19.2.2011, 18:44
surlac, не теоритический, а идеологический, практический религиозный.
правда в том, что scrum - в конце концов создает какой-то алгоритм практик.
и этот алгоритм имеет преимущества и недостатки.

Самым большим недостатком является (по-моему!!!) некая надежда на то, что клиент - "знает что он хочет".
если заказчик без понятия что точно ему надо - никакой скрам не поможет.

поэтому обычно эта методология хорошо работает когда заказчик - другой департамент твоей же фирмы, или там твоя фирма софта поставляет услуги другой фирме софта услуги по аут-сорсингу или ин-сорсингу.

но это опять же - имхо.

Автор: surlac 23.2.2011, 19:54
Цитата(bilbobagginz @  19.2.2011,  18:44 Найти цитируемый пост)
scrum - в конце концов создает какой-то алгоритм практик

Я так понимаю, это алгоритм практик для ScrumMaster'а (типа, итерации - такой-то длины, митинги с таким-то контентом). А что касается команды - то никаких практических методов в Scrum я не вижу. Вот XP - другое дело, там и парное прогр-е и игры в планирование.

Цитата(bilbobagginz @  19.2.2011,  18:44 Найти цитируемый пост)
если заказчик без понятия что точно ему надо - никакой скрам не поможет.

Это точно, т.к. объём работ и приоритеты задач определяются product owner’ом. В этом случае по-моему остается одно - выбивать из owner'а тех.задание и подписывать его, для этого в общем-то и нужен руководитель (менеджер) проекта.

Автор: bilbobagginz 25.2.2011, 07:55
Цитата(surlac @  23.2.2011,  18:54 Найти цитируемый пост)
Я так понимаю, это алгоритм практик для ScrumMaster'а 

нет. для всей команды:
1. standup-meeting - для всех, рассказать вслух (и во всеуслышание) о сделанном/спланированном
2. координация пересмотра кода
3. вопросы к product owner-у в процессе планировок низкого уровня.

всё это делают ВСЕ.
кроме того, что фломастер (скрам мастер) - это довольно нудная работа, которая в хорошей команде плавает от проекта к проекту по разным людям.

Автор: surlac 25.2.2011, 19:41
Спасибо за разъяснения bilbobagginz, теперь понятно, что в скраме практики тоже хватает.
Но все-таки, как по мне, эта практика носит более организационный характер, в отличие от XP. Я не хочу сказать, что одно лучше другого, просто решают разные задачи.

Цитата(bilbobagginz @  25.2.2011,  07:55 Найти цитируемый пост)
фломастер (скрам мастер) - это довольно нудная работа, которая в хорошей команде плавает от проекта к проекту по разным людям

И еще по ролям: фломастер - любой человек из команды, руководитель (менеджер) проекта - работает на стороне product owner'а. Куда делся пресловутый начальник отдела? 
Является ли это переходом в управлении проектами от функционально-ориентированных подразделений (отдел разработки на базе .NET, Java,...) к проектно-ориентированным структурам (проект А, проект Б и др.)?

Автор: bilbobagginz 7.4.2011, 00:04
Цитата(surlac @  25.2.2011,  18:41 Найти цитируемый пост)
руководитель (менеджер) проекта - работает на стороне product owner'а

не правда. он на стороне стратегической планировки. "куда мы хотим ползти завтра?"
Цитата(surlac @  25.2.2011,  18:41 Найти цитируемый пост)
Куда делся пресловутый начальник отдела? 

не факт что оно нужно.
есть очень много нефункциональных ролей, которые создают скрытую безработицу.
не только на уровне обслуги, но и на уровне управления.
аджайл ненужный жир пытается стопить.
Цитата(surlac @  25.2.2011,  18:41 Найти цитируемый пост)
к проектно-ориентированным структурам (проект А, проект Б и др.)? 

не каждой фирме аджайл подходит без модификаций.
характер проектов и работы должен откладывать отпечаток на практики и фокус.
одна из проблем "отдел .нет" в том, что кроме дотнета они мало чего знают, и не развиваются очень сильно. и не всегда этот дотнет нужен.
в скраме более важно разношерстная команда, чем узкая специализация в какой-то технологии.
потому как 99% кода надо писать по общим принципам, а 1 оставшийся % можно даже нанять внешнего спеца на 3 дня в году.
и технологии постоянно новые выходят. напр. сегодня на основе старой системы java+ejb можно прикрутить jython.
и расширять функционал, или даже мигрировать на фиг от джавы, плавненько так. ессно что для этого надо изучить и python. зато цикл код-запуск сокращается до почти 0. не надо весь проект пересобирать.

все это мое имхо, конечно.

Автор: Jey_k 13.5.2011, 12:32
Цитата(bilbobagginz @  19.2.2011,  18:44 Найти цитируемый пост)
Самым большим недостатком является (по-моему!!!) некая надежда на то, что клиент - "знает что он хочет".если заказчик без понятия что точно ему надо - никакой скрам не поможет.


Знать куда движемся должен Product Owner. Его задача понять заказчика и разработать концепт сервиса\проекта. Заказчик по факту говорит что хотелось бы и потом то что получилось смотрит и принимает.

Цитата(surlac @  25.2.2011,  19:41 Найти цитируемый пост)
И еще по ролям: фломастер - любой человек из команды, руководитель (менеджер) проекта - работает на стороне product owner'а. Куда делся пресловутый начальник отдела? 



он есть, только он выполняет более административные функции, просто продакт оунеры как правило работают напрямую с заказчиком, читай топ менеджментом, и им в принципе еще какая-то промежуточная ступень просто не нужна

Добавлено через 1 минуту и 1 секунду
Цитата(surlac @  25.2.2011,  19:41 Найти цитируемый пост)
бой человек из команды, руководитель (менеджер) проекта - работает на стороне product owner'а



В скраме нет проектов. И нет проектного планирования. SCRUM - метода для работы с продуктами, а не проектами. Это разные вещи и реализуются по разному.

Автор: flowergirl 26.6.2011, 15:22
Цитата

 SCRUM - метода для работы с продуктами, а не проектами. Это разные вещи и реализуются по разному.


Если можно поподробнее о различиях.


А еще интересует каким образом в SCRUM реализуется ведение одновременно нескольких проектов (продуктов). Или к примеру, когда возникают вопросы о поддержке старых.  Каким образом удается совмещать и планировать спринты в таких условиях, со всеми вытекающими сложностями.  

Автор: Jey_k 1.8.2012, 12:47
Цитата(flowergirl @  26.6.2011,  15:22 Найти цитируемый пост)
Если можно поподробнее о различиях.


Продукт - законченный набор функционала, читай фич, User Stories и т.д. Имеет версии и несет Business Value уже с первого спринта

Проект - регламентированный по времени и ресурсам объем работ приводящий к конкретному результату


Цитата(flowergirl @  26.6.2011,  15:22 Найти цитируемый пост)
А еще интересует каким образом в SCRUM реализуется ведение одновременно нескольких проектов (продуктов). Или к примеру, когда возникают вопросы о поддержке старых.  Каким образом удается совмещать и планировать спринты в таких условиях, со всеми вытекающими сложностями.


Путем формирования объема спринта и приоретизации US. Это работа продакт оунера он должен выставлять приоритеты и приоретизировать Backlog.

Автор: bilbobagginz 18.10.2012, 19:47
Jey_k, 
как говорится - самая хорошая стратегия - это тактика примененная в нужном месте в нужное время smile

Если не быть осторожным, и постоянно гнаться за спринтами друг-друга (команда за командой),  то может получиться, что из-за отсутствия Business Value СЕЙЧАС и СРАЗУ в некоторых сферах разработки  (поддержка  инфраструктуры, новые технологии,  пост-эволюционный рефакторинг и остальные "прививки от эволюционных мутаций"), Вдруг! 
приходит новое маленькое расширение функционала, из-за которого надо СРАЗУ и СЕЙЧАС "выписывать ВСЕ прививки разом" (переписывать пол системы, изменять сервисы, API,  и инфраструктуру)

И все из-за постоянной ориентации спринтов на эти User Stories (a.k.a. тактики)

Я к тому, что для общего здоровья продукта или нужно вести несколько параллельных процессов, и распределять архитектурные и стратегические задачи другими ритмами спринтов.
Что немного напрягает участников этих "других" спринтов: вон UI ребята получают медали и рукопожатия, а мы системщики/архитекторы - сидим и разгребаем все это собранное по законам сохранения отходов в системе....

Автор: KirSl 27.10.2012, 23:31
как правильно было сказано: скрам для работы над продуктами, не проектами. Хотя пытались внедрить для работы над проектами, но не вышло, т.к проект оказался маленьким и не смогли разбить на итерации. В продукте выпустил и работает, всё, бабки пошли. А проект должен быть огромным, как продукт, и разбит на итерации, тогда можно использовать.

Сложность во внедрении. Был в роли менеджера.

Автор: esperanto 8.7.2013, 07:48
Аджайл метод с одной стороны хорош, как система регулирования и практик. С другой стороны метод не научный, и включает в себя много псевдонаучного и разных мифов, особенно когда работающие скрам мастера считают себя психологами, начитавшимися Берна.

Но тем не менее есть много плюсов

Автор: Петрович1 15.7.2014, 13:51
А почему никто не говорит про Planning Poker?

Автор: phpsuxxx 11.8.2014, 16:57
Цитата(Петрович1 @ 15.7.2014,  13:51)
А почему никто не говорит про Planning Poker?

Потому, что никто здесь не умеет правильно разрабатывать ПО. Половина про Planning Poker и не слышала ни разу, а другая половина в него ни разу не играла.

Автор: specialist1 23.1.2015, 10:58
Мне многое нравится: ранняя поставка продукта, итерационная разработка. Из того что не нравится в теоретических рекомендациях, пожалуй, частые собрания и коллективная ответственность.
http://dev-doc.blogspot.com/2015/01/scrum_22.html

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)