Про роботу · 7 травня 2016, 21:31 6653

Taras Kovtun, живет в своих мечтах

Скрам — зло или благо?

Давно не работал по системе скрам а недавно попал на проект где скрам был в полный рост. Оценка тасков, хаддлы, спринты по неделе, капитан и прочее.

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

Постоянное давление и спешка не позволяет рефакторить код. За рефакторинг и баги баллы не дают. Ревизию архитектуры тоже иногда сложно уложить в таск длиной в день — написали на коленке дизайн но постоянно вылезают какие то рога и надо вносить изменения но опять — это дополнительные таски. Они расширяют скоп спринта и скрам мастер за это ругает.

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

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

Все должны быть способны подменить всех. Что за бред? В итоге таски где надо знать хорошо UI делают люди кто шарит только в базах данных. Код выходит соответственный.

По идее методология должна agile но почему то на разную мишуру уходит куча времени.

У вас такой же опыт?

Теми: Scrum

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Найкращі коментарі пропустити

Oleksandr Kostiukevych 08.05.2016 13:21

Проблема не в Скрамі, а в тому що у вас він через одне місце реалізований. Скрам не передбачає ні тиску на команду (для цього потрібен нормальний скрам-майстер, його пряма задача — забезпечувати комфортну робочу атмосферу у команді і захищати її від будь-якого зайвого тиску), ні відсутності балів за технічний борг (це нормальні задачі беклогу, які мають свою оцінку і пріорітет), ні «все должны всё бросить и помогать» (це взагалі Канбанівська тема). Короче, у вас якась каша, вам потрібен нормальний скрам-майстер. Якщо з цим проблеми — є скрам-коучі, які допомагають налагодити робочі процеси, працюючи із скрам-майстрами.
У Agile є проблема — всі сприймають гнучкість як можливість відкинути ключові принципи, зате використати зовнішні другорядні атрибути (стенд-апи, естімейти і.т.д.) для закручування гайок і посиленого контролю. Ключова тема скраму це співпраця і комунікації. Стенд-ап — це не звіт, це синхронізація. Скрам-масйтер — це не наглядач, а фасилітатор. Ну і.т.д.

Перейти до дискусії

Котэ 07.05.2016 22:46

Скрам нужен только бадишопам, чтобы обозначить «значимость» © процесса, а надувание щек имело красивую обертку.
Ну и раздеть клиента на большее кол-во часов, конечно.

Разработчики и QA видели в гробу эти «встаньте дети, встаньте в круг» и глубокомысленные газификации луж в прочих by-the-book ритуалах.

Перейти до дискусії

Oleksandr Terpelovskyy 08.05.2016 17:59

Скрам — очень крутой процесс разработки, если у команды есть доверие и взаимопонимание с заказчиком, если в команде присутствует здоровая атмосфера, нету халявщиков и отъявленных бездарей. В ином случае или в случае отсутсвии понимания процесса со стороны высшего руководства или заказчика начинаются проблемы в виде постоянного challenging estimation, непонимания team efficiency, ухода PO от своей прямой роли — служить команде, а не наоборот, что приводит к тому что команда не ощущает что она self-managed и empowered. Страдает мотивация, нарастает прессинг и недовольство свиней и цыплят друг другом и т.д.

Перейти до дискусії

Andrusenko Dmitry 10.05.2016 15:54

Молоток — это зло или благо?
Если вы умеете им пользоваться и можете забить гвоздь в стену, чтобы повесить картину — то скорее благо, но можно также:
1) Разбить себе пальцы, а гвоздь так и не забить
2) Разбить кому-нибудь голову
3) Повесить молоток в рамку под стеклом, и молиться на него, как наглядное пособие идеальной работы на проекте, где все сообирается на шурупах, а не на гвоздях
и.т.д. и т.п...
Со всему методологиями, не только с agile, а со всеми сообще, ситуация аналогична: если вы понимаете когда, что и для чего использовать — то и результат будет положительным, а если ~~молоток~~ методология прикручена только для того, чтобы на нее молиться — результат будет соответствующим.
На практике я почти не встречал проектов с чистым Scrum. Почти всегда присутствуют только отдельные элементы методологии, которые подходят и помогают на конкретном проекте.

Перейти до дискусії

Олексій Пєніє 08.05.2016 03:30

Если кто вдруг забыл.

Перейти до дискусії

Ctrl + Enter

Ctrl + Enter

Dmytro Danchevskyi Scrum Master в Symphony Solutions 31.05.2021 15:20

Коментар порушує правила спільноти і видалений модераторами.

Vladimir 14.04.2018 21:48

"В этот раз мне показалось, что это притянутая методология которая работает только на очень коротких проектах-заплатках или же это попытка спасти где все уже рушится.«©
Нет.
Это методология создана для применения в тех проектах/процессах, где не надо результата (где важен только сам процесс: «команда работает на проекте»).
Будет там результат или его не будет — здесь значения не имеет.
Сама суть скрама не подразумевает результата, процесс заточен только на протекание процесса (Но в свете того, что, пожалуй, под 90 процентов современных проектов протекают, собственно, ради самого протекания этих проектов, потом либо закрываются, либо так и текут вечно, вот поэтому скрам и изобретен)

Відповісти

Підтримати

Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 14.04.2018 22:27

Ну как для начала то весьма неплохо, вы уже обошли процентов 90% скрам-мастеров в понимании, но не стоит останавливаться — финиш не близко ...

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 14.04.2018 22:55

некропо-о-о-о-осте-е-е-е-ер

Відповісти

Підтримати

Fedir Brynzza 18.05.2016 23:30

консенсус: скрам — это злаго!

Відповісти

Підтримати

Stanislav Oles 19.05.2016 12:45

скорее «скрам — это бло» (или «блё»), что совсем жизненно :)

Відповісти

Підтримати

Mykola Gurov тролль 17.05.2016 20:14

Не работает Скрам? Проверь чеклист. Особое внимание на правый верхний квадрат. www.crisp.se/...12/05/Scrum-checklist.pdf

Відповісти

Підтримати

belmondo 17.05.2016 11:42

А є контори/тіми які не працюють по скрам, або такі які відмовилися від цієї методології?

Відповісти

Підтримати

Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 17.05.2016 20:21

Конечно есть. В первую очередь те где есть адекватный методист по процессам разработки.

Відповісти

Підтримати

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в Self Employed 17.05.2016 11:38

Если нормально следовать процессам то SCRUM вполне удобный фреймворк который больше помогает чем вредит. Если из SCRUM процессов использовать только какие то небольшие части то работать тоже может не очень но зависит от проекта.
В целом я за SCRUM и Agile. Но я наоборот считаю что SCRUM как раз для больших проектов.

Відповісти

Підтримати

Yevgen Nesterenko Senior Delivery Manager в EPAM 12.05.2016 23:10

А что капитан делает? Это скрам мастер у вас так называется?

Відповісти

Підтримати

Taras Kovtun живет в своих мечтах 12.05.2016 23:13

Из команды избирается как бы ведущий на каждый спринт. Он типа ответственный за спринт. Следующий спринт кто-то другой капитан.

Відповісти

Підтримати

Yevgen Nesterenko

Котэ 12.05.2016 23:35

Такой себе свинг для айтишников.
Будем знать.

Відповісти

Підтримати

Yevgen Nesterenko Senior Delivery Manager в EPAM 12.05.2016 23:48

Насколько я знаю такой сетап называется rotating scrum master role. Иногда встречается имеет свои достоинства и недостатки. Но никогда не слышал термин капитан :)

Відповісти

Підтримати

Stanislav Oles 17.05.2016 11:58

А какие достоинства, кроме как «чтоб каждый почувствовал себя в роли мастера»?

Відповісти

Підтримати

Yevgen Nesterenko

Mykola Gurov тролль 17.05.2016 20:18

Меньше процессов завязано на одного человека. Лучшее понимание процесса. Тенденция к облегчению процесса.

Відповісти

Підтримати

Taras Kovtun живет в своих мечтах 12.05.2016 23:54

Назывался. Я там бульше не работаю слава Аллаху.

Відповісти

Підтримати

Yevgen Nesterenko

anonymous 11.05.2016 14:21

Мнение авторитетных людей о скраме
www.youtube.com/watch?v=hG4LH6P8Syk — соавтор аджайл манифеста
www.youtube.com/watch?v=FvMuPtuvP5w — создатель LINQ в .Net, и Rx, ученый
www.youtube.com/watch?v=HZyRQ8Uhhmk — известный автор книг по C++ и Java.

Проблема — карго культ, смысл agile в гибкости (agility), способность адаптироваться, но ведь находятся ебл*ны которые говорят что мы будем делать так, и никак по другому, потому что в scrum book так написанно.

Відповісти

Підтримати

anonymous 11.05.2016 17:31

Что характерно, комментарий с видео с жесткой критикой скрама пролайкали люди с тайтлами
Training Department Manager в SCRUMguides
и
Scrum Expert

Видимо знают что-то.

Відповісти

Підтримати

Vladimir Pauchev Don't care 12.05.2016 00:14

Allen Holub — просто отличное видео :)

Відповісти

Підтримати

belmondo 17.05.2016 20:58

після першого відео перехотілося йти завтра на роботу

Відповісти

Підтримати

anonymous 18.05.2016 19:18

Во втором есть решение — vote with your legs.

Відповісти

Підтримати

ultras 11.05.2016 00:43

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

Відповісти

Підтримати

anonymous 11.05.2016 01:14

Если я хочу работать — то я буду работать в любой обстановке.

Оке, чувак. Прикинь ситуацию — перетащили столик с футболом, а на место столика впилили парту. Именно парту, бо столом назвать нельзя. Вообщем за партой — твое рабочее место, монитор перпендикулярен к остальным (видно все с другого здания даже). Рядом 3 фишки: параша, которая не закрывается, вход на кухню (ой! сори чувак разлил!), когда на тебя разливают кофе, и впереди сидит команда сельских КУА, которые не прекращают трепаться ни на секунду. Ну ты проработаешь максимум 2 дня, я, помню, 3 недели даже справлялся.... Обстановка очень влияет не надо тут пороть ересь.

Відповісти

Підтримати

Taras Kovtun живет в своих мечтах 11.05.2016 02:23

Вы описали офис фейсбука. Как то работают

Відповісти

Підтримати

Taras Kovtun живет в своих мечтах 11.05.2016 04:55

Я имел в виду офис Фейсбука в Менло Парке. Сегодня там был. Стоит гвалт, парты очень близко посажены одна к другой, туда сюда снуют толпы народу. Но как то получается работать.

Відповісти

Підтримати

Oleg Sobko Project Manager 11.05.2016 11:19

Но как то получается работать.

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

Відповісти

Підтримати

Yaroslav Romanyuk 11.05.2016 15:05

В офисе не получается, но не беда. Дома завсегда получится.

Відповісти

Підтримати

anonymous 11.05.2016 17:00

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

Відповісти

Підтримати

Serge Loboda Senior Software Developer в Access Softek, Inc. 11.05.2016 17:35

Они там случайно не андроидным приложением занимаются? Если да — я резко перестаю удивляться.

Відповісти

Підтримати

ultras 11.05.2016 09:26

Какое отношение сортиры имеют к скруму?
А то что вы описали — таких офисов вагон и тележка. практически все «топ» компании имеют такие помещения. или как другая крайность — офисы 2 на 2 без окон. да мало ли? поэтому многие и работают из дому.

Відповісти

Підтримати

Vladimir 14.04.2018 21:52

Не влияет обстановка на продуктивность и работу совершенно.
Если на кого-то «влияет» — это просто человек сам по себе неорганизованный и будет искать любые оправдания своей неорганизованности (то обстановка не та, то кофе невкусный, то окно слева, а было бы справа и т.д.)

Відповісти

Підтримати

Victor Moroz Lead Adaptive Practices Implementation Manager в Raiffeisen Bank 11.05.2016 00:37

Ознакомитесь. Ваш вопрос отпадёт сам собой.
scrumguides.org/scrum-guide.html
И Скрам — это не процесс и не методология. Это фреймворк.

Відповісти

Підтримати

Нестор Иванович 11.05.2016 00:07

Скрам ок если ВСЕ участники работают не деструктивно и понимают зачем они здесь

Забавно то что в Украине ( в аутсорсе ) я видел обычно сильно меньше проблем с реализацией SCRAM чем поуехав и работая строго в продуктовых компаниях.

Менеджмента в Украине тупо мало и они мурзилки которые в массе в процесс разработки ссут лесть — их ответственность часы в отчеты забивать, бюджетов у них обычно нет, вреда тоже мало.

А вот у продуктовых пацанов на команду в 9 человек может быть три начальника по разным веткам, и иногда чаечкой залетает еще кто нибудь с позиций по выше — в итого стыд и срам вместо планирования и планомерной спокойной работы. Тут тебе и стендапы по 45 минут с утра, и вкидывание чего попало в спринт и что угодно

Відповісти

Підтримати

Vladimir Pauchev Don't care 11.05.2016 00:13

Сразу видно опытный человек.
Scrum как методология хорошо показывает себя в out source проектах/компаниях. По ряду причин.
В продуктовых же треш, ад, угар, содомия и чад кутежа — практически гарантированы.

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 11.05.2016 00:24

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

Відповісти

Підтримати

Vladimir Pauchev

Yaroslav Uspenskyi EU Resident Entrepreneur в Latvian Company Registration 17.05.2016 10:45

хотя Скрам и гибкий костяк, но таймбоксинг — святое. Можно назначить обсуждение любых проблем после перерыва по завершении стендапа. А вот насчет «вкидывания» — выше я приводил пример!

Відповісти

Підтримати

Нестор Иванович

Artem Komisarenko C++ Software Developer в Zultys 10.05.2016 23:32

Схожий досвід. Одного разу десь пів року пропрацював під Scrum’ом, за цей час встигло змінитись керівництво, потім тімлід вигорів й пішов на нове місце простим девелопером (хоча пропонували знов тімлідом) та я й сам звільнився з величезним полегшенням.

Незважаючи на те, що хтось називає його agile’ом — це брехня. Ритуалів і магічних пасів руками в ньому більше ніж навіть в класичному процесі. Купа часу витрачалось будь на що, окрім власне роботи. Постійно якась срань, що втручається в роботу й збиває концентрацію, то мітинг, то п’ятихвилинка ненависті, то пленінг та презенташіон дей. Постійні узгодження, нескінченні мітинги та «консенсуси» з некомпетентними людьми, бо ж «команда», спроба примусити ходити всіх строєм. Купа бюрократії, завдяки якій закрити таску це була неабияка справа. Після стартапу з його динамічним процесом, де я працював перед цим, ця повільна тепла багнюка просто вибішувала.

Коли звільнився влаштувався в нормальну продуктову фірму і зараз, коли минуло кілька років, згадую все це як зубний біль. Але ж як я тоді вигорів.

Відповісти

Підтримати

Vladimir Pauchev Don't care 10.05.2016 23:57

1. Ви как команда не могли говорить нет и давать реалистичные эстимейты — давление и выгорание. Это проблема команды, а не процесса.
2. Бюрократия тоже не часть процесса, а фича компании.

Відповісти

Підтримати

Artem Komisarenko

Artem Komisarenko C++ Software Developer в Zultys 11.05.2016 00:19

1. Насправді, естімейти якраз не були проблемою. Ніхто особливо не давив. Вигоряння було завдяки забюрократизованності й спроб примусити команду (розподілену як географічно, так і по таскам) ходити строєм. Її власними силами, до речі, це ж Scrum.

2. Я в курсі. Scrum — це як комунізм. Якщо не сподобалось — значить він був неправильний.

Відповісти

Підтримати

Vladimir Pauchev

Vladimir Pauchev Don't care 11.05.2016 00:31

Ходить строем это что имеется в виду?
У моей команды стендап занимает минут 5-10 и сводиться к обмену информацией. Демо — пол часа, ретро — обычно ± час.
Это бюрократия и хождение строем? По сравнению с одной из контор где надо было развернутые отчеты по работе за день писать ...

Відповісти

Підтримати

Artem Komisarenko

Artem Komisarenko C++ Software Developer в Zultys 11.05.2016 12:08

Ходить строем это что имеется в виду?

Наприклад, спільний для різних команд code convention, який намагалися скласти демократичним шляхом, враховуючи думку student developers, що тільки вчора прочитали щось модне про це в черговому бложику. Або пре-мерж коде-рев’ю, яке призводило до великого гемору із закриттям тасків, особливо в кінці спринта.

У моей команды стендап занимает минут 5-10 и сводиться к обмену информацией.
Демо — пол часа, ретро — обычно ± час.

В нас десь так й було, тільки ж потрібно було ще й підготуватись. Враховуючи, що стендап був з самого ранку, а єдиний час в “курятнику” коли було тихо й можно було спокійно попрацювати — увечорі, це дуже сильно за***ло. Пленінг й Демо дні не призупиняли але сильно гальмували роботу десь на день кожний.

Відповісти

Підтримати

Vladimir Pauchev

Stanislav Oles 11.05.2016 12:21

спільний для різних команд code convention, який намагалися скласти демократичним шляхом, враховуючи думку student developers,

Вы зря иронизируете и думаете, что “да чему может научить этот молодняк?”. Многие матёрые программисты, которые мне попадались, пытались называть все классы с ’C’, а их члены — с ’m_’, просто потому что “ну так все делают” и “мы так привыкли”.

Або пре-мерж коде-рев’ю, яке призводило до великого гемору із закриттям тасків, особливо в кінці спринта.

Вообще-то код-ревью не имеет отношения к скраму. Но если оно у вас практикуется (у нас тоже) — закладывайте время в тасках на эту деятельность.

а єдиний час в “курятнику” коли було тихо й можно було спокійно попрацювати — увечорі

Возможно, в этом дело, а не в скраме? Если в офисе стоит гам, вам не удастся поработать хоть по какой методологии.

Відповісти

Підтримати

Artem Komisarenko

Vladimir 14.04.2018 21:57

Так эта методология иного и не подразумевает — это же и есть сама ее основа.
Так что ничего удивительного в описанном

Відповісти

Підтримати

Artem Komisarenko

Stanislav Oles 10.05.2016 18:31

По опыту, SCRUM — это такая красивая обёртка для продажи формализированного эджайла большим дядям, которые привыкли мыслить ватерфоллом. Они бы и дальше им мыслили, вот только консюмерский софт, произведённый по нему — особенно с долгосрочными планами (от года) — оказывается устаревшим ещё в середине цикла. В результате чего часть работы идёт в помойку и теряются деньги.

И вот тут приходит скрам (точнее, скрам-мастер, евангелист итд) и объясняет этим людям азбучные в общем-то истины — что нужен частый фидбек, что новые хотелки нельзя втиснуть в график просто так etc etc. Команде же объясняется то же самое, но с другой стороны — что регулярно нужен business value, а не правка кода ради более красивого кода. Если команда по уши в инженерном долге — надо донести это до заказчика и оценки делать соответствующие, с поправкой на разгребание давнокода, только и всего.

Только вот с тезисом о том, что «в команде все — одинаковые девелоперы» я в корне не согласен, конечно. Мало того, что по классическому скраму не различаются даже QA и программист (как нам объясняла тренер), так ещё и у программистов вообще-то есть разная экспертиза (кто-то по гую, кто-то по БД), и это нельзя не учитывать. К счастью, во вменяемых компаниях и командах жизнь успешно вносит свои требуемые коррективы в процесс.

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

Відповісти

Підтримати

Vladimir Pauchev Don't care 11.05.2016 00:06

Только вот с тезисом о том, что «в команде все — одинаковые девелоперы» я в корне не согласен, конечно. Мало того, что по классическому скраму не различаются даже QA и программист (как нам объясняла тренер), так ещё и у программистов вообще-то есть разная экспертиза (кто-то по гую, кто-то по БД), и это нельзя не учитывать. К счастью, во вменяемых компаниях и командах жизнь успешно вносит свои требуемые коррективы в процесс.

Вы путаете то, что все команды равны и свободны в выборе тасков с тем что все одинаковы и нет разницы. Ново созданный таск изначально ни к кому не назначен. Любой может его выбрать. В нормальных командах взрослых людей вопросов кто что берет не возникает.
Кроме того, разумно что бы хотя бы люди уровня Senior могли выполнять худо бедно любые таски, что возникают на проекте(что бы не было ситуации, когда UI дев заболел и никто не может цвет кнопок поменять).

Відповісти

Підтримати

Andrusenko Dmitry Senior Developer в DataArt 10.05.2016 15:54

Молоток — это зло или благо?
Если вы умеете им пользоваться и можете забить гвоздь в стену, чтобы повесить картину — то скорее благо, но можно также:
1) Разбить себе пальцы, а гвоздь так и не забить
2) Разбить кому-нибудь голову
3) Повесить молоток в рамку под стеклом, и молиться на него, как наглядное пособие идеальной работы на проекте, где все сообирается на шурупах, а не на гвоздях
и.т.д. и т.п...
Со всему методологиями, не только с agile, а со всеми сообще, ситуация аналогична: если вы понимаете когда, что и для чего использовать — то и результат будет положительным, а если ~~молоток~~ методология прикручена только для того, чтобы на нее молиться — результат будет соответствующим.
На практике я почти не встречал проектов с чистым Scrum. Почти всегда присутствуют только отдельные элементы методологии, которые подходят и помогают на конкретном проекте.

Відповісти

Підтримати

proger 09.05.2016 17:24

когда я слышу «Do your uncle BOB?» говорю — извините, досвиданья.

я даже согласен что там есть некие полезные методики, но оно очень похоже на регилию (привет хаббард) и очень легко вырождается в непонятно что.
в принципе , для менеджеров оно «полезное», можно фигачить красивые графики и вроде как при деле постоянно

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 14.05.2016 09:06

когда я слышу «Do your uncle BOB?» говорю — извините, досвиданья.

Хм, фраза в кавычках не гуглится (есть «Bob your uncle», но непонятна связь). Это что-то специфически скрамовое?

Відповісти

Підтримати

Serge Loboda Senior Software Developer в Access Softek, Inc. 09.05.2016 14:43

Скрам, он как рыба фугу. Блюдо крутое, но очень сложно готовить. А если готовить неправильно, резултат плачевен.

Відповісти

Підтримати

Oleksandr Terpelovskyy Engineering Project Manager 08.05.2016 17:59

Скрам — очень крутой процесс разработки, если у команды есть доверие и взаимопонимание с заказчиком, если в команде присутствует здоровая атмосфера, нету халявщиков и отъявленных бездарей. В ином случае или в случае отсутсвии понимания процесса со стороны высшего руководства или заказчика начинаются проблемы в виде постоянного challenging estimation, непонимания team efficiency, ухода PO от своей прямой роли — служить команде, а не наоборот, что приводит к тому что команда не ощущает что она self-managed и empowered. Страдает мотивация, нарастает прессинг и недовольство свиней и цыплят друг другом и т.д.

Відповісти

Підтримати

Val Budkin Працює в Intellias 08.05.2016 21:50

А почему продакт оунер должен служить команде? Он вроде за ROI отвечает, и юзер стори по ценности для бизнеса приоритезирует.

Відповісти

Підтримати

Oleksandr Terpelovskyy

Oleksandr Terpelovskyy Engineering Project Manager 08.05.2016 23:41

Потому что в этом суть Скрама — все стремятся удовлетворить команду. Процесс разработки должен походить на игру и инженеры в команде должны чувствовать себя центром вселенной, где все вокруг помогают им достичь максимум результата. Если ПО начинает себя вести так, как будто команда для него играет роль лампы Алладина, которая должна выполнять все его пожелание по моновению руки, на вопросы команды отвечать небрежно или еще хуже — в стиле «сделайте все как в продукте Х», а личное общение с командой расценивать как нисхождение Зевса к черни, то команда быстро все сечет и никакого Скрама уже не получиться, хотя ПО гордо всех будет уверять, что работает команда по Скраму, потому что есть стендапы, планирование, ревью и даже ретроспектив митинг.

Відповісти

Підтримати

Yaroslav Uspenskyi EU Resident Entrepreneur в Latvian Company Registration 10.05.2016 12:39

Scrum Master должен дружить с РО и ориентировать команду. Правда если начать закрывать ретиво дыры в фирме, могут и попрощаться. Но без QA и в сарае без оборудования Скрама точно не будет — sweat shop будет, как бы на спринты не нарезали почасовку ;)

Відповісти

Підтримати

Oleksandr Terpelovskyy

Val Budkin Працює в Intellias 13.05.2016 13:58

С таким PO scrum подход в принципе бессмысленный.
Но с «все стремятся удовлетворить команду» я не соглашусь. Scrum (да и остальные около-agile методологии) скорее trade-off «заказчики не пишут красивые спецификации утверждённые в контрактах, а вместо этого общаются с командой и могут в конце каждого спринта менять направление движения» vs «у команды есть спринт в течение которого никто ей не будет говорить бежать в противоположную сторону, но придётся в лепёшку разбиться и то что пообещали на планировании сделать».

Відповісти

Підтримати

Oleksandr Terpelovskyy

Dmitriy Chaban 14.05.2016 09:23

Только вот надо помнить, что ПО в скраме ответственен за понимание и донесение требований команде, и вот тут становится интересно, если ПО не доносит все требования в полном объеме, то как можно запланить коня в ваккууме и закомитится его сделать? — Никак, потому что во время спринта требования могут 100 раз изменится("уточниться"), а скоуп работы значительно вырости. Именно поэтому команда по сути комитится сделать именно Х стори поинтов, и велосити именно в них измеряется. А поскольку в аутсорсе все происходит как вы описали, то скрам превращает команду разработчиков в команду кодящих аналитиков-угадаек, и разработка чаще всего идет куда хуже чем могла бы.

Відповісти

Підтримати

Vladimir 14.04.2018 23:10

"но придётся в лепёшку разбиться и то что пообещали на планировании сделать«©
Что сделали — то и сделали.
Те стори, которые не сделали в этом спринте, просто переносятся на следующий спринт.
И все.
К чему эти пафосные лозунги про «в лепешку разбиться..»

Відповісти

Підтримати

Yaroslav Romanyuk 10.05.2016 18:43

Идеальная команда, идеальные условия работы.

Відповісти

Підтримати

Oleksandr Terpelovskyy

Artem Bykovets Agile & Org Coach в Simplesense. 08.05.2016 16:23

из того, что Вы описали — у вас не Scrum

Відповісти

Підтримати

anonymous 08.05.2016 15:20

Насчет замены, меня как дева заставляют быть мануал куэй для некоторых тасков, жизнь боль

Відповісти

Підтримати

Mykola Gurov тролль 08.05.2016 16:07

И это очень правильно, ИМХО.

Відповісти

Підтримати

anonymous 08.05.2016 16:36

Аж ровным счетом ничего правильного, прожиг ресурса и потеря результата.

Відповісти

Підтримати

Mykola Gurov тролль 08.05.2016 16:37

Нетестированный результат хуже меньшего результата. Ресурс пусть чем дальше весело г*внокодить лучше озаботится как уменьшить боль и сделать систему тестируемой.

Відповісти

Підтримати

anonymous 08.05.2016 16:45

Коментар порушує правила спільноти і видалений модераторами.

Mykola Gurov тролль 08.05.2016 21:55

Коментар порушує правила спільноти і видалений модераторами.

anonymous 08.05.2016 22:25

Коментар порушує правила спільноти і видалений модераторами.

Максим Ковтун Chief Software Architect в Sigma Software 10.05.2016 15:35

Коментар порушує правила спільноти і видалений модераторами.

anonymous 10.05.2016 16:09

и про жмущие короны

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

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

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

вы почитайте сперва, подумайте, а потом пишите.

я так смотрю Вы уже из секты 23х синьоров, менеджмент организации закончили, а культуре общения так и не научлись

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

Відповісти

Підтримати

Максим Ковтун

Максим Ковтун Chief Software Architect в Sigma Software 10.05.2016 16:34

Человек как раз пишет умную вещь, а Вы, вместо того, чтоб прочитать, вдуматься, поразмышлять об этом (или в крайнем случае пообсуждать с ним, позадавать вопросы), считаете именно его долбоебом, вместо того, чтоб подкрепить свое мнение (ведь это всего лишь субъективное мнение) аргументами или описать ситуацию более подробно.

Менять людей разных профессий местами — это одно. Заставлять Вас тестировать некоторые таски — совершенно другое. Не спрашивали руководителя, для чего он это делает? Может это не просто для того, чтоб выполнить какой-то ритуал (в скраме кстати нет правила, что люди должны быть взаимозаменяемы, есть правило/рекомендация, что команда должна быть кросс-функциональной, т.е. членов команды должно быть достаточно для реализации юзер сторей, следовательно все необходимые для этого специальности должны присутствовать в команде). Если к примеру это конец спринта и все фичи запедалены и осталось проверить качество последней/пары последних, то почему это должен делать один из команды, а остальные должны смотреть видосы на ютюбе? Ведь вы же команда, все вместе отвечаете за результат, за обещания, данные заказчику.

А еще бывает люди не понимают сложность работы других специальностей и бездумно футболят работу друг другу («это не баг» или «вот вам гавнобилд» или «я запедалил фичу за 2 часа до конца спринта — тестируйте!»), и тогда дать людям возможность побывать в шкуре другого — это очень удачный ход со стороны вашего руководителя.

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

Відповісти

Підтримати

anonymous 10.05.2016 17:23

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

Человек как раз пишет умную вещь

вообще то нет.

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

А еще бывает люди не понимают сложность работы других специальностей и бездумно футболят работу друг другу

при чем тут мой кейс?

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

это типа воспитатель в детском саду? такие проблемы решаются иначе, и без потери эффективности

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

для этого он не один, а это целая команда

вообщем, куча фантазии, и теория построена на ней

Відповісти

Підтримати

Максим Ковтун

Максим Ковтун Chief Software Architect в Sigma Software 10.05.2016 17:45

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

Відповісти

Підтримати

anonymous 10.05.2016 17:52

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

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

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

с точки зрения его целей — более чем.

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

Відповісти

Підтримати

Максим Ковтун

Євген Козлов Front-end developer в SoftServe 08.05.2016 16:44

ну, «потеря результата» — то перебор.
а в чем конкретно дело? в смысле, раз только «для некоторых тасок», то есть какая-то специфика?

Відповісти

Підтримати

anonymous 08.05.2016 16:49

ну, «потеря результата» — то перебор.

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

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

распределение рандомное.

не, когда меня вначале как фронтедщика кидали на джаву, было норм, хотя другим девам было жестко. как бекендщикам так и фронтендщикам.

Відповісти

Підтримати

Євген Козлов

Mykola Gurov тролль 08.05.2016 17:26

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

то есть девы не разбираются в том что понаписали и не хотят и это типа нормально?

Відповісти

Підтримати

Vladimir Pauchev Don't care 08.05.2016 17:28

то есть девы не разбираются в том что понаписали и не хотят и это типа нормально?

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

Відповісти

Підтримати

Mykola Gurov тролль 08.05.2016 18:03

Да, но девы хоть одной ступенькой ближе к пониманию в таком случае.

Відповісти

Підтримати

Vladimir Pauchev

Vladimir Pauchev Don't care 08.05.2016 18:34

Нет. Если понимания не было в самом начале — то никто к нему и близко не находится.

Відповісти

Підтримати

Mykola Gurov тролль 08.05.2016 19:06

Ну тогда опять же проблема иного характера и масштаба, чем обсуждаемая растрата ценного ресурса. И выхода в принципе два: или закрыть глаза и диплоить — типа юзеры протестируют, или садится вместе заказчику, девелоперу и тестеру и смотреть что получалось. Последнее обычно бывает больно поначалу, приведет наверное к переделываниям многого, но имеет шанс на успех в конце пути.

Відповісти

Підтримати

Vladimir Pauchev

Vladimir Pauchev Don't care 08.05.2016 19:22

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

Так нельзя.

Відповісти

Підтримати

Андрюха Цибрій Freelancer в freelance 08.05.2016 19:06

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

Відповісти

Підтримати

Vladimir Pauchev

Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 08.05.2016 19:25

Тем не менее так работает порядка половины АйТи бизнеса

Відповісти

Підтримати

Андрюха Цибрій

Vladimir Pauchev Don't care 08.05.2016 19:26

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

Відповісти

Підтримати

Андрюха Цибрій

Mykola Gurov тролль 08.05.2016 20:13

Самому-то так нравится работать?

Відповісти

Підтримати

Vladimir Pauchev

Vladimir Pauchev Don't care 08.05.2016 20:58

Привык и Герасим к городской жизни

Відповісти

Підтримати

anonymous 08.05.2016 17:36

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

Відповісти

Підтримати

Mykola Gurov тролль 08.05.2016 18:06

То есть QA это типа уборщицы, а девы — это CEO?

Відповісти

Підтримати

anonymous 08.05.2016 18:29

Не суть

Відповісти

Підтримати

Mykola Gurov тролль 08.05.2016 18:38

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

Відповісти

Підтримати

anonymous 08.05.2016 20:15

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

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 08.05.2016 21:17

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

Відповісти

Підтримати

anonymous 08.05.2016 21:33

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 08.05.2016 21:49

предлагаю не останавливаться на достигнутом и брать на себя также функции менеджмента. финансового в том числе :)

Відповісти

Підтримати

anonymous 08.05.2016 22:05

А тут они вспоминают о компетенциях...

Відповісти

Підтримати

Євген Козлов

anonymous 08.05.2016 22:21

мы пробовали договорится с нашим менеджером ротироватся, который был генератором этой идеи — не вышло

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

Відповісти

Підтримати

Євген Козлов

Victor Mikhaylov junior manual tester 08.05.2016 15:10

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

Відповісти

Підтримати

Yaroslav Uspenskyi EU Resident Entrepreneur в Latvian Company Registration 09.05.2016 12:32

как раз «линии» решаемы — в любой момент РО может добавить их в беклог и установить приоритетность. Проверено неоднократно.

Відповісти

Підтримати

Victor Mikhaylov

Oleg Sobko Project Manager 09.05.2016 14:56

если в текущий спринт можно засунуть левые таски, то это уже не скрам

Відповісти

Підтримати

Yaroslav Uspenskyi

Yaroslav Uspenskyi EU Resident Entrepreneur в Latvian Company Registration 09.05.2016 15:27

В спринт, ессно, невозможно, а в беклог — всегда пожалуйста. При отсутствии Тех. долга ;) теоретически эти таски могут попасть в спринт — вы же не в пятницу планируете на следующий?

Відповісти

Підтримати

Yaroslav Uspenskyi EU Resident Entrepreneur в Latvian Company Registration 25.05.2016 17:56

Хочу расписать более детально, чтобы за колдунство не приняли ;) Т.к. РО в любой момент может подкинуть в беклог fooo.n с макс. приоритетом, оно все равно не попадет в таски на Спринт. Хотя Скрам — это гибкий «скелет», но аджайл принцип требует приоритет общения с заказчиком над предустановками и ОДНОВРЕМЕННО приоритет людей над процессом т.е. Скрамом, а цель — все таки рабочий продукт, возможна такая коллизия:
1) Без приёма всеми учасниками команды в беклог на спринт задача не пойдет
2) НО если все ивенты прошли, можно закончить спринт на день раньше, например, а бэклог пропаботать до закрытия спринта и принять требования от РО
3) Если оценка на планинг-ивенте дана до суток, то скрам-мастер может принять с командой задачи по Эпику на выполнение
Однако успеть выполнить можно только при достаточно мелком Эпике и железной оценке часов по всем таскам, т.к. 60% времени программиста в лучшем случае идёт на код, да и работа творческая, предполагающая риск. Скрам-мастер, как «защитник» тут должен сблансировать выгоду от PSI с неудобствами для команды, но т.к. все митинги, кроме стенд-апа возможно переносить — таймбокс не пострадает.

Відповісти

Підтримати

Yaroslav Uspenskyi

Eugene But Software Engineer 08.05.2016 14:32

На ваш вопрос нету бинарного ответа да / нет. Для каких то проектов скрам подходит для каких то нет. Утверждение: «скрам применим везде, если его правильно использовать» так же не очень верно как и «скрам это плохая методология, которая выжимает все соки из программиста». Есть много хорошей литературы которая описывает преимущества скрама и как его использовать. Вы также можете найти в интернете мнения что скрам плох: michaelochurch.wordpress.com/...ially-scrum-are-terrible

Я работал на проектах где скрам в чистом виде не применим. И если это ваш случай, поменяйте процесс. Оставьте вещи которые для вас работают хорошо (например daily standup). Уберите вещи, которые вам мешают (например формальное демо для всей команды). Добавьте вещи, которых вам не хватает (например поощряйте рафакторинг). Ну и тогда наверное перестаньте говорить что вы работаете «по скраму» :).

Відповісти

Підтримати

anonymous 08.05.2016 14:26

-

undefined pointer 08.05.2016 13:48

С аджайлаии проблема в том что они требуют определенного уровня самосознания каждого члена команды. От рядового программиста до менеджеров.
А так как такой уровень дай бог есть у т.н. скрам-мастера, то приходится прибегать к классическим методам корпоративного менеджмента. Но, впрямую их использовать тоже низя, «у нас же скрам!» то и получается какой-то уродец в итоге.

Відповісти

Підтримати

Oleksandr Kostiukevych Product Owner в GR8 Tech 08.05.2016 13:21

Проблема не в Скрамі, а в тому що у вас він через одне місце реалізований. Скрам не передбачає ні тиску на команду (для цього потрібен нормальний скрам-майстер, його пряма задача — забезпечувати комфортну робочу атмосферу у команді і захищати її від будь-якого зайвого тиску), ні відсутності балів за технічний борг (це нормальні задачі беклогу, які мають свою оцінку і пріорітет), ні «все должны всё бросить и помогать» (це взагалі Канбанівська тема). Короче, у вас якась каша, вам потрібен нормальний скрам-майстер. Якщо з цим проблеми — є скрам-коучі, які допомагають налагодити робочі процеси, працюючи із скрам-майстрами.
У Agile є проблема — всі сприймають гнучкість як можливість відкинути ключові принципи, зате використати зовнішні другорядні атрибути (стенд-апи, естімейти і.т.д.) для закручування гайок і посиленого контролю. Ключова тема скраму це співпраця і комунікації. Стенд-ап — це не звіт, це синхронізація. Скрам-масйтер — це не наглядач, а фасилітатор. Ну і.т.д.

Відповісти

Підтримати

Yaroslav Uspenskyi EU Resident Entrepreneur в Latvian Company Registration 09.05.2016 12:30

Мне начальство как раз сказало, что надо командовать, раздавать задачи и авторитаризм как при Гитлере — ищу новую команду :)

Відповісти

Підтримати

Oleksandr Kostiukevych

Vladimir 14.04.2018 22:44

Очевидно, у вас на проекте результат реально нужен.

Відповісти

Підтримати

Yaroslav Uspenskyi

Vladimir 14.04.2018 22:43

"Проблема не в Скрамі, а в тому що у вас він через одне місце реалізований«©
Ну это обычная стандартная типовая фраза, и не более того (Обычно так везде и принято прикрываться — «проблема в реализации». )
Тем не менее, все прекрасно помним, что 100% вариантов реализаций Скрама уже проработаны в научно-методологической работе И. А. Крылова «Квартет» )

Відповісти

Підтримати

Oleksandr Kostiukevych

Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 15.04.2018 00:02

Тем не менее, все прекрасно помним, что 100% вариантов реализаций Скрама уже проработаны в научно-методологической работе И. А. Крылова «Квартет» )

+ 100

Відповісти

Підтримати

Виктор Карпенко 08.05.2016 11:59

Коментар порушує правила спільноти і видалений модераторами.

anonymous 08.05.2016 12:13

-

Котэ 08.05.2016 12:40

Коментар порушує правила спільноти і видалений модераторами.

Виктор Карпенко 08.05.2016 16:00

Коментар порушує правила спільноти і видалений модераторами.

Виктор Карпенко 08.05.2016 15:51

Коментар порушує правила спільноти і видалений модераторами.

Vladimir Pauchev Don't care 08.05.2016 16:13

Коментар порушує правила спільноти і видалений модераторами.

anonymous 08.05.2016 16:17

-

Dmitry Zozulya 08.05.2016 10:22

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

Відповісти

Підтримати

Vladimir 14.04.2018 22:49

Совершенно верно !!!
А у каждого инструмента есть своя область применения (назначение).
Как нет смысла применять стеклянный кувшин для забивания гвоздей (и даже неважно в каких руках кувшин будет находиться — он не для єтого в принципе предназначен) — точно такой же смысл и в применении этого инструмента (Скрама) для получения результата в проекте.

Відповісти

Підтримати

Олексій Пєніє 08.05.2016 03:30

Если кто вдруг забыл.

Відповісти

Підтримати

anonymous 08.05.2016 15:24

Лучше ссылку на оригинал давать

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 09.05.2016 06:12

Оригинал не настолько улыбает. Русская версия получилась куда лаконичнее.

Відповісти

Підтримати

Oleksiy Protas CFO в Ecognize.me OÜ 11.05.2016 12:57

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

Відповісти

Підтримати

Олексій Пєніє

Grez 08.05.2016 01:16

Давно не работал по системе скрам а недавно попал на проект где скрам был в полный рост. Оценка тасков, хаддлы, спринты по неделе, капитан и прочее.

Главное что есть Капитан!

Відповісти

Підтримати

Vladimir Pauchev Don't care 07.05.2016 23:40

Все должны быть способны подменить всех. Что за бред?

Это неправильное прочтение cross-functional teams www.scrumalliance.org/...ss-functional-scrum-teams
Если не вдаваться в детали, то идея не в том, что каждый член команды может делать любую таску. Идея в том, что команда может делать любую таску в рамках проекта. То есть имеет все возможные необходимые квалификации

Відповісти

Підтримати

Vasyl Lytovchenko бомж в отключке 07.05.2016 23:30

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

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

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

За .. баги баллы не дают

Была такая фишка, в итоге удалось убедить что это не правильно. Бывают баги на 30 минут, а бывают и на весь спринт, время команды тратится, нужно это учитывать, иначе velocity даже приблизительно ничего не показывает. А показывать должно: это в принципе-то инструмент для планирования.

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

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

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

Ради одной не стоит собираться, ради десятка, которые можно обсудить за час — вполне. Если нужно было оценить конкретную стори, я например обычно спрашивал того кто потенциально ее будет делать. Не по правилам, но отрывать толпу на 5 минут — как-то глупо.

Все должны быть способны подменить всех. Что за бред? В итоге таски где надо знать хорошо UI делают люди кто шарит только в базах данных. Код выходит соответственный.

Все индивидуально. У нас в команде, например, бэкенды на фронтенд таски не жаловались, скорее даже наоборот, в команде через стенку — жаловались и соответственно не делали. Это должно быть решением команды с учетом особенностей людей. Спускать сверху и надламывать через колено 100% не стоит.

Ревизию архитектуры тоже иногда сложно уложить в таск длиной в день

Обычно предусматривают таски и длинной в спринт. В сложных случаях мы, например, брали время на подумать, соответственно таски результатами которых должен был быть план как мы будем решать эту проблему (соответственно свой набор тасков). Иногда даже на коленке писался PoC, и доносилось что это захардкоженное неработающее решение, сделанно просто шобы было понятен объем работ.

Відповісти

Підтримати

Олексій Пєніє 07.05.2016 22:58

Подбросьте скрам-мастеру слабительное. Если не поймёт — привяжите к батарее, слабительное не отменять.

Відповісти

Підтримати

Vladimir Pauchev Don't care 07.05.2016 23:47

Безусловно, если их скрам мастер будет проводить время в туалете вместо митингов — это улучшит атмосферу в команде.

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 08.05.2016 03:29

Но можно столкнуться с недостатком туалетов. На галерах всегда хватает желаующих порукамиводить.

Відповісти

Підтримати

Vladimir Pauchev

Dmitry Zozulya 08.05.2016 10:24

В туалете атмосферу точно ухудшит...

Відповісти

Підтримати

Vladimir Pauchev

Vladimir Pauchev Don't care 07.05.2016 22:50

Краткий ответ — вы делаете Scrum не правильно.
И такой момент, что да, это не всегда и не везде применимо.

Они расширяют скоп спринта и скрам мастер за это ругает.

Вашего скрам мастера надо уволить, он ничего в скраме не понимает в принципе.

Відповісти

Підтримати

Олексій Пєніє 07.05.2016 22:57

вы делаете Scrum не правильно.
Вашего скрам мастера надо уволить, он ничего в скраме не понимает в принципе.

Эти слова можно высечь в граните. Они актуальны везде, где есть скрам.
Он похож на секс, когда все партнёры против, но не должны подавать виду.

Відповісти

Підтримати

Vladimir Pauchev

Vladimir Pauchev Don't care 07.05.2016 23:06

Ну я бы не сказал.
Проблема вот в чем. Люди которые придумали Agile (и Scrum) ненавидели project manager’ов(имел честь бывать на семинарах/тренингах/конференциях с людьми которые подписали манифест, потому информация скажем так из первых рук) которые работали по PMI методологии(я не совсем уверен как сама методология называется, но речь идет о американской культуре проджект менеджмента). Потому Agile вообще не о том, как доставлять в рамках классического треугольника ПМа. И вот тут вся проблема и кроется. Прикрываясь buzz word Scrum продолжают делать то, что привыкли делать.
Потому проблема не в Scrum, проблема в корпоративной культуре и вашем его понимании.
При этом сам Scrum и Agile панацеей не являются и не везде подходят.

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 08.05.2016 03:27

Всё гораздо банальнее — Scrum подходит далеко не всем процессам. Есть задачи, которые он просто не решает, и потому процессы которые «нерешаемую» категорию задач имеют — не смогут их воплотить в рамках только Scrum, без вышестоящей поддержки.

И да, Scrum действительно превратился в «buzz word». В ритуал. Оттуда выбросили всё «ненужное», оставив только «безвредные» процессы. И потому бесполезные. Как молитва перед завтраком.

Відповісти

Підтримати

Vladimir Pauchev

Dmitry Zozulya 08.05.2016 10:32

Кстати в книге М.Кона «Скрам. Гибкая разработка ПО» написано, что скрам будет работать только если соблюдать все рекомендации на 100%. Попытки что-то упростить или изменить для себя всегда приводят к провалу внедрения.

Відповісти

Підтримати

Олексій Пєніє

Vladimir Pauchev Don't care 08.05.2016 10:53

Это кстати плохая книга. И насчет соблюдения на все 100% тоже не совсем верно. Проблема внедрения как раз не в слепом следовании в попытке создания карго культа, а в изменение парадигмы своего мышления(чему здорово мешает классические PMI подходы).

Відповісти

Підтримати

Alex Koshterek погромизд 08.05.2016 13:03

Небось двухдневный тренинг прошёл за 900 баксов

Відповісти

Підтримати

Vladimir Pauchev

Vladimir Pauchev Don't care 08.05.2016 13:50

Я скорее думаю что какого то PMP обозвали капитаном

Відповісти

Підтримати

Котэ 07.05.2016 22:46

Скрам нужен только бадишопам, чтобы обозначить «значимость» © процесса, а надувание щек имело красивую обертку.
Ну и раздеть клиента на большее кол-во часов, конечно.

Разработчики и QA видели в гробу эти «встаньте дети, встаньте в круг» и глубокомысленные газификации луж в прочих by-the-book ритуалах.

Відповісти

Підтримати

Victor Mikhaylov junior manual tester 08.05.2016 15:12

однобоко. у нас не бодишоп, а инициатива ввести скрам исходит от самих разработчиков. нам так удобно потому что все так привыкли

Відповісти

Підтримати

Котэ 08.05.2016 19:27

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

Однажды в России ,Англии и Франции ввели закон об Анальном Изнасиловании граждан по субботам. Из за этого Англичане переизбрали Парламент , во Франции начались волнения, приведшие к Революции, а в России граждане стали занимать очередь на изнасилование в Пятницу , чтобы пораньше освободиться в Субботу.

Відповісти

Підтримати

Victor Mikhaylov

Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 07.05.2016 22:36

Аналогичный.

Відповісти

Підтримати

Підписатись на коментарі

Ваша пошта

Не підписуватись