Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода

[romas1982]

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

[some_x]

Я проблем не заметил. Люди говорят тимлид и прóдукт в реальной жизни.А вы предлагаете писать «лидер команды» и «товар», чтоб формально было грамотно, но никто ничего не понял?

из-за таких намерений появляются книги «Исскуство автономного тестирования» (вместо искусство unit тестирования).

[time2rfc]

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

[eross]

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

[eross]

«возможность к масштабированию», прошу прощения за опечатку.

[time2rfc]

Scrum методология которая имеет возможность в масштабирование.
Вы рассказали об одном из подходов к организации межкомандного взаимодействия.
После прочтения статьи мне не до конца ястно как первое предложение связанно со вторым. Вы описали очень интересный опыт трансформации, но в упор не могу понять отчего в заголовке слово scrum.
Не придирок ради, а моего лучшего понимания для.

[eross]

Масштабировать Scrum можно по разному, мы рассказал о нашей имплантации, думаю, если вы посмотрите выступление станет понятнее

[time2rfc]

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

Родился еще один вопрос, а какие задачи выполняет у вас тимлид в рамках scrum процессов? Есть scrum роли, и там нет тимлида, интересно узнать как вам удалось состыковать эти две вещи.

[eross]

teamlead роль не scrum, конечно не прописанная, но его жизнь радикально изменилась, как только участников его команды растащили по разным value stream. В задачу teamlead'a входит контролировать целостность кода следить за вопросами архитектуры и делать так, что бы код не превратился в спагетти. Создав кроссфункциональные команды, которые стимулируют быстрый запуск фич в прод, мы можем привести состояние кодовой, например Android, в неподдерживаемое состояние. Teamlead препятствует анархии.

[time2rfc]

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

[eross]

Например, есть teamlead Android, это самый опытный разработчик или несколько разработчиков, в их задачу входит стратегия развития кода. У Teamled есть команда (мы ее называем «платформа»), которая так же работает по scrum. При этом есть команды value stream, в которых тоже есть Adnroid разработчики. Teamlead участвует в планировании платформы, но не участвует в планирование Android разработчиков, входящих в value stream'ов. Teamlead не называет сроки ни в команде платформы и уж тем более в команде value stream'ов. Сроки каждая команда определяет сама и сама старается их соблюсти.

[time2rfc]

Пока только понял что тим-лид просто сидит на планировании. А какие еще есть обязоности у тимлида ?

[eross]

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

[time2rfc]

а ответственность на тимлиде или на команде ?

[eross]

в конечном счете, отвечает все, это же командная работа.

[time2rfc]

а наймом кто занимаеться?

[GoldJee]

Teamlead в Scrum? Хм.

[SergeyMax]

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

Буду рад, если всё было не так)

[eross]

Не руководство, в сама команда увидела что time2market составляет 4 месяца, для очень простой фичи, что не простительно много. Стало ясно, что есть очень много сложных связей внутри большой команды и чем сложнее фича, тем вероятность успеха её внедрения меньше. Создавать под каждую фичу сложную и каждый раз разную структуру проектного управления неуелессодразно. Так что шаг, который мы предприняли помог уменьшить количество зависимостей между людьми внутри команды, которая пилит отдельную фичу. К слову Иметь в команде болтунрв и любителей футбола это намного лучше, чем людей не желающих общаться.

[jehy]

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

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

Если да, то вы очень точно назвали произошедшее с лидами «стокгольмском синдромом».

Определение из википедии

Стокго́льмский синдро́м — термин, популярный в психологии, описывающий защитно-бессознательную травматическую связь, взаимную или одностороннюю симпатию, возникающую между жертвой и агрессором в процессе захвата, похищения и (или) применения угрозы или насилия. Под воздействием сильного переживания заложники начинают сочувствовать своим захватчикам, оправдывать их действия и в конечном счёте отождествлять себя с ними, перенимая их идеи и считая свою жертву необходимой для достижения «общей» цели.

[PkXwmpgN]

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

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

[eross]

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

[jehy]

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

[eross]

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

[justhabrauser]

«Технический директор ivi Евгений Россинский (eross) хорошо знаком участникам наших конференций» — ???.. (в смысле — ORLY?)
Ну и далее в том же духе

[romas1982]

Не совсем понял суть вопроса. Если говорить про конференции Бунина, то Евгений несколько раз выступал и является членом одного из программных комитетов. Так что вполне себе знаком участникам.

[napa3um]

Получилась каша (заоверинжиниренные регламенты и иерархия зон ответственностей) из топора (одноуровневого скрамного цикла). Скрамной и аджайловой истории, кажется, в этом не очень много, кроме тех моментов, которые вы героически преодолеваете.

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

[mifa]

Какой кошмар. Бедные разработчики…

[hunterxp]

Интересно, но по-моему очень сложно получилось.
Наверное, в команде разработчиков из 130-140 человек, по-другому быть не может.
Но, всё равно спасибо — есть идеи, которые стоит почерпнуть и попробовать в своей среде.

[jehy]

Наверное, в команде разработчиков из 130-140 человек, по-другому быть не может.

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

[vyatsek]

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

Почему бы не сделать приоритет новой фичи одинаковым и координировать реализацию фичи сразу в трех продуктах?
Почему не выделить людей ответственных за Product Area во всех трех типах продуктов?

[wrmax]

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