Comments 33

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


То, что прокатывает в реале, в тексте выглядит неопрятно и постыдно.

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стартапу — скрам, а бизнесу — квалифицированный менеджер, и, увы, отсутствие такого менеджера не компенсировать ритуалами скрама (делегированием менеджмента на исполнителей). Важно не перепутать и помнить, когда стартап превращается в бизнес (а денежно-тщеславная мотивация совладельцев стартапа в полугодовые премии и мед-страховку наёмного директора выращенного бизнеса).
Интересно, но по-моему очень сложно получилось.
Наверное, в команде разработчиков из 130-140 человек, по-другому быть не может.
Но, всё равно спасибо — есть идеи, которые стоит почерпнуть и попробовать в своей среде.
Наверное, в команде разработчиков из 130-140 человек, по-другому быть не может.
В команде из любого количества человек может быть что угодно. Очень разные люди и проекты бывают.
Странный подход менеджмента, работают по принципу индуса в саппорте на первой линии: решение проблемы осуществляется поиском в Knowledge Base нужной статьи, без понимания деталей. Для решения узкой проблемы, в разных продуктах у одной и той же фичи разный приоритет, вы берете и перестраиваете работу полностью. Вместо того, чтобы свести васю из продукта с мишей из сервера и сказать: парни надо сделать такую фичу, договоритесь о тех деталях и все.

Почему бы не сделать приоритет новой фичи одинаковым и координировать реализацию фичи сразу в трех продуктах?
Почему не выделить людей ответственных за Product Area во всех трех типах продуктов?
не очень понятно как решается проблема зависти,
перекинуть разработчика с проекта на проект нетривиальная задача:
это минимум с двумя бизнес-заказчиками договариваться придётся
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.ontico.ru
Employees
11–30 employees
Registered

Habr blog