"Глупый учится на своих ошибках, умный на чужих".
Всем доброго дня. В этой статье я намереваюсь разобрать ошибки произошедшие и досконально описанные в топике Обратная сторона Agile. Это ни в коей мере не holywar, ни тем более какой-либо blame. Мне лишь интересно препарировать эти вопросы со стороны исследования и отчасти восстановить доброе имя SCRUM'a.
Вопросы и ответы. Всё коротенько.
Прежде чем мы перейдём к разборам ситуаций и попыткам найти правильные решения, а я верю, что практически в любой ситуации его можно найти и тем более применить (иногда через очень больно), я бы хотел ответить на несколько вопросов которые могут возникнуть у читателя.
Кто ты такой чтобы рассуждать о SCRUM'е и разбирать ошибки? — Я сертифицированный SCRUM master по программе SCRUM.org'а. Сейчас PSM level I. Да, я получил сертификат недавно, но практикую и готовлю данную методологию (framework ;) ) уже на протяжении последних лет 5, если не больше, как с нуля, так и меняя существующие.
- Ты то зд**есь что забыл? — У меня свои корыстные цели: я готовлюсь сейчас к сертификации PSM level II, а для подтверждения второго уровня необходимо разбирать кейсы, а не бездумно кликать на правильные ответы, сверяясь со SCRUM Guide. Поэтому подобные случаи для меня — золотой кладезь (да и если кому-то будет интересно, присылайте мне Ваши случаи, постараюсь их препарировать, ну или возопию о помощи и пойду её искать).
Итак, если со всеми вопросами разобрались, приступим.
Вносите пациента.
В один прекрасный момент руководство компании решило попробовать новомодную для России методологию разработки. Был выбран Agile (Scrum), в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а также получить понимание, на что тратят время разработчики.
Найм SCRUM master'а (везде далее SM) — это хороший и логичный шаг, потому что иногда встречаются попытки приготовить SCRUM на своём зачастую специфическом понимании. Надеюсь опыт у человека в этой области был, т.к. делать SCRUM с нуля, занятие далеко не простое, хотя, судя по дальнейшему содержанию исходной статьи, я в этом сильно сомневаюсь. Но пока что оставим его компетенцию под вопросом.
- Коснёмся хотелок менеджмента: улучшение скорости и качество — хорошо, на что тратят время разработчики — это мимо и не к SCRUM'у. Это обычный time-tracking, никак не описанный в SCRUM Guide и его можно применять для любой методологии, будь то KonьBan, Waterfall или прочие RUP'ы.
Я, конечно, прекрасно понимаю, что времена меняются, и раньше, возможно, разработка проекта была чем-то вроде творчества. Теперь это отлаженный бизнес-процесс, целью которого является зарабатывание денег. Но доведенный до апофеоза этот процесс может подавить в разработчиках тягу к креативу и заинтересованности в развитии проекта.
- Как раз задача SCRUM'а — поддержание креативности, заинтересованности и хорошей атмосферы. Основной нюанс — правильно научиться его применять и не менять основные правила, т.к. если в хорошо отлаженном механизме заменить одну деталь совершенно другой, неподходящей ни по размеру, ни по функциям, то получится одно большое ничего из всего механизма.
Поначалу, после внедрения новомодного Скрама, все радовались его логичности и внешней простоте. Всё понятно, делим процесс разработки на спринты, получаем от менеджеров user-story (задачи что делать), включаем их в те или иные спринты, в конце спринта делаем ретроспективу (смотрим что сделали, и что пошло не так) и зацикливаем этот процесс.
- Тут и первая серьёзная ошибка — получение user-story от менеджеров. Из всего текста, прочитанного мною в изначальном топике, я не встретил упоминания роли Product Owner (везде далее РО). Кто же такой РО — человек ответственный за конечное видение, развитие проекта и управление бэклогом проекта, у него есть ещё ряд обязанностей, но пока что ограничимся этими. Т.е. PO — первый сдерживающий барьер от всего стада менеджерья обитающего на просторах вашего офиса. Так это должно выглядеть и работать.
У команды есть РО, который агрегирует все хотелки\видения\фидбэки от всех заинтересованных лиц, обрабатывает этот список и доносит его до команды и РО должен быть один и только один(!) для SCRUM команды, а не куча менеджеров, потому что получится как в той басне Крылова:
Когда в товарищах согласья нет,
На лад их дело не пойдет,
И выйдет из него не дело, только мука.
- Следующий нюанс — отсутствие факта оценки. Может быть автор статьи забыл указать, а может её просто не было, но команда должна давать свою оценку на ту или иную User Story. Если оценка дана кем-то другим, не Development Team'ом (везде далее DT), то это будет боль\печаль и вообще так делать нельзя. Должен соблюдаться постулат, кто выполняет задачу, тот и даёт оценку. Не менеджер Вася, а весь DT.
Менеджмент начал конвертировать задачи во время их выполнения и естественно в стоимость. Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую? Возможно, отдел разработки с точки зрения бизнеса всегда выглядит как ленивые сотрудники, которые хорошо, если бы смогли работать втрое, а лучше в пять раз быстрее, чтобы снизить расходы на разработку и увеличить её скорость.
- Вот в этот момент должен был вступить в игру SM и
послать всех менеджеров в пешее эротическое путешествиеоградить разработчиков(DT) от менеджерского беспредела. Желание менеджмента понятно и применимо: оценить, измерить, сэкономить бабла (не ну всё менеджеры этим занимаются, от этого никуда не деться). Но в данном случае в дело должен был вмешаться SM, принимая весь удар на себя, объясняя всем что делает команда, чем занимается и почему их нельзя трогать. Ну а если в комнату к DT прокрадётся какой-либо особо ретивый менеджер, то гнать его ссаными тряпками. Да, я предвижу возражения: "Чел, этож менеджеры, кто им слово-то против скажет, не говоря про тряпки?", но тут всё достаточно просто, SM заранее должен договориться с ТОП\МегаТОП и прочими большими менеджерами, что команду не трогают и работают через него. Собственно, это одна из обязанностей SM'а — внедрять SCRUM в организации и внедрять его правильно, а не тяп ляп. Тут же судя по всем SM устранился от проблемыи сидел гамал в танчики?
Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени. Стали возникать вопросы в духе «почему вы потратили целый день на разработку или тестирование того-то»?
- Один DT — один PO и желательно один проект (или обязательно один Product Backlog), или необходимо менять серьёзно процесс, менять методологию с чистого SCRUM'а на Kanban (а ещё лучше помесь сделать SCRUMBan, и да, тут нет ничего страшного, если будет интересно, расскажу, как это делать и внедрять
плюс всякой разной чернухи). Т.е. когда много реквестов с многих проектов, то это уже попахивает support'ом и тут лучше уходить от SCRUM'а. Плюс где был SM (аааууу?), почему не защищал DT? Он точно SCRUM знал? Был готов его внедрять? Имел опыт? К этому абзацу я уже сомневаюсь в положительных ответах на эти вопросы чуть более чем полностью.
Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало.
- Не было PO, неверно внедрён SCRUM — отсюда и лютая боль. Если бы был один(!) PO, который отвечал за управление Project\Product Backlog'ом, а не стадо оголтелых менеджеров, то всё было бы проще (Да ему бы пришлось ругаться с менеджерами и быть ими нелюбимым, ну а что делать? Судьба у него такая в некоторых реалиях. Это потом бы уже все попривыкли и смирились.)
Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
- Я повторюсь если скажу, что PO нет и SM мудак и это основная проблема? На самом деле Backlog item (в нашем случае User Story) — это необходимый артефакт, кто-то скажет, что это дань формализму, но тут я посмею возразить — нет. Это описание, понимание и видение конечных результатов того что должно быть сделано. И должно это быть оформлено таким образом, что Вася\Петя\Ктулху из DT — все понимали, что нужно сделать и могли это объяснить PO и SM'у. Зачем объяснять им если они и так знают? Затем, чтобы увидеть, что члены DT правильно понимают и нет разночтений. По рекомендациям — всё просто, выставить PO и SM'a на переднюю линию обороны DT, чтобы все какашки летели в них, а DT отсечь от мира и подогнать им чай\кофе\печенюшки\куртизанок.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
- Framework, Bro. Не методология, ни разу. Она учитывает человеческие отношения это одна из основных целей SCRUM'а и базируется на этих отношениях. Почему я так решил, да вот почему (кусок выдран из SCRUM Guide'а):
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts. Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people
Согласно SCRUM'у люди — основа. Хотя, чего я тут его восхваляю — люди основа везде у любого управленца и при любом процессе\подходе\методологии. Если мозга нет, если же менеджеры думают седалищем, то тут всё плохо.
Уважаемый Keks650, я могу постараться даже дополнить вашу статью, как мне кажется вы забыли упомянуть один серьёзный фактор, который сильно повлиял на всю команду и на весь процесс. Возможно я и ошибусь, но как мне подсказывает интуиция он имел место быть — оценка для User Story рассматривалась как commitment, и разработчики сидели в овертаймах по самые уши. Угадал?
- Казалось бы, это как-то незначительно commitment или прогноз. Какая в пень разница? А различие на самом деле огромно. В SCRUM Guide нет такого понятия как commitment по срокам выполнения. Если задача была оценена неверно\неправильно или не учтены все факторы, то это предмет торга между DT и PO, но никак не "умри, но сделай". Да и вообще есть понятие прогноз, если обратить внимание, то SCRUM Guide не описывает способы эстимации и единицы измерения. Все эти часы, покеры и прочие размеры трусов, появились как локальные расширения, которые "прижились". Но в первоскраме их попросту нет. Таким образом если прогноз не удался, то в рамках Retro, DT должна рассмотреть что\почему и как это исправить, чтобы подобного не повторялось. И если SCRUM внедрён нормально, то проблем с этим не возникает.
Посмертный эпикриз.
Я так полагаю что пациент спасён не был, поэтому подведём итоги.
В принципе все фиксы для ошибок описаны в статье, но ниже я соберу короткое резюме:
- РО и SM должны быть и должны быть вовлечены в процесс согласно своим обязанностям.
- РО должен работать напрямую с stakeholder’ами. DT должна только исполнять видение РО согласно бэклогу проекта и не общаться с менеджерами вообще, кроме как для уточняющих вопросов и получения обратной связи в рамках ревью.
- SM должен быть не для галочки, не потому что это модно\молодёжно, не для попила бабла, а для настройки процесса, т.к. без грамотного SM’a весь процесс пойдёт прахом. В частности, в данной ситуации он должен был инициировать создание роли РО, затем обучить его как работать с бэклогом, DT и внешними менеджерами. Так же на первых парах смотреть чтобы он не накосячил и на него не оказывали излишнее влияние менеджеры.
Затем работать с командой, получая от неё обратную связь и устраняя то что команде мешает: будь то сквозняк в помещении или какой-либо особо назойливый и ретивый менеджер. - У РО должен быть проработанный и приоритезированный Project Backlog, с чётким определением приоритетов, а не так что пришёл очередной парниша и ввёл супер-пупер приоритет потому что ему так надо.
Эпилог
Почему я так отреагировал на статью, местами теряя нить логического повествования и скатываясь в рассуждения - потому что у меня подгорело пожалуй потому что SCRUM хаят очень часто не разобравшись. Как итог это приведёт к тому, что кто-то скажет: "%username%, ты знаешь SCRUM — гавно, соковыжималка и фашизм. Не будем его внедрять." и как итог все что-нибудь потеряют.
В изначальном топике явно видны огромные проблемы в организации самого процесса, на которые забили\положили\подставить_на_своё_усмотрение. SCRUM как раз тут не причём. При правильном подходе он просто бусечка и вообще
Это я могу заявить с полной уверенностью человека, делавшего SCRUM с нуля, изменявшего SCRUM, миксовавшего его с Kanban, использовавшего его успешно с проектами Fixed Price(!).
Да, переход на него агрессивен, новшества всегда, пожалуй, неожиданны и больны, но если его правильно преподнести, то он будет работать очень хорошо.
PS — я не призываю что SCRUM — панацея от всего. Иногда бывает, что он не применим, какие бы асаны ему не пели, но эта неприменимость заключается в разных факторах: бюджет, ограничения, необходимость применять другой процесс. Но, его неприменимость нельзя относить на счёт кривых рук. Кривые руки — это кривые руки, ими можно изговнять всё, не только SCRUM.
Почти все мои рассуждения пересекаются со SCRUM Guide. Очень рекомендую изучить внимательно и работать активно с этим документом, а не слепо следовать за чьим кривым мнением.
Комментарии (155)
sshikov
26.01.2017 21:46>улучшение скорости и качество — хорошо, на что тратят время разработчики — это мимо и не к SCRUM'у.
А разве качество — это не мимо? Не, ну вот серьезно — разве Agile где-то обещает именно повышение качества?
Особенно в такой вот постановке «улучшить скорость и качество» — при том что большинство людей прекрасно знает, во что это как правило выливается. В повышение стоимости, разумеется. Они точно этого хотели?
Mephistophele
26.01.2017 22:21А разве качество — это не мимо? Не, ну вот серьезно — разве Agile где-то обещает именно повышение качества?
Аgile не обещает, а вот SCRUM обещает. Agile и SCRUM — не одно и тоже.
В SCRUM есть такое понятие как Definition of Done которое играет большую роль в рамкам спринта, в котором как раз таки quality goals do not decrease.
Есть ряд нюансов, таких что quality goals вырабатываютя ST'ой. As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.
Кроме того — During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.
Т.е. есть некий документ DoD, который описывает критерии качества для backlog item'а. Что внесёт в DoD команда — полностью на её совести. Но в состав ST входит и РО, а он как раз заинтересованное лицо и представляет всех stakeholder'ов, но в одном лице и если качество не будет соответствовать, ему сделают секир башка. Поэтому РО играет большую роль в определении DoD и как итог определении качества всего продукта.
ЗЫ: все выдержки взяты из SCRUM Guide.
BalinTomsk
27.01.2017 01:41+5Когда я работал в компании РИМ у нас на 15 девелоперов было 1PM, 1 директор и 1 VP (и не одного специального архитектора), компания купалась в деньгах, когда к нам привнесли Agile и Scrum атесстованные мастера, у нас стало 5-7 ПМ-ов на каждого девелопера, целая группа архитекторов (чем они занимались я за несколько лет так и не понял).
Очень скоро RIM умер и даже теперь Blackberry в убытках. Это кстати не едиственная компания, которуя я знаю и что с ней стало в результате прогрессивных методов эффективных менеджеров.
Когда приходит VP с опытом написания софта отпуска таблеток в больнице и учит синьер инженеров как писать высоконагруженные сервера становится печально.
В конце вылилось в то что 90% времени стали тратить на митинги, где девелоперы находясь то в одной виртуальной группе выслушали очередную прогрессивную ахинию.
На девелопмент времени уже не оставалось. Рим развалился. Кто сам сбежал, кто дождался жирного бонуса.
ad1Dima
27.01.2017 08:23+2, когда к нам привнесли Agile и Scrum атесстованные мастера, у нас стало 5-7 ПМ-ов на каждого девелопера, целая группа архитекторов (чем они занимались я за несколько лет так и не понял).
Не думали ли вы, что одновременно, или даже последовательно идущие события не всегда имеют прямую связь между собой?
sshikov
27.01.2017 09:18Ну вы же понимаете, надеюсь, что это не происходит само собой? И вообще ничто не происходит само собой? Что повышение качества — это работа, которая требует времени и стоит денег? Т.е., грубо говоря, проведение ретроспективы — это и есть та работа. И когда говорят, что хотят улучшить скорость и качество — надо заведомо готовиться к увеличению стоимости, разве бывает иначе?
Я это к чему — когда цели ставятся так, в заведомо странной постановке, можно уже не разбирать, что было причиной — Agile или что-то еще. Если мы не знаем, чего хотим достигнуть — мы этого точно не достигнем никогда.Mephistophele
27.01.2017 13:40Ну вы же понимаете, надеюсь, что это не происходит само собой? И вообще ничто не происходит само собой? Что повышение качества — это работа, которая требует времени и стоит денег? Т.е., грубо говоря, проведение ретроспективы — это и есть та работа. И когда говорят, что хотят улучшить скорость и качество — надо заведомо готовиться к увеличению стоимости, разве бывает иначе?
Тут как и везде нужно понимать, если мы ловим рыбу, то не ловим на золотой крючок, ибо дороже выйдет. У скрама, как и любого формализованного процесса есть накладные расходы, пожалуй, их нет только в подходе "Пиши код бл**ть!", но большой продукт уровня Enterprise врядли можно создать по подобной методологии. :)
Просто зачастую с помощью коллективного разума на той же ретре можно найти какие-то вещи которые можно оптимизировать и срубить с этого дофига профита. Вот например эффективное испольование по сути ретро описано в этой книге.
ApeCoder
27.01.2017 13:49+2Повышение качества может даже экономить средства в долгосрочной перспективе. Не сделанный баг не надо воспроизводить, репортить, опять воспроизводить на разработческой машине, тестировать, триажить и т.д… Также учтите, что пока баг живет, на него снова и снова натыкаются новые люди, и часть этих шагов повторяются
sshikov
27.01.2017 14:01В долгосрочной да, может. Хотя до этого еще надо дожить.
Но прямо сейчас — а особенно в сочетании с сокращением сроков разработки — это вряд ли.Mephistophele
27.01.2017 14:12Как правило эффект от экономии наступает через спринт. Т.е. если внедрили и оно заработало, то где-то со следующего спринта будет достаточно ощутимый эффект. Это конечно не прямо сейчас, но вполне ближайшая перспектива.
sshikov
27.01.2017 14:27Мы о каком-то разном качестве очевидно говорим. Я не думаю, что качество разработки в команде можно повысить в рамках спринта, чтобы под этим не понималось.
Mephistophele
27.01.2017 14:37Дано: Разработчик Вася может не докоммитать код в гит. Васе стучали по голове тапком, но Вася упрям и невнимателен. Как итог на QA сервера попадает битый код\solution\продукт, который работает лишь местами. QA инженеры тратят время на то чтобы зайти, посмотреть что билд битый и пойти поругаться.
Решение: Вводим дополнительную настройку CI которая позволяет закоммитать в бранч проекта только после того как пройдёт промежуточный билд фичи. Линкуем статус фичи в билде и статус фичи в системе учёта задач, т.е. пока не будет норм. билда статус сменить нельзя на complete.
Итог: если Вася всё также невнимателен, то QA не тратят время на проверку, мы экономим время и средства и повышаем качество продукта.
Это можно отнести к качеству?
sshikov
27.01.2017 14:59Можно конечно. Просто это частный случай.
В общем случае отчего низко качество разработки: Либо разработчик Вася просто низкой квалификации (тут есть варианты, может он просто новенький), либо эта квалификация низкая у кого-то еще (аналитики, QA и пр.), либо плохо с взаимодействием — из-за чего Васю не понимает QA Петя. И это уже поправить быстро нельзя. Хотя да, внедрение другой методологии может поправить взаимодействие в команде — но вряд ли все-таки быстро.ApeCoder
27.01.2017 15:14Definition of done это как раз про договоренность команды что она считает правильным и как комуницировать между разнми стадиями разработки.
Еще иногда бывает, что на ретроспективе команда решает автоматизировать проверку каких-то критериев.
VolCh
27.01.2017 21:13Вводим дополнительную настройку CI
А причём тут скрамы и спринты? Автоматические и автоматизированные методы контроля качества не привилегия ни то, что скрама, а даже аджайла.ApeCoder
27.01.2017 22:09Тут уже более частная тема — можно ли вообще повысить качество разработки за короткий срок.
Mephistophele
27.01.2017 14:45Вот ещё пример из достаточно раннего, сейчас вспомнил. Кстати реально существовавшая ситуация.
Дано: есть legacy система, её нужно мигрировать на новые "рельсы", тобишь с применением модных и современных фрэймворков. В системе достаточно строгие требования по валидации и UI элементам. Разработчики могли забить на расположение элементов или не докрутить валидацию.
Решение: расширили DoD, введя чеклист из, вроде, 10 пунктов, где было описано проверь то, затем проверь то и если есть это, то ещё и вон то. Распечатали и повесили у каждого на перегородку, Плюс ввели в воркфлоу в джире дополнительный этап — проверка согласно DoD. На это выдавалсь 20-30 минут где-то (за это время можно и проверить и сходить покурить, сам заполнял такие листы и тогда ещё курил), как итог разработчик прикреплял заполненный чеклист (да он был и в электронном виде).
Итого: Количество UIных багов сократилось в 7 раз. В течении 2х недель.
А теперь представьте что это был проект в котором работало 70 разработчиков и примерно 50 тестировщиков.
Подходит под описание качества?
sshikov
27.01.2017 15:06Вы получили хороший и быстрый эффект потому, что ваши работы масштабировались на 120 человек. Т.е. все по большому счету делали примерно одно и тоже и допускали примерно одинаковые баги. Но это все равно частный случай.
Это не всегда так. Это не всегда так просто достигается.
sshikov
27.01.2017 14:00Да речь даже не о накладных расходах. Просто качество и скорость разработки — это противоречивые критерии. Они сами по себе не достигаются одновременно — а только ценой повышения стоимости.
И если задача изначально ставится как «хотим это и это» — то никакая методология тут ничего не даст, потому что чудес не бывает. И тут можно уже не разбирать детально причины провала — постановка противоречивых целей и есть одна из главных причин.Mephistophele
27.01.2017 14:10И тут можно уже не разбирать детально причины провала
Всегда нужно разбирать причины провала, чтобы снова не зафакапить. Я, например, веду в OneNote общие заметки по проектам, только для себя лично. Этакий post mortem. Чтобы в дальнейшем не зафакапиться, бо и у самого скелетов в шкафу хватает.
oldschoolgeek
27.01.2017 14:06есть некий документ DoD, который описывает критерии качества для backlog item'а. Что внесёт в DoD команда — полностью на её совести.
Ах, если бы это было так! В реальности, зачастую бывает совсем по-другому, и вовсе не потому, что команда не умеет «готовить» Scrum. А потому, что качество — это просто ещё одна из характеристик создаваемого программного продукта, и далеко не всегда заказчик готов платить за решение, сделанное полностью «по фэншую».Mephistophele
27.01.2017 14:08Есть такое. Просто иногда нужно это очень аккуратно размазать в project plan'е и не палиться. Т.е. задачу можно сделать за 4ч., но заложив накладные расходы на нормальный процесс мы получим 5ч., вот последнюю цифру и отсылаем заказчику.
oldschoolgeek
27.01.2017 17:56«Прятать шляпу» — это святое :) Правда, есть особо въедливые заказчики, эдакие control freak'и, которые сами перепроверяют чуть ли не каждую строчку в коде, и, если, например, увидят там юнит-тест, хотя сами говорили «юнит тесты не пишем» — жди скандала.
http3
26.01.2017 22:39команду не трогают и работают через него (СМ)
А потянет ли 1 СМ команду из 25 разрабов и 13 менеджеров? :)
Коммуникация вместо разраб <-> менеджер будет разраб <-> СМ <->менеджер? :)
(менеджеры не из бизнеса, а менеджеры проектов, бизнес-аналитики)
работая параллельно над тремя-пятью проектами каждый
Разве скрам подходит для аутсорса? :)
Т.е. когда много реквестов с многих проектов, то это уже попахивает support'ом и тут лучше уходить от SCRUM'а.
А если много запросов с одного проекта? :)
Я повторюсь если скажу, что PO нет и SM мудак и это основная проблема?
Короче, все зависит от людей.
Дебилы могут испоганить что угодно. :)
Т.е. PO — первый сдерживающий барьер от всего стада менеджерья обитающего на просторах вашего офиса.
Хм.
А у нас не так.
Менеджеры из бизнеса называются просто бизнес.
А менеджеры проектов являются и PO.
Вот эти PO и неадекватные. :) Вообще не фильтруют бред от бизнеса.
А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :) Если бы скрам внедряли адекватные люди, то возможно и проблем бы не было. Да проблем не было при любой методологии.
Скрам — это гибкая методология?
Как часто допускается вносит изменения в ТЗ?khim
27.01.2017 03:29+2Коммуникация вместо разраб <-> менеджер будет разраб <-> СМ <->менеджер? :)
Да, разумеется. Собственно основная проблема, которую так или иначе пытаются решить все эти методологии — это решить всем известную проблему. Менеджеры часто искренне стараются помочь разработчикам делать своё дело (а иначе зачем они нафиг нужны?), но не понимая чем «время творца» отличается от «времени менеджера» делают только хуже. И даже рассказы в красках не помогают. Приходится вводить какую-то формализацию, позволяющую оставить разработчикам возможность, собственно, разрабатывать.
(менеджеры не из бизнеса, а менеджеры проектов, бизнес-аналитики)sshikov
27.01.2017 09:24Именно. Вот довольно типичная картина из жизни: говоришь PM, что не хватает времени, так как занят несколькими проектами. И митинги, в том числе, отнимают слишком много полезного времени. В ответ организуется еще два дополнительных митинга на неделе. Спрашивается — для чего? Чтобы помочь с работой? Так я не просил вроде, да и не может он этого. Чтобы лучше понимать, чем я занят, и контролировать сроки проекта? А то что два митинга — это еще два часа из моего и так совсем не резинового временного бюджета — это не доходит?
khim
27.01.2017 12:55+3А то что два митинга — это еще два часа из моего и так совсем не резинового временного бюджета — это не доходит?
В том-то и дело, что нет! Менеджеры свою основную работу часто делают на тех самых митингах (по русски, вообще-то — совещаниях) и дополнительные совещания для них весьма полезны (вместо досятка писем достаточно переоброиться лично парой фраз). Представить себе, что для разработчика, в общем-то ситуация противоположная — они просто не могут. Не «не хотят» — не могут. Они по-другому устроены в большинстве своём, иначе они выбрали бы другую работу! Типичная реакция на рассказ — там же, в комментариях: «Какие мы нежные. Поплачьте в углу, только соплями не захлебнитесь, нытики.»
Многие менеджеры искренне полагают, что тот факт, что разработчики не умеют жить по их расписанию — проблема, которую нужно исправить — и на фирме наступит согласие. Так зачастую и происходит — а что при этом людей, способных глубоко вникнуть в суть проблемы и сделать всё быстро и качественно на фирме не остаётся совсем — вещь, которая из их сознания ускользает.ApeCoder
27.01.2017 13:37Типичная реакция на рассказ — там же, в комментариях: «Какие мы нежные. Поплачьте в углу, только соплями не захлебнитесь, нытики.»
Я довольно давно занимаюсь разработкой, но вот в таком тоне со мной никто ни разу не говорил.
qw1
28.01.2017 19:20Попробуйте объяснить менеджерам, что отвлекать вас в середине рабочего дня нельзя, и если захотят что-то спросить, уточнить, или предложить, пусть приходят после 17:00. Тогда и услышите от них всё, что они думают по этому поводу )))
ApeCoder
28.01.2017 21:03+2Ну какое-то количество совещаний должно быть же. Надо координировать работу. Мой рецепт — когда в течение нескольких дней в рамках daily scrum говоришь, что задача не продвинулась, так как часто отвлекали, то они сами что-нибудь придумывают :)
И даже, если бы я такое сказал, про до 17:00 скорее всего ответ был бы конструктивный, а не хамский.
qw1
29.01.2017 10:19+2когда в течение нескольких дней в рамках daily scrum говоришь, что задача не продвинулась, так как часто отвлекали, то они сами что-нибудь придумывают
Нет, потому что «что такого, мне всего на 1 минутку спросить» и тут нужна инфа по своей задаче, которая попадёт в следующий спринт, а разработчик делает «чужую» (это если BA контактируют с разработчиками в обход SM и PO)
Mephistophele
27.01.2017 13:47+1Разные системы координат. Если менеджер гавно, то лучше уйти. Я как-то почти год мучался, держал проект в зелёной зоне (это когда всё хорошо), когда соседние проекты рушились. Со мной половина delivery менеджеров уже не здоровалась (не удивлюсь если и иголки Вуду втыкали в мою куклу, в грёзах так точно). Но проект держался, команда была довольна, они работали, создавали продукт. Соседние проекты сидели в жёлтой и красной зонах — это когда плохо и очень хе**во. А я был просто конченный мудак (с точки зрения некоторых менеджеров), отстаивал интересы команды, но только и клиент оставался всегда доволен. :)
ApeCoder
27.01.2017 10:24А потянет ли 1 СМ команду из 25 разрабов и 13 менеджеров? :)
Никаких менеджеров в скраме нет.
http://www.scrumguides.org/scrum-guide.html#team
Development Team Size
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
Как часто допускается вносит изменения в ТЗ?
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team
http3
27.01.2017 10:31Назовите их бизнес аналитики, PO, как угодно.
Ок, пусть нету.
Потянет ли 1 СМ команду из 25 разрабов? :)
Он будет ТЗ писать? :)ApeCoder
27.01.2017 10:41Удалось ли вам прочитать хотя бы те цитаты, которые я привел? Хотя бы выделенное жирным ;)
Там есть про рекомендуемый размер комаднды.
Посмотрите в скрам гайд.
Задача SM — чтобы процесс соблюдался, а не писать ТЗ.
Задача PO — чтобы продукт был клёвый — управление беклогом и приоритетами.
Никаких ТЗ в скраме нет, как собирать требования, в какой форме их представлять — не ограничивается. Скрам про управление процессом разработки.
В Agile духе писать User Stories.
Если вы хотите разобраться — читайте гайд — он написан понятным языком и хорошо структурирован.
http3
27.01.2017 15:03+1Это из-за различия терминологии.
Нету менеджеров. А под менеджерами я понимал то, что тут называют СМ:
линк
проектные менеджеры должны играть роль скрам мастера
Нету ТЗ.
В Agile духе писать User Stories.
Та плевать как вы это назовете.
Скрам про управление процессом разработки.
Судя по всему это 5-ое колесо в телеге. :)ApeCoder
27.01.2017 15:18Та плевать как вы это назовете.
Это как раз одна вещей, которая сильно улучшает ваимодействие между людьми — называть одно и то же одними и теми же словами :)
Mephistophele
27.01.2017 15:19Нету менеджеров. А под менеджерами я понимал то, что тут называют СМ:
Не-не-не. Не перевирайте, пожалуйста, мои слова. Я описал фикс и моё видение для кокретного состава команды, приведённого в изначальном комменте. Исходя из того что в рамках бизнеса состав команды поменять невозможно, можно лишь сделать иной сетап с иными входными инструкциями к дейтсвию. Иногда это помогает.
http3
27.01.2017 15:49Та я вижу, что Вы уже поменяли свое мнение. :)
Вот так у нас внедрили скрам. :)
Лучше бы часы придавили. :)Mephistophele
27.01.2017 15:51Где я мнение поменял?
Я дал своё видение как оно должно быть или как бы пробовал на входе это переделать при существующем раскладе. Я мнение не менял.
ApeCoder
27.01.2017 10:32+1А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :)
В скраме команда самоуправляема, и встроенны механизмы обратной связи от разработчиков — каждый день задается вопрос, не мешает ли что разработке, по окончанию спринта устраивают ретроспективу.
http3
27.01.2017 15:09Только в жизни выходит наоборот.
Команда была самоуправляема до внедрения модных методологий, а чем больше внедряют методологию, тем больше выходит наоборот.ApeCoder
27.01.2017 15:25Как выяснилось выше, некоторые даже не дают себе труда разобраться в том, что из себя представляет методология. Хотя бы на уровне основных понятий. :) Но при этом делают выводы космического масштаба. Разумеется, им можно втюхать любой карго культ и назвать чем угодно.
VolCh
27.01.2017 23:22+2Что значит «втюхать»? К нам приходит начальник, приводит человека и говорит его во всем слушаться. Человек говорит делать то-то и то-то и говорит, что это называется скрам. Мы делаем то, что он говорит и получается ерунда какая-то. Логичный для нас вывод, что то, что называется скрам — ерунда какая-то. Мы разработчики, мы не менеджеры, нам нет нужды разбираться в методологиях управления разработки, мы объекты этих методологий, а не субъекты.
ApeCoder
28.01.2017 14:55нам нет нужды разбираться в методологиях управления разработки, мы объекты этих методологий, а не субъекты.
Это ваш выбор, но вы почему-то здесь распрашиваете про методологии и о них рассуждаете. Значит это вам почему-то интересно и роль объекта вас не устраивает.
Если бы вы разобрались раньше, у вашего начальника появилось бы второе аргументированное мнение по поводу процесса, у вашего скрам-мастера была бы возможность узнать что-то новое, а у вас получить более устраивающий вас процесс.
Но если вы хотите быть объектом, то пожалуйста, стойте куда вас поставят и говорите себе, что ничего изменить нельзя, или это не ваше дело, или что виноват скрам-мастер или тупой начальник.
VolCh
29.01.2017 02:07Меня устраивает роль объекта управления, но не устраивает когда субъекты управления перекладывают на меня свою ответственность за результат их управления. Без всяких формальных методологий почему-то я отвечаю только за свою работу только перед непосредственным начальником, но как только начинается сверху «так жить нельзя, внедряем XYZ», то и продуктивность моя падает, и ответственности я начинаю нести больше, а предложения по улучшению процессов типа «давайте работать, а не митинги проводить» встречают «железный» аргумент: «у нас XYZ, а по нему митинги нужно проводить».
ApeCoder
29.01.2017 19:13Меня устраивает роль объекта управления, но не устраивает когда субъекты управления перекладывают на меня свою ответственность за результат их управления.
Какая кому разница, что вас не устраивает, если вы объект? И самое главное какая для вас польза жаловаться на хабр и не пытаться изменить не устраивающий вас процесс доступными способами.
а предложения по улучшению процессов
Во-первых, как только вы вносите какие-то предложения, вы становитесь субъектом — так как сами пытаетесь внести какие-то изменения в процесс.
типа «давайте работать, а не митинги проводить» встречают «железный» аргумент: «у нас XYZ, а по нему митинги нужно проводить».
Во-вторых, для того, чтобы контрагрументировать железный аргумент, надо знать и понимать XYZ. Это если вам хочется что-то изменить. А если не хочется, то зачем вообще вносить предложения?
— Нет, профессор, ответственность работает не так, — Гарри заговорил таким голосом, словно он объяснял что-то ребёнку, который наверняка ничего не поймёт. Мальчик отвёл от неё взгляд и уставился куда-то в стену справа от неё. — Когда проводишь анализ ошибок, нет никакого смысла винить ту часть системы, которую всё равно не удастся изменить в следующий раз — это всё равно, что прыгнуть со скалы и обвинить гравитацию. Гравитация в следующий раз будет совершенно такой же. Нет смысла пытаться возложить ответственность на тех людей, которые всё равно не изменят своего поведения. И если вы посмотрите на дело с такой стороны, то поймёте, что обвинять имеет смысл только самого себя, потому что именно вы и есть тот единственный человек, чьи действия вы можете изменить, возлагая на него ответственность
Например, если у вас менеджер, верящий в XYZ и вы не можете это изменить, стоит это использовать.
VolCh
29.01.2017 19:34Какая кому разница, что вас не устраивает, если вы объект?
Объект я в процессе управления разработкой, а в трудовых отношениях я полноправный субъект, и если что-то меня не устраивает в роли объекта управления, то в роли субъекта трудовых отношений я протестую
Во-первых, как только вы вносите какие-то предложения, вы становитесь субъектом — так как сами пытаетесь внести какие-то изменения в процесс.
Внося предложения я становлюсь субъектом не процесса управления разработкой, а субъектом процесса управления процессом разработки, но быть субъектом процесса управления разработкой я не хочу. Проще говоря, у меня есть мнение как лучше управлять разработкой, по сути как лучше управлять мной, но сам участвовать в этом управлении не хочу. А «эффективные менеджеры», внедряя какой-то модный процесс, пытаются прежде всего повесить на меня роль субъекта управления разработкой, но не допускают меня в роль субъекта управления управлением. Грубо, они хотят чтобы я участвовал в принятии решений что и как делать в рамках спринта, чтобы сделать как можно больше важного именно сейчас, но к принятию решения сделать спринт единственным, но бесконечным, не допускают.qw1
29.01.2017 21:11+2Грубо, они хотят чтобы я
У меня такая же проблема. Спрашивают, не желаю ли я получить новую эргономичную клавиатуру (и вообще, интересуются, какие клавиатуры мне больше нравятся), но моё мнение о покупке X-BOX в офис их вообще не интересует.
ApeCoder
29.01.2017 21:49Непонятно, почему отмена итераций -> субьет процесса управления процессом, а, например, замена комитментов на форекасты -> субъект процесса :). К тому же, когда вы меняете процесс управления процессом — это опосредованное управление процессом :).
Мне кажется, уже схоластика пошла какая-то. Я за этим вижу форму игры ПБВНДН
Mephistophele
27.01.2017 13:21+2А потянет ли 1 СМ команду из 25 разрабов и 13 менеджеров? :)
В скраме команд из 25 человек не бывает или это уже будет не правильный скрам. Команда должна быть от 3х до 9 человек — это достаточно жёсткое тербование. Таким образом, мы получаем около 4х команд, по 6-5 разработчиков в каждой. Да, такой состав один скрам мастер потянет, а отбиваться от 13ти менеджеров не такое уже и дурное занятие при наличие необходимого опыта.
Разве скрам подходит для аутсорса? :)
Аутсорс это такие же проекты как и всё остальное. Есть 2 основных типа оплаты проекта: Fix Price (когда платят за проект определённую сумму, т.е. продукт стоит столько-то и не центом больше) и Time&Material(когда платят за работу, т.е. за сколько часов отчитались, столько и получили), на второй тип оплаты проекта всё ложится просто изумительно; с первым же придётся немного погеммороится — там нужно сразу заложить в проектный план(ну или видение проектного плана) всю скрам коммуникацию. а это примерно 2ч из 8ч рабочего дня; но ничего сложного в этом нет. Я сам работаю только в аутсорсе, так сложилось, и вполне годно применяю скрам.
А если много запросов с одного проекта? :)
Смотреть надобно, если это багофикс или maintenance, то тут лучше Kanban, если новый development, то таки лучше как правило SCRUM.
А менеджеры проектов являются и PO. Вот эти PO и неадекватные. :) Вообще не фильтруют бред от бизнеса.
Посмею заметить, что это не правильно. Люди от бизнеса должны быть РО, а проектные менеджеры должны играть роль скрам мастера. Но если люди не адекватные, то тут печаль-беда.
Скрам — это гибкая методология?
Да, гибкая.
Как часто допускается вносит изменения в ТЗ?
Смотрите, в скраме нет такого понятия как ТЗ. Там есть project backlog и есть sprint backlog. Первый можно изменять когда угодно и как угодно, изменения должен вносить Product Owner. Второй же — sprint backlog — он формируется development team'ом, согласно приоритетам product owner'a, но его изменять не может никто. Только если члены команды разработки видят что там дофига как-то работы и что-то не учли, то они(и только они) могут раздробить какие-то задачи или выделить из уже сущесвтующих в рамках этого спринта и положить в sprint backlog. Т.е. по сути в течении спринта, sprint backlog принадлежит только команде разработки и никто туда соваться не имеет права. А большой бэклог, пожалуйста, и в хвост и в гриву, меняйте. Главное чтобы бюджета хватило. :)
http3
27.01.2017 14:58Аутсорс это такие же проекты как и всё остальное.
Под аутсорсом понимается веб с кучей клиентов (сайтов).
Посмею заметить, что это не правильно. Люди от бизнеса должны быть РО, а проектные менеджеры должны играть роль скрам мастера. Но если люди не адекватные, то тут печаль-беда.
А, тогда у нас 25 разрабов, они, конечно поделены на команды.
И 13 скрам-мастеров. :)
Т.е. по сути в течении спринта, sprint backlog принадлежит только команде разработки и никто туда соваться не имеет права.
Если PO вносит кардинальные изменения, то нужно ли команде продолжать делать старое неактуальное задание или делать новое? Как на это смотрит скрам?Mephistophele
27.01.2017 15:26Под аутсорсом понимается веб с кучей клиентов (сайтов).
Может быть стоит посмотреть в сторону микса скрама и коньбана.
И 13 скрам-мастеров. :)
Не, у вас 13 менеджеров :) Они ни разу не скрам мастера, судя по всему. :)
Если PO вносит кардинальные изменения, то нужно ли команде продолжать делать старое неактуальное задание или делать новое? Как на это смотрит скрам?
Тут должен смотреть Product Owner, если он видит что цели спринта уже не принесут ему business value или они уже obsolete, то он может прервать спринт. Но скрам на подобное смотрит ОЧЕНЬ отрицательно, хотя и допускает. При том если часть сделанной работы можно использовать в дальнейшем, то её нужно использовать. При этом если спринт прерван, то тут же начинается новый, но уже согласно новым целям и бизнес видению.
http3
27.01.2017 15:41Не, у вас 13 менеджеров :) Они ни разу не скрам мастера, судя по всему. :)
Хм.
Ну так я и говорю, что это менеджеры проектов. :)
Значит у нас скрам-мастеров нету и мы работаем по скраму.
Скрам-мастеры в скраме как бы и лишние. :)
Или с кем cкрам-мастеры будут общаться? С теми 13 менеджерами проектов? :)
У нас уже и над теми 13 менеджерами есть еще одни менеджеры, а уже над теми бизнес. :)
Нужно еще больше менеджеров (мастеров)?
Или таки меньше? :)
ApeCoder
27.01.2017 15:28Ответили же — в пределах спринта команда решает. Чтобы уменьшит количество кардинальных изменений в рамках одного спринта надо хорошо грумить беклог на вертикальные кусочки.
Cromathaar
27.01.2017 14:43Скрам — это фреймворк. А фреймворк — это, вообще говоря, задание потока управления. Например, ночью спите, в 8 на работу, в 6 с работы, отдых до полуночи, и так по кругу. Фреймворк «я трудоустроен» управляет потоком вашей деятельности. То же самое делает и Скрам, а задача его — дать вам понимание относительной эффективности продакт менеджемента и практик разработки. Это же в самом Скрам гайде написано, но, мне иногда кажется, что люди смотрят в книгу, а видят фигу. Сам по себе Скрам не говорит вам ни как бэклог формировать, ни как планировать, ни как разрабатывать. Вы делаете все это так, как считаете нужным, а Скрам дает вам понять, насколько это удачные или неудачные решения, а спроектирован он таким образом, чтобы проблемы всплывали, как можно быстрее. Таким образом Скрам не про «скорость и качество», а просто про качество, а скорость — лишь побочный эффект, т.к. качественное проще модифицировать, а постоянные модификации и адекватное реагирование на них — это и есть суть Agile, который про ушедшие от водопада бизнесы, которые вынуждены были становиться все динамичнее и динамичнее, отвечая на вызовы рынка.
http3
27.01.2017 15:25это и есть суть Agile, который про ушедшие от водопада бизнесы, которые вынуждены были становиться все динамичнее и динамичнее, отвечая на вызовы рынка.
Только выходит наоборот. :)
Адекватно оттюненный водопад лучше неработающего скрама (а это почти всегда так). :)Cromathaar
27.01.2017 16:04Потому что водопад прост, как пять копеек. С точки зрения понятности процесса, понятное дело. Вокруг аджайла и скрама же молодые и перспективные, как здесь справедливо уже было замечено, выстроили целый ритуальный культ. Вы вот заметили, что ни в этой статье, ни в статье, на которую эта статья ссылается, по факту нет ничего про саму разработку. Т.е. пришли некие люди, поменяли процесс. Как это повлияло на инженерные практики? Какие они были до? Какие они стали после? На каком основании одни заменились другими? Как это повлияло на технические метрики? Ничего этого нет. Есть только пара слов про убиение творческого начала. Потому что все это лишнее, мешающее, приземленное и плебейское, когда речь идет о высоком — поставке ценности, ценностях команды, самоорганизации и разделении принципов. Как это все может вообще работать при такой интерпретации? Да вообще никак. Оно, собственно, и не работает.
Mephistophele
27.01.2017 16:08Как это повлияло на инженерные практики? Какие они были до? Какие они стали после? На каком основании одни заменились другими? Как это повлияло на технические метрики? Ничего этого нет.
Как на всё это влияет водопад? :)
Cromathaar
27.01.2017 16:35Водопад — это процесс разработки, поэтому влияет напрямую. В ванильном водопаде, например, нельзя проектировать, когда пошел уже этап конструирования. Ну вот нельзя и все. Соответственно про TDD, например, как про инженерную практику можно забыть. Скрам, как ниже правильно отметил ApeCoder, — это не процесс, это организационно-коммуникационный фреймворк, который про то, как заставить всех общаться в ключе выявления изъянов в процессе, который может быть любым (даже водопадом при некоторых допущениях).
Mephistophele
27.01.2017 16:41Какие технические метрики тогда определяет водопад?
Cromathaar
27.01.2017 16:53Метрики — это измерение чего-либо с целью понимания ситуации путем сравнения. Мерить и понимать вы можете что угодно и где угодно. Можете мерить кол-во строк кода, кол-во регрессий, велосити команды, etc. Какая разница, водопад там или нет.
Mephistophele
27.01.2017 19:29Что такое метрики я знаю, а вот какие конкретно водопад предлагает?
Cromathaar
27.01.2017 21:26Вы, наверное, невнимательно прочитали мой предыдущий ответ. Попробуйте еще раз.
Mephistophele
28.01.2017 01:00Прочитал, но конкретики не нашёл, поэтому вернусь к вопросу. Какие конкретно метрики водопад предлагает использовать?
ApeCoder
27.01.2017 16:12+2SCRUM — это про процесс — организацию и коммуникацию.
https://martinfowler.com/bliki/FlaccidScrum.html
XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work.
schroeder
27.01.2017 01:22+3DT, PM, SM и т.д.
Вопрос: сколько букв вы сэкономили используя эти сокращения и сколько раз «что это за херь?» прозвучало из уст читателей? Это того стоит? Посчитайте общее количество букв в этом топике и количество сэкономленных букв. Прикиньте какие это доли процента. 0.01%? Меньше?
vadim_ig
27.01.2017 10:15+4С каждым днем во мне укрепляется уверенность, что скрам придуман и продвигается с единственной целью — самообеспечение. Все эти скрам-тренера, скрам-консультанты… Огромное количество людей кормится на ритуальной части. А результат внедрения скорее зависит от качества команды — хорошей будет достаточно описания технологии, чтобы извлечь возможные для себя выгоды, а плохая завалит все и сведет к имитации процесса, сколько тренингов не проводи и как их не сопровождай. Под командой я имею в виду всю цепочку, заинтересованную в производстве: заказчик-менеджер-исполнитель. На практике все равно все сведется к банальным вещам — достаточно ли у заказчика денег, есть ли талантливые архитекторы, эффективен ли менеджмент, мотивированы и квалифицированы ли исполнители, реалистична ли задача…
Mephistophele
27.01.2017 13:27+1Не соглашусь. Я столько видел кривых имплементаций скрама, что аж жуть берёт.
Вообще у него другая задача — когда заказчик хочет непонятный космический корабль, а на деле ему нужна глубоководная субмарина, но он этого не понимает, т.к. у него нет необходимых знаний, но есть какое-то смутное конечное видение из разряда: "Хочу большой корабль, способный бороздить бескрайние, чёрные глубины." Вот тут-то и приходит на помощь скрам, где всё делается постепенно и шаг за шагом. Т.е. в скраме развернутья и побежать в другое направление проще, нежели в последовательных методологиях.
А то что многое зависит от команда — да, никто и не спорит.Cromathaar
27.01.2017 14:50Тут на помощь приходит инкрементная итеративная разработка, а не Скрам, и технические методологии ее поддерживающие, например ХР. Скрам всего лишь даст вам понять, насколько хреново формируются, оцениваются и реализуются требования, и даже не предложит никаких решений, решения вы должны будете найти сами. Это лакмусовая бумажка процесса разработки, но не более.
Mephistophele
27.01.2017 15:29Скрам тоже итеративен, кстати. Но он не методология, а фреймворк, поэтому иногда скорость фикса той или иной проблемы зависит от опыта, знаний и команды. Тот же RUP\XP предоставит наличие дополнительных артефактов, но проблемы сам тоже не пофиксит. Всё от людей зависит.
Cromathaar
27.01.2017 16:26Хорошо, давайте разбираться. Ваш пример:
«Вообще у него другая задача — когда заказчик хочет непонятный космический корабль, а на деле ему нужна глубоководная субмарина, но он этого не понимает, т.к. у него нет необходимых знаний, но есть какое-то смутное конечное видение из разряда: „Хочу большой корабль, способный бороздить бескрайние, чёрные глубины.“ Вот тут-то и приходит на помощь скрам, где всё делается постепенно и шаг за шагом. Т.е. в скраме развернутья и побежать в другое направление проще, нежели в последовательных методологиях.»
Ответом на это является инкрементность и итеративность. Клиент приходит, рассказывает сказки, через равные интервалы видит результат, вносит коррективы и так по кругу. Внимание, вопрос: где тут Скрам? Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность через механизм спринтов. Но суть в том, что самих по себе их достаточно для обеспечения того, что вы описываете, и Скрам тут — ни к селу, ни к городу. Другое дело, если бы вы говорили, что инкрементности и итеративности может быть недостаточно для обеспечения надлежащего качества/объема работ или попадания в сроки при заданном бюджете. Вот тогда можно было бы говорить о Скраме как об инструменте, с помощью которого можно понять, где есть проблемы (на стороне PO, на стороне команды или и там, и там), которые снижают оные показатели. Еще раз — лакмус.Mephistophele
27.01.2017 16:35И как вас SCRUM поможет попасть в бюджет при Fix Price и изначально зафакапленной оценке? Как на это поможет XP?
Cromathaar
27.01.2017 16:43Скрам поможет вам понять на ранних этапах, что вы не успеваете в свой фиксед прайс. После первого же спринта у вас разработчики собираются на ретро и начинают ныть, что не успели полбэклога они потому, что постоянно меняли одни и те же файлы все вместе, из-за чего уходила тонна времени на слияние. Скрам заставляет их не молчать в тряпочку, не дуться втихую на Васю и не обсуждать эти проблемы только с Петей на перекуре, потому что остальные «ну дебиииилы», а говорить об этом открыто. Задача SM'а не дать скатиться этому в базар. И если он со своей задачей справится и поможет команде самоорганизоваться, т.е. самой поднимать проблемы, обсуждать их и находить решения, то есть все шансы вернуться на нужные рельсы и таки успеть фиксед прайс в срок. В данном конкретном примере, команда имела бы все шансы решить, что им срочно нужно в систему контроля версий, иначе кердык.
ApeCoder
27.01.2017 16:39Ответом на это является инкрементность и итеративность.
Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность
Скрам тут — ни к селу, ни к городу.Вам же надо будет выбрать какой-то процесс или придумать свой, чтобы поддерживать инрементность?
Cromathaar
27.01.2017 16:46Безусловно. Иногда Скрам описывают как контейнер для процесса, хоть это и не совсем корректно.
vadim_ig
28.01.2017 01:15Кривая имплементация обычно обусловлена куда более серьезными проблемами проекта, чем неправильный подход к разработке. А десант скрам-поддержки от специализированной компании может говорить прекрасные и правильные вещи, но изменить ничего не в состоянии. Они просто поддерживают ритуал — видимость прогресса, что даже опаснее, на мой взгляд, чем честный фейл в самом начале.
Вот например, статья — первоисточник. Похоже руководство просто решило подзатянуть гайки, заставить сотрудников работать интенсивнее, пусть и с перегибами. Так вышло, что перегиб принял форму скрама. А мог выразиться в штрафах за минутные опоздания и запретах обеденных перерывов… Едва ли проблему можно было бы решить просто приходя вовремя и не обедая.
VolCh
27.01.2017 10:53+2Один DT — один PO и желательно один проект (или обязательно один Product Backlog), или необходимо менять серьёзно процесс, менять методологию с чистого SCRUM'а на Kanban (а ещё лучше помесь сделать SCRUMBan, и да, тут нет ничего страшного, если будет интересно, расскажу, как это делать и внедрять плюс всякой разной чернухи).
Очень интересно. Вот конкретная ситуация есть, дано:
— одна команда
— два бизнеса, аналогичные по сути, но с поправками на разные юрисдикции, языки, обычаи делового оборота и некоторые регламенты
— технически две независимые системы уровня ERP+CRM, плюс интеграции с внешними системами, плюс по публичному веб-сайту с развитым «личным кабинетом», практически аналогом фронтофиса в сотнях отделений «на земле», функциональность пересекается процентов на 90 в идеале, по факту около 50 сейчас (где-то реализована одна фича, где-та другая, а должен быть один набор фич), архитектура когда-то была обычная трехзвенка, сейчас стала сервис-ориентированная с уклоном в микросервисы путем выделения из легаси-монолита. В идеале и кодовая база должна быть общей, но с полгода назад для второго (нового) бизнеса форкнули репозитории первого и с тех пор развиваются независимо, сводясь лишь иногда копипастой баг-фиксов, и то не всегда когда надо бы. Для команды по факту есть два глобальных проектах с кучей подсистем, обычное дело для одной юзерстори затронуть с три-четыре подсистемы.
— бизнес не воспринимает системы как единое целое, для него проект — это бизнес-фича, набор новых юзерстори и(или) качественное изменение старых. Это может быть новая подсистема, это могут быть заметные изменения в нескольких существующих. У каждого такого проекта свой владелец, но и у каждой подсистемы с видимым UI есть владелец в бизнесе, у некоторых подсистем в двух бизнесах один владелец, у некоторых (например по бухучету) два, но кроме них задачи команде или отдельным специалистам ставят и другие заинтересованные лица, обычно подчиненные владельца, но нередко и из параллельных департаментов. Конфликты интересов по приоритетам обычное дело, из-за чего часто в работе несколько задач с одинаковым приоритетом, что часто приводит к тому, что вместо запуска одной фичи через месяц, а второй через два, обе релизится в лучшем случае через два c половиной.
— наиболее квалифицированных членов команды часто вызывают на внезапные (для них) длительные совещания по планированию запуска новых фич, по которым им ставится неформальная задача «подумать», не фиксируемая в трекере в принципе
— временная оценка задач дается командой в часах в форме «минимум 80 часов», но бизнес практически всегда переводит её в даты для себя, хорошо если из расчёта 40 часов в неделю и воспринимает не как прогноз, а как обязательство
— постоянные задачи по поддержке, типа зайти в базу ручками и что-то добавить/изменить задним числом. Задачи быстрые, но частые. За месяц грубо набегает время, достаточное для создания UI для таких кейсов
— технический долг огромный, ядро системы разработано в 2011-м, сменилось полностью минимум три поколения разработчиков, считая сейчас четвертое, в которое из третьего перешел только я. Навскидку нужно два месяца работы всей команды без отвлечения на текущие задачи чтобы прикрыть хоть наиболее важные костыли, и даже известные баги и дыры в безопасности и инкапсулировать не самые важные. Долг постоянно растёт. При том что бэклог бизнес-задач на полгода точно.
Попытка внедрения скрама провалилась, как по мне то прежде всего из-за организации работ по бизнес-проектам с собственным бэклогом у каждого, невключения даже в них задач поддержки и «подумать» и низкой взаимозаменяемости. Что кто делает в принципе было понятно, но как делает, никто толком не знает, каждый занимается своей задачей в «своих» подсистемах. После увольнения нескольких человек целые подсистемы болтаются «бесхозными», на любую задачу по изменению логики разработчик просит минимум неделю чтобы только дать оценку, а ещё лучше две-четыре недели, чтобы переписать.
Были попытки как-то упорядочить, разделить команду на две, условные бэкенд и фронтенд, но получилось ещё хуже, даже когда был только один бизнес, а потом началась подготовка ко старту второго. Опять команду разбили на две, но уже по глобальным проектам, но из-за низкой взаимозаменяемости разбиение было довольно условным, хотя было строгое указание каждый занимается прежде всего своим, а другому проекту помогает в свободное время, которого никогда не было. В итоге стояли задачи по обоим и тимлиды и пмы проектов договаривались «мы тебе нашего бэкендера на три дня, а ты нам своего верстальщика на пять», хотя по сути команды были «фуллстэк», способные с нуля решить любую задачу. Но таких практически не было.
Что нам лучше подойдёт?ApeCoder
27.01.2017 11:14+1Я такого никогда не делал, но как мне кажется, чисто по ощущениям, для начала надо, чтобы у вас был какой-нибудь чувак с презентационными скилами чтобы продать изменения бизнесу. То есть в какие проблемы для бизеса выливаются проблемы разработки и какими изменениями их достичь.
Например, одинаковый приоритет задач — все равно, что отсутствие приоритета. Внедрение единого беклога и единого PO может сделать разработку более предсказуемой — как электронная очередь в сбербанке. Дыры в безопасности — риски потерь денег (тут чувак красочно расписывает какие-нибудь примеры точно такого же бизнеса как ваш) и т.д.
Дальше надо понять с кем можно говорить, кто может менять процесс и какие части трудно изменить, какие нет.
У вас есть люди которые говорят ярко и доступно и умеют договариваться и в курсе ваших проблем?
Ктоме вас лично кто-то понимает ситуцию и также недоволен происодящим?
dm_wrike
27.01.2017 12:17Не первый раз, с удивлением, слышу что скрам неприменим в случае когда бюджет важен. Как будто бывают другие случаи.
Что вы на самом деле имели ввиду говоря что Scrum не стоит использовать если бюджет является важным фактором?
ApeCoder
27.01.2017 12:18Что вы на самом деле имели ввиду говоря что Scrum не стоит использовать если бюджет является важным фактором?
Я???
qw1
28.01.2017 19:56архитектура когда-то была обычная трехзвенка, сейчас стала сервис-ориентированная с уклоном в микросервисы путем выделения из легаси-монолита
А как вы решаете вопрос с транзакциями?
Обычно, если изначально был монолит, там можно было с ними не заморачиваться. Но если выносить куски в сервисы, которые меняют данные, получается непросто.VolCh
29.01.2017 02:14+1Прежде всего на уровне разделения на сервисы решаем. Где ACID железно необходим, стараемся в одном сервисе. А там где можно чутка что-то рассогласовать ненадолго, то мониторингом. В одном месте только распределенные двухфазные транзакции.
Chelyuk
27.01.2017 13:28Если я правильно помню, то Scrum хоть и не равно Agile, но ноги у него растут из Agile, в котором четко прописано, что рекомендованный размер команды 6-8 человек. Если больше 12 вообще не стоит мучать ни себя ни команду натягивая на нее Scrum или наоборот. Всему свой инструмент. Если есть потребность в столь больших командах оправданы внедрения элементов WaterFall и требуется тратить время на бюрократию с документацией, иначе очень много проблем от "испорченного телефона".
Изменения в ТЗ вносится на 1 спринт, в течении спринта менять моветон. Длительность спринта -вопрос философский, обычно от 1ой недели до 1го месяца.ApeCoder
27.01.2017 13:46+1Agile — не конкретная методология а понятие расплывчатое — просто некоторый набор ценностей. SCRUM является одним из фреймворков/методологий поддерживающим ценности agile.
Если больше 12 вообще не стоит мучать ни себя ни команду натягивая на нее Scrum или наоборот. Всему свой инструмент.
Если больше 12 — рекомендуют рабить на мелкие команды и внутри них применять SCRUM а снаружи уже пользоваться чем-то для координации. Например, авторы SCRUM развивают Nexus есть еще SAfE
Mephistophele
27.01.2017 13:58@ApeCoder всё правильно ответил, я лишь немного дополню его ответ.
Если есть потребность в столь больших командах оправданы внедрения элементов WaterFall и требуется тратить время на бюрократию с документацией, иначе очень много проблем от "испорченного телефона".
Есть ещё масштабируемый SCRUM, так называемый SAFE Его можно на любой размер натянуть. :) А вообще да, подробили команду 3-9 человек и вперёд. SAFE больше подойдёт когда 50+ человек.
Изменения в ТЗ вносится на 1 спринт, в течении спринта менять моветон. Длительность спринта -вопрос философский, обычно от 1ой недели до 1го месяца.
Изменения в Project Backlog вносятся когда захочется, а вот в Sprint Backlog вообще никто вносить не имеет права за исключением Development Team. Я в этом комменте чуть детальнее описал.
Что же касается длительности, отчасти философский, там есть несколько рекомендаций, сводящихся к тому что чем короче-то тем лучше, но по длине они должны оставаться достаточными чтобы выпустить рабочую версию продукта (shippable increment). Там есть только верхнее ограничение — 1 месяц, а так хоть однодневные спринты можно делать. :) На практике как правило это 2 недели ~ 10 дней.
LanSaid
27.01.2017 13:28+1Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время.
— расскажите, как вы скрещиваете поддержку и разработку? или что, надо поделить команду на 2 части: разработку и support?Mephistophele
27.01.2017 13:59+1Это я в отдельном топике запилю, пожалуй, для коммента достаточно много писать.
ilja903
27.01.2017 13:28Неубедительно. Сомневаюсь, что наим скрам мастера вкупе с по сэкономит деньги проекту. Да и на самом деле скрам мастер — это тот же добренький манагер, который защищает программистов от других манагеров. Еще один слои мэнэджмента. Бывает что и весьма не плохо защищающий. Но сомневаюсь что экономически целесообразный. Короче при хорошей команде специалистов любая методология будет работать.
Mephistophele
27.01.2017 13:33Выделенный скрам мастер зависит от бюджета, если бюджет проекта позволяет, то можно и пожировать. Но я к таким не отношусь, я обычно играю роль человек-оркестр: Project Manager\Delivery Manager\Project Coordinator\Architect\Development Lead\Team Lead. И все эти роли вполне успешно можно совмещать с ролью SCRUM Master'a.
ИМХОЯ как-то общался с выделенными скрам мастерами, ну чё сказать. Они отчёты делают по 2-3 дня. Я поржал тогда с них, а они обиделись. :) Я то отчёты генерю за 15 минут в тулах.
Chelyuk
27.01.2017 14:15Подскажите пару рекомендаций:
1) Реально ли использовать 1го сотрудника в проектах с разными методологиями(Scrum, support, Waterfall) или лучше стараться максимально разделять по проектам исходя из используемых методологий?
2) Как организационно в небольшой компании совмещать методологии? Например, разработчики и тестировщики разделены тим-лидами, что хорошо в случае WaterFall или CanBan. Agile и Scrum не очень разделяют такие взгляды, для них характерно другая расстановка ролей и 2 тим-лида в одну команду не очень хорошо укладываются, потому как TL должен взять на себя роль Product Ownera(PO), а 2 PO — это как 2 хозяйки на одной кухне.
Небольшая компания, где менеджеры не хотят набирать на каждую роль человека и приходится балансировать изображая человек-оркестр.ApeCoder
27.01.2017 14:38Team — это "команда", значит Team lead — это "вожд команды", для разделения прориаммеров и тестеров используется слово discipline. Но раз суествует team, то должен быть кто-то кто ей управляет. То есть еще есть и team team lead. А теперь интересно, как разделятся ответственность между team lead и discipline lead?
http3
27.01.2017 15:30Чем дальше лес, тем больше дров и непонимания. :)
Проще работать по старинке, пока все работает как часы. :)Mephistophele
27.01.2017 15:34Главное чтобы потом этими часами насмерть не придавило. :D
qw1
29.01.2017 11:39Ну так IT-директор посмотрит на все эти отзывы и подумает, что делать
1. Оставить всё как есть и ждать падения часов.
2. Внедрить SCRUM, но с риском в 90% (по тутошним комментариям), что скрам будет неправильным и всё сразу полетит к чертям.Mephistophele
30.01.2017 13:03Первый раз всегда больно, а потом уже нравится. :D
qw1
30.01.2017 20:19Стокгольмский синдром?
Mephistophele
31.01.2017 11:57Отнюдь.
qw1
01.02.2017 20:03Значит, описанное здесь в статье — это нормально, и можно списать на «первый раз»?
Mephistophele
01.02.2017 21:27Судя по всему стокгольмский синдром у вас, бо не вошло. У нас же всё замечательно. :P
И не спорьте.
Mephistophele
27.01.2017 14:30Реально, но лучше разделять. Т.к. когда человека раздирают между несколькими проектами, то у него эффективность будет снижаться. Это если мы говорим про разработчиков и тестировщиков.
- Можно чуть более детально описать? Потому что достаточно общо и сложно какие-то детальные рекомендации дать.
Chelyuk
27.01.2017 15:41Понятно, что в идельном мире, у одного человека 1 проект. В реалиях, если компания не исчисляет сотрудников тысячами этого очень сложно добиться и придется совмещать. Но даже в реальной ситуации можно выкручиваться и я предполагаю что желательно если и разделять человека на проекты, то хотя бы делить группы проектов по методологиям. Будет ли выигрышь, если людей распределять, не между проектом 1-Scrum и проектом 2-Waterfall, а между проектом 1-Scrum и проектом 2-Scrum. Или если у человека будет 2 проекта уже не столь принципиально одна в них методика или разная?
- Кейс примерно такой:
Проектальная компания, порядка 40-45 человек из них около 25 разработчиков и 5 тестировщиков. Остальные менеджмент, компания территориально разделена. Менеджмент — одна локация, разработчики и тестировщики — другая локация. Локации — 1 часовой пояс, но 3000 км.
Проекты есть разные, небольшая нагрузка по саппорту, 2-3 основных длительных проекта в которых задействованы от 10 человек(разработчиков и тестировщиков) компании и проекта 3-4 где потребность в людях возникает периодически(3-4 человека), так сказать фоновые проекты.
Девелоперы делятся между 4мя лидами, тестировщики закреплены за 1м лидом. Основные проекты ведуться 1 по сценарию приближенному к WaterFall, 2 других на субподряде у основного заказчика декларируется Scrum.
Вот пытаюсь во всем этом нащупать балланс, учитывая что раньше практически все проекты шли по WaterFall c некоторыми изменениями. Либо, действительно упразднить такое явление как Team Lead тестировщиков и двигаться в сторону перераспределения ролей по Scrum сценарию(PO, SM ...). Либо искать еще какие-то варианты перераспределения, например как предложили выше, оставить тимлидов разработчиков и перевести тимлида тестировщиков в discipline.
Вопрос вызван тем что работь на субподряде по жестким методикам стало крайне тяжело, когда есть зависимотсти своего кода от кода и сроков внешней команды заказчика,
Mephistophele
27.01.2017 15:55По первому вопросу: я работаю в большой компании, у нас более 20к сотрудников по всему миру. Но у нас SCRUM очень успешно используется. Тут зависит больше от того оплачивает ли проект 100% человека. Если оплачивает, то нет смысла разрывать человека между несколькими проектами и это уже менеджмент косячит, пытаясь урвать как можно больше бабла.
По второму вопросу подумать надо.
Mephistophele
27.01.2017 16:06По второму вопросу, я бы поступил так.
Тим лидов оставить, можно даже названия их не менять. Одному из лидов дать роль Scrum Master'a. Из всех проектов сформировать проектный портфолио, расставив проектные приоритеты. Чтобы было понимание, что если что-то в фоновом проекте появляется и он имеет высокий приоритет то это добавим в спринт. Спринты же сделать достаточно короткими, что-то около недели, чтобы можно было быстро переключаться в случае чего. Т.е. если что-то приходит по высоко-приоритетным проектам, то задержка будет около недели и можно с высокой точностью сказать когда разработка будет закончена и отдана в релиз. На мой взгляд, неделя — допустимая задержка.
И чисто моё ИМХО, я не увидел у вас наличие бизнес аналитика, лучше наймите, потому что мне не очень понятно кто у вас сбором требований занимается. Возможно сможете высвободить чуток времени разработчикам, если они задают много вопросов и тратят на это много времени.Chelyuk
27.01.2017 16:49Спасибо, за ответы будет над чем подумать. Линия в принципе понятна, дальше буду уже из нюансов смотреть на какие роли кого двигать. По-хорошему, бы ставить тим лидов разработчиков Scrum Master в своих проектах. Но не хватает у них навыков, случаются факапы с качеством продукта. Тимлид разрабточиков в роли Scrum master, чрезмерно влияет на тестировщика в проекте из-за чего выбор сценария тестирования разработчиком приводит к проблемам, он зацикливается на положительных тестах фичера разработанных в рамках спринта из-за чего не выделяется время на регрессионные и негативные тесты и мало исследуется влияние нового фичера на уже существующие.
ApeCoder
27.01.2017 23:06имлид разрабточиков в роли Scrum master, чрезмерно влияет на тестировщика в проекте из-за чего выбор сценария тестирования разработчиком приводит к проблемам
- Являются ли эти проблемы проблемами для самого тим лида?
- Есть ли какой-то Acceprtance Criteria в PBI и кем он вырабатывается?
Mephistophele
28.01.2017 01:02Есть ли какой-то Acceprtance Criteria в PBI и кем он вырабатывается?
Надо сделать так, чтобы команда выработала. SM тут по сути решающей роли не имеет. Поэтому и проблема уйдёт по идее.
ApeCoder
28.01.2017 15:00SM тут по сути решающей роли не имеет
У SM, как я понял, тут мета-роль — организовать процесс так, чтобы команда выработала этот критерий. Организовать ретро так, чтобы всем было понятно что проблема есть.
dmitriyabr
30.01.2017 16:36Искренний совет автору:
Перед тем, как пробовать сдать PSM-II – подучись еще. В этом разборе много расхождений с гайдом и много собственных выводов, которые с очень большой натяжкой можно назвать реальностью.
Source:
У меня есть PSM-II и я внедрял Scrum не раз, так что думаю, могу как-то котироваться ;)
P.S.
Не ради холивара, конечно же. Рад, что кто-то пытается самостоятельно учиться в этой сфере.ApeCoder
30.01.2017 17:00Было бы интересно более детальное мнение. Например, какие основные ошибки допустил автор.
dmitriyabr
30.01.2017 17:01+2Как только дойдут руки, сразу напишу. (чтобы написать нормальный разбор, нужно время)
Либо автор сам уже напишет, к тому времени.
slope_style
30.01.2017 17:05Насколько я понимаю, ничего не мешает сениор тим-лиду быть СМ-ом. У меня вопрос к обитающим в комментах — уважаемые эксперты, я пишу диплом о разработке ПО (геймдев) на СКРАМе. Хочу склепать за полтора года студией в 20 человек игруху на PS4. Заказчиком выступает в данном случае аудитория РФ с PS4, из их предпочтений будет формироваться ТЗ с помощью маркетинга (аутсорсинг). Возможно ли, на ваш взгляд, если в команде должно быть не более девяти человек, сделать две непересекающиеся СКРАМ команды со своими СМ-ами и ярко выраженной специализацией (допустим, код и дезигн) и подавать каждой из них ТЗ на спринт в зависимости от фидбека маркетинга и требований другого отдела? Это может растянуть сроки, но повысить качество продукта, а в данном случае основное требование — бездефектность.
Mephistophele
30.01.2017 17:07Сделайте 2-3 команды, дайте им одного Scrum Master'a и общий бэклог. Ибо можете столкнуться с проблемой, что каждая команда копает в своём направлении или делает то, что уже сделано другой командой. А насчёт универсализации — все девелоперы — вы этого не добьётесь в наших реалиях, так что наличие специализаций я считаю нормально, хоть это и расходится с официальной позицией Scrum Guide.
ApeCoder
30.01.2017 17:15ярко выраженной специализацией (допустим, код и дезигн)
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.
Никогда не работал в геймдеве. Нельзя ли разделить на команды так, чтобы каждая команда могла параллельно работать над чем-то целостным, включающим в себя дизайн и код?
funca
01.02.2017 05:52Постановка вопроса уже вызывает много вопросов. Но в науке, в отличии от практики, даже отрицательный результат это тоже результат. Хотя уж на совсем очевидные грабли наступать, конечно, не стоит. Пообщайтесь со своим научным консультантом на тему выбранной проблемы, гипотезы и метрик.
funca
01.02.2017 05:35+2Как говорил Ильич: «Недостатки у человека как бы являются продолжением его достоинств. Но если достоинства продолжаются больше, чем надо, обнаруживаются не тогда, когда надо, и не там, где надо, то они являются недостатками».
Scrum, будучи монолитным «framework for managing product development», декларирует слишком много прикольных, но второстепенных, в общем-то, практик. Будучи декларированными эти практики становятся почему-то вдруг важными и при внедрении заставляют менять то, что нормально работает.
Scrum привносит свою систему ценностей и метрик, оптимизация под которые может идти в разрез с целями конкретного проекта, требованиями бизнеса, особенностями задач, спецификой коллективов и т.п.
Scrum предполагает включение и синхронизацию разработки product increment в пределах спринта и команды. Поэтому он плохо подходит для команд с высокой степенью специализации разработчиков, команд, распределенных географически или по времени, при наличии зависимостей от внешних подрядчиков, в ситуации комплексных фич, при наличии контроля качества снаружи, формализованной приемки и т.п… Чтобы обеспечить синхронизацию, процесс вынужден блокироваться, что уже само по себе вызывает кучу вопросов и поводов для менеджерского креатива. Отсюда же и ограничение на размер команд.ApeCoder
01.02.2017 09:29Я так понимаю, управление зависимостями — это просто уровень выше чем скрам. См. тут, например.
То есть скрам просто описывает нижний уровень организационной декомпозиции, а остальное описывают другие процессы.
Отсюда же и ограничение на размер команд.
Я думаю, управление ограниченным количеством чего угодно есть свойство человеческого мышленгия. Например когда ходил в детстве в походы, мой руководитель говорил, что оптимальное число тургруппы тоже в районе 8 человек.
VolCh
01.02.2017 10:57+1То есть скрам просто описывает нижний уровень организационной декомпозиции, а остальное описывают другие процессы.
Могут быть горизонтальные зависимости на нижнем уровне. Грубо, скрам-команда разработчиков мобильного приложения и скрам-команда бэкенда с АПИ, в том числе (но не только) для него. Нет АПИ — не проверить приложение в условиях приближенных к боевым, нет приложения — не проверить АПИ.ApeCoder
01.02.2017 11:14Разбиение на команды, это не данность. Можно перейти к feature teams.
VolCh
01.02.2017 13:05Не всегда это реально. Например, одна команда бэкендеров обслуживает интересы многих команд пользователей API. А разбивать её по принципу «каждой команде клиента по своему бэкендеру» сильно замедлит разработку и все равно будут задачи, которые будут перекидываться на бэкендера из другой команды, например, как лучше всего владеющего искусством оптимизации SQL-запросов
ApeCoder
01.02.2017 13:13Если команды компонентные это зависимость на между командами, а не на нижнем уровне. Можно делать гибриды — достаточно простые правки бекэнда могут делать фронтендеры и мерджить после ревью бекендом. В остальных случаях зависимостями надо управлять в любом случае. Надо пересмотреть видео выше — там есть разные варианты.
funca
02.02.2017 00:59Кстати для тургрупп Scrum может быть применим вот прям сразу, т.к. они обычно однородны и действуют автономно.
В случае современной web-разработки, product increment в виде какого-нибудь банального лендинга может задейстовать целую зондер-команду всяких-разных специалистов. Например:
1. Sales/account manager
2. Business analyst
3. UX/UI designer
4. Frontend developer
5. Backend developer
6. DBA
7. QA
8. DevOps
9. Delivery manager
10. Tech writer
11. SEO engineer
Понятно, что нагрузка на них будет сильно варьироваться по времени. Scrum предлагает решать вопрос за счет совмещения ролей и сокращения штата. Просто в противном случае в рамках этой модели в разное время кому-то придется работать в поте лица, а кому-то — гонять танчики в ожидании коллег. Ведь команда не должна набирать в спринт больше работы, чем способна задеплоить. Вариант имеет право на жизнь, но не панацея же.ApeCoder
02.02.2017 08:57Я не вебдев и не очень понимаю, зачем столько для лендинга. Например, зачем Tech Writer. Да, в скраме пропагандируют совмещение в рамках команды, T-shaped и М-shaped specialists.
funca
04.02.2017 16:34Это работает лишь для решения небольших типовых задач, при наличии невысоких требований к масштабированию и надежности команд. Когда есть возможность самостоятельно форумулировать критерии качества, готовить и расхлебывать.
В ситуации заказной разработки, крупные заказчики часто отдают наружу лишь отдельные функции в рамках проекта. Нередко QA находится на стороне заказчика, с какими-то своими циклами тестирования и релизов. На выходе требуется не только код, но документация, вместе с инструкциями по развертыванию, тестированию и сопровождению.ApeCoder
04.02.2017 17:06Вот для примера лендига — там столько специфики, что нужен специальный Tech Writer чтобы ее написать? Разработчик не может?
funca
04.02.2017 20:08Человек с подходящим уровнем английского делает эту работу лучше, быстрее и стоит дешевле, чем кодер. Процессы частично параллелятся, что дает выигрыш по срокам.
ApeCoder
04.02.2017 23:22То есть у конкретного лендинга есть столько специфики, что разработчик не может взять рыбу и поменять конкретные места, ему проще как-то описать это техпису, что бы он потом описал это пользователям?
Вообще по моему опыту некоторую документацию писали разработчики, потом техписы доводили ее по стилю. И вообще был некий аджайл внутри команды разработчиков но во вне уже была некоторые процедуры управления зависимостями.
funca
05.02.2017 01:04В этом все и дело. Agile как концепция и Scrum как набор конкретных методик и практик это разные вещи. Гибкость состоит не в том, чтобы вгонять коллектив в рамки, которые требует гибкая методика, а возможности выстраивать процесс с учетом специфики проекта и наиболее эффективного использования имеющихся ресурсов.
Вопрос «может в принципе или не может» это уже давно не самый важный вопрос. В принципе этим может заниматься кто угодно, но специально подготовленные люди справляются лучше.ApeCoder
05.02.2017 15:33В этом все и дело. Agile как концепция и Scrum как набор конкретных методик и практик это разные вещи.
Я бы сказал, что тут можно достаточно сильно варьировать методику в зависимости от того, как определять "Продукт" и "Команду" в конкретном случае. Грубо говоря, подставить в соответсвующие параметры адаптеры для каких-то вещей вне данного процесса.
Гибкость состоит не в том, чтобы вгонять коллектив в рамки, которые требует гибкая методика, а возможности выстраивать процесс с учетом специфики проекта и наиболее эффективного использования имеющихся ресурсов.
Я где-то встречал мысль, что чтобы узнать что-то новое надо постараться внедрить идею буквально ища смысл в ее деталях — тогда это заставит взглянуть на процесс с другой стороны и узнать что-то новое. Иначе просто человек отвергнет что-то значимое исходя из своих текущих стереотипов и останется при своих
Вопрос «может в принципе или не может» это уже давно не самый важный вопрос. В принципе этим может заниматься кто угодно, но специально подготовленные люди справляются лучше.
Тут возникает вопрос, окупает ли это что-то лучшее затраты на коммуникацию со специально подготовленным человеком. Например, почему мы не используем специальных завязывальщиков шнурков?
В каком-то конкретном случае может окупать, а в каком-то может и нет.
Askofen
02.02.2017 20:29Из всего текста, прочитанного мною в изначальном топике, я не встретил упоминания роли Product Owner (везде далее РО). Кто же такой РО — человек ответственный за конечное видение, развитие проекта и управление бэклогом проекта, у него есть ещё ряд обязанностей, но пока что ограничимся этими.
Тут следует заметить, что наличие product owner'а — не изобретение скрама. Ещё Том Демарко писал о необходимости наличия бизнес-аналитика, который будет собирать требования от пользователей, перерабатывать их и формулировать их в виде требований к системе. При разработке видеоигр есть продюсер, который ответственен за разработку концепции игры и за то, чтобы игра соответствовала желаниям пользователей (целевой аудитории).
В данном случае скрам просто занимается переименованием уже известных вещей.ApeCoder
02.02.2017 21:06+1бизнес-аналитика, который будет собирать требования от пользователей, перерабатывать их и формулировать их в виде требований к системе.
В скраме у PO нет таких обязанностей. Он отвечает за беклог, но не обязан сам делать все это.
Askofen
03.02.2017 12:37Зато продюсеры в игровых студиях отвечают как за игровой дизайн, так и за формулировку фич и критериев их приемки.
Так что возражение остаётся прежним: привычной роли в разработке ПО придумали иное название. Суть-то не поменялась.ApeCoder
03.02.2017 13:17Так какое старое название для PO я так и не понял. Продюсер-в-игровой-студии? Но даже если такой продюсер и был PO сам термин не эквивалентен. Он, возможно, более общий. Это как сказать, "зачем вы ввели понятие "хордовые", если собаки и рыбы нам давно известны.
И я сомневаюсь, что продюсер-в-игровой-студии является PO если там не введен скрам.
Askofen
03.02.2017 15:24И я сомневаюсь, что продюсер-в-игровой-студии является PO если там не введен скрам.
Предлагаю обсуждать не чьи-либо сомнения (это — неконструктивно), а факты.
А факт остаётся тем же: взяли уже имеющуюся роль и обозвали по-другому. В крайнем случае — взяли часть функций уже имеющейся роли и выделили в отдельную роль, дав ей иное название. В чём новизна?
Нужны чёткие критерии отличия и обоснование, почему эти критерии важны. А иначе выглядит, как обыкновенный ребрендинг.ApeCoder
03.02.2017 17:51А факт остаётся тем же: взяли уже имеющуюся роль и обозвали по-другому
Это ваше суждние, я не факт. И судя по тому, что вы понимали под PO в первой версии, я ему не доверяю :)
В крайнем случае — взяли часть функций уже имеющейся роли и выделили в отдельную роль, дав ей иное название.
Мне кажется, что в формулировке процессов это одна из важных частей — выделить из уже имющегося существенное и потребовать его :). Это и есть новизна. А что вы ожидали — небывалого мегапрорыва от введения ровно одной роли?
Askofen
03.02.2017 18:30я ему не доверяю :)
«Я-суждения» не являются аргументами при ведении дискуссии.
Мне кажется, что в формулировке процессов это одна из важных частей — выделить из уже имющегося существенное и потребовать его :).
Ещё одно «я-суждение».
А в целом — приведите аргументы, почему функция «управления бэклогом» требует отдельной роли, хотя с этим хорошо справляется и продюсер.ApeCoder
03.02.2017 21:40Я совершенно не знаю, требуют или не требуют отдельной роли функция "управление беклогом". Мне хотелось бы узнать, кто такой продюсер — нет ли у вас ссылки на описание такой же степени однозначности и понятности как в скрам гайде?
Askofen
03.02.2017 23:46Впервые термин продюсер применительно к разработке видеоигр использовал Трип Хоукинс, основатель Electronic Arts, в 1982 году.
Подробно об обязанностях продюсера видеоигр рассказано в статье на википедии.
Еще более подробно обязанности продюсера изложены во внутренних документах игровых студий.
При разработке бизнес-приложений есть аналогичная роль, которая называется по-другому. Например, в Майкрософт — это program manager (не путать с project manager'ом!). О его обязанностях рассказано здесь и здесь.funca
04.02.2017 16:04Для scrum несложно искать аналогии во всем потому, что тут все занимаются всем понемногу. Проводя аналогии между разными областями, вы начинаете строить обобщения и наделять термины несвойственными им значениями, в результате чего получаются некорректные выводы. Принципиальная разница между разными моделями не в их, кажущихся на первый взгляд, сходствах, а в отличиях.
ApeCoder
04.02.2017 17:08Если посмотреть внимательно на определения, то PO и перечисленные категории пересекающиеся множества — продюсер может быть как PO так и не PO, и PO может быть как продюсером так и нет. PO специфический термин в рамках именно скрама.
Askofen
03.02.2017 18:25Вот в этот момент должен был вступить в игру SM и послать всех менеджеров в пешее эротическое путешествие оградить разработчиков(DT) от менеджерского беспредела. Желание менеджмента понятно и применимо: оценить, измерить, сэкономить бабла (не ну всё менеджеры этим занимаются, от этого никуда не деться). Но в данном случае в дело должен был вмешаться SM, принимая весь удар на себя, объясняя всем что делает команда, чем занимается и почему их нельзя трогать.
На мой взгляд, крайне слабое решение. Как делается у нас? Если ожидания менеджеров или заказчиков — в плане трудозатрат — не совпадают с оценкой команды, то запускается процедура согласования. Что она включает?
Во-первых, подключаются более опытные инженеры, которые пытаются найти проблемные места, из-за которых «раздувается» эстимейт. Эти проблемные места могут объясняться наличием «рисков незнания» (технологии, стандартного подхода к решению аналогичных задач, пробелами в требованиях и т.д. и т.п.). Если проблемы заключаются в незнании подходов и методологий, то опытные инженеры проясняют их, в результате чего риски снижаются и снижается оценка. Если проблемы в неясности требований, то проясняются требования.
Во-вторых, заказчикам и менеджерам объясняется, из-за чего раздувается оценка. Нередко случается так, что на оценку влияет какое-нибудь совершенно несущественное требование, без реализации которого заказчик может обойтись. Такие требования исключается. Если же оценку увеличивает важное требование, то инженеры и заказчики совместными усилиями думают, а можно ли его как-нибудь переформулировать так, чтобы реализация не требовала бы значительного времени.
Разговор же с менеджерами и заказчиками в стиле «Это наша оценка, и отстаньте от нас» вряд ли повышает успешность проекта.funca
04.02.2017 15:27«Это ваша оценка вряд ли повышает успешность проекта.» В самом деле, для того, чтобы продуктивно торговаться, нужно иметь специфический набор навыков. Такой формат удобен людям с нормальным управленческим образованием, поставленной риторикой и прокаченными софт-скиллами, в большей степени, чем тем, кто умеет программировать компьютеры.
Если подходить к вопросу торга при оценке задач чисто с рыночных позиций, то в условиях свободного рынка, кастомизация продается дороже, а не дешевле типовых решений. Типовые же решения стоят вполне определенные деньги. Затраты снижаются за счет реюзинга, автоматизации и инноваций. Для обмена знаниями между инженерами рулит парное программирование и образовательные программы, а не стресс на глазах заказчика и менеджмента.
Возвращаясь же к нашим наемным работникам, то после «внедрения» scrum, все это и правда классно складывается на оперативных показателях. Как минимум, пока команда не разберется что к чему и соглашается на переработки. Но у этого есть свои побочные эффекты, из-за которых в нормальных компаниях, применяют другие методики управления, а не голимый scrum.
VolCh
Спасибо за разбор. У нас тоже был неСкрам значит. В связи с чем вопрос, а предполагает ли успешный скрам активное участие команды во внедрении? Ну хотя бы изучение что такое Скрам самостоятельно, что бы фиксировать отклонения от эталона? Или достаточно лишь ознакомиться с новой инструкцией по порядку взятия задач в работу и т. п.?
Mephistophele
Всё зависит от уровня команды и предъявляемых к ним требований. Так например есть даже специальный документ для членов DT — Professional Scrum Developer — PSD.
Вообще я обычно описываю ребятам их обязанности, возможности и пр. согласно SCRUM'y, ну а сам играю роль этакого зонтика скрам мастера. Потому что без принятия самой командой, скрама не получится, но обучить команду, дать им правильную культуру скрама и помогать им её взростить — прямая обязанность SM'a. Притом через некоторое время они сами и отклонение от эталона заметят и порядок наведут. Главное их от негативного внешнего влияния защищать.