Comments 110
Вам не кажется, что вы себе противоречите?
Да и в целом:
плохо: Если команда зависит от компетенций одного из её членов
Когда команда справляется с отсутствием компетенции (новый член команды...
Да и в целом:
классные профессионалы, способные решать любые задачитермин «профессионал» про специализацию, а не про решение любых задач.
Скрам — про гибкое управление в условиях изменяющихся бизнес-требований, про максимальное снижение лага обратной связи для возможности быстро проверять бизнес-идеи (путём ускорения доставки создаваемой ценности и оценки реакции пользователей/рынка). По сути, скрам — это про стартапы, когда «лучше хуже, но раньше». И именно для стартапов подходит компактная команда, «средне-компетентная» во всех технических аспектах (каждый член команды — full-stack), как раз этим достигается минимизация издержек на коммуникацию между уровнями стека разрабатываемого продукта (ну и сама компактность команды снижает издержки на бюрократию согласований). И в этом таятся нюансы, которые, как мне кажется, часто упускают евангелисты скрама.
Первое — это мотивация для такой бодрой и разносторонней работы с размытой зоной ответственности. Ведь по сути скрам — это делегирование задач микроменеджмента на технических специалистов, экономия на выделенной роли менеджера. Каждый член настоящей скрам-команды должен быть напрямую заинтересован в успехе продукта не просто фиксированной зарплатой или идеей, а возможностью стать совладельцем бизнеса (акционером), когда он из стартапа превратится в таковой. А второе — это то, что скрам заканчивается, когда стартап зарелизил MVP, привлёк инвесторов, выстроил бизнес-модель и, собственно, превратился в бизнес с финансовыми показателями и обязательствами перед инвесторами. Это уже именно тот момент, когда для удержания завоёванных позиций на рынке нужны более жёсткие регламенты и специализация сотрудников, когда уже пора «цементировать» выстроенные в ходе «скрамного» этапа неявные процессы в виде явных ролей, документов, регламентов и прочей ненавистной хипстерскому духу бюрократии. Это тот момент, когда контроль рисков от разрушения процессов становится ценнее духа команды и прочей романтики стартапов.
Отсюда и большинство негатива по отношению к скраму и расхожие слухи о его неудачных внедрениях. Да, часто его внедряют не так (и об этом, в том числе, данная статья). Но ещё чаще, как мне кажется, его внедряют совершенно не там.
Первое — это мотивация для такой бодрой и разносторонней работы с размытой зоной ответственности. Ведь по сути скрам — это делегирование задач микроменеджмента на технических специалистов, экономия на выделенной роли менеджера. Каждый член настоящей скрам-команды должен быть напрямую заинтересован в успехе продукта не просто фиксированной зарплатой или идеей, а возможностью стать совладельцем бизнеса (акционером), когда он из стартапа превратится в таковой. А второе — это то, что скрам заканчивается, когда стартап зарелизил MVP, привлёк инвесторов, выстроил бизнес-модель и, собственно, превратился в бизнес с финансовыми показателями и обязательствами перед инвесторами. Это уже именно тот момент, когда для удержания завоёванных позиций на рынке нужны более жёсткие регламенты и специализация сотрудников, когда уже пора «цементировать» выстроенные в ходе «скрамного» этапа неявные процессы в виде явных ролей, документов, регламентов и прочей ненавистной хипстерскому духу бюрократии. Это тот момент, когда контроль рисков от разрушения процессов становится ценнее духа команды и прочей романтики стартапов.
Отсюда и большинство негатива по отношению к скраму и расхожие слухи о его неудачных внедрениях. Да, часто его внедряют не так (и об этом, в том числе, данная статья). Но ещё чаще, как мне кажется, его внедряют совершенно не там.
скрам заканчивается, когда стартап зарелизил MVP
Лично мне кажется, что наоборот, скрам начинается, когда получили инвестиции, набрали спецов и теперь надо слаженно(эффективно, быстро, гибко...) работать
Потому что при создании MVP можно пренебречь сном, графиком и работать без перерыва. Но такое не может продолжаться вечно и мотивация быстро протухнет. Как раз после выхода из такого режима приходит время agile/scrum, который говорит, что является ценным, важным и как нужно работать.
Все эти стендапы, ретро, демо — по сути трата времени. Некоторые этого не понимают. Они хотят работать. А ведь эти артефакты как раз расчитаны на долгосрочную перспективу.
Например, возьмём ретро. После каждого спринта тратим «драгоценное время высоклассных разработчиков» на осбуждения каких-то бытовых проблем. На деле же, мы экономим кучу времени в будущем из-за преодоленных заранее преград, получаем фидбек и делаем улучшения раз за разом.
… когда стартап зарелизил MVP, привлёк инвесторов, выстроил бизнес-модель и, собственно, превратился в бизнес с финансовыми показателями и обязательствами перед инвесторами.
Вы, кажется, не дочитали про все остальные этапы, перечисленные через запятую после MVP. Важное здесь не MVP, а утверждённая бизнес-модель с принятыми обязательствами («чужими» деньгами).
На счёт MVP — это вы загнули. Скорее с него Scrum как раз начинается, т.к. до этого обратной связи взяться неоткуда, инкременты фиктивные.
… когда стартап зарелизил MVP, привлёк инвесторов, выстроил бизнес-модель и, собственно, превратился в бизнес с финансовыми показателями и обязательствами перед инвесторами.
Вы, кажется, тоже поняли меня так, будто всё кончается на MVP. Кончается всё на фиксации бизнес-модели и рисков для инвесторов.
Поддерживаю. До MVP максимально эффективно поделить объем работ между теми, кто лучше всех знает технологию, и педалить. Тот же бас фактор до MVP не так страшен, и демо-ретро не особо имеют смысл.
Хотя… с другой стороны, время до MVP это отсутсвие непрогнозируемых багов с прода и фидбеков (вещей, о которых забывают написать в радостных картинках-схемах), и возможность поскрамить, не соприкасаясь с реальным миром.
Хотя… с другой стороны, время до MVP это отсутсвие непрогнозируемых багов с прода и фидбеков (вещей, о которых забывают написать в радостных картинках-схемах), и возможность поскрамить, не соприкасаясь с реальным миром.
Очень плохо, когда инкременты фиктивные. В целом можно и до MVP получать обратную связь, прототипное тестирование (бумага, картон), например. Делая автоматизирование решение, можно готовить сперва прототип с человеком внутри, который будет выполнять задачи автоматизации. Сила эмпирического процесса в том, чтобы получать обратную связь как можно раньше. Если проявлять изобретательность, то можно делать не-фиктивные инкременты, а пригодные для получение обратной связи (но например непригодные для выпуска на рынок).
Важный вопрос сколько нужно времени на создание MVP, если это полгода в вакууме, то стоит подумать об эмпиризме. Если это месяц, то делайте месячные спринты (конечно если scrum вам подходит).
Важный вопрос сколько нужно времени на создание MVP, если это полгода в вакууме, то стоит подумать об эмпиризме. Если это месяц, то делайте месячные спринты (конечно если scrum вам подходит).
Мне кажется, в стартапе вообще фреймворки не нужны (Ровно из тех причин, которые вы описываете). В стартапе ты либо делаешь то что нужно, либо стартап исчезнет. В моем опыте стартап (нас было 9 человек, я был разработчиком) — это по-настоящему эмпирический процесс, но не настолько формализованный как scrum. И, например, когда нужно было монтировать оборудование, то никто не говорил — «это не моя обязанность», мы просто шли и делали.
Тут еще вопрос что называть стартапом, ведь понятие стартапа зачастую опошлено, также как agile и scrum. Приходилось видеть, как компании с более чем 10-тилетним существованием на рынке и 1000+ сотрудников любят называть себя стартапом.
Мне кажется грубоватое допущение. Это может быть во многих аспектах так (стартап — это же ограниченный бюджет), но скорее всего (если мы говорим о технологических стартапах) в области ключевого преимущества продукта работают настоящие спецы.
Эта схема актуальна на конкурентном рынке: либо ты запускаешь свежую бизнес-идею, либо ты позже копируешь её у конкурентов. Т.е. потребность есть не только в стартапах. Закрывать потребность можно по разному и scrum — это не единственный ответ.
Сильное утверждение, но я не до конца понимаю почему это "НУЖНО"? Понимаю, что это холиварная тема, тут в общем то копья и ломаются. Но может быть у вас есть примеры?
Золотые слова! Очень хочется, чтобы перед внедрением scrum, те кто это делают осознали для чего они это делают? И подходит ли scrum под решение их задачи.
Тут еще вопрос что называть стартапом, ведь понятие стартапа зачастую опошлено, также как agile и scrum. Приходилось видеть, как компании с более чем 10-тилетним существованием на рынке и 1000+ сотрудников любят называть себя стартапом.
И именно для стартапов подходит компактная команда, «средне-компетентная» во всех технических аспектах (каждый член команды — full-stack)
Мне кажется грубоватое допущение. Это может быть во многих аспектах так (стартап — это же ограниченный бюджет), но скорее всего (если мы говорим о технологических стартапах) в области ключевого преимущества продукта работают настоящие спецы.
максимальное снижение лага обратной связи для возможности быстро проверять бизнес-идеи… По сути, скрам — это про стартапы, когда «лучше хуже, но раньше».
Эта схема актуальна на конкурентном рынке: либо ты запускаешь свежую бизнес-идею, либо ты позже копируешь её у конкурентов. Т.е. потребность есть не только в стартапах. Закрывать потребность можно по разному и scrum — это не единственный ответ.
Это уже именно тот момент, когда для удержания завоёванных позиций на рынке нужны более жёсткие регламенты и специализация сотрудников, когда уже пора «цементировать» выстроенные в ходе «скрамного» этапа неявные процессы в виде явных ролей, документов, регламентов и прочей ненавистной хипстерскому духу бюрократии.
Сильное утверждение, но я не до конца понимаю почему это "НУЖНО"? Понимаю, что это холиварная тема, тут в общем то копья и ломаются. Но может быть у вас есть примеры?
Отсюда и большинство негатива по отношению к скраму и расхожие слухи о его неудачных внедрениях. Да, часто его внедряют не так (и об этом, в том числе, данная статья). Но ещё чаще, как мне кажется, его внедряют совершенно не там.
Золотые слова! Очень хочется, чтобы перед внедрением scrum, те кто это делают осознали для чего они это делают? И подходит ли scrum под решение их задачи.
Эта схема актуальна на конкурентном рынке: либо ты запускаешь свежую бизнес-идею, либо ты позже копируешь её у конкурентов. Т.е. потребность есть не только в стартапах.
Да, это уже вопрос терминологии. В рамках большой и долгоживущей корпорации вполне себе можно выделять небольшие рабочие группы для проверки новых бизнес-идей, и их вполне себе можно называть стартапами. Под стартапом я понимаю только одно — это отсутствие рабочей бизнес-модели, этап её активного поиска (через активную обратную связь с рынком). И этот этап может быть очень затяжным, так, что и десятилетние компании с тысячами сотрудников могут называться стартапом, если они до сих пор не зарабатывают денег, а живут только на вере инвесторов (hello, Twitter).
С этим согласен. И мне нравятся компании, которые так и поступают: создают под свежую бизнес-идею отдельную команду, не зажатую общими правилами игры.
Но все-таки хотелось бы понять, почему с зарабатыванием «нужно бетонировать»? Почему эмпирический процесс перестаёт работать?
Но все-таки хотелось бы понять, почему с зарабатыванием «нужно бетонировать»? Почему эмпирический процесс перестаёт работать?
Потому что обязательства перед «внешними» людьми, «чужими» деньгами, и страхование от рисков, чтобы в случае банкротства провести официальную процедуру, подкреплённую бумагами, что «все были согласны с таким процессом/решением», а не открытие уголовного дела на топ-менеджеров. И в случае успеха распределить заработанные деньги так, чтобы все были довольны, а не открывали уголовные дела на топ-менеджеров.
Это все справедливо, но наверное все таки разные плоскости. Scrum может оставаться тактическим инструментом в разработке. Не вижу явной несовместимости инвестирования и наличия scrum. Насколько я знаю на западе некоторые фонды наоборот требуют наличия scrum.
Да, существует так называемое венчурное инвестирование (или посевное, если говорить о более ранних этапах) и соответсвующие фонды, специализирующиеся на поддержке как раз стартапов. Скрам может оставаться тактическим инструментом, да, если бизнес может себе позволить статью расходов на исследование рынка (позволить себе создавать и уничтожать рабочие группы для быстрого создания принципиально новых продуктов и проверки их жизнеспособности), а не только развивать уже построенную бизнес-модель (когда исследования сводятся, по сути, к AB-тестированию, а не проверке принципиально новых бизнес-идей).
Тут нет противоречия. 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.»
Но и про «решение задач» — это относится к команде целиком, а не о каждом её члене в отдельности. Конечно нужны настоящие профессионалы в своих различных областях, чтобы команде были по плечу настоящие вызовы. Вопрос в том, что станет с общекомандной функциональной мощностью в отсутствии одного из его членов: команда полностью не сможет решать определенный пласт задач, либо просто будет это делать дольше и с меньшим качеством.
НО это абсолютно не означает, что все члены должны быть одинаковыми по своим умениям и знаниям. Наоборот если команда полностью состоит 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.»
термин «профессионал» про специализацию, а не про решение любых задач.
Но и про «решение задач» — это относится к команде целиком, а не о каждом её члене в отдельности. Конечно нужны настоящие профессионалы в своих различных областях, чтобы команде были по плечу настоящие вызовы. Вопрос в том, что станет с общекомандной функциональной мощностью в отсутствии одного из его членов: команда полностью не сможет решать определенный пласт задач, либо просто будет это делать дольше и с меньшим качеством.
«Это» не обозначает, про отсутствие специализаций внутри команды — другие пункты:
Суть идеи в том, что любой член команды может решить любую задачу из backlog. А не в том, что сыплем задачи в одну кучу, хотя знаем, что с БД может работать только один человек, а с GUI только другой.
- Scrum recognizes no titles for Development Team members
- Scrum recognizes no sub-teams in the Development Team
- Individual Development Team members may have specialized skills and areas of focus, but
accountability belongs to the Development Team as a whole.
Суть идеи в том, что любой член команды может решить любую задачу из backlog. А не в том, что сыплем задачи в одну кучу, хотя знаем, что с БД может работать только один человек, а с GUI только другой.
Суть идеи в том, что любой член команды может решить любую задачу из backlog
Где именно такое указывается? Я видел утверждения лишь о кроссфункциональных командах, которые могут самостоятельно решить любую задачу из беклога, но не о кроссфункциональных людях.
Термин T-shaped-people — это о том, что люди в команде должны уметь всё. Да, это утверждение не сильно содержательное, и все понимают его очень по-разному. Менеджеры вытягивают горизонтальную палочку в букве T, видят в нём команду лесорубов, которые полностью могут заменить друг друга (можно даже не запоминать, как их зовут). А программисты, как правило, вытягивают вертикальную палочку в букве T, и даже, возможно, выстраивают эти T в виде лесенки по авторитетности экспертного мнения каждого. Программисту хочется ковыряться в своём модуле или слое архитектуры, быть ответственным за внутреннее качество реализации какой-то части функционала или инструментария, владеть каким-то артефактом разработки. Потому что профессионал-исполнитель не только делает продукт (ведь не он его владелец), он ещё и делает себя, растёт профессионально, углубляясь в интересные ему темы (чтобы поддерживать свою актуальность на рынке труда). Чтобы после такого «эффективного стартапа» не оказаться отработанным и бесполезным T-шейпед-эникеем (нихрена не умею толком, но могу подменить тестировщика или дизайнера, если тот заболеет).
Прекрасно расписано!
Помимо самих скилов в букве Т, важна готовность делать задачи в горизонтальной плоскости. Важно различать «можется» и «хочется». ИМХО scrum говорит о том, что команды в которых люди готовы делать не профильную работу — более подвижны и способны к адаптации.
Помимо самих скилов в букве Т, важна готовность делать задачи в горизонтальной плоскости. Важно различать «можется» и «хочется». ИМХО scrum говорит о том, что команды в которых люди готовы делать не профильную работу — более подвижны и способны к адаптации.
Да, я и хотел в первом своём комментарии подчеркнуть такой нюанс. Нюанс в том, что эта готовность и подвижность должна быть обоснована каким-то реальным мотивом. Должна быть прямая связь между успехом создаваемого продукта и успехом готового на кроссфункциональную активность специалиста (ведь это так или иначе идёт в ущерб его профессиональному росту, снижает фокус на его основных компетенциях). И зарплатой тут не обойтись, реальный мотив будет только у совладельца бизнеса, он может рискнуть своим профессиональным ростом, т.к. в будущем его будет кормить созданный бизнес, а не продажа своих человеко-часов. Любой другой мотив будет временным, и рано или поздно вовлечённый в горизонтальную активность специалист «перегорит», почувствует себя обманутым и использованным. И вместо признания проблемы управления эффективный менеджер уволит такого специалиста и вернётся к поиску нового, молодого и перспективного, с горящими глазами, продолжить эту игру в скрам.
Да про мотивацию абсолютно верно. Совсем недавно была статья на хабре про реалии российского IT рынка. Что очень странно ждать вовлеченности от людей на окладе. Запад это давно осознал и опционы — это просто мастхэв. Надеюсь наш рынок дорастет до этого.
Люто плюсую
Суть идеи в том, что любой член команды может решить любую задачу из backlog.
Это где такая суть? У кого?
Если разбирать перечисленные вами пункты из scrum guide, то приведу моё понимание:
Scrum recognizes no titles for Development Team members
Фокус на том, чтобы не было фраз типа «я [такой то] и не буду делать [то-то], потому что это не моя обязанность». Если работа должна быть сделана, то она должна быть сделана. Все прикладывают максимально возможные усилия для достижения цели спринта. Опять же это не означают тупое вкалывание. Scrum требует планирование спринта, где один из вопросов на который должна ответить команда это: «How will the work needed to deliver the Increment be achieved?». Т.е. команда составляет план спринта и прикидывает как распределить свои силы на дистанции. Т.е. уже на планировании команда может увидеть, что не хватает сил по какому то направлению, и как следствие распределить эту работу. пример из другого моего комментария.
Scrum recognizes no sub-teams in the Development Team
Ну это примерно как и предыдущий пункт, не должно быть под-ролей / под-команд с личными целями. У всех фокус на достижение цели спринта.
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
А тут в общем то и говорится, что могут быть специализированные скилы у отдельных членов команды и они усиливают команду в целом. Что в этом и сила: берем людей разной специализации, правильно настраиваем их (взаимопомощь, обучение друг друга, фокусировка на общей цели) и получаем scrum команду.
Вот вы сами себе и ответили: «обязанность» — это умения, знания, навыки которые ты озвучил приходя в команду.
Это просто логика от обратного: если в команде есть специализация — это обязанность. Если двое специализируются на БД — это sub-team, который явно запрещён. Если на БД специализируется один — теряется смысл общего backlog'f — т.к. задачи по факту заранее назначены конкретным специалистам.
Это просто логика от обратного: если в команде есть специализация — это обязанность. Если двое специализируются на БД — это sub-team, который явно запрещён. Если на БД специализируется один — теряется смысл общего backlog'f — т.к. задачи по факту заранее назначены конкретным специалистам.
Если двое специализируются на БД — это sub-team, который явно запрещён.
Во-первых, почему это сабтим? Они не обязаны работать только друг с другом (так же как и все специалисты по БД в компании не образуют "команду БД")
Еще у них могут быть разные горизонтальные палочки в T — один из них БД-и-тестер, а другой БД-и-бекенд.
А разница? — всё равно они оказываются подгруппой, которая внутри себя делит все задачи по БД, а бэклог оказывается не общим.
Почему не общим? Они могут работать на одним PBI в сотрудничестве с другими членами команды? А то получается что каждый отдельный человек это отдельная команда.
Потому что общий — это одинаковый для всех. А у вас он общий только на картинке, а реально вы подразумеваете, что спец по БД, как сознательный сотрудник, будет в первую очередь брать задачи по БД.
Общий — это один на всех, а не одинаковый. И там обычно на задачи а вот что:
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".
То есть например PBI может быть "Добавить обработку бесконтактных карт", которая подразумевает "дизайн, реализация и тестирование". Соответственно команда делает PBI внутри себя распределяя задачи.
Скорее всего, спец по БД, если нет задачи по БД, вполне может, например, выполнить задачу по тестированию PBI если есть такой, а тестеры заняты.
Из того что я могу писать plsql процедуры вовсе не значит что я это буду делать. Знаю я вот например такой язык из 90х — Gupta называется, но и под страхом увольнения на нем ни оператора не добавлю (Там не текстовые исходники).
Во всех предложениях сверху говорится о команде целиком. Есть правда ересь о подкомандах. Ну так и не обязательно следовать всякой мути.
Не стоит путать технические задачи и элементы бэклога. Если в вашем понимании в продуктовом бэклоге лежат задачи типа «Запилить индекс в базе ...», то что-то не так с вашим продуктовым бэклогом.
Scrum guide не дает ответа как должны выглядеть элементы бэклога. Это уже вопрос индивидуальный. Но весьма распространена практика собирать backlog из epics и user story. В таком подходе, я не понимаю как будет следовать специализация историй. История описывает потребность. Команда решает как она будет её закрывать. Наличие различных специалистов в команде дает гибкость такой команде в поиске вариантов решения (любую задачу можно решить кучей способов). Задача команды исходя из своих компетенций придумать такое решение, которое принесет максимальную пользу (value). И команда нацелена доставить инкремент и закрыть пользовательскую потребность имеющимися силами.
Я не понимаю, где тут противоречие? Где потребность в выравнивании членов команды? Узкие специализации отдельных членов команды, только усиливают команду целиком. ВАЖНО чтобы люди не запирались в колодце своей специализации, не для каждой истории может быть необходима именно эта специализация, в такие моменты член команды приносит пользу другой работой.
Scrum guide не дает ответа как должны выглядеть элементы бэклога. Это уже вопрос индивидуальный. Но весьма распространена практика собирать backlog из epics и user story. В таком подходе, я не понимаю как будет следовать специализация историй. История описывает потребность. Команда решает как она будет её закрывать. Наличие различных специалистов в команде дает гибкость такой команде в поиске вариантов решения (любую задачу можно решить кучей способов). Задача команды исходя из своих компетенций придумать такое решение, которое принесет максимальную пользу (value). И команда нацелена доставить инкремент и закрыть пользовательскую потребность имеющимися силами.
Я не понимаю, где тут противоречие? Где потребность в выравнивании членов команды? Узкие специализации отдельных членов команды, только усиливают команду целиком. ВАЖНО чтобы люди не запирались в колодце своей специализации, не для каждой истории может быть необходима именно эта специализация, в такие моменты член команды приносит пользу другой работой.
Да, в backlog PO кладёт epics и user story. Но затем проводят Product Backlog refinement:
В результате получается два уровня: обобщённые «пользовательские истории» и технические задачи для их решения:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.
В результате получается два уровня: обобщённые «пользовательские истории» и технические задачи для их решения:
Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones.
В SCRUM guide не написано что задачи должны быть в backlog — см также мое сообщение задачи могут выделяться формально (например статус или задача внутри айтема) или неформально но это не значит, что задачи сами по себе обязаны являться элементом PBI. Напрмер в процессе с выделеными тестерами "Тестирование" может являться просто статусом PBI так что у тестеров нет отдельного беклога.
Речь была не о том, что куда конкретно пишут. А том, что при специализации задачи/элементы backlog получаются персонализированными. PO когда создаёт запись в backlog знает, что делать это будет делать Петя и Вася (потому что backend на Питоне, а его только они знают), но делает вид, что она общая для команды; команда когда детализирует задачу, знает что делать её будет Петя и Вася, но делает вид, что она общая для команды. Это и есть «механический скрам» — создаём видимость командной работы, хотя бОльшая часть как бы заведомо расписана по конкретным специалистам.
Тут надо еще понять, какие навыки у другой команды. Вася и Петя могут получить ошибку из рук Валеры, который сначала ее воспроизведет, а потом проверит фикс.
Если Валера занят, Вася может проверить фикс Пети или написать скрипт, который поможет Маше.
У Пети может быть альтернативный подход — он скажет, что он не тестер а программер, поэтому тестировать за Васей не будет. А если не хватает тестеров, то пусть нанимают, а он лучше почитает про новый фреймфорк.
Если Валера занят, Вася может проверить фикс Пети или написать скрипт, который поможет Маше.
У Пети может быть альтернативный подход — он скажет, что он не тестер а программер, поэтому тестировать за Васей не будет. А если не хватает тестеров, то пусть нанимают, а он лучше почитает про новый фреймфорк.
Речь была не о том, что куда конкретно пишут. А том, что при специализации задачи/элементы backlog получаются персонализированными.
Зависит. Вы используете конкретный термин "элемент беклог", если он не означает отделное действие по фиче, а всю фичу в целом, то он не персонализированный.
Например, если вы в список дел записываете "Заказать новый холодильник", то он не специализирован для ваших органов. А если вы записываете "Глазам — посмотреть налево, пальцам — набрать на клавиатуре "холодильник с большой морозилкой"" то каждый пункт специализирован.
UFO just landed and posted this here
Чем плохо: Это не scum.Опечаточка по Фрейду? Извините.
Скрам с аджайлом это конечно модно стильно молодежно, даже проходили это лет 10 назад и до сих пор пытаемся. Не сильвербуллет, как оказалось, далеко не, но в любом случае не надо ничего абсолютизировать.
bus factor… Если команда зависит от компетенций одного из её членов, это неустойчивая к изменениям команда.… Узкая специализация разработчиков сильно усложняет организационную работуКоманда, любой член которой способен эффективно выполнять любую работу в команде, это команда землекопов, в крайнем случае лесорубов. В программировании на любом проекте сложнее «hello world» все члены просто физически не вытянут компетенции всех прочих, узкие специализации будут. Можно по 2 человека на одну специализацию держать, типа один в резерве. Сам не пробовал, возможно у вас получится, только непонятно как между ними взаимодействие выстроить, они же должны будут одно и то же делать.
Не сильвербуллет, как оказалось, далеко не, но в любом случае не надо ничего абсолютизировать.
Полностью согласен. И в статье пытаюсь донести мысль, что карго-scrum больше вредит, чем приносит пользу. Первое что нужно сделать перед внедрением scrum — это понять для чего вы это делаете? какие задачи решаете? какие цели преследуете? Scrum в чистом виде требует многого от непосредственных участников и как следствие от организации. И это точно не серебряная пуля. Scrum сработает там, где это осознанный и взвешенный выбор.
Команда, любой член которой способен эффективно выполнять любую работу в команде, это команда землекопов, в крайнем случае лесорубов… Можно по 2 человека на одну специализацию держать, типа один в резерве...
Конечно же если уравнивать команду, то получим среднячков, которые решают небольшой набор задач. Приведу простой пример из WEB, допустим есть frontend и backend специалисты в команде. Собрали спринт где требуется больше backend. И есть два поведения команды:
- Frontend делает свою работу, и «ждет» backend.
- Backend делает архитектуру решения и куски реализации отдает frontend разработчикам, а затем уже ревьют результаты.
Во втором варианте команда более гибкая. По моему мнению нужно стремится ко второму варианту.
«Удваивать» компетенции только для резерва точно не стоит. Больше людей => нужно больше коммуникаций => эффективность ниже.
это команда землекопов, в крайнем случае лесорубов
(Голосом эффективного менеджера) Воу, а это разве не так?!
Действительно, идея о T-шейпед-специалистах легко продаётся людям «сверху», эффективным менеджерам, которые не способны увидеть в ней подвоха. Как же удобно, когда у тебя склад гомогенных ресурсов, а не группа капризных «суперзвёзд» с различными компетенциями. Но мартышки стали хомосапиенсами как раз тогда, когда научились в специализацию (и дипломатию для коллективизации «суперзвёзд»).
Менеджеры они такие, вот на днях буквально
(Ты): *Говоришь менеджеру, что на реализацию фичи X понадобится N дней, оптимистично несколько занизив оценку*
(Менеджер): *Искренне удивляется* – зачем так много, ведь нужно всего лишь сделать X?
(Ты): *Думаешь, с чего начать, с необходимости давно назревшего рефакторинга, хотя бы вокруг этой конкретной фичи, с того, что понадобятся юнит-тесты и интеграционные, с того, что надо потихоньку уменьшать количество legacy и под эту дудку можно было бы опять же связанные вещи причесать, с того, что постоянные отвлечения на саппорт* – ок, попробую за 2 дня сделать.
(Ты): *Говоришь менеджеру, что на реализацию фичи X понадобится N дней, оптимистично несколько занизив оценку*
(Менеджер): *Искренне удивляется* – зачем так много, ведь нужно всего лишь сделать X?
(Ты): *Думаешь, с чего начать, с необходимости давно назревшего рефакторинга, хотя бы вокруг этой конкретной фичи, с того, что понадобятся юнит-тесты и интеграционные, с того, что надо потихоньку уменьшать количество legacy и под эту дудку можно было бы опять же связанные вещи причесать, с того, что постоянные отвлечения на саппорт* – ок, попробую за 2 дня сделать.
Так а в чем подвох, и вправду?
К примеру, на продукте с highload есть человек, который гуру в базах данных, и знает все оптимизации нужной для проекта СУБД (и такие навыки действительно необходимы для продукта), но при этом, может попедалить однотипные задачки в JS на уровне джуна-мидла, предварительно получив консультацию у JS девелопера, в спринтах, когда задач на БД нет.
Если бы он принципиально не соглашался на написание JS кода, то было бы 3 варианта:
1) в таких спринтах не делать ничего (читать литературу, экспериментировать с новыми СУБД, которые еще пока в альфа версии), и тем самым деморализовать впахивающую команду.
2) «продать» ненужное усложнение архитектуры, только ради того, чтобы обеспечить себя достойными вызовами (при этом, конечно же, нагрузив и коллег тоже)
3) сказать «встретимся через спринт» своей команде, и пойти искать вызовы в других командах (тем самым, создал код, который некому поддерживать там, и сломав всю идеологию о коммитментах, командной ответственности и прочих эджальных вещах)
Поэтому, увы, выбора то, кроме T-shaped, и нет.
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, и нет.
может попедалить однотипные задачки в JS на уровне джуна-мидла
А может и кофе подавать, и полы помыть, чтобы быть при деле и не деморализовывать команду. «А если мне пилу к заднице привязать, я ещё и пилить смогу» © анекдот.
А может и кофе подавать, и полы помыть, чтобы быть при деле и не деморализовывать команду.
Вопрос не в «при деле», а что корону надо снимать. Если мытье полов помогает приблизится команде к цели спринта, то почему бы и нет.
Это нормально — lenta.ru/news/2018/06/05/premier
Корону снимать надо, тут не поспоришь, и да, лучше подтереть за собой, если нагадил, вне зависимости от своего социального статуса или профессиональных компетенций. И позаниматься работой, связанной не со своими прямыми профессиональными качествами и зоной ответственности тоже бывает полезным, когда ты действительно хочешь «вырасти» в эту новую для себя область или хотя бы владелец бизнеса.
100% scrum из под палки не заработает. Через боль можно только создать видимость agile. Это начинает работать только когда добровольно и осознано.
когда добровольно и осознано
Т.е., когда ты совладелец бизнеса. Именно об этом я и говорю. Все другие «добрые воли» и «осознания» — иллюзия, которая рано или поздно заканчивается, и команда начинает искать нового сектанта взамен перегоревшего старого.
Люди любят делать крутые полезные вещи для других людей. Не вся мотивация сводится к баблецу. То, что что-то заканчивается не значит, что это иллюзия.
Люди любят делать полезные вещи, которыми потом владеют, распоряжаются (да, в том числе, например, чтобы отдать в опенсорс или ещё как сделать этот мир лучше). Владеют юридически или как декларируемый автор, а не безымянная шестерёнка в чужом проекте. Собрать команду бескорыстных и идейных профессионалов, которые продукт-овнеру будут делать бизнес за альтруизм, а не за баблецо (или славу), кажется, чересчур наивной затеей :).
Таким образом мы пришли к одному и тому же: практически всегда действует спектр мотиваций и сведение "добровольно и осознано" к "когда ты совладелец бизнеса" (если принимать это "совладелец" буквально, а не как-то метафорически) — некоторое упрощение реальности.
Если принимать метафорически, то совершенно согласен — хороший профессионал чувствует себя ответственным за конечный результат — в каком-то смысле им владеет.
И это владение обеспечивается юридическим правом управления разрабатываемым продуктом и получением выгод реализации этого продукта на рынке. Всё другое — просто попытки обмануть специалиста, заставляя его работать на себя в ущерб его профессиональному росту и сохранения актуальности на рынке труда (путём «размазывания» его компетенций). Потому что размазанные в одном стартапе компетенции в другом уже вряд ли пригодятся (там будут уже другие компетенции «внахлёст» попадать), либо специалист будет ходить по строго одинаковым (а потому заведомо провальным) стартапам.
Потому что размазанные в одном стартапе компетенции в другом уже вряд ли пригодятся (там будут уже другие компетенции «внахлёст» попадать),
Так же как и специализация. Тут скорее наоборот, больше вероятность переместить вертикальную палку от T в другое место, если есть горизонтальная — т.е. приспособиться для других условий если есть общее представление о смежных областях.
Я не разбираюсь в этих технологиях, так что не могу прокомментировать детально. Я думаю, что некоторые знания переносимы — т.е. если человек в принципе знает реляционные базы и веб разработку, то он может быстрее приспособиться к конкретной реляционной базе и конкретному фреймворку. Т.е. нельзя знать только MySQL, если узнаешь MySQL ты узнаешь так же про реляционные базы вообще, индексы, SQL латентность и прочее.
Если он на досуге поучит NoSQL он сможет применить знания и в том и в этом стартапе и владеть большим количеством технических решений — т.е. большее чувство собственности.
Всё верно, знагия переносимы, и для специалиста, например, по СУБД горизонтальная палочка в букве T — это его компетенции, выходящие за потребности данного конкретного стартапа, знания MS-SQL, например, когда в стартапе используется Oracle. А не знание Фотошопа, чтобы подменить дизайнера. А скрам именно о такой (утрирую) переносимости знаний, когда каждый специалист является компетентным во всём стеке технологий разрабатываемого продукта.
Когда специалист по MS-SQL ковыряется в Oracle — это нормально и полезно ему самому. А когда он начинает играть шрифтами на макете, это бесплдезно и для него, и для бизнеса.
А если он ковыряется в ASP.NET? Я вот думаю что может быть несколько направлений смежности можно растить горизонтальную палку в направлении разных СУБД (но тогда получается что эта палка будет не использоваться точно в каждом конкретном месте работы кроме некоторых исключений). Можно расти в смежные вещи по стеку. Например в MS-SQL используются другие технологии MS — .NET и Powershell, зная C# можно выучить ASP.NET и уже просто чтобы добавить галочку в форму не надо будет звать фронтэндщика. Знание C# и PS пригодиться и для администрирования IIS. Зная C# можно на другом месте работы выучить Java и т.д.
Если он начнет играть шрифтами и это ему нравится то почему бы нет? Будет способ отдыха. Возможно, ему легче будет понять, как на мир смотрят дизайнеры и это будет источником метафор.
Да, фантазировать можно бесконечно.
Да, фантазировать можно бесконечно.
Ну я, честно говоря, больше видел специалистов которые изучали смежные по стеку технологии чем по уровню (трудно на досуге очень хорошо изучить Oracle — так как вся практика на MS SQL — принципы можно, но конкретные глюки/приемы/навыки не очень удобно, так как нужно иметь какой-то рабочий пример) я скорее видел специалистов, которые могли знать соседние элементы стека. Или даже поверхностно весь стек и глубоко предметную область.
А какой у вас опыт?
У меня опыт, показывающий, что участие в стартапе с изучением смежных технологий из любознательности — не очень совместимые процессы. Да, такие разносторонне развитые (уже развитые) люди бывают, да, они могут собраться вместе, да, их стартап может «выстрелить» и «взорвать» рынок. И да, им в этом вполне может помочь скрам. Но это не наёмники, которым спустили сверху директиву «надо поковыряться вот в этой, не связанной с вашей компетенцией, области, чтобы дух команды, чтобы скрам, чтобы во имя процветания человечества».
Я не очень понял — вы в стартапе или наемником? Т.е. например команда отвечает за продукт/подсистему X. Надо в продукт добавить галочку в настройки (UI, логику обработки и поле в СУБД) — как это происходило?
Я работал и в стартапах, и наёмником. И в роли менеджера в том числе.
Не думаю, что ваш вопрос будет интересно обсуждать в теме про скрам. Думаю, я уже исчерпывающе объяснил свою точку зрения. Спасибо за участие в беседе.
Не думаю, что ваш вопрос будет интересно обсуждать в теме про скрам. Думаю, я уже исчерпывающе объяснил свою точку зрения. Спасибо за участие в беседе.
Почему? Мне просто чисто практически непонятно — в ситуации когда есть потребность при добавлении галки подправить условно html, js, sql и java, вроде все подталкивает к тому чтобы чисто практически выучить немножко того и немножко сего, чтобы сделать эту галку полностью самостоятельно, а не просить Васю. А чтобы в дополнении в MS SQL учить Оракл, придется откуда-то выдумывать задачу и держать этот Оракл в голове работая с MS SQL (см кривая забывания).
Т.е. с моей точки зрения в практической работы горизонтальная линейка у T весьма органично растет на соседние слои стека, и для менеджера это более ценно (для простых операций не надо накладных расходов для взаимодействия между членами команды, а для сложных — больше взаимопонимания).
Именно поэтому мне интересен опыт такого разностороннего профессионала как вы, как получается, что выгоднее по другому. Именно на этом простом примере.
Я буду благодарен если вы мне объясните здесь или персональными сообщениями. Спасибо за дискуссию в любом случае.
Ваш нафантазированный пример возможен в проектах уровня хелло-ворлд, для реализации которых, вообще говоря, не нужен не только скрам, но и вообще команда. Не думаю, что смогу вам объяснить наивность ваших фантазий, постепенно сами столкнётесь с масштабированием процесса разработки на своём реальном опыте.
Не думаю, что смогу вам объяснить наивность ваших фантазий, постепенно сами столкнётесь с масштабированием процесса разработки на своём реальном опыте.
Как жаль что такой опытный, разносторонний и вежливый профессионал как вы не снизошел до объяснения на конкретном примере своей концепции развития компетенций.
Буду надеяться, что мне встретится кто-то другой, кто снизойдет до новичков моего уровня. Или может быть, вы сможете выделить время на то, чтобы написать мемуары о вашем участии в больших проектах? Я понимаю, у вас мало времени, но человечество в моем лице было бы очень благодарно вам. Тем более что это, наверное, менее затратно, чем объяснять чуть дела каждому остолопу, вроде меня. Спасибо большое, что отвечали на мои вопросы, хотя я и понимаю, что ваше терпение не безгранично. Извините, пожалуйста, еще раз за назойливость и еще раз спасибо.
Вы немного о разных вещах рассуждаете
В одном случае — о том, что иногда (или даже часто) получается и выгодно работодателю, и о том, что выгодно самому специалисту
Поясню очень просто: я, например, в силу, в частности, потребностей работодателя, очень много на чем пишу на уровне джуна/мидла, но я не буду писать это все в резюме (потому что раздутые резюме работают хуже, возможно я попытаюсь это использовать как козырь на собеседовании), если завтра решу сменить работу, я напишу одну компетенцию, в которой я не развиваюсь или даже деградирую, пока пилю очередную однотипную задачу в другой области и, типа, развиваюсь
Реально подобное может быть (а может и не быть) выгодно молодым специалистам, которые в основной специализации чуть выше джуна, всем остальным оно зло
В одном случае — о том, что иногда (или даже часто) получается и выгодно работодателю, и о том, что выгодно самому специалисту
Поясню очень просто: я, например, в силу, в частности, потребностей работодателя, очень много на чем пишу на уровне джуна/мидла, но я не буду писать это все в резюме (потому что раздутые резюме работают хуже, возможно я попытаюсь это использовать как козырь на собеседовании), если завтра решу сменить работу, я напишу одну компетенцию, в которой я не развиваюсь или даже деградирую, пока пилю очередную однотипную задачу в другой области и, типа, развиваюсь
Реально подобное может быть (а может и не быть) выгодно молодым специалистам, которые в основной специализации чуть выше джуна, всем остальным оно зло
Странно, что тут противоречие. Если человек ценен для работадателя, то это повышает его ценность на рынке труда. (если работодатель не очень особенный).
Противоречие потому, что есть конкретный работодатель и его конкретная текущая задача, а есть рынок с абстрактным работодателем, на которого работает абстрактный рекрутер
Работодателю нужно чтобы вы просто выполняли за свою зарплату максимальный объем работ по проекту и делали это, по возможности, эффективно
Рекрутеру говорят «нам нужен ангулярщик» и он его ищет по ключевым словам
Рекрутеру редко говорят «нам нужен ангулярщик, чтобы он еще чуть-чуть в MySQL мог и питонисту иногда помогал, а еще уборщицу уволили за воровство, надо подменять и бухгалтер приходящий нужен раз в месяц», а найти хорошего специалиста (да и работу) под все компетенции проекта обычно невозможно, только под одну-две, остальные ожидается, что человек на необходимом уровне освоит на месте
Так что не работодатель особенный, а каждый проект более или менее особенный: посмотрите на стек технологий практически в любой области, сделайте поправку на наполнение конкретной команды (где-то, скажем, много бэкендщиков, а где-то фронтендщиков), еще одну поправку просто на стечение обстоятельств на проекте (Вася заболел, Петя уволился, нет времени объяснять, теперь ты еще и специалист по БД, сдаем продукт завтра), вот и выйдет, что объем странных мелких рутинных задач, который на вас свалится будет везде разным и часто предельно странным для вашей целевой компетенции
В итоге специалисту почти всегда выгодно быть максимально компетентным в одной, максимум двух технологиях, а работодателю выгоден относительный фуллстак, если это эффективно и не мешает основной работе, а еще при умении так можно «заточить» специалиста под проект, так что на месте он будет макимально эффективен, а вот «убежать» за большей зарплатой ему будет сложнее
Работодателю нужно чтобы вы просто выполняли за свою зарплату максимальный объем работ по проекту и делали это, по возможности, эффективно
Рекрутеру говорят «нам нужен ангулярщик» и он его ищет по ключевым словам
Рекрутеру редко говорят «нам нужен ангулярщик, чтобы он еще чуть-чуть в MySQL мог и питонисту иногда помогал, а еще уборщицу уволили за воровство, надо подменять и бухгалтер приходящий нужен раз в месяц», а найти хорошего специалиста (да и работу) под все компетенции проекта обычно невозможно, только под одну-две, остальные ожидается, что человек на необходимом уровне освоит на месте
Так что не работодатель особенный, а каждый проект более или менее особенный: посмотрите на стек технологий практически в любой области, сделайте поправку на наполнение конкретной команды (где-то, скажем, много бэкендщиков, а где-то фронтендщиков), еще одну поправку просто на стечение обстоятельств на проекте (Вася заболел, Петя уволился, нет времени объяснять, теперь ты еще и специалист по БД, сдаем продукт завтра), вот и выйдет, что объем странных мелких рутинных задач, который на вас свалится будет везде разным и часто предельно странным для вашей целевой компетенции
В итоге специалисту почти всегда выгодно быть максимально компетентным в одной, максимум двух технологиях, а работодателю выгоден относительный фуллстак, если это эффективно и не мешает основной работе, а еще при умении так можно «заточить» специалиста под проект, так что на месте он будет макимально эффективен, а вот «убежать» за большей зарплатой ему будет сложнее
Рекрутеру говорят «нам нужен ангулярщик» и он его ищет по ключевым словам
Рекрутеру редко говорят «нам нужен ангулярщик, чтобы он еще чуть-чуть в MySQL мог и питонисту иногда помогал, а еще уборщицу
https://hh.ru/search/vacancy?text=MySQL
Я вижу что там как правило требования на соседние по стеку навыки. Откуда ваши сведения?
когда ты действительно хочешь «вырасти» в эту новую для себя область или хотя бы владелец бизнеса
Есть такая точка зрения, и есть профессионализм рекрутеров, чтобы таких людей на этапе собеседования отсеивать. Увы, гибкие методологии требуют некоторой степени мотивации от членов команды. К слову, некоторые более сложные фреймворки типа скрамбана еще и «взрослости».
Просто человек не в той команде. «Продуктом» вполне может быть модуль, сервис, микросервис, БД. В скрамгайде явно указано, что может быть много взаимодействующих команд. А не как в этой статье предлагается тянуть всё единственной командой.
«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.»
«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.»
А не как в этой статье предлагается тянуть всё единственной командой.
Как же вы легко суть то улавливаете? Интересно на чем основан этот вывод?
Нет смысла думать о масштабировании, до того момента пока в одной команде не смогли scrum наладить. Я в статье предлагаю запустить пилот, и уже по его результатам пробовать расширять scrum.
На вашей рекомендации бесконечно расширять компетенции:
Со временем команда должна стремиться расширять свою функциональность, чтобы полностью покрывать цепочку создания ценности.
Зачем бесконечно покрывать? Цепочка создания ценности ограничена, команда не может в рамках неё бесконечно расширять компетенции.
Суть моего высказывания в том, что не стоит выделять команды по компетенциям, т.е. команда фронтендеров, команда бэкендеров и команда QA — это не scrum команды. Scrum команда должна состоять из различных специалистов.
Суть моего высказывания в том, что не стоит выделять команды по компетенциям, т.е. команда фронтендеров, команда бэкендеров и команда QA — это не scrum команды. Scrum команда должна состоять из различных специалистов.
Scrum команда должна состоять из различных специалистов.должна?! — с чего вы это взяли? Я бы понял, если бы речь шла о «может», но с чего «должна»?
Как по-вашему должна быть организована работа в контексте:
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.Как несколько универсальных команд должны делить между собой общий backlog?
должна?! — с чего вы это взяли?
Согласен неправильно высказался. Конечно «может».
Как несколько универсальных команд должны делить между собой общий backlog?
Ну вариантов уйма. У нас в Wrike 20+ «универсальных» команд. Продукт на всех один — это wrike. Верхне-уровнево продуктовый бэклог один и стратегия общая. Но дальше он бьется по направлениям, и каждая команда отвечает за определенный кусок функционала.
Ваш тезис в чем? Если команды будут не универсальными, то что изменится?
Но с другой стороны не только менеджеру полезен t-shaped
В современном мире технологии стремительно рождаются и умирают, прокапывая в глубь конкретную технологию можно оказаться на дне, когда технология уже никому не нужна. Если же в угоду менеджерам человек будет смотреть вширь, то ему самому легче будет оставаться актуальным и востребованным на рынке.
В современном мире технологии стремительно рождаются и умирают, прокапывая в глубь конкретную технологию можно оказаться на дне, когда технология уже никому не нужна. Если же в угоду менеджерам человек будет смотреть вширь, то ему самому легче будет оставаться актуальным и востребованным на рынке.
Скажем, если человек занимается СУБД, в стартапе пилит MySQL, то на досуге он будет расширять свои компетенции в MS-SQL, Postgre, Mongo, что, скорее всего, совершенно не нужно данному конкретному стартапу. А если пилит на Angular, то в свободное время изучает React, Vue или Polymer. Взгляды на T-шейп для менеджера в конкретном стартапе и программиста сильно различаются.
Это так. Но ценный член scrum команды — это тот, кто умеет кооперировать личные и командные интересы.
Еще мне в свете разговоров о scrum непонятно, что за лютый менеджер, который кошмарит бедных разработчиков?
Еще мне в свете разговоров о scrum непонятно, что за лютый менеджер, который кошмарит бедных разработчиков?
Но ценный член scrum команды — это тот, кто умеет кооперировать личные и командные интересы.
Всё верно. Я всего лишь акцентирую внимание на том, каким образом этот самый командный интерес возникает, как возникает долгосрочное желание заниматься «не своей» работой. Чтобы она стала «своей», чтобы команда имела ценность, все её участники должны быть владельцами бизнеса. Вот и весь секрет. А сектанством тут не получится подпереть отсутствие мотивации, примерами подтирающего кофе премьерами (если я подотру за собой кофе, я премьером не стану).
Команда, любой член которой способен эффективно выполнять любую работу в команде
Между "эту работу может выполнить ровно один человек в команде" и "эту работу одинаково хорошо могут выполнить все люди в команде" есть степени: "эту работу могут выполнить двое" или "эту работу могут выполнить несколько людей но с разной эффективностью"
то вся свобода творчества у команды обычно с продукта перекидывается на технологии.
Правильная команда в любом случаи будет пытаться внедрить в проект новые технологии, которые естественно будут замедлять процесс. Программисты так устроенны, если они не будут что-то новое учить, то их развитие остановится, они начнут чахнуть и убегут с Вашего проекта. И хотя с точки зрения менеджера может показаться что запрет на новые технологии это выгодно, он должен понимать, что действительно стоящие профессионалы не будут работать в таких условиях. А переложить на них другой вид ответственности… В этой идеи что-то конечно есть, но только с точки зрения гуманитария, который больше склонен метаться из одной сферы в другую. Но прежде всего, когда речь идет о команде, до принятия каких-либо решений, нужно советоваться с самой командой.
И тут уже сказали, что цель показать статьи показать какой scrum «не очень», но мне кажется причина в другом. Прежде всего в жестких ограничениях, которые Вы так пытаетесь выделить. Для примера тот же лидер в команде. Вы говорите что лидера быть не должно… Но где Вы найдете команду из ТАКИХ профессионалов, которые в лидере не нуждаются? Таких команды если и есть, то ну в очень и очень и очень крутых компаниях. Поэтому получается что либо scrum только для крутых компаний, либо идеологи не сочли нужным писать на банке coca-cola, что ей «нельзя бить прохожих по голове»-«можно видоизменять для большей эффективности», только потому, что решили что это и так всем понятно.
+1, вера в полностью «горизонтальную» команду — это как вера в социализм, где все люди равны во всех проявлениях.
Отцы-основатели scrum того же мнения, scrum — это практический фреймворк, а не сферический конь. Никто и не требует этого, когда все равны, то
Scrum — это про объединение людей с разными специализациями в одну команду, готовых помогать друг другу людей.
- если это среднячки, то крутые штуки они делать не смогут.
- если это мегафулстэки, то не сделать из них команду. Будет лебедь, рак и щука.
Scrum — это про объединение людей с разными специализациями в одну команду, готовых помогать друг другу людей.
Это не скрам, а обычная софистика, которой, конечно, не возразишь. Да, нужно друг другу помогать, да, нужно друг друга слышать, да, нужно не болеть и быть счастливыми, а код писать без багов — но всё это и без всякого скрама нужно делать, и скрам совсем не о том, его цели — это укорачивание обратной связи между бизнесом и рынком путём ограничения размера команды и размазывания зон ответственности за счёт некритичного и управляемого снижения качества и поддерживаемости создаваемого продукта для занятия ниши в условиях высокой конкуренции и пост-постиндустриальной (т.н. инновационной) экономики. А весь этот сектантский/религиозный/идеологический флёр — это непонимание схемы мотивации в таком процессе.
Программисты так устроенны, если они не будут что-то новое учить, то их развитие остановится, они начнут чахнуть и убегут с Вашего проекта…
Но прежде всего, когда речь идет о команде, до принятия каких-либо решений, нужно советоваться с самой командой.
Естественно, что если не заниматься рефакторингом, не использовать современные технологии, не работать со свежими версиями библиотек и т.д., то ваш продукт погрязнет в тех.долге и умрет.
Когда команда отвечает за то «как» будет сделана задача, то она вольна выбирать инструментарий, а PO должен довериться ей в этом. Когда команде говорят «ЧТО» делать, т.е. сразу дают тех.задание, то команда начинает битву за технологию.
Кейс именно об этом, что разработчики более сведущие в технологии, дайте им право решать как делать задачу. Это win-win схема PO занимается продуктом и не лезет в детали разработки, а команда решает задачи, о которых им рассказал PO. Они верят, что если PO сказал, что у пользователя болит тут, то это не пустые слова. А как снять боль — это команда решает сама и делает это лучшими средствами.
Для примера тот же лидер в команде. Вы говорите что лидера быть не должно… Но где Вы найдете команду из ТАКИХ профессионалов, которые в лидере не нуждаются?
Не совсем так, я говорю что «назначенный» лидер и scrum плохо подходят друг к другу. Лидерство должно быть ситуационным и органическим. Команда сама понимает, что Вася мегакрут в СУБД, а к Пете можно обратиться по вопросом браузерной оптимизации JS. Просто это естественный процесс, не нужно влезать в него бюрократической машиной.
Таких команды если и есть, то ну в очень и очень и очень крутых компаниях. Поэтому получается что либо scrum только для крутых компаний,
Дело не в крутизне компаний, а в том для чего вам scrum и как понимание этого донесено до людей. Как уже не раз писалось, scrum — это не серебряная пуля. И к сожалению, работать в scrum могут не все люди (жесткий индивидуалист с болью встраивается в scrum процесс). Но если scrum вам подходит, то при правильной настройке, вы получите то, чего хотите. А моя статья — это некие маячки необходимости подстройки.
Иногда здравый смысл помогает. Я не пойму, зачем его бежать?
Напомнило
— Мы думали туман, — ответила Ирма.
— Что?
— Думали туман, — повторила Ирма.
— Про туман, — поправил Виктор. — Или о тумане.
— Зачем это — про туман? — сказала Ирма.
— Думать — непереходный глагол, — объяснил Виктор. — Он требует
предлогов. Вы проходили непереходные глаголы?
— Это когда как, — сказала Ирма. — Думать туман — это одно, а думать
про туман — это совсем другое… и кому это нужно — думать про туман,
неизвестно.
Виктор вытащил сигарету и закурил.
— Погоди, — сказал он. — Думать туман — так не говорят, это
неграмотно. Есть такие глаголы — непереходные: думать, бегать, ходить. Они
всегда требуют предлога. Ходить по улице. Думать про… что-нибудь там…
— Что?
— Думали туман, — повторила Ирма.
— Про туман, — поправил Виктор. — Или о тумане.
— Зачем это — про туман? — сказала Ирма.
— Думать — непереходный глагол, — объяснил Виктор. — Он требует
предлогов. Вы проходили непереходные глаголы?
— Это когда как, — сказала Ирма. — Думать туман — это одно, а думать
про туман — это совсем другое… и кому это нужно — думать про туман,
неизвестно.
Виктор вытащил сигарету и закурил.
— Погоди, — сказал он. — Думать туман — так не говорят, это
неграмотно. Есть такие глаголы — непереходные: думать, бегать, ходить. Они
всегда требуют предлога. Ходить по улице. Думать про… что-нибудь там…
А где самое главное? Как из группы людей сделать команду?
У меня был опыт когда практически все проблемы, описанные в статье, были решены. Но все равно командой разработчиков в том проекте нельзя было называть. Не было групповой ответственности, все продолжали жить в парадигме «я сделал свою задачу, я молодец». А то, что цель не достигнута или инкремент не работает, это не их вина…
Что в таком случае делать? Разгонять всех и искать новых или надежда есть?
У меня был опыт когда практически все проблемы, описанные в статье, были решены. Но все равно командой разработчиков в том проекте нельзя было называть. Не было групповой ответственности, все продолжали жить в парадигме «я сделал свою задачу, я молодец». А то, что цель не достигнута или инкремент не работает, это не их вина…
Что в таком случае делать? Разгонять всех и искать новых или надежда есть?
Отличный вопрос. Спасибо.
Разгонять крайний случай. Большинству людей комфортно в scrum, просто нужна подстройка. Нужно больше деталей конечно, но сходу следующие мысли есть.
Ответственность это такая штука, которую мало передать, её еще должны взять (прошу простить за капитанство). Отсюда вопрос как у вас проходят планирования?
Кто занимается технической декомпозицией задач? кто определяет цель спринта? кто определяет объём элементов бэклога входящих в инкремент.
ИМХО хорошее планирование должно проходить по следующему сценарию:
Если же цели не достигаются и инкременты не выпускаются, то на ретроспективе, нужно разбирать с командой: что пошло не так и почему так вышло? Тут опять же роль SM слушать и слышать. Если все сводится к «наши вашим чем то машут», то SM (в зависимости от команды) можно:
В целом SM — это человек, который должен лучше всех чувствовать и понимать команду. Жесткие меры и создание стресса лучше не применять как главный инструмент работы с командой. Но и совсем пренебрегать им я думаю не получится. Иногда нужен холодный душ, чтобы привести людей в чувства.
qwez если это все опять в молоко, то можно перенести общение в личку. Либо тут раскройте побольше деталей про ваш процесс
Разгонять крайний случай. Большинству людей комфортно в scrum, просто нужна подстройка. Нужно больше деталей конечно, но сходу следующие мысли есть.
Не было групповой ответственности, все продолжали жить в парадигме «я сделал свою задачу, я молодец».
Ответственность это такая штука, которую мало передать, её еще должны взять (прошу простить за капитанство). Отсюда вопрос как у вас проходят планирования?
Кто занимается технической декомпозицией задач? кто определяет цель спринта? кто определяет объём элементов бэклога входящих в инкремент.
ИМХО хорошее планирование должно проходить по следующему сценарию:
- PO ставит цель на спринт (обсуждается с командой)
- PO предлагает объем элементов backlog, которые необходимо сделать чтобы достигнуть цели.
- Команда разбирает (общение с PO) эти элементы, декомпозирует их на задачи (тут важно, чтобы SM фасилитировал и давал высказаться каждому члену команды, чтобы решения были согласованные, а не продиктованные кем-нибудь. Один из возможных инструментов scrum poker)
- Команда составляет план спринта (сново важно, чтобы высказывались все — за этим следит SM)
- Команда САМА выбирает тот объем работы на спринт, с которым она согласна, и который она обязуется сделать.
Если же цели не достигаются и инкременты не выпускаются, то на ретроспективе, нужно разбирать с командой: что пошло не так и почему так вышло? Тут опять же роль SM слушать и слышать. Если все сводится к «наши вашим чем то машут», то SM (в зависимости от команды) можно:
- Вместе с командой попытаться СОВМЕСТНО найти решение, как сделать так чтобы ситуация не повторилась. «Вы согласны что ситуация нехорошая? А давайте найдем способ, как избежать подобной ситуации в будущем.»
- Напрямую вскрыть причины отсутствия взаимопомощи. «Почему ты не помог, если видел, что команде нужна помощь? Какие у тебя были мотивации? Какие у тебя приоритеты и чем ты руководствуешься во время принятие решений?»
- придумать что-то свое
В целом SM — это человек, который должен лучше всех чувствовать и понимать команду. Жесткие меры и создание стресса лучше не применять как главный инструмент работы с командой. Но и совсем пренебрегать им я думаю не получится. Иногда нужен холодный душ, чтобы привести людей в чувства.
qwez если это все опять в молоко, то можно перенести общение в личку. Либо тут раскройте побольше деталей про ваш процесс
На самом деле было бы интересно послушать реальный пример решения подобной проблемы. Т.е. была такая ситуация, полгода делали такие-то упражнения, итог такой-то.
Про мою ситуацию — да все, вроде, было по гайду, но «механически», как вы выразились. И вот это все «Вы согласны что ситуация нехорошая? А давайте найдем способ, как избежать подобной ситуации в будущем.» было, все соглашались и придумывали решения. Но потом ничего не делали и все возвращалось на круги своя. И я не знал как сделать так, чтобы они захотели сплотиться и сделать все красиво.
Единственным решением, мне виделось, это устраивать бесконечные ретро и индивидуальные разговоры. Помогать выбирать нужные для цели задачи. Водить за ручку на нужные встречи. И так далее. Может быть через какое-то время мы бы и взлетели. А может реально людям неинтересно это было и ничего бы не помогло… У всех так в начале или это запущенный случай? :)
Про мою ситуацию — да все, вроде, было по гайду, но «механически», как вы выразились. И вот это все «Вы согласны что ситуация нехорошая? А давайте найдем способ, как избежать подобной ситуации в будущем.» было, все соглашались и придумывали решения. Но потом ничего не делали и все возвращалось на круги своя. И я не знал как сделать так, чтобы они захотели сплотиться и сделать все красиво.
Единственным решением, мне виделось, это устраивать бесконечные ретро и индивидуальные разговоры. Помогать выбирать нужные для цели задачи. Водить за ручку на нужные встречи. И так далее. Может быть через какое-то время мы бы и взлетели. А может реально людям неинтересно это было и ничего бы не помогло… У всех так в начале или это запущенный случай? :)
У меня нет опыта, когда все сделали правильно, а команда не вовлеченная. Обычно что-то сделано не так и отсюда проблемы. Поэтому тяжело такой кейс привести. Но исходя из этого:
Проблема то не в вовлеченности участников, а в том что фокуса командного нет.
Я был в ситуации, когда команде нужно за спринт делать разношерстные задачи. Цель спринта выбиралась синтетически (т.е. сперва собирали спринт, а уже потом выписывали цель) — например, самая толстая история — это цель, а остальное подавалось под соусом «это не цель, но тоже очень важно сделать». Но проблема то не в команде, а в такой системе. Решается это все-таки работой с PO и backlog. При желании всегда можно переприоретизировать бэклог так, чтобы истории можно было объединить общей целью. И когда мы пришли к ситуации сфокусированных спринтов (сперва цель, потом истории), когда люди делают задачи под общей целью, то проблема «не переживают, что не достигаем цели спринта» ушла.
Еще момент, нельзя позволять команде садиться на шею SM. Быть только нянькой плохо. Надо жесткости давать.
А задачи для цели делают 2-3 человека (из 8) и в итоге не успевают. По идее, если не успевают, то вся команда должна навалиться и сделать, но сами они это делать не будут.
Проблема то не в вовлеченности участников, а в том что фокуса командного нет.
Я был в ситуации, когда команде нужно за спринт делать разношерстные задачи. Цель спринта выбиралась синтетически (т.е. сперва собирали спринт, а уже потом выписывали цель) — например, самая толстая история — это цель, а остальное подавалось под соусом «это не цель, но тоже очень важно сделать». Но проблема то не в команде, а в такой системе. Решается это все-таки работой с PO и backlog. При желании всегда можно переприоретизировать бэклог так, чтобы истории можно было объединить общей целью. И когда мы пришли к ситуации сфокусированных спринтов (сперва цель, потом истории), когда люди делают задачи под общей целью, то проблема «не переживают, что не достигаем цели спринта» ушла.
Еще момент, нельзя позволять команде садиться на шею SM. Быть только нянькой плохо. Надо жесткости давать.
Мне кажется тут или планироваться надо лучше, чтобы цели спринта достигались набором задач спринта. Или на каждом дейли задавать правильный вопрос «Что ты сделал для достижения цели спринта? Что планируешь делать для достижения цели спринта?». Часто ведь люди берут задачи которые им хочется делать(легче, интереснее и тд) не думая о целостности.
— «Что планируешь делать для достижения цели спринта?»
— «Ну, я для цели ничего не могу сделать, поэтому будут пилить эту штуку.»
А задачи для цели делают 2-3 человека (из 8) и в итоге не успевают. По идее, если не успевают, то вся команда должна навалиться и сделать, но сами они это делать не будут.
— «Ну, я для цели ничего не могу сделать, поэтому будут пилить эту штуку.»
А задачи для цели делают 2-3 человека (из 8) и в итоге не успевают. По идее, если не успевают, то вся команда должна навалиться и сделать, но сами они это делать не будут.
Ну у нас такое решалось парным программированием, делаешь задачу вместе со специалистом.
Ещё задавали вопросы «Что тебе мешает сделать? Каких навыков не хватает?». Задавайте вопрос Почему? Зачем? Пока не доберётесь до истинных причин.
Это ежедневная работа с сотрудниками, пока они не привыкнут, когда будет полное доверие и желание развиваться.
И есть такая штука как оценка сотрудника службой персонала, по показателям которые можно измерить, для повышения материальной составляющей например. И там просто подводят итог, пол года назад ты такие задачи не делал, а теперь делаешь, давай дальше молодец!
Ещё задавали вопросы «Что тебе мешает сделать? Каких навыков не хватает?». Задавайте вопрос Почему? Зачем? Пока не доберётесь до истинных причин.
Это ежедневная работа с сотрудниками, пока они не привыкнут, когда будет полное доверие и желание развиваться.
И есть такая штука как оценка сотрудника службой персонала, по показателям которые можно измерить, для повышения материальной составляющей например. И там просто подводят итог, пол года назад ты такие задачи не делал, а теперь делаешь, давай дальше молодец!
Всё наоборот:
«Цель скрипта» — это «агрегатная функция» для распланированных задач.
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog
«Цель скрипта» — это «агрегатная функция» для распланированных задач.
Всё наоборот:
Наоборот с чем? Что вы опять оспариваете?
«Цель скрипта» — это «агрегатная функция» для распланированных задач.
А кто говорил обратное? Это и есть фокусировка, когда цель соответствует набору элементов бэклога, составляющих спринт.
Странно, когда цель и спринтовый бэклог не соответствуют друг другу.
Наоборот с тем, что написал Tanyapdr. Если задача запланирована на Sprint, значит она ведёт к Sprint Goal. «Правильные вопросы»: «Что ты сделал для достижения цели спринта? Что планируешь делать для достижения цели спринта?» — не имеют смысла.
«Что ты сделал для достижения цели спринта? Что планируешь делать для достижения цели спринта?» — не имеют смысла.
Ну это вопросы согласно scrum guide:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the
Sprint Goal?
Т.е. цель Daily Scrum — это не отчет о проделанной работе. А фокусировка команды на цели спринта. Инспекция в эмпирическом процессе.
Какие с вашей точки зрения правильные вопросы DSM?
Скажем так: команда из backlog'а запланировала несколько задач по GUI и сформулировала цель: «Упростить взаимодействие пользователя с системой». А может даже на более близком бизнесу языке: «снизить нагрузку на саппорт» или «уменьшить отток пользователей на этапе регистрации».
Эта краткая формулировка — «цель спринта» не должна подменять собой конкретные запланированные задачи/пользовательские истории. «Goal» и «цель» не совсем одно и то же. Не говоря о других «упрощениях» перевода с частичной потерей смысла.
«Как я вчера помогал команде завершить спринт?»
«Чем я могу помочь сегодня?
Примерно так это может звучать по-русски.
Эта краткая формулировка — «цель спринта» не должна подменять собой конкретные запланированные задачи/пользовательские истории. «Goal» и «цель» не совсем одно и то же. Не говоря о других «упрощениях» перевода с частичной потерей смысла.
«Как я вчера помогал команде завершить спринт?»
«Чем я могу помочь сегодня?
Примерно так это может звучать по-русски.
Если весь сыр бор вокруг сложностей перевода, то мне страшно вставать на этот скользкий путь (я собственно поэтому цитирую первоисточник). Понятно что сперва происходит некая деформация сути, когда мы мысль облачаем в слова, но когда еще начинают это переводить, то есть риск сильно исказить изначальный замысел.
Слова очень важны при формулировках, но так же важны люди для которых эти слова произносятся. Ведь формулировка вопроса на DSM очень тесно связано с тем, как команда получала знания о scrum. В целом это уже мастерство SM так ставить вопросы, чтобы помогать команде синхронизировать усилия и сфокусироваться. (серебряных пуль нет нигде, в том числе и в формулировках)
Еще насчет формулировок, я так понимаю, что scrum guide переводит группа энтузиастов. Вы могли помочь им с этим.
Слова очень важны при формулировках, но так же важны люди для которых эти слова произносятся. Ведь формулировка вопроса на DSM очень тесно связано с тем, как команда получала знания о scrum. В целом это уже мастерство SM так ставить вопросы, чтобы помогать команде синхронизировать усилия и сфокусироваться. (серебряных пуль нет нигде, в том числе и в формулировках)
Еще насчет формулировок, я так понимаю, что scrum guide переводит группа энтузиастов. Вы могли помочь им с этим.
Эта краткая формулировка — «цель спринта» не должна подменять собой конкретные запланированные задачи/пользовательские истории
А мне кажется должна. Команда должна вместе достигнуть цель спринта и думать о задачах именно в этом контексте. Т.е. специалист по пуговицам должен думать о пиждаке в целом и делать такие пуговицы, которые хорошо будут смотреться на пиджаке а не лучшие пуговицы взятые отдельно.
Команда также может согласовать какие-то изменения прямо в контексте спринта. То есть думать не только о своей задачи а о том имеет ли она смысл для команды.
During the Sprint:
- No changes are made that would endanger the Sprint Goal; Quality goals do not decrease; and,
- Scope may be clarified and re-negotiated between the Product Owner and
- Development Team as more is learned.
Это получается испорченный телефон: пользователи жалуются на баги в обработке формы. Мы ставим цель «улучшить интерфейс», а в результате перекрашиваем в более контрастный и увеличиваем кнопки, чтобы на мобильнике было удобнее пользоваться.
Аналогия с пиджаком очень далёкая и непонятная — где там цель и инкремент спринта? (и где вы слышали, чтобы пуговицы производились прямо в ателье одежды?)
Аналогия с пиджаком очень далёкая и непонятная — где там цель и инкремент спринта? (и где вы слышали, чтобы пуговицы производились прямо в ателье одежды?)
Это получается испорченный телефон: пользователи жалуются на баги в обработке формы. Мы ставим цель «улучшить интерфейс», а в результате перекрашиваем в более контрастный и увеличиваем кнопки, чтобы на мобильнике было удобнее пользоваться.
Это значит что либо цель спринта неправильная либо задача.
Еще возможно, если исполнители ссами не могут понять эту рассогласованность, то скрам — не для них.
Аналогия с пиджаком очень далёкая и непонятная — где там цель и инкремент спринта? (и где вы слышали, чтобы пуговицы производились прямо в ателье одежды?)
Разумеется все аналогии врут.
Если задача запланирована на Sprint, значит она ведёт к Sprint Goal. «Правильные вопросы»: «Что ты сделал для достижения цели спринта? Что планируешь делать для достижения цели спринта?» — не имеют смысла.
Почему?
Sign up to leave a comment.
Лечение «механического» Scrum. Часть 2. Команда