LINUX.ORG.RU
ФорумTalks

Полезен ли Scrum в разработке ?

 


1

2

Сабжи ? Особенно касается «ежедневных совещаний». Новое начальство ввело такие совещания. Если честно после 3 уже надоело до чертиков: приходится рассказывать о такой чепухе, о которой в обычном режиме вообще не задумываешься. Если честно хватило бы встречи раз в неделю.


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

вышло конечно не совсем то что нужно, но вполне повысило производительность (тогда сроки горели и было весело, хз как там щас)

Deleted
()

Правильный Scrum - полезен.

Неправильный, а просто в силу веяний моды, как любят компании, в которые любит ходить erzent - бесполезен и вреден.

dvrts ★★★
()
Ответ на: комментарий от Deleted

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

Deleted
()

Особенно касается «ежедневных совещаний».

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

drull ★☆☆☆
()
Последнее исправление: drull (всего исправлений: 1)

Полезен
Только очень желательно, чтобы в команде, которая начинает работать по скрам, был уже человек с опытом работы со скрам. Иначе хрень выходит и на деле скрам ради скрам.

kiotoze ★★★★
()

При работе больше одного человека на проекте ежедневные митинги полезны - позволяет узнать, кто над чем работает, когда будет готово что-то, чего ты ждёшь (интерфейс который ты будешь использовать, например) и вообще как продвигается разработка. Если разработчики сильно изолированы то, наверное, не так важно.

roy ★★★★★
()

Если честно хватило бы встречи раз в неделю.

например, затем оно и нужно, чтобы кто-нибудь не пропал на неделю

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

stevejobs ★★★★☆
()

Про Scrum не знаю, что это такое, а ежедневные совещания полезны. Помогают лучше планировать сроки, всегда быть в курсе, что нужно добавить, какие баги исправить и т.д. Мы каждый день совещаемся с утра в конференции Skype.

Den_Zurin
()
Ответ на: комментарий от roy

Если разработчики сильно изолированы то, наверное, не так важно.

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

Den_Zurin
()

Полезен ли Scrum в разработке ?

Зависит от команды/проекта/манагера

Особенно касается «ежедневных совещаний»

Внутри команды если есть люди склонные к ИБД - обязательно, между командами если пилят связанные вещи, например одна пилит ядро/фреймворк а другие его пользуют - в случае аврала. Межгрупповые кодеры-тестеры-аналитики полезны если у менеджмента семь пятниц на неделе и есть реальные шансы получить противоположные указания.

А в остальном раз в неделю вполне норм. С другой стороны такие микросовещания не должны затягиваться больше чем на 15 мин. Так что потенциальный вред явно ниже потенциальной пользы.

ya-betmen ★★★★★
()
Ответ на: комментарий от drull

Пятиминутные летучки нужны.

Ну вот и пусть манагеры звенят. Обычных разработчиков-то зачем таскать?

mv ★★★★★
()
Ответ на: комментарий от Den_Zurin

Тимлид не всегда есть, а менеджер проекта не обязательно передаёт техническую информацию между разработчиками.

roy ★★★★★
()
Ответ на: комментарий от roy

Тимлид/проектный менеджер/кто там еще есть должен общаться с клиентами и передавать их замечания и предложения разработчикам для внесения изменений в ПО.

Den_Zurin
()
Ответ на: комментарий от Den_Zurin

Можно и удаленно. Групповой чат. Это еще и стимулирует удаленщиков быть на месте к митингу. Почти как на работу вовремя.

deep-purple ★★★★★
()

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

unt1tled ★★★★
()

Нет, не помогает.

http://jdevelop.livejournal.com/2074384.html — тут, в общем, правильно написано.

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

Miguel ★★★★★
()

а зачем в Scrum ежедневные совещания? мне казалось они только перед или после сприанта

umren ★★★★★
()
Последнее исправление: umren (всего исправлений: 1)

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

vostrik ★★★☆
()
Ответ на: комментарий от umren

перед спринтом планирование, после спринта ретроспектива, каждый день стендап, чтобы знать, кто в команде чем занимается и на какой он стадии

vostrik ★★★☆
()
Ответ на: комментарий от Miguel

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

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

Скажите мне, дураку, а багтрекеры напрасно придуманы? Надо обязательно каждый день слушать мэкание - «ну я это, типа да, в общем работаю да, у меня задача да»?

Xellos ★★★★★
()
Ответ на: комментарий от vostrik

И ещё на один вопрос ответьте дураку. Как раньше инженеры без ваших стендапов и митингов и коучингов со смузи в коворкинге обходились?

Xellos ★★★★★
()
Ответ на: комментарий от Xellos

вообще говоря, багтрекеры придуманы для трекинга багов. но даже если у вас вся работа только из них и состоит - есть два варианта:
1) потратить 5 минут утром на то, чтобы выяснить что там у хохлов какие задачи в процессе и какие по ним проблемы/планы
2) постоянно мониторить жиру, на тему «изменились ли эстимейты?» «закрылись ли задачи?» «появились ли линки blocked by?»
на какой сам сядешь, на какой мать посадишь?

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

постоянно мониторить жиру, на тему «изменились ли эстимейты?» «закрылись ли задачи?» «появились ли линки blocked by?»

А уведомления на почту отменили? Давно?

потратить 5 минут утром на то, чтобы выяснить что там у хохлов

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

Xellos ★★★★★
()
Ответ на: комментарий от Xellos

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

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

багтрекеры придуманы для трекинга багов

Спеціальне пояснення для дітей пріроди - кроме багзиллы есть ещё системы учёта и управления задачами. Давно есть. Окей, для любителей смузи на коучинге - таск менеджмент системсы.

Xellos ★★★★★
()
Ответ на: комментарий от vostrik

А потом холодильник «Днепр» работал 60 лет, если у него раз в 30 лет уплотнитель сменить. И космические корабли бороздили просторы Большого театра.

Xellos ★★★★★
()
Ответ на: комментарий от Xellos

А уведомления на почту отменили? Давно?

Родина дала им задачу, делай. Делай задачу, б$@ь! Не хочу, хочу подписываться на все таски всей команды и читать почту!

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

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

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

если найдешь сейчас идиота, который оплатит такой процесс разработки

А что, нынче платят за процесс разработки, а не за результат?

tailgunner ★★★★★
()
Ответ на: комментарий от Xellos

угу. все, кроме того, что человек согласен был купить, работало отлично. только не покупал никто костюмы фабрики 8 марта, покупали джинсы. аналогию с ПО сам проведешь?

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

Вот и делай задачу, а не болтай ерундой каждое утро. Не хочу слушать, как ты ерундой болтаешь.

если ты утром узнал

Не узнал ты утром. Оно в обед случилось.

Не хочу, хочу подписываться на все таски всей команды и читать почту!

А зачем тебе таски всей команды? Или у тебя все таски независимые, без связей от слова совсем? И ты никак-никак не можешь узнать, какие из задач и работ тебя касаются, а какие нет? И что, в этом случае тебя спасёт митинг в коворкинге?

Xellos ★★★★★
()
Ответ на: комментарий от tailgunner

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

vostrik ★★★☆
()
Ответ на: комментарий от Xellos

Не узнал ты утром. Оно в обед случилось.

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

А зачем тебе таски всей команды?

вот затем, чтобы я оперативно видел, что и как изменилось на проекте, а не узнавал об этом после работы почитав жиру.

Или у тебя все таски независимые, без связей от слова совсем?

сколько времени надо провести за администрированием жиры, чтобы она присылала человеку, на которого заассайнен QAAuto sub-task, апдейты по Technical sub-task в рамках одной задачи, и не присылала апдейты по QA сабтаске овнеру Development сабтаски если та в состоянии resolved, но присылала в open и in progress?

И ты никак-никак не можешь узнать, какие из задач и работ тебя касаются, а какие нет?

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

vostrik ★★★☆
()

Да, полезен. Если ты рассказываешь о чепухи, значит ты и занимаешься чепухой. Это заметят и тебя уволят. Профит!

vurdalak ★★★★★
()
Ответ на: комментарий от vostrik

если найдешь сейчас идиота, который оплатит такой процесс разработки

А что, нынче платят за процесс разработки, а не за результат?

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

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

tailgunner ★★★★★
()

Есть что-нибудь почитать про Scrum для полного чайника? А то регулярно слышу, хотелось бы быть в теме.

German_1984 ★★
()
Ответ на: комментарий от vostrik

«вовремя» - не обязательно означает «за разумное время».

«Вовремя» означает «не позднее, чем нужно заказчику».

tailgunner ★★★★★
()
Ответ на: комментарий от Miguel

бряхня

у автора верно только:

Как и любая методология, скрам ничем не лучше и не хуже другой. Годная команда сможет годно работать и по скраму, и по водопаду. Негодная команда точно так же будет гнать порожняк хоть по скраму, хоть по рупу, хоть по канбану.

Ну и остается добавить что у них команда была не годная, и все.

Deleted
()
Ответ на: комментарий от Xellos

не напрасно, но летучки нужны для того чтобы люди знали о приближении песца и осязали его

Deleted
()
Ответ на: комментарий от tailgunner

не обязательно

ну и да, желание менять требования на ходу - это тоже требования к процессу разработки, а не к результату.

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

Хотя ЛОР сцуко глючед и ты отвечал не мне, я таки добавлю: изменения требований на ходу - тоже вещь обычная и не нуждается в дополнительном упоминании.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

во-первых, отвечал я тебе.

Я не говорил процитированной тобой фразы.

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

То, что модель водопада неадекватна реальности, мне говорили 20+ лет назад на лекциях. А я говорил о реальности, а не о водопаде.

tailgunner ★★★★★
()

Похер на эти привязки к какойто методике, часто это синдром медвеженка Тедди.

Делай как считаешь удобным, анализируй и корректируй действия.

Если честно после 3 уже надоело до чертиков: приходится рассказывать о такой чепухе, о которой в обычном режиме вообще не задумываешься.

Если не отвертется, то как советует Саттон в таких случаях - «делайте спустив рукава». :)

tooolya
()
Ответ на: комментарий от vostrik

утром я узнал, что над таской, которая меня аффектит, сегодня будет работать воооон тот человек, и сегодня он её закончит.

Это тоже игры больного разума, что, будто, можно спокойно работу между программистами перекидывать. Сегодня, типа, это говно Петя пилит, а завтра - Вася.

mv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.