В первой части мы рассмотрели тревожные симптомы и возможные способы «лечения» Product Owner в «механическом» scrum. Продолжим разбор ролей и следующая на очереди – команда.
Все же знают мантру, что команда должна быть самоорганизованной и кросс-функциональной, это выглядит как самая простая часть scrum: берем людей с нужными компетенциями, говорим им: «вы команда», и полетели! Но на деле все несколько сложнее.
Самоорганизация
Симптом: Существует явная иерархия (директивное подчинение) снаружи, или что еще хуже внутри команды. Т.е. фактически разработчику продукта может прийти задача, непосредственно не связанная с деятельностью команды. Либо внутри команды люди не вольны в выборе работы для достижения цели спринта, а получают задания от «руководителя».
Чем плохо:
Любые границы — ограничивают @КЭПКогда человек зажат должностной инструкцией, иерархией подчинения и т.п., это не дает ему раскрыться. Сила scrum команды в открывающихся перед людьми возможностях. Есть задача, бери на себя смелость и отвечай за её выполнение. Человек должен сам принимать решение о том, что он будет делать для достижения цели спринта. Если ему говорят что делать, то это не самоорганизация и не scrum.
Как лечим: Для людей в команде отменяются все должностные инструкции и иерархии, структура стремится к плоской. Все, кто в команде — это разработчики продукта (других ролей scrum guide не допускает). Есть только ситуационное лидерство, и люди сами решают, как им комфортно работать, чтобы быть эффективными. Конечно же, есть общие правила игры в компании, команда никоим образом их не нарушает (хотя может влиять на изменение на уровне компании), но за все внутренние вещи отвечает сама. Если есть серьезные препятствия на пути отмены ограничений для разработчиков, то стоит эскалировать вопрос до тех, кто принял решение о внедрении scrum и agile трансформации. Можно попробовать запустить плоскую структуру, как эксперимент на несколько спринтов, а затем провести обширную ретроспективу, где всеми заинтересованными лицами обсудить результаты эксперимента.
Симптом: Люди, помимо работы в команде, должны выполнять другие функциональные обязанности в компании. Например: 50% времени выполняет задачи команды, 50% — задачи отдела (разработка, тестирование и т.п.).
Чем плохо: Одна из ценностей в scrum — это сфокусированность. Команда фокусируется на цели спринта и движется к ней. Если помимо работы в команде человеку приходится заниматься еще чем-то, то фокус теряется. Как следствие, результат работы будет хуже. Сложно поддерживать командный дух в таких условиях.
Как лечим: Нужно добиваться, чтобы люди, входящие в команду, работали ТОЛЬКО в этой команде. Для этого стоит понять природу работы, свалившейся на разработчиков команды извне, и найти способы делать её не ломая scrum. Наверняка эта работа необходима компании, поэтому в зависимости от специфики работы можно:
- либо поместить работу в backlog команды, а дальше она будет сделана по единому рабочему процессу.
- либо передать её другим сотрудникам вне команды. Например: не вся компания работает по scrum, и нужно делать некую регулярную работу в конкретное время, тогда такая работа больше подходит не scrum сотрудникам.
- либо может быть создана специальная команда и выделен продукт, который соберет в себя все работы такого типа.
- либо, если это уникальная функция, которая делается одним человеком для нескольких команд из-за нехватки специалистов. Тогда стоит вывести человека из всех команд и выстроить для него другой процесс, не ломающий scrum остальным (например: приоритезируемая очередь задач), до тех пор, пока не будут найдены специалисты в эти scrum команды.
Кросс-функциональность
Симптом: Люди внутри команды выполняют только определенную работу, есть четкая специализация. Хуже когда это еще покрыто должностными обязанностями, регламентами и прочей бюрократией. Отсутствие (отпуск, больничный и т.п.) одного члена команды, уменьшает функциональность команды. Привет, bus factor.
Чем плохо: Если команда зависит от компетенций одного из её членов, это неустойчивая к изменениям команда. Выстраивать с ней коммуникации сложно, т.к. нужно понимать текущую её функциональность и помнить о рисках, связанных с таким уровнем отказоустойчивости. Узкая специализация разработчиков сильно усложняет организационную работу для команды: при планировании нужно много думать о том, кто и чем будет заниматься; не каждая задача нуждается в заданных пропорциях компетенций команды, следовательно собрать сбалансированный спринт сложно; в такой схеме обязательно возникает «узкое горлышко», снижающая общую скорость команды.
Что делать: Нужно пропагандировать и поддерживать t-shaped навыки. Чтобы команда оставалась гибкой, важно чтобы конкретная функция или знание не были сосредоточены в одном человеке. Нужно стимулировать и поощрять постоянное развитие. Важно следить, чтобы команда совершенствовалась, искала способы улучшить процессы. Как варианты развития t-shaped: проведение внутренних семинаров, где члены команды делятся друг с другом знаниями; принять правило выполнения непрофильной задачи каждый спринт каждым членом команды; парная работа над задачами и т.д. Можно искусственно стимулировать команду, «выключая» её членов на некоторое время: отпуска, семинары, тренинги, командировки и т.п.
Симптом: В цепочке создания ценности команда отвечает (оказывает влияние) лишь за небольшую её часть, и как следствие, команда не может выпускать инкременты самостоятельно.
Чем плохо: Если команда слабо влияет на доставку инкремента (релиз продукта), то scrum тоже теряет свою суть: релизы происходят с задержкой, обратная связь происходит с еще большей задержкой. В общем, отсутствует ритм, а значит и скорость. Нет скорости — нет гибкости. Такая команда не чувствует свою сопричастность, она просто функциональный винтик в большой машине. Функциональности команды должно хватать на закрытие большей части цепочки создание ценности, иначе команда просто не будет доставлять ценность, а просто будет один вид «заготовки» перерабатывать в другой и передавать его дальше.
Проиллюстрируем это примером из web. Где упрощенно создание новой фичи включает в себя следующие этапы:
- разработка UI / UX прототипа
- разработка дизайна
- создание RESTful API
- создание SPA
- написание интеграционных автотестов
- сборка и выливка на боевое окружение
Для этих работ необходимы различные компетенции. Пример неудачного разделения на команды: выделить команду А из UI/UX, дизайнеров и frontend разработки, они готовят свой инкремент в виде SPA; но они зависят от того, когда backend подготовит API для работы нового функционала; ждут когда QA проверит все интеграционно и напишет тесты; а потом еще ожидают DevOps, чтобы те раскатали все на бой. Такой команде А трудно отвечать за релиз и доставку ценности, она просто пилит «заготовку» — SPA.
Как лечим: Определяем, каких компетенций не хватает команде, чтобы доставлять инкремент. Наделяем команду этими компетенциями благодаря обучению существующих членов команды, или добавлением новых игроков в команду. Т.к. найти / научить людей – задача не самая простая и быстрая, то можно налаживать коммуникации с соседними командами / отделами, объясняя им ценности scrum и договариваясь с ними об специальных регламентах / правилах взаимодействия, при которых они не будут ломать scrum вашей команде. Стоит подсветить процесс расширения функциональности команды: после первой ретроспективы и определения недостающих компетенций, можно их распечатать и разместить перед командой. Когда команда справляется с отсутствием компетенции (научились; новый член команды; настроили эффективную коммуникацию с другой командой и т.д.), то поверх ранее недостающей компетенции вешаем решение. Со временем команда должна стремиться расширять свою функциональность, чтобы полностью покрывать цепочку создания ценности.
Команда и продукт
Симптом: Команда есть, а продукта нет. Нет PO, нет backlog. Просто люди делают задачи, приходящие с разных сторон.
Чем плохо: Это не scrum. Когда за командой не закреплен продукт, то команда вряд ли будет «гореть» работой. Когда есть глобальная цель (видение / стратегия / roadmap развития продукта), то хочется идти к ней. Ты делаешь работу, получаешь обратную связь, рефлексируешь и делаешь следующий шаг. Без чувства причастности ты рискуешь оказаться в рутине: обратная связь тебе особо не нужна, команда становится просто инструментом переработки ТЗ в функционал.
Как лечим: У команды должны быть свой продукт с backlog и PO, который сможет зажечь команду продуктом и увлечь её за собой — в этом суть. Нужно понять, зачем вам scrum? Понять, откуда у команды берутся задачи? Понять, есть ли среди этого потока «продукт»? Выбрать среди «заказчиков» команды одного и сделать его владельцем продукта, наделив его единоличным правом отвечать за backlog. Возможно, придется разделить команду на scrum команду работающую с одним PO (это может быть «пилотная» scrum команда) и вторую команду, ПОКА работающую по-старому с остальными «заказчиками». Обеспечивая максимальную прозрачность процессов и результатов, происходящих в новой scrum команде, можно заложить базис для дальнейшего распространения scrum и agile в организации.
Симптом: Команда не имеет влияния на продуктовую составляющую: она не решает, «как делать?», команде просто говорят «что делать?», т.е. на вход приходит ТЗ, а команда рассматривается как функциональная единица.
Чем плохо: Это очень опасный вариант, если в компании действительно провозглашаются ценности agile и scrum. Обычно это подразумевает, что все сотрудники — классные профессионалы, способные решать любые задачи, которые не боятся принимать решения и брать ответственность. Но если не дают принимать продуктовые решения, то вся свобода творчества у команды обычно с продукта перекидывается на технологии. Раз команде не дают решать, как сделать жизнь пользователя легче, мир лучше, а продукт полезнее; то команда начинает развивать кодовую базу, пробовать новые технологии / инструменты / фреймворки и т.д. Возникает конфликт интересов между PO и командой, команда начинает продавать «рефакторинги», «оптимизации», «серебряные пули» в виде нового стека и т.д. А страдают от этого в первую очередь пользователь и продукт. В процессе перехода от директивных моделей управления к agile есть опасность застрять в понимании команды как функциональной единицы (команда до этого не принимала решения). Это чревато тем, что либо убьем инициативу команды, либо придем к ситуации, когда команде интереснее технологии, чем продукт.
Как лечим: нужно выявить причину недоверия к команде или её нерешительности: почему команда не ищет решения, а работает только с детальным тех.заданием? Найдя причину, можно постепенно устранять её. Например:
- У команды не хватает компетенций или опыта.: Кто-то же прорабатывает решения и пишет ТЗ, можно либо добавить этого человека в команду, либо позволять ему работать над некоторыми задачами совместно с командой, тем самым передавая часть своих навыков и опыта команде. Так постепенно команда научится и привыкнет решать продуктовые задачи.
- У руководства есть страх, что команда ошибется.: Это краеугольный страх при переходе к agile, но, не преодолев его, не получится приобрести всю силу scrum команды. Команда обязательно ошибется, потому что ошибаются все. Но ошибка — это источник опыта и мастерства. Полезнее, когда команда ошибется, потому что она так решила, а не из-за неправильного внешнего ТЗ. Scrum — это ритм: быстро сделали решение для проверки гипотезы; получили обратную связь; осознали, что пошли не туда; выкинули решение. Стоимость ошибки резко сокращается (потратили спринт, а не квартал / год / ваш релизный срок), что позволяет переступить через страх ошибки.
Симптом: У членов команды нет свободного доступа к командным артефактам. Например, не все видят спринтовый или общий backlog, или есть сложности с возможностью актуализации его состояния.
Чем плохо: Scrum базируется на прозрачности, артефакты помогают увеличивать прозрачность. Если у членов команды сложности работы с этими артефактами, то нет прозрачности в командной работе у самих участников команды, а для остальных заинтересованных лиц ситуация будет еще хуже: не ясно, кто чем и зачем занимается. Не ясно, где команда находится на пути к цели.
Как лечим: Нужно командно определить форматы scrum артефактов и сделать их (можно посвятить этому ретроспективу), а затем разместить так, чтобы команде было комфортно с ними работать. Отлично, если получится создать отдельное пространство для команды, условия, при которых команда будет работать рядом (плечом к плечу) в одно и тоже время. Это позволит уменьшить накладные расходы на коммуникации. И в общем пространстве легко все визуализировать (флипчарты, стикеры, маркеры — любимые инструменты agile), главное чтобы это было удобно, ненапряжно для команды. Артефакты должны помогать, а не мешать работе команды, не бюрократизировать её. Вербальное взаимодействие хорошо для командности. Если же есть сложности с организацией локальной работы команды (например, распределенной или удаленной), то нужно максимально создавать эффект командности и единения. Например, каналы видео-присутствия, интерактивные scrum доски в непосредственной видимости каждому члену команды и т.д.
Заключение
В следующей части продолжим рассматривать роли scrum, и доберемся, наконец, до scrum master-а. Кратко напомню, что вам делать с симптомами:
- Отбираете симптомы, применимые к вашей ситуации.
- Из них выбираете наиболее острые.
- Осознаете эту боль.
- Придумываете с командой решение (за отправную точку можно брать кейсы из статьи).
- Реализуете ваше решение.
- Переходите к пункту 1.
Спасибо, что читаете, хотелось бы увидеть известные вам «симптомы» в комментариях.
Спасибо Sai Kin за илюстрации.
Комментарии (91)
dipsy
01.07.2018 07:06+1Чем плохо: Это не scum.
Опечаточка по Фрейду? Извините.
Скрам с аджайлом это конечно модно стильно молодежно, даже проходили это лет 10 назад и до сих пор пытаемся. Не сильвербуллет, как оказалось, далеко не, но в любом случае не надо ничего абсолютизировать.
bus factor… Если команда зависит от компетенций одного из её членов, это неустойчивая к изменениям команда.… Узкая специализация разработчиков сильно усложняет организационную работу
Команда, любой член которой способен эффективно выполнять любую работу в команде, это команда землекопов, в крайнем случае лесорубов. В программировании на любом проекте сложнее «hello world» все члены просто физически не вытянут компетенции всех прочих, узкие специализации будут. Можно по 2 человека на одну специализацию держать, типа один в резерве. Сам не пробовал, возможно у вас получится, только непонятно как между ними взаимодействие выстроить, они же должны будут одно и то же делать.Demetrikl Автор
01.07.2018 09:59Не сильвербуллет, как оказалось, далеко не, но в любом случае не надо ничего абсолютизировать.
Полностью согласен. И в статье пытаюсь донести мысль, что карго-scrum больше вредит, чем приносит пользу. Первое что нужно сделать перед внедрением scrum — это понять для чего вы это делаете? какие задачи решаете? какие цели преследуете? Scrum в чистом виде требует многого от непосредственных участников и как следствие от организации. И это точно не серебряная пуля. Scrum сработает там, где это осознанный и взвешенный выбор.
Команда, любой член которой способен эффективно выполнять любую работу в команде, это команда землекопов, в крайнем случае лесорубов… Можно по 2 человека на одну специализацию держать, типа один в резерве...
Конечно же если уравнивать команду, то получим среднячков, которые решают небольшой набор задач. Приведу простой пример из WEB, допустим есть frontend и backend специалисты в команде. Собрали спринт где требуется больше backend. И есть два поведения команды:
- Frontend делает свою работу, и «ждет» backend.
- Backend делает архитектуру решения и куски реализации отдает frontend разработчикам, а затем уже ревьют результаты.
Во втором варианте команда более гибкая. По моему мнению нужно стремится ко второму варианту.
«Удваивать» компетенции только для резерва точно не стоит. Больше людей => нужно больше коммуникаций => эффективность ниже.
napa3um
01.07.2018 11:22это команда землекопов, в крайнем случае лесорубов
(Голосом эффективного менеджера) Воу, а это разве не так?!
Действительно, идея о T-шейпед-специалистах легко продаётся людям «сверху», эффективным менеджерам, которые не способны увидеть в ней подвоха. Как же удобно, когда у тебя склад гомогенных ресурсов, а не группа капризных «суперзвёзд» с различными компетенциями. Но мартышки стали хомосапиенсами как раз тогда, когда научились в специализацию (и дипломатию для коллективизации «суперзвёзд»).dipsy
01.07.2018 11:32+1Менеджеры они такие, вот на днях буквально
(Ты): *Говоришь менеджеру, что на реализацию фичи X понадобится N дней, оптимистично несколько занизив оценку*
(Менеджер): *Искренне удивляется* – зачем так много, ведь нужно всего лишь сделать X?
(Ты): *Думаешь, с чего начать, с необходимости давно назревшего рефакторинга, хотя бы вокруг этой конкретной фичи, с того, что понадобятся юнит-тесты и интеграционные, с того, что надо потихоньку уменьшать количество legacy и под эту дудку можно было бы опять же связанные вещи причесать, с того, что постоянные отвлечения на саппорт* – ок, попробую за 2 дня сделать.
algotrader2013
01.07.2018 11:56Так а в чем подвох, и вправду?
The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one's own.
К примеру, на продукте с highload есть человек, который гуру в базах данных, и знает все оптимизации нужной для проекта СУБД (и такие навыки действительно необходимы для продукта), но при этом, может попедалить однотипные задачки в JS на уровне джуна-мидла, предварительно получив консультацию у JS девелопера, в спринтах, когда задач на БД нет.
Если бы он принципиально не соглашался на написание JS кода, то было бы 3 варианта:
1) в таких спринтах не делать ничего (читать литературу, экспериментировать с новыми СУБД, которые еще пока в альфа версии), и тем самым деморализовать впахивающую команду.
2) «продать» ненужное усложнение архитектуры, только ради того, чтобы обеспечить себя достойными вызовами (при этом, конечно же, нагрузив и коллег тоже)
3) сказать «встретимся через спринт» своей команде, и пойти искать вызовы в других командах (тем самым, создал код, который некому поддерживать там, и сломав всю идеологию о коммитментах, командной ответственности и прочих эджальных вещах)
Поэтому, увы, выбора то, кроме T-shaped, и нет.napa3um
01.07.2018 12:09+1может попедалить однотипные задачки в JS на уровне джуна-мидла
А может и кофе подавать, и полы помыть, чтобы быть при деле и не деморализовывать команду. «А если мне пилу к заднице привязать, я ещё и пилить смогу» © анекдот.Demetrikl Автор
01.07.2018 12:47А может и кофе подавать, и полы помыть, чтобы быть при деле и не деморализовывать команду.
Вопрос не в «при деле», а что корону надо снимать. Если мытье полов помогает приблизится команде к цели спринта, то почему бы и нет.
Это нормально — lenta.ru/news/2018/06/05/premiernapa3um
01.07.2018 13:06Корону снимать надо, тут не поспоришь, и да, лучше подтереть за собой, если нагадил, вне зависимости от своего социального статуса или профессиональных компетенций. И позаниматься работой, связанной не со своими прямыми профессиональными качествами и зоной ответственности тоже бывает полезным, когда ты действительно хочешь «вырасти» в эту новую для себя область или хотя бы владелец бизнеса.
Demetrikl Автор
01.07.2018 13:14100% scrum из под палки не заработает. Через боль можно только создать видимость agile. Это начинает работать только когда добровольно и осознано.
napa3um
01.07.2018 13:27+1когда добровольно и осознано
Т.е., когда ты совладелец бизнеса. Именно об этом я и говорю. Все другие «добрые воли» и «осознания» — иллюзия, которая рано или поздно заканчивается, и команда начинает искать нового сектанта взамен перегоревшего старого.ApeCoder
01.07.2018 14:25Люди любят делать крутые полезные вещи для других людей. Не вся мотивация сводится к баблецу. То, что что-то заканчивается не значит, что это иллюзия.
napa3um
01.07.2018 14:31+1Люди любят делать полезные вещи, которыми потом владеют, распоряжаются (да, в том числе, например, чтобы отдать в опенсорс или ещё как сделать этот мир лучше). Владеют юридически или как декларируемый автор, а не безымянная шестерёнка в чужом проекте. Собрать команду бескорыстных и идейных профессионалов, которые продукт-овнеру будут делать бизнес за альтруизм, а не за баблецо (или славу), кажется, чересчур наивной затеей :).
ApeCoder
01.07.2018 15:11Таким образом мы пришли к одному и тому же: практически всегда действует спектр мотиваций и сведение "добровольно и осознано" к "когда ты совладелец бизнеса" (если принимать это "совладелец" буквально, а не как-то метафорически) — некоторое упрощение реальности.
Если принимать метафорически, то совершенно согласен — хороший профессионал чувствует себя ответственным за конечный результат — в каком-то смысле им владеет.
napa3um
01.07.2018 15:16И это владение обеспечивается юридическим правом управления разрабатываемым продуктом и получением выгод реализации этого продукта на рынке. Всё другое — просто попытки обмануть специалиста, заставляя его работать на себя в ущерб его профессиональному росту и сохранения актуальности на рынке труда (путём «размазывания» его компетенций). Потому что размазанные в одном стартапе компетенции в другом уже вряд ли пригодятся (там будут уже другие компетенции «внахлёст» попадать), либо специалист будет ходить по строго одинаковым (а потому заведомо провальным) стартапам.
ApeCoder
01.07.2018 15:34Потому что размазанные в одном стартапе компетенции в другом уже вряд ли пригодятся (там будут уже другие компетенции «внахлёст» попадать),
Так же как и специализация. Тут скорее наоборот, больше вероятность переместить вертикальную палку от T в другое место, если есть горизонтальная — т.е. приспособиться для других условий если есть общее представление о смежных областях.
napa3um
01.07.2018 15:47ApeCoder
01.07.2018 16:43Я не разбираюсь в этих технологиях, так что не могу прокомментировать детально. Я думаю, что некоторые знания переносимы — т.е. если человек в принципе знает реляционные базы и веб разработку, то он может быстрее приспособиться к конкретной реляционной базе и конкретному фреймворку. Т.е. нельзя знать только MySQL, если узнаешь MySQL ты узнаешь так же про реляционные базы вообще, индексы, SQL латентность и прочее.
Если он на досуге поучит NoSQL он сможет применить знания и в том и в этом стартапе и владеть большим количеством технических решений — т.е. большее чувство собственности.
napa3um
01.07.2018 16:51Всё верно, знагия переносимы, и для специалиста, например, по СУБД горизонтальная палочка в букве T — это его компетенции, выходящие за потребности данного конкретного стартапа, знания MS-SQL, например, когда в стартапе используется Oracle. А не знание Фотошопа, чтобы подменить дизайнера. А скрам именно о такой (утрирую) переносимости знаний, когда каждый специалист является компетентным во всём стеке технологий разрабатываемого продукта.
ApeCoder
01.07.2018 17:00А скрам именно о такой (утрирую) переносимости знаний, когда каждый специалист является компетентным во всём стеке технологий разрабатываемого продукта.
Не затруднит ли это подтвердить цитатой из скрам гайд?
napa3um
01.07.2018 16:57Когда специалист по MS-SQL ковыряется в Oracle — это нормально и полезно ему самому. А когда он начинает играть шрифтами на макете, это бесплдезно и для него, и для бизнеса.
ApeCoder
01.07.2018 17:06А если он ковыряется в ASP.NET? Я вот думаю что может быть несколько направлений смежности можно растить горизонтальную палку в направлении разных СУБД (но тогда получается что эта палка будет не использоваться точно в каждом конкретном месте работы кроме некоторых исключений). Можно расти в смежные вещи по стеку. Например в MS-SQL используются другие технологии MS — .NET и Powershell, зная C# можно выучить ASP.NET и уже просто чтобы добавить галочку в форму не надо будет звать фронтэндщика. Знание C# и PS пригодиться и для администрирования IIS. Зная C# можно на другом месте работы выучить Java и т.д.
Если он начнет играть шрифтами и это ему нравится то почему бы нет? Будет способ отдыха. Возможно, ему легче будет понять, как на мир смотрят дизайнеры и это будет источником метафор.
napa3um
01.07.2018 17:24Да, фантазировать можно бесконечно.
ApeCoder
01.07.2018 18:02Да, фантазировать можно бесконечно.
Ну я, честно говоря, больше видел специалистов которые изучали смежные по стеку технологии чем по уровню (трудно на досуге очень хорошо изучить Oracle — так как вся практика на MS SQL — принципы можно, но конкретные глюки/приемы/навыки не очень удобно, так как нужно иметь какой-то рабочий пример) я скорее видел специалистов, которые могли знать соседние элементы стека. Или даже поверхностно весь стек и глубоко предметную область.
А какой у вас опыт?
napa3um
01.07.2018 18:10У меня опыт, показывающий, что участие в стартапе с изучением смежных технологий из любознательности — не очень совместимые процессы. Да, такие разносторонне развитые (уже развитые) люди бывают, да, они могут собраться вместе, да, их стартап может «выстрелить» и «взорвать» рынок. И да, им в этом вполне может помочь скрам. Но это не наёмники, которым спустили сверху директиву «надо поковыряться вот в этой, не связанной с вашей компетенцией, области, чтобы дух команды, чтобы скрам, чтобы во имя процветания человечества».
ApeCoder
01.07.2018 18:26Я не очень понял — вы в стартапе или наемником? Т.е. например команда отвечает за продукт/подсистему X. Надо в продукт добавить галочку в настройки (UI, логику обработки и поле в СУБД) — как это происходило?
napa3um
01.07.2018 18:28Я работал и в стартапах, и наёмником. И в роли менеджера в том числе.
Не думаю, что ваш вопрос будет интересно обсуждать в теме про скрам. Думаю, я уже исчерпывающе объяснил свою точку зрения. Спасибо за участие в беседе.ApeCoder
01.07.2018 21:57+1Почему? Мне просто чисто практически непонятно — в ситуации когда есть потребность при добавлении галки подправить условно html, js, sql и java, вроде все подталкивает к тому чтобы чисто практически выучить немножко того и немножко сего, чтобы сделать эту галку полностью самостоятельно, а не просить Васю. А чтобы в дополнении в MS SQL учить Оракл, придется откуда-то выдумывать задачу и держать этот Оракл в голове работая с MS SQL (см кривая забывания).
Т.е. с моей точки зрения в практической работы горизонтальная линейка у T весьма органично растет на соседние слои стека, и для менеджера это более ценно (для простых операций не надо накладных расходов для взаимодействия между членами команды, а для сложных — больше взаимопонимания).
Именно поэтому мне интересен опыт такого разностороннего профессионала как вы, как получается, что выгоднее по другому. Именно на этом простом примере.
Я буду благодарен если вы мне объясните здесь или персональными сообщениями. Спасибо за дискуссию в любом случае.
napa3um
01.07.2018 22:18-1Ваш нафантазированный пример возможен в проектах уровня хелло-ворлд, для реализации которых, вообще говоря, не нужен не только скрам, но и вообще команда. Не думаю, что смогу вам объяснить наивность ваших фантазий, постепенно сами столкнётесь с масштабированием процесса разработки на своём реальном опыте.
ApeCoder
01.07.2018 22:45+1Не думаю, что смогу вам объяснить наивность ваших фантазий, постепенно сами столкнётесь с масштабированием процесса разработки на своём реальном опыте.
Как жаль что такой опытный, разносторонний и вежливый профессионал как вы не снизошел до объяснения на конкретном примере своей концепции развития компетенций.
Буду надеяться, что мне встретится кто-то другой, кто снизойдет до новичков моего уровня. Или может быть, вы сможете выделить время на то, чтобы написать мемуары о вашем участии в больших проектах? Я понимаю, у вас мало времени, но человечество в моем лице было бы очень благодарно вам. Тем более что это, наверное, менее затратно, чем объяснять чуть дела каждому остолопу, вроде меня. Спасибо большое, что отвечали на мои вопросы, хотя я и понимаю, что ваше терпение не безгранично. Извините, пожалуйста, еще раз за назойливость и еще раз спасибо.
napa3um
02.07.2018 00:18Не обижайтесь и не воспринимайте слишком серьёзно мои слова. Мне действительно лениво продолжать этот разговор, не вижу в этом ничего криминального. Я и так уже изрядно тут понаписал.
APaMazur
02.07.2018 09:30Вы немного о разных вещах рассуждаете
В одном случае — о том, что иногда (или даже часто) получается и выгодно работодателю, и о том, что выгодно самому специалисту
Поясню очень просто: я, например, в силу, в частности, потребностей работодателя, очень много на чем пишу на уровне джуна/мидла, но я не буду писать это все в резюме (потому что раздутые резюме работают хуже, возможно я попытаюсь это использовать как козырь на собеседовании), если завтра решу сменить работу, я напишу одну компетенцию, в которой я не развиваюсь или даже деградирую, пока пилю очередную однотипную задачу в другой области и, типа, развиваюсь
Реально подобное может быть (а может и не быть) выгодно молодым специалистам, которые в основной специализации чуть выше джуна, всем остальным оно злоApeCoder
02.07.2018 10:07Странно, что тут противоречие. Если человек ценен для работадателя, то это повышает его ценность на рынке труда. (если работодатель не очень особенный).
APaMazur
02.07.2018 10:43Противоречие потому, что есть конкретный работодатель и его конкретная текущая задача, а есть рынок с абстрактным работодателем, на которого работает абстрактный рекрутер
Работодателю нужно чтобы вы просто выполняли за свою зарплату максимальный объем работ по проекту и делали это, по возможности, эффективно
Рекрутеру говорят «нам нужен ангулярщик» и он его ищет по ключевым словам
Рекрутеру редко говорят «нам нужен ангулярщик, чтобы он еще чуть-чуть в MySQL мог и питонисту иногда помогал, а еще уборщицу уволили за воровство, надо подменять и бухгалтер приходящий нужен раз в месяц», а найти хорошего специалиста (да и работу) под все компетенции проекта обычно невозможно, только под одну-две, остальные ожидается, что человек на необходимом уровне освоит на месте
Так что не работодатель особенный, а каждый проект более или менее особенный: посмотрите на стек технологий практически в любой области, сделайте поправку на наполнение конкретной команды (где-то, скажем, много бэкендщиков, а где-то фронтендщиков), еще одну поправку просто на стечение обстоятельств на проекте (Вася заболел, Петя уволился, нет времени объяснять, теперь ты еще и специалист по БД, сдаем продукт завтра), вот и выйдет, что объем странных мелких рутинных задач, который на вас свалится будет везде разным и часто предельно странным для вашей целевой компетенции
В итоге специалисту почти всегда выгодно быть максимально компетентным в одной, максимум двух технологиях, а работодателю выгоден относительный фуллстак, если это эффективно и не мешает основной работе, а еще при умении так можно «заточить» специалиста под проект, так что на месте он будет макимально эффективен, а вот «убежать» за большей зарплатой ему будет сложнееApeCoder
02.07.2018 12:34Рекрутеру говорят «нам нужен ангулярщик» и он его ищет по ключевым словам
Рекрутеру редко говорят «нам нужен ангулярщик, чтобы он еще чуть-чуть в MySQL мог и питонисту иногда помогал, а еще уборщицуhttps://hh.ru/search/vacancy?text=MySQL
Я вижу что там как правило требования на соседние по стеку навыки. Откуда ваши сведения?
algotrader2013
01.07.2018 13:28-1когда ты действительно хочешь «вырасти» в эту новую для себя область или хотя бы владелец бизнеса
Есть такая точка зрения, и есть профессионализм рекрутеров, чтобы таких людей на этапе собеседования отсеивать. Увы, гибкие методологии требуют некоторой степени мотивации от членов команды. К слову, некоторые более сложные фреймворки типа скрамбана еще и «взрослости».napa3um
01.07.2018 13:35+1Взрослость как раз и заключается в трезвом понимании того, что пользы будет больше, если каждый будет заниматься своим делом.
Busla
01.07.2018 13:36Просто человек не в той команде. «Продуктом» вполне может быть модуль, сервис, микросервис, БД. В скрамгайде явно указано, что может быть много взаимодействующих команд. А не как в этой статье предлагается тянуть всё единственной командой.
«The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.»Demetrikl Автор
02.07.2018 10:34А не как в этой статье предлагается тянуть всё единственной командой.
Как же вы легко суть то улавливаете? Интересно на чем основан этот вывод?
Нет смысла думать о масштабировании, до того момента пока в одной команде не смогли scrum наладить. Я в статье предлагаю запустить пилот, и уже по его результатам пробовать расширять scrum.Busla
02.07.2018 11:00На вашей рекомендации бесконечно расширять компетенции:
Со временем команда должна стремиться расширять свою функциональность, чтобы полностью покрывать цепочку создания ценности.
Demetrikl Автор
02.07.2018 11:07Зачем бесконечно покрывать? Цепочка создания ценности ограничена, команда не может в рамках неё бесконечно расширять компетенции.
Суть моего высказывания в том, что не стоит выделять команды по компетенциям, т.е. команда фронтендеров, команда бэкендеров и команда QA — это не scrum команды. Scrum команда должна состоять из различных специалистов.
Demetrikl Автор
01.07.2018 12:03Но с другой стороны не только менеджеру полезен t-shaped
В современном мире технологии стремительно рождаются и умирают, прокапывая в глубь конкретную технологию можно оказаться на дне, когда технология уже никому не нужна. Если же в угоду менеджерам человек будет смотреть вширь, то ему самому легче будет оставаться актуальным и востребованным на рынке.napa3um
01.07.2018 12:14Скажем, если человек занимается СУБД, в стартапе пилит MySQL, то на досуге он будет расширять свои компетенции в MS-SQL, Postgre, Mongo, что, скорее всего, совершенно не нужно данному конкретному стартапу. А если пилит на Angular, то в свободное время изучает React, Vue или Polymer. Взгляды на T-шейп для менеджера в конкретном стартапе и программиста сильно различаются.
Demetrikl Автор
01.07.2018 12:45Это так. Но ценный член scrum команды — это тот, кто умеет кооперировать личные и командные интересы.
Еще мне в свете разговоров о scrum непонятно, что за лютый менеджер, который кошмарит бедных разработчиков?napa3um
01.07.2018 13:11+1Но ценный член scrum команды — это тот, кто умеет кооперировать личные и командные интересы.
Всё верно. Я всего лишь акцентирую внимание на том, каким образом этот самый командный интерес возникает, как возникает долгосрочное желание заниматься «не своей» работой. Чтобы она стала «своей», чтобы команда имела ценность, все её участники должны быть владельцами бизнеса. Вот и весь секрет. А сектанством тут не получится подпереть отсутствие мотивации, примерами подтирающего кофе премьерами (если я подотру за собой кофе, я премьером не стану).
ApeCoder
01.07.2018 14:22Команда, любой член которой способен эффективно выполнять любую работу в команде
Между "эту работу может выполнить ровно один человек в команде" и "эту работу одинаково хорошо могут выполнить все люди в команде" есть степени: "эту работу могут выполнить двое" или "эту работу могут выполнить несколько людей но с разной эффективностью"
Fengol
01.07.2018 12:13то вся свобода творчества у команды обычно с продукта перекидывается на технологии.
Правильная команда в любом случаи будет пытаться внедрить в проект новые технологии, которые естественно будут замедлять процесс. Программисты так устроенны, если они не будут что-то новое учить, то их развитие остановится, они начнут чахнуть и убегут с Вашего проекта. И хотя с точки зрения менеджера может показаться что запрет на новые технологии это выгодно, он должен понимать, что действительно стоящие профессионалы не будут работать в таких условиях. А переложить на них другой вид ответственности… В этой идеи что-то конечно есть, но только с точки зрения гуманитария, который больше склонен метаться из одной сферы в другую. Но прежде всего, когда речь идет о команде, до принятия каких-либо решений, нужно советоваться с самой командой.
И тут уже сказали, что цель показать статьи показать какой scrum «не очень», но мне кажется причина в другом. Прежде всего в жестких ограничениях, которые Вы так пытаетесь выделить. Для примера тот же лидер в команде. Вы говорите что лидера быть не должно… Но где Вы найдете команду из ТАКИХ профессионалов, которые в лидере не нуждаются? Таких команды если и есть, то ну в очень и очень и очень крутых компаниях. Поэтому получается что либо scrum только для крутых компаний, либо идеологи не сочли нужным писать на банке coca-cola, что ей «нельзя бить прохожих по голове»-«можно видоизменять для большей эффективности», только потому, что решили что это и так всем понятно.napa3um
01.07.2018 12:16+1, вера в полностью «горизонтальную» команду — это как вера в социализм, где все люди равны во всех проявлениях.
Demetrikl Автор
01.07.2018 12:42Отцы-основатели scrum того же мнения, scrum — это практический фреймворк, а не сферический конь. Никто и не требует этого, когда все равны, то
- если это среднячки, то крутые штуки они делать не смогут.
- если это мегафулстэки, то не сделать из них команду. Будет лебедь, рак и щука.
Scrum — это про объединение людей с разными специализациями в одну команду, готовых помогать друг другу людей.napa3um
01.07.2018 13:17+1Это не скрам, а обычная софистика, которой, конечно, не возразишь. Да, нужно друг другу помогать, да, нужно друг друга слышать, да, нужно не болеть и быть счастливыми, а код писать без багов — но всё это и без всякого скрама нужно делать, и скрам совсем не о том, его цели — это укорачивание обратной связи между бизнесом и рынком путём ограничения размера команды и размазывания зон ответственности за счёт некритичного и управляемого снижения качества и поддерживаемости создаваемого продукта для занятия ниши в условиях высокой конкуренции и пост-постиндустриальной (т.н. инновационной) экономики. А весь этот сектантский/религиозный/идеологический флёр — это непонимание схемы мотивации в таком процессе.
Demetrikl Автор
01.07.2018 12:35Программисты так устроенны, если они не будут что-то новое учить, то их развитие остановится, они начнут чахнуть и убегут с Вашего проекта…
Но прежде всего, когда речь идет о команде, до принятия каких-либо решений, нужно советоваться с самой командой.
Естественно, что если не заниматься рефакторингом, не использовать современные технологии, не работать со свежими версиями библиотек и т.д., то ваш продукт погрязнет в тех.долге и умрет.
Когда команда отвечает за то «как» будет сделана задача, то она вольна выбирать инструментарий, а PO должен довериться ей в этом. Когда команде говорят «ЧТО» делать, т.е. сразу дают тех.задание, то команда начинает битву за технологию.
Кейс именно об этом, что разработчики более сведущие в технологии, дайте им право решать как делать задачу. Это win-win схема PO занимается продуктом и не лезет в детали разработки, а команда решает задачи, о которых им рассказал PO. Они верят, что если PO сказал, что у пользователя болит тут, то это не пустые слова. А как снять боль — это команда решает сама и делает это лучшими средствами.
Для примера тот же лидер в команде. Вы говорите что лидера быть не должно… Но где Вы найдете команду из ТАКИХ профессионалов, которые в лидере не нуждаются?
Не совсем так, я говорю что «назначенный» лидер и scrum плохо подходят друг к другу. Лидерство должно быть ситуационным и органическим. Команда сама понимает, что Вася мегакрут в СУБД, а к Пете можно обратиться по вопросом браузерной оптимизации JS. Просто это естественный процесс, не нужно влезать в него бюрократической машиной.
Таких команды если и есть, то ну в очень и очень и очень крутых компаниях. Поэтому получается что либо scrum только для крутых компаний,
Дело не в крутизне компаний, а в том для чего вам scrum и как понимание этого донесено до людей. Как уже не раз писалось, scrum — это не серебряная пуля. И к сожалению, работать в scrum могут не все люди (жесткий индивидуалист с болью встраивается в scrum процесс). Но если scrum вам подходит, то при правильной настройке, вы получите то, чего хотите. А моя статья — это некие маячки необходимости подстройки.
maxstroy
01.07.2018 16:01Иногда здравый смысл помогает. Я не пойму, зачем его бежать?
ApeCoder
01.07.2018 16:47Напомнило— Мы думали туман, — ответила Ирма.
— Что?
— Думали туман, — повторила Ирма.
— Про туман, — поправил Виктор. — Или о тумане.
— Зачем это — про туман? — сказала Ирма.
— Думать — непереходный глагол, — объяснил Виктор. — Он требует
предлогов. Вы проходили непереходные глаголы?
— Это когда как, — сказала Ирма. — Думать туман — это одно, а думать
про туман — это совсем другое… и кому это нужно — думать про туман,
неизвестно.
Виктор вытащил сигарету и закурил.
— Погоди, — сказал он. — Думать туман — так не говорят, это
неграмотно. Есть такие глаголы — непереходные: думать, бегать, ходить. Они
всегда требуют предлога. Ходить по улице. Думать про… что-нибудь там…qwez
02.07.2018 10:55А где самое главное? Как из группы людей сделать команду?
У меня был опыт когда практически все проблемы, описанные в статье, были решены. Но все равно командой разработчиков в том проекте нельзя было называть. Не было групповой ответственности, все продолжали жить в парадигме «я сделал свою задачу, я молодец». А то, что цель не достигнута или инкремент не работает, это не их вина…
Что в таком случае делать? Разгонять всех и искать новых или надежда есть?Demetrikl Автор
02.07.2018 11:51Отличный вопрос. Спасибо.
Разгонять крайний случай. Большинству людей комфортно в scrum, просто нужна подстройка. Нужно больше деталей конечно, но сходу следующие мысли есть.
Не было групповой ответственности, все продолжали жить в парадигме «я сделал свою задачу, я молодец».
Ответственность это такая штука, которую мало передать, её еще должны взять (прошу простить за капитанство). Отсюда вопрос как у вас проходят планирования?
Кто занимается технической декомпозицией задач? кто определяет цель спринта? кто определяет объём элементов бэклога входящих в инкремент.
ИМХО хорошее планирование должно проходить по следующему сценарию:
- PO ставит цель на спринт (обсуждается с командой)
- PO предлагает объем элементов backlog, которые необходимо сделать чтобы достигнуть цели.
- Команда разбирает (общение с PO) эти элементы, декомпозирует их на задачи (тут важно, чтобы SM фасилитировал и давал высказаться каждому члену команды, чтобы решения были согласованные, а не продиктованные кем-нибудь. Один из возможных инструментов scrum poker)
- Команда составляет план спринта (сново важно, чтобы высказывались все — за этим следит SM)
- Команда САМА выбирает тот объем работы на спринт, с которым она согласна, и который она обязуется сделать.
Если же цели не достигаются и инкременты не выпускаются, то на ретроспективе, нужно разбирать с командой: что пошло не так и почему так вышло? Тут опять же роль SM слушать и слышать. Если все сводится к «наши вашим чем то машут», то SM (в зависимости от команды) можно:
- Вместе с командой попытаться СОВМЕСТНО найти решение, как сделать так чтобы ситуация не повторилась. «Вы согласны что ситуация нехорошая? А давайте найдем способ, как избежать подобной ситуации в будущем.»
- Напрямую вскрыть причины отсутствия взаимопомощи. «Почему ты не помог, если видел, что команде нужна помощь? Какие у тебя были мотивации? Какие у тебя приоритеты и чем ты руководствуешься во время принятие решений?»
- придумать что-то свое
В целом SM — это человек, который должен лучше всех чувствовать и понимать команду. Жесткие меры и создание стресса лучше не применять как главный инструмент работы с командой. Но и совсем пренебрегать им я думаю не получится. Иногда нужен холодный душ, чтобы привести людей в чувства.
qwez если это все опять в молоко, то можно перенести общение в личку. Либо тут раскройте побольше деталей про ваш процессqwez
02.07.2018 12:56На самом деле было бы интересно послушать реальный пример решения подобной проблемы. Т.е. была такая ситуация, полгода делали такие-то упражнения, итог такой-то.
Про мою ситуацию — да все, вроде, было по гайду, но «механически», как вы выразились. И вот это все «Вы согласны что ситуация нехорошая? А давайте найдем способ, как избежать подобной ситуации в будущем.» было, все соглашались и придумывали решения. Но потом ничего не делали и все возвращалось на круги своя. И я не знал как сделать так, чтобы они захотели сплотиться и сделать все красиво.
Единственным решением, мне виделось, это устраивать бесконечные ретро и индивидуальные разговоры. Помогать выбирать нужные для цели задачи. Водить за ручку на нужные встречи. И так далее. Может быть через какое-то время мы бы и взлетели. А может реально людям неинтересно это было и ничего бы не помогло… У всех так в начале или это запущенный случай? :)Demetrikl Автор
02.07.2018 14:23У меня нет опыта, когда все сделали правильно, а команда не вовлеченная. Обычно что-то сделано не так и отсюда проблемы. Поэтому тяжело такой кейс привести. Но исходя из этого:
А задачи для цели делают 2-3 человека (из 8) и в итоге не успевают. По идее, если не успевают, то вся команда должна навалиться и сделать, но сами они это делать не будут.
Проблема то не в вовлеченности участников, а в том что фокуса командного нет.
Я был в ситуации, когда команде нужно за спринт делать разношерстные задачи. Цель спринта выбиралась синтетически (т.е. сперва собирали спринт, а уже потом выписывали цель) — например, самая толстая история — это цель, а остальное подавалось под соусом «это не цель, но тоже очень важно сделать». Но проблема то не в команде, а в такой системе. Решается это все-таки работой с PO и backlog. При желании всегда можно переприоретизировать бэклог так, чтобы истории можно было объединить общей целью. И когда мы пришли к ситуации сфокусированных спринтов (сперва цель, потом истории), когда люди делают задачи под общей целью, то проблема «не переживают, что не достигаем цели спринта» ушла.
Еще момент, нельзя позволять команде садиться на шею SM. Быть только нянькой плохо. Надо жесткости давать.
Tanyapdr
02.07.2018 12:23+1Мне кажется тут или планироваться надо лучше, чтобы цели спринта достигались набором задач спринта. Или на каждом дейли задавать правильный вопрос «Что ты сделал для достижения цели спринта? Что планируешь делать для достижения цели спринта?». Часто ведь люди берут задачи которые им хочется делать(легче, интереснее и тд) не думая о целостности.
qwez
02.07.2018 13:03— «Что планируешь делать для достижения цели спринта?»
— «Ну, я для цели ничего не могу сделать, поэтому будут пилить эту штуку.»
А задачи для цели делают 2-3 человека (из 8) и в итоге не успевают. По идее, если не успевают, то вся команда должна навалиться и сделать, но сами они это делать не будут.Tanyapdr
02.07.2018 13:19+1Ну у нас такое решалось парным программированием, делаешь задачу вместе со специалистом.
Ещё задавали вопросы «Что тебе мешает сделать? Каких навыков не хватает?». Задавайте вопрос Почему? Зачем? Пока не доберётесь до истинных причин.
Это ежедневная работа с сотрудниками, пока они не привыкнут, когда будет полное доверие и желание развиваться.
И есть такая штука как оценка сотрудника службой персонала, по показателям которые можно измерить, для повышения материальной составляющей например. И там просто подводят итог, пол года назад ты такие задачи не делал, а теперь делаешь, давай дальше молодец!
Busla
Вам не кажется, что вы себе противоречите?
Да и в целом: термин «профессионал» про специализацию, а не про решение любых задач.
napa3um
Скрам — про гибкое управление в условиях изменяющихся бизнес-требований, про максимальное снижение лага обратной связи для возможности быстро проверять бизнес-идеи (путём ускорения доставки создаваемой ценности и оценки реакции пользователей/рынка). По сути, скрам — это про стартапы, когда «лучше хуже, но раньше». И именно для стартапов подходит компактная команда, «средне-компетентная» во всех технических аспектах (каждый член команды — full-stack), как раз этим достигается минимизация издержек на коммуникацию между уровнями стека разрабатываемого продукта (ну и сама компактность команды снижает издержки на бюрократию согласований). И в этом таятся нюансы, которые, как мне кажется, часто упускают евангелисты скрама.
Первое — это мотивация для такой бодрой и разносторонней работы с размытой зоной ответственности. Ведь по сути скрам — это делегирование задач микроменеджмента на технических специалистов, экономия на выделенной роли менеджера. Каждый член настоящей скрам-команды должен быть напрямую заинтересован в успехе продукта не просто фиксированной зарплатой или идеей, а возможностью стать совладельцем бизнеса (акционером), когда он из стартапа превратится в таковой. А второе — это то, что скрам заканчивается, когда стартап зарелизил MVP, привлёк инвесторов, выстроил бизнес-модель и, собственно, превратился в бизнес с финансовыми показателями и обязательствами перед инвесторами. Это уже именно тот момент, когда для удержания завоёванных позиций на рынке нужны более жёсткие регламенты и специализация сотрудников, когда уже пора «цементировать» выстроенные в ходе «скрамного» этапа неявные процессы в виде явных ролей, документов, регламентов и прочей ненавистной хипстерскому духу бюрократии. Это тот момент, когда контроль рисков от разрушения процессов становится ценнее духа команды и прочей романтики стартапов.
Отсюда и большинство негатива по отношению к скраму и расхожие слухи о его неудачных внедрениях. Да, часто его внедряют не так (и об этом, в том числе, данная статья). Но ещё чаще, как мне кажется, его внедряют совершенно не там.
ilnuribat
Лично мне кажется, что наоборот, скрам начинается, когда получили инвестиции, набрали спецов и теперь надо слаженно(эффективно, быстро, гибко...) работать
Потому что при создании MVP можно пренебречь сном, графиком и работать без перерыва. Но такое не может продолжаться вечно и мотивация быстро протухнет. Как раз после выхода из такого режима приходит время agile/scrum, который говорит, что является ценным, важным и как нужно работать.
Все эти стендапы, ретро, демо — по сути трата времени. Некоторые этого не понимают. Они хотят работать. А ведь эти артефакты как раз расчитаны на долгосрочную перспективу.
Например, возьмём ретро. После каждого спринта тратим «драгоценное время высоклассных разработчиков» на осбуждения каких-то бытовых проблем. На деле же, мы экономим кучу времени в будущем из-за преодоленных заранее преград, получаем фидбек и делаем улучшения раз за разом.
napa3um
Вы, кажется, не дочитали про все остальные этапы, перечисленные через запятую после MVP. Важное здесь не MVP, а утверждённая бизнес-модель с принятыми обязательствами («чужими» деньгами).
Busla
На счёт MVP — это вы загнули. Скорее с него Scrum как раз начинается, т.к. до этого обратной связи взяться неоткуда, инкременты фиктивные.
napa3um
Вы, кажется, тоже поняли меня так, будто всё кончается на MVP. Кончается всё на фиксации бизнес-модели и рисков для инвесторов.
algotrader2013
Поддерживаю. До MVP максимально эффективно поделить объем работ между теми, кто лучше всех знает технологию, и педалить. Тот же бас фактор до MVP не так страшен, и демо-ретро не особо имеют смысл.
Хотя… с другой стороны, время до MVP это отсутсвие непрогнозируемых багов с прода и фидбеков (вещей, о которых забывают написать в радостных картинках-схемах), и возможность поскрамить, не соприкасаясь с реальным миром.
Demetrikl Автор
Очень плохо, когда инкременты фиктивные. В целом можно и до MVP получать обратную связь, прототипное тестирование (бумага, картон), например. Делая автоматизирование решение, можно готовить сперва прототип с человеком внутри, который будет выполнять задачи автоматизации. Сила эмпирического процесса в том, чтобы получать обратную связь как можно раньше. Если проявлять изобретательность, то можно делать не-фиктивные инкременты, а пригодные для получение обратной связи (но например непригодные для выпуска на рынок).
Важный вопрос сколько нужно времени на создание MVP, если это полгода в вакууме, то стоит подумать об эмпиризме. Если это месяц, то делайте месячные спринты (конечно если scrum вам подходит).
Demetrikl Автор
Мне кажется, в стартапе вообще фреймворки не нужны (Ровно из тех причин, которые вы описываете). В стартапе ты либо делаешь то что нужно, либо стартап исчезнет. В моем опыте стартап (нас было 9 человек, я был разработчиком) — это по-настоящему эмпирический процесс, но не настолько формализованный как scrum. И, например, когда нужно было монтировать оборудование, то никто не говорил — «это не моя обязанность», мы просто шли и делали.
Тут еще вопрос что называть стартапом, ведь понятие стартапа зачастую опошлено, также как agile и scrum. Приходилось видеть, как компании с более чем 10-тилетним существованием на рынке и 1000+ сотрудников любят называть себя стартапом.
Мне кажется грубоватое допущение. Это может быть во многих аспектах так (стартап — это же ограниченный бюджет), но скорее всего (если мы говорим о технологических стартапах) в области ключевого преимущества продукта работают настоящие спецы.
Эта схема актуальна на конкурентном рынке: либо ты запускаешь свежую бизнес-идею, либо ты позже копируешь её у конкурентов. Т.е. потребность есть не только в стартапах. Закрывать потребность можно по разному и scrum — это не единственный ответ.
Сильное утверждение, но я не до конца понимаю почему это "НУЖНО"? Понимаю, что это холиварная тема, тут в общем то копья и ломаются. Но может быть у вас есть примеры?
Золотые слова! Очень хочется, чтобы перед внедрением scrum, те кто это делают осознали для чего они это делают? И подходит ли scrum под решение их задачи.
napa3um
Да, это уже вопрос терминологии. В рамках большой и долгоживущей корпорации вполне себе можно выделять небольшие рабочие группы для проверки новых бизнес-идей, и их вполне себе можно называть стартапами. Под стартапом я понимаю только одно — это отсутствие рабочей бизнес-модели, этап её активного поиска (через активную обратную связь с рынком). И этот этап может быть очень затяжным, так, что и десятилетние компании с тысячами сотрудников могут называться стартапом, если они до сих пор не зарабатывают денег, а живут только на вере инвесторов (hello, Twitter).
Demetrikl Автор
С этим согласен. И мне нравятся компании, которые так и поступают: создают под свежую бизнес-идею отдельную команду, не зажатую общими правилами игры.
Но все-таки хотелось бы понять, почему с зарабатыванием «нужно бетонировать»? Почему эмпирический процесс перестаёт работать?
napa3um
Потому что обязательства перед «внешними» людьми, «чужими» деньгами, и страхование от рисков, чтобы в случае банкротства провести официальную процедуру, подкреплённую бумагами, что «все были согласны с таким процессом/решением», а не открытие уголовного дела на топ-менеджеров. И в случае успеха распределить заработанные деньги так, чтобы все были довольны, а не открывали уголовные дела на топ-менеджеров.
Demetrikl Автор
Это все справедливо, но наверное все таки разные плоскости. Scrum может оставаться тактическим инструментом в разработке. Не вижу явной несовместимости инвестирования и наличия scrum. Насколько я знаю на западе некоторые фонды наоборот требуют наличия scrum.
napa3um
Да, существует так называемое венчурное инвестирование (или посевное, если говорить о более ранних этапах) и соответсвующие фонды, специализирующиеся на поддержке как раз стартапов. Скрам может оставаться тактическим инструментом, да, если бизнес может себе позволить статью расходов на исследование рынка (позволить себе создавать и уничтожать рабочие группы для быстрого создания принципиально новых продуктов и проверки их жизнеспособности), а не только развивать уже построенную бизнес-модель (когда исследования сводятся, по сути, к AB-тестированию, а не проверке принципиально новых бизнес-идей).
Demetrikl Автор
Тут нет противоречия. Scrum guide говорит о том, что команда должна быть кросс-функциональной: «Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;» Отсюда мой кейс о том, что команда должна стараться получать все необходимые компетенции для создания инкремента. Это фактически необходимое правило. А дальше уже становится важен bus factor команды: развиваем t-shaped, чтобы одни члены команды могли подстраховать других в случае чего.
НО это абсолютно не означает, что все члены должны быть одинаковыми по своим умениям и знаниям. Наоборот если команда полностью состоит MEGE-FULL-STACK специалистов, то из таких людей сложно сколотить команду, потому что они могут решать задачи в одиночку, зачем им работать командой?
Речь именно о T — специалистах: «individual who has deep knowledge and skills in a particular area of specialization, along with and the desire and ability to make connections across disciplines.»
Но и про «решение задач» — это относится к команде целиком, а не о каждом её члене в отдельности. Конечно нужны настоящие профессионалы в своих различных областях, чтобы команде были по плечу настоящие вызовы. Вопрос в том, что станет с общекомандной функциональной мощностью в отсутствии одного из его членов: команда полностью не сможет решать определенный пласт задач, либо просто будет это делать дольше и с меньшим качеством.
Busla
«Это» не обозначает, про отсутствие специализаций внутри команды — другие пункты:
accountability belongs to the Development Team as a whole.
Суть идеи в том, что любой член команды может решить любую задачу из backlog. А не в том, что сыплем задачи в одну кучу, хотя знаем, что с БД может работать только один человек, а с GUI только другой.
algotrader2013
Где именно такое указывается? Я видел утверждения лишь о кроссфункциональных командах, которые могут самостоятельно решить любую задачу из беклога, но не о кроссфункциональных людях.
napa3um
Термин T-shaped-people — это о том, что люди в команде должны уметь всё. Да, это утверждение не сильно содержательное, и все понимают его очень по-разному. Менеджеры вытягивают горизонтальную палочку в букве T, видят в нём команду лесорубов, которые полностью могут заменить друг друга (можно даже не запоминать, как их зовут). А программисты, как правило, вытягивают вертикальную палочку в букве T, и даже, возможно, выстраивают эти T в виде лесенки по авторитетности экспертного мнения каждого. Программисту хочется ковыряться в своём модуле или слое архитектуры, быть ответственным за внутреннее качество реализации какой-то части функционала или инструментария, владеть каким-то артефактом разработки. Потому что профессионал-исполнитель не только делает продукт (ведь не он его владелец), он ещё и делает себя, растёт профессионально, углубляясь в интересные ему темы (чтобы поддерживать свою актуальность на рынке труда). Чтобы после такого «эффективного стартапа» не оказаться отработанным и бесполезным T-шейпед-эникеем (нихрена не умею толком, но могу подменить тестировщика или дизайнера, если тот заболеет).
Demetrikl Автор
Прекрасно расписано!
Помимо самих скилов в букве Т, важна готовность делать задачи в горизонтальной плоскости. Важно различать «можется» и «хочется». ИМХО scrum говорит о том, что команды в которых люди готовы делать не профильную работу — более подвижны и способны к адаптации.
napa3um
Да, я и хотел в первом своём комментарии подчеркнуть такой нюанс. Нюанс в том, что эта готовность и подвижность должна быть обоснована каким-то реальным мотивом. Должна быть прямая связь между успехом создаваемого продукта и успехом готового на кроссфункциональную активность специалиста (ведь это так или иначе идёт в ущерб его профессиональному росту, снижает фокус на его основных компетенциях). И зарплатой тут не обойтись, реальный мотив будет только у совладельца бизнеса, он может рискнуть своим профессиональным ростом, т.к. в будущем его будет кормить созданный бизнес, а не продажа своих человеко-часов. Любой другой мотив будет временным, и рано или поздно вовлечённый в горизонтальную активность специалист «перегорит», почувствует себя обманутым и использованным. И вместо признания проблемы управления эффективный менеджер уволит такого специалиста и вернётся к поиску нового, молодого и перспективного, с горящими глазами, продолжить эту игру в скрам.
Demetrikl Автор
Да про мотивацию абсолютно верно. Совсем недавно была статья на хабре про реалии российского IT рынка. Что очень странно ждать вовлеченности от людей на окладе. Запад это давно осознал и опционы — это просто мастхэв. Надеюсь наш рынок дорастет до этого.
Demetrikl Автор
Люто плюсую
Demetrikl Автор
Это где такая суть? У кого?
Если разбирать перечисленные вами пункты из scrum guide, то приведу моё понимание:
Фокус на том, чтобы не было фраз типа «я [такой то] и не буду делать [то-то], потому что это не моя обязанность». Если работа должна быть сделана, то она должна быть сделана. Все прикладывают максимально возможные усилия для достижения цели спринта. Опять же это не означают тупое вкалывание. Scrum требует планирование спринта, где один из вопросов на который должна ответить команда это: «How will the work needed to deliver the Increment be achieved?». Т.е. команда составляет план спринта и прикидывает как распределить свои силы на дистанции. Т.е. уже на планировании команда может увидеть, что не хватает сил по какому то направлению, и как следствие распределить эту работу. пример из другого моего комментария.
Ну это примерно как и предыдущий пункт, не должно быть под-ролей / под-команд с личными целями. У всех фокус на достижение цели спринта.
А тут в общем то и говорится, что могут быть специализированные скилы у отдельных членов команды и они усиливают команду в целом. Что в этом и сила: берем людей разной специализации, правильно настраиваем их (взаимопомощь, обучение друг друга, фокусировка на общей цели) и получаем scrum команду.
Busla
Вот вы сами себе и ответили: «обязанность» — это умения, знания, навыки которые ты озвучил приходя в команду.
Это просто логика от обратного: если в команде есть специализация — это обязанность. Если двое специализируются на БД — это sub-team, который явно запрещён. Если на БД специализируется один — теряется смысл общего backlog'f — т.к. задачи по факту заранее назначены конкретным специалистам.
ApeCoder
Еще у них могут быть разные горизонтальные палочки в T — один из них БД-и-тестер, а другой БД-и-бекенд.
Busla
А разница? — всё равно они оказываются подгруппой, которая внутри себя делит все задачи по БД, а бэклог оказывается не общим.
ApeCoder
Почему не общим? Они могут работать на одним PBI в сотрудничестве с другими членами команды? А то получается что каждый отдельный человек это отдельная команда.
Busla
Потому что общий — это одинаковый для всех. А у вас он общий только на картинке, а реально вы подразумеваете, что спец по БД, как сознательный сотрудник, будет в первую очередь брать задачи по БД.
ApeCoder
Общий — это один на всех, а не одинаковый. И там обычно на задачи а вот что:
То есть например PBI может быть "Добавить обработку бесконтактных карт", которая подразумевает "дизайн, реализация и тестирование". Соответственно команда делает PBI внутри себя распределяя задачи.
Скорее всего, спец по БД, если нет задачи по БД, вполне может, например, выполнить задачу по тестированию PBI если есть такой, а тестеры заняты.
UnclShura
Из того что я могу писать plsql процедуры вовсе не значит что я это буду делать. Знаю я вот например такой язык из 90х — Gupta называется, но и под страхом увольнения на нем ни оператора не добавлю (Там не текстовые исходники).
Во всех предложениях сверху говорится о команде целиком. Есть правда ересь о подкомандах. Ну так и не обязательно следовать всякой мути.
Demetrikl Автор
Не стоит путать технические задачи и элементы бэклога. Если в вашем понимании в продуктовом бэклоге лежат задачи типа «Запилить индекс в базе ...», то что-то не так с вашим продуктовым бэклогом.
Scrum guide не дает ответа как должны выглядеть элементы бэклога. Это уже вопрос индивидуальный. Но весьма распространена практика собирать backlog из epics и user story. В таком подходе, я не понимаю как будет следовать специализация историй. История описывает потребность. Команда решает как она будет её закрывать. Наличие различных специалистов в команде дает гибкость такой команде в поиске вариантов решения (любую задачу можно решить кучей способов). Задача команды исходя из своих компетенций придумать такое решение, которое принесет максимальную пользу (value). И команда нацелена доставить инкремент и закрыть пользовательскую потребность имеющимися силами.
Я не понимаю, где тут противоречие? Где потребность в выравнивании членов команды? Узкие специализации отдельных членов команды, только усиливают команду целиком. ВАЖНО чтобы люди не запирались в колодце своей специализации, не для каждой истории может быть необходима именно эта специализация, в такие моменты член команды приносит пользу другой работой.