Наверх ▲

Построение распределенной софтверной компании / подразделения на основе Scrum

Борис Вольфсон Борис Вольфсон Борис Вольфсон занимается веб-разработкой и разработкой программного обеспечения с 2003 года. Карьеру начал в качестве программиста компании «Систем-Софт» в Оренбурге. С 2008 года – руководитель проектов и руководитель регионального отдела разработки в компании Softline.

Борис Вольфсон: Я расскажу об опыте компании "Softline", об опыте Департамента разработки интернет-проектов. Вначале принято кратко рассказывать о себе. Покажу мотивационный слайд, чтобы подчеркнуть свой авторитет, и кратко расскажу, чем мы занимаемся.

Мы, в основном, занимаемся разработкой веб-проектов. Обычно это не просто сайты – веб, скорее, выполняет в них роль front-end. Сайты, связанные с автоматизацией производства либо бизнес-процессов, с электронной коммерцией, и так далее.

На данный момент у нас задействовано в разработке более 100 человек. Четыре региона. Соответственно, около 15 команд.

В рамках своего доклада я хочу рассказать

  • о том, как мы постепенно выросли;
  • о том, как мы справились с этим ростом;
  • о том, как изменялась наша организационная структура;
  • о том, какие интересные решения мы выработали;
  • о том, как изменялись наши процессы.  

Сначала хочу рассказать анекдот.

Приходит мужик к доктору и говорит: "У меня какая-то сыпь. Дайте мне какое-нибудь лекарство". Доктор дает ему таблетки. Говорит: "Приходите через неделю". Он приходит. Говорит: "Сыпь прошла, но что-то у меня низ спины чешется". Доктор осматривает. Говорит: "Вы знаете, у вас хвост растет". Мужик немного удивился этому. Доктор ему говорит: "Вот, держи еще пилюли. Через неделю приходи". Он приходит. Говорит: "Вы знаете, у меня хвост продолжает расти. И еще что-то спина чешется". Доктор смотрит: "Ой, да у вас крылья растут. Вот вам порошок и приходите еще через три недели". Мужик уже обреченно спрашивает: "А есть какой-то смысл? Это может помочь?" Доктор отвечает: "Просто хочу посмотреть, что из тебя в итоге получится".

Такая вот байка. Из нее можно сделать очень простые выводы: изменениями очень сложно управлять. Особо сложным с точки зрения менеджмента является управление ростом компании. С этим сталкиваются стартапы, которые за месяцы (может быть, за год) вырастают из "гаражного" производства до полноценных компаний. Некоторые на этом этапе  погибают.

Либо они перестают быть достаточно гибкими. Становятся тяжелыми, бюрократическими, "медленными". В итоге их обходят конкуренты. Соответственно, надо не просто расти, но и оставаться при этом гибкими.

Я хочу четко понять, что за аудитория здесь собралась. До этого читал доклад, и народ почти не слышал про Scrum. Есть в зале те, кто по методологии Scrum работает? Ага, я буду ориентироваться на то, что хотя бы половина из вас точно знает, что это такое. Есть компании (может, какие-то представители подразделений), где организована работа по Scrum? В Scrum-командах от 50 до 90 человек. Нет. Ну, тогда третий вопрос задавать не буду: есть распределенные компании, команды, рассредоточенные по нескольким городам? Ок.

Все эти вопросы я постараюсь затронуть в докладе.

Начнем со "скелета" организации – с организационных структур. Мне очень нравится эта картинка с анти-паттерном: много руководителей, и бедный Вася один копает яму.

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

Можно сформулировать проще – "чтобы было мало начальников".

Она должна поддерживать гибкие процессы. Это может быть Scrum. Это может быть популярный ныне Kanban.

Она должна поддерживать и обеспечивать быстрый рост компании. Если мы вырастаем на 100% за год, мы не должны менять организационную структуру полностью.

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

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

Получается, методологии такого рода фикция, можно сказать. Английский вариант: "Пиши код". Я не знаю, переводить ругательство или нет. Есть еще русский вариант: "Пиши, блин, код". В качестве анти-паттерна можно посмотреть.

Первый уровень масштабирования (все, кто применял Scrum, с ним сталкивались) – это просто уровень команды. Он описывается в любой книжке по Scrum. Его можно очень быстро внедрить, за несколько недель. Если у вас команда такого опыта не имеет – может быть, за несколько месяцев.

Что такое Scrum, знаете?

Этот термин пришел к нам из регби. Внизу есть описание. Это три роли (я подробно рассказывать, останавливаться не буду):

  • Product Owner;
  • Scrum Master;
  • Команда.

Это процессы Daily Scrum, на котором мы синхронизируем работу команды.

Это планирование спринта, на котором мы выбираем задачи, которые будем делать дальше.

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

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

Также существует понятие артефакта. Два из них я назову. Я их буду упоминать в моем докладе. Это backlog-спринт (то, что мы делаем за спринт), backlog-релиз (то, что мы делаем за релиз). Burndown спринта и Burndown релиза. Это графики, которые позволяют нам отслеживать, успеваем мы все вовремя сделать или нет.

Обычно Scrum-команда состоит из 5-9 человек. Если наша команда значительно меньше, то Scrum получается "недо-Scrum", что ли, потому что те практики, которые используются в Scrum, становятся слишком "дорогими".

Наоборот, если в команде становится больше 9 человек, то у нас удлиняются собрания и вообще все мероприятия. Большую команду надо разбить на несколько маленьких.

У команды есть Product Owner со своим backlog. Но в один прекрасный момент (на нескольких проектах у нас это достаточно быстро произошло) участников становится больше 10. Ваш "паровоз" уже не может увезти всех: вам надо что-то делать, как-то разделять команды.

Для этого мы используем, прежде всего, масштабирование организационной структуры, и процессов, которые есть в традиционном Scrum. Удачные практики и организационные приемы, которые используются на уровне команды, мы пытаемся перенести на уровень нескольких команд.

С производственной точки зрения это выглядит следующим образом. Организуется достаточно традиционное (не одни мы это делаем) собрание. Оно у нас называется Scrum of Scrum. На нем обычно присутствуют оба исполнителя роли Scrum Master команд и руководитель разработки.

У меня здесь обозначен Program Manager. О его роли чуть позже скажу.

Что делается на этом мероприятии?

Во-первых, обсуждаются проблемы, которые есть у команд.

Если вы читали любую книжку про Scrum, любую статью про Scrum, там сказано, что Scrum Master должен решать проблемы команды, устранять препятствия. Но как именно, не сказано. Такая встреча с руководителем дает постоянный механизм, где эти проблемы можно эскалировать на его уровень.

Во-вторых, это, безусловно, синхронизация работы между командами. Это особенно важно, когда у вас один проект делают несколько команд. Или, допустим, в вашем портфеле проектов есть проекты, которые между собой связаны, но довольно слабо. Тем не менее, все равно имеется определенная взаимосвязь. Соответственно, требуется синхронизация работы между ними.

Очень хорошая практика. Все, кто использует Scrum, думаю, ее на себе опробовали: это жесткий тайм-боксинг. У каждого выступающего надо жестко обрубать время. У нас это обычно примерно 2 минуты на человека. За эти 2 минуты надо рассказать, что команда сделала (обычно за неделю).

Самый положительный эффект от жесткого тайм-боксинга заключается в том, что люди начинают говорить главное. Когда человек знает, что его время жестко ограничено, он не растекается мыслью по древу, выбирает самое важное. Доводит до сведения коллег самые важные проблемы.

Если у вас, например, 5 команд, вы можете за 10 минут получить полную картину того, что у вас происходит, какие есть проблемы, какие есть планы у команд.

Еще одна возможность использования Scrum of Scrum – это распределение ресурсов. Это может  быть перераспределение людей в командах.

Например, перераспределение ресурсов, которые не задействованы на полный рабочий день на проектах. Это могут быть дизайнеры (в зависимости от специфики ваших проектов).

Третий уровень масштабирования – это Scrum of Scrum of Scrum. У нас обычно это называется просто 3S-meeting. На нем Program Manager встречается с руководителем разработки. Это следующий шаг, этап, уровень в масштабировании. 

Что касается времени, у нас обычно дается около 10 минут, чтобы рассказать, что 30-40 человек сделали за неделю. Какие есть проблемы? Что планируется сделать? В итоге за час или за 50 минут можно получить информацию о проблемах, о планах, о том, каковы результаты работы около 100 человек.

Хочу кратко еще рассказать про управление продуктами. Я поверхностно расскажу, потому что это не мое основное занятие, но у нас получилось масштабировать и "продуктовую" часть.

У каждой команды есть Product Owner. У них есть их руководитель – Chief Product Owner (главный Product Owner).

У нас в компании обычные исполнители роли Product Owner административно подчиняются Chief Product Owner. У него есть возможность управлять высокоуровневыми задачами на высоком уровне. Он может выставлять приоритеты по проектам, по крупным функциональностям и спускать их в backlog к конкретным исполнителям роли Product Owner.

Внизу у меня PBL – program backlog. Это может быть нечто физическое, материальное – можно сделать высокоуровневую доску с проектами. Это могут быть просто виртуальные наборы задач в трекере, например.

Есть обратное течение, когда исполнители роли Product Owner могут предлагать свои функционалы в продукты (тоже высокоуровневые), через Chief Product Owner выделять на это либо время команды, либо новые команды.

Чтобы довершить картину, надо все, что я рассказал, просто объединить в одной схеме. В итоге получится стройная схема с минимальным количеством уровней иерархии. У Chief Product Owner тоже добавляется свой топ-менеджер.

Я хочу обратить внимание, что в рамках такой схемы (я об этом скажу попозже) у нас работает уже более 100 человек. С продуктовой частью, наверное, около 120 получается. О результатах скажу чуть позже.

При этом топ-менеджер разработки может быть одновременно и топ-менеджером управления продуктами (в зависимости от размера компании). Не надо здесь делать какое-то жесткое противопоставление разработки (research &development) и "продуктового" управления.

Поскольку есть четкая и жесткая иерархия, необходимо устраивать качественные коммуникации между этой частью и этой.

Как эта схема у нас накладывается на Scrum?

Стоит отдельно сказать: то, что я рассказал, не подменяет традиционные практики Scrum. Все они у нас используются. Если посмотреть на процессную часть, у нас практически дистиллированный Scrum, но уже со своими многолетними наработками в аналитике, тестировании.

У исполнителя Chief Product Owner есть возможность влиять на program backlog, на backlog отдельных проектов, но обычно это делается на уровне больших серьезных функционалов. Также у него и у исполнителя роли Program Manager есть влияние на приоритеты: фактически на то, что отбирается для реализации в проект.

Безусловно, последнее слово будет за исполнителем роли Product Owner этого проекта. Но, например, вмешательство исполнителя роли Program Manager требуется в случае технических задач. Это могут быть разного рода рефакторинги, увеличение покрытия тестами. Все, что угодно. Любые технические задачи.

У Program Manager также есть возможность влиять на ход спринта. У нас стандартные спринты обычно длятся 2 недели, а Scrum of Scrum проходит каждую неделю. В итоге (посередине спринта обычно получается) есть возможность каким-то образом повлиять, выделить ресурсы, синхронизировать работу команд.

На демонстрации продукта крайне желательно приглашать PM и CPO. По возможности лучше вытаскивать туда все заинтересованные стороны. Особенно если это предрелизная демонстрация либо демонстрация какого-то важного функционала.

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

Последний множитель. Все, что я рассказал, надо еще домножить на то, что сейчас Scrum обычно делают распределенным. Географически такой "аутсорсинг" в рамках одной компании уже вполне стандартное явление.

На эту схему просто "натянуть" возможность работы распределенно (в нескольких городах). У нас фактически имеются сформированные филиалы и отделы. Они организуются достаточно просто.

Program Manager становится руководителем филиала. Но, в силу сложившейся традиции, наши клиенты и заказчики обычно располагаются в Москве, и нижняя, "продуктовая" часть тоже находится в столице. Получается,  что наша команда собрана в одном месте, а исполнители роли Product Owner от нее удалены.  

В качестве анти-паттерна могу привести пример из личной практики. Желательно, чтобы команды, даже если они реализуют несколько проектов, были собраны в рамках одного филиала, одного отдела, чтобы не получалось, что у вас разработчики сидят в одном городе, а тестировщики в другом. Гибкие методологии, прежде всего, основаны на коммуникациях. Удаленность, безусловно, влияет на качество коммуникаций. Причем очень сильно.

Чего нам удалось добиться? Хвалебный слайд.  

У нас в рамках этой системы идут более 15 проектов (в зависимости от текущих потребностей). При этом есть проекты, которые делают сразу несколько команд. Есть проекты, которые реализуются одной командой.

В такой схеме работает более 100 человек. С продуктовой частью – около 120. Всего такая схема с тремя уровнями масштабирования поддерживает работу до 700 человек. Это средняя компания. Я думаю, что неплохо.

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

У нас 4 региональных филиала. В прошлом финансовом году мы открыли новый филиал. На это у нас ушло примерно около месяца с bootcamp. В такую схему очень просто добавлять новые подразделения. Очень просто ее экстенсивно расширять за счет добавления новых регионов.

Мы умеем быстро расти. За прошлый год мы выросли на 100% по количеству проектов и по количеству разработчиков. Такая схема это очень хорошо поддерживает.

У меня все. Здесь есть мои контакты, корпоративный e-mail, если что (если захотите проверить эту схему на себе), личный e-mail и twitter. Я туда достаточно часто и подробно пишу. 

Если у вас есть вопросы, я готов ответить.

Вопросы и ответы

Реплика из зала: Очень интересно послушать про то, как Agile растянуть на 700 человек.

Вопрос вот в чем. Были ли у вас кейсы… Вся эта структура изначально строилась под Agile? Это все выглядит очень структурно, очень системно и строго структурировано под конкретную задачу.

Это все изначально так было, или был момент перехода?

Борис Вольфсон: Спасибо. Очень хороший вопрос. У нас буквально несколько лет назад (точнее, три года) была классическая корпоративная матричная структура. Причем там доминировала, наверное, функциональная часть.

Стыдно говорить (еще и на камеру снимают): был отдел разработки, был отдел тестирования, отдел системной аналитики, и так далее. Между этими отделами были железные, бетонные стены с колючей проволокой наверху и с пулеметными гнездами. Проекты делались очень медленно. Благодаря поддержке руководства удалось постепенно переструктурировать все это дело.

Эта схема получилась тоже не сразу. Она получилась из трех схем того, как работают иностранные аутсорсеры (это есть в открытых источниках, соответствующей литературе по гибким методологиям и масштабированию), и консультаций с отечественными "гуру". Я бы так сказал.  

Трансформация заняла примерно год. Это не мгновенно, и это выстраивалось не с нуля. До начала трансформации у нас было примерно 40-50 человек. Мы смогли осуществить трансформацию и вырасти за это время.

Спасибо.

Реплика из зала: Хорошо. Я не с самого начала подошел, поэтому задам, может быть, очень глупый вопрос.

Я посмотрел на эту схему. Если я правильно понял, те люди, которые исполняют роль Product Owner, прикреплены и собираются как команда исполнителей роли Product Owner. Те, кто исполняют роль Scrum Master, являются руководителями групп команд, функционал которых – это сроки и поставка.

Борис Вольфсон: Абсолютно правильно поняли. Плюс у них, конечно, основная задача – поддерживать бизнес-процессы, сам Scrum… Это основная задача исполнителя роли Scrum Master: поддерживать процессы и выстраивать доверительную атмосферу.

Реплика из зала: Исполнители роли Product Owner занимаются тем, что им нужно для бизнеса… Они занимаются бизнесом и выставляют требования по срокам. Они выставляют требования по срокам?

Борис Вольфсон: Я здесь сошлюсь на классический Scrum. Это делается очень просто. Это абсолютно не зависит от этой схемы. У Product Owner есть набор требований. У него есть сроки, к которым эти требования надо сделать. Я думаю, 70% проектов у нас это имеет.

Здесь, как и в любой гибкой методологии… Наверное, даже тут есть специфика Scrum, где оговорены жесткие итерации. Срок выравнивается за счет объема, за счет содержания (scope) проекта. Если у нас фиксированы два этих элемента, мы можем только за счет содержания что-то менять.

Для этого я как раз вначале сказал, что очень удобно использовать релиз burndown. Там на каждом спринте видно, успеваете вы сделать этот объем или нет.

Реплика из зала: Хорошо, а теперь вопрос. Если у нас Product Owner выставляет сроки, соответственно, Scrum Master как элемент процессной структуры следует процессу и достигает этих сроков.

Кто в этой структуре отвечает за следование качеству? У нас есть определенный уровень качества. Мы можем даже подвинуть сроки, отослать Product Owner вместе со своим бизнесом подальше, пока мы не сделаем так, как надо.

Борис Вольфсон: За качество, конечно, у нас команда отвечает. Это не пустые слова: отвечают разработчики и тестировщики. При этом (я понимаю, к чему вы клоните) мы стараемся не выравнивать сроки за счет качества.

У нас проекты в основном длительные. Если (могут быть какие-то внешние обстоятельства – может быть, давление Product Owner) по срокам команда на себя принимает какие-то непосильные обязательства в ущерб качеству, то в следующем релизе это ей выйдет боком.

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

Реплика из зала: Они "сидят в общей лодке"?

Борис Вольфсон: Да, они "сидят в одной лодке".

Реплика из зала: Тогда вопрос – как устроена эта мотивация? Мотивация на уровне: как Product Owner вместе с разработчиками…

Борис Вольфсон: Да-да. Я очень кратко скажу. У нас есть система премирования. Все решается через руководство Product Owner и команды: если релиз сделан не вовремя, либо с ним есть проблемы по качеству, никто премию не получит. Если получают, то все вместе. Тут получается именно "одна лодка".

Реплика из зала: Это набор продуктов. Филиалы конкретно делают один большой продукт, или они делают разные продукты?

Борис Вольфсон: Еще раз говорю, у нас проекты очень разные. У нас есть проекты, которые делают несколько команд.

Реплика из зала: Тогда остановимся на ситуациях, где есть несколько команд, где их много. Как в них решаются вопросы проектирования, дизайна приложений. Очевидно, что если у нас есть несколько команд, значит, у нас должен быть один ответственный архитектор, который будет за всем этим делом следить. Раздавать им…

Борис Вольфсон: Да. Мы прошли через это – у нас был один такой человек. Он практически всегда при решении становился "узким местом" и замедлял производство. При этом у нас есть команда, которая занимается инфраструктурными задачами. Если вы с вебом связаны, это веб-сервисы. Мы стараемся через них все делать. На уровне этой команды такие решения принимаются.

Если мы говорим о каком-то конкретном проекте... У нас команды очень тесно взаимодействуют между собой. Архитектурные решения, все вопросы по проектирования системы обычно обсуждаются и согласуются.

Очень хорошей практикой является нулевой спринт. Про это обычно мелкими буквами пишут в книжках по Scrum. Набрасывается высокоуровневая архитектура, чтобы у команды было не только общее видение продукта (о рынке, о клиентах и так далее), но и общее архитектурное видение. Что они будут делать, что они будут использовать...

Реплика из зала: Роли Owner для этой архитектуры нет?

Борис Вольфсон: Нет. Еще раз говорю, у нас получился анти-паттерн, когда этот человек становился "узким местом" (при этом это достаточно грамотный специалист был) именно по скорости.

Реплика из зала: Цифра 700 чем обусловлена? Это количество людей в командах, или это общая численность персонала компании?

Борис Вольфсон: Общая численность персонала – это 9 в третьей степени или 8 в третьей степени.

Почему я это число неточно написал? По своему опыту могу сказать, что если у вас команда большая… У меня в самом начале было написано, что Scrum-команда должна включать 7 ± 2 человека.

Еще лучше, когда она от 5 до 7 человек, потому что когда добавляется 8-й, 9-й, 10-й человек, начинает теряться управляемость команды и прозрачность ее работы.  

Спасибо.

Реплика из зала: Простите, а можно услышать по поводу технологической составляющей этого процесса? Что у вас используется как система управления задачами? Инфраструктурный вопрос очень интересен.

Борис Вольфсон: Инфраструктуру – можно. В качестве системы управления задачами мы используем "Redmine", настроенный и кастомизированный "под себя", с собственным набором плагинов. 

У нас достаточно демократичная диктатура! Команды обычно используют доски, где задачи дублируются и в рамках одного спринта расписываются.

Язык программирования у нас в 80% PHP. В качестве сервера непрерывной интеграции использовали "Cruise control". Сейчас потихоньку переезжаем на "Jenkins".

Если какие-то еще технологические вещи интересуют, уточните.

Спасибо.

Реплика из зала: Борис, мой вопрос где-то рядом со всем, о чем вы рассказывали. Преимуществом Scrum-команд является то, что можно быстро передавать знание от одного человека другому. У вас команд много. И филиалов много. Как-то организован обмен знаниями?

Борис Вольфсон: Да, организован. Я в рамках доклада про это не рассказывал специально. Очень обширная тема. Можно сказать, выстраданная.

Мы стараемся… У нас есть несколько вариантов, несколько способов. У нас проводятся вебинары, когда команды делятся опытом друг с другом. Проводятся семинары в рамках одного региона. В последнее время нам нравится формат внутренних конференций: мы как компания сами проводим конференции. Наши сотрудники выступают, делятся опытом. Приглашаем и людей извне.

Плюс (можно сказать, что это основа) у нас есть сообщества по специализациям: сообщество разработчиков, сообщество аналитиков. Это такая слабая-слабая версия отделов. У них нет руководителя, но они все вместе обсуждают стандарты работы.

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

Нас пока эта схема устраивает. У нас люди закреплены за командами, но они также участвуют в сообществах, чтобы была какая-то общая технологическая часть.

Реплика из зала: Дополнительный вопрос. Общие жестко заданные практики среди команд разделяются? Соглашение о кодировании или что-то еще (что-то, что сверху).

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

Объясню, почему. Если команда умеет внутри себя совершенствоваться, и она приходит к тому (привожу первый пример, который в голову пришел), что вместо одних стандартов кодирования использует какие-то другие стандарты кодирования, то ей никто возражать не будет, если при этом команда достигает результата.

Реплика из зала: Спасибо.

Борис Вольфсон: Все тогда. Всем спасибо!

(Аплодисменты)

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Андрей Юношев

Андрей Юношев

Глава мобильной разработки Game Insight.

Андрей Юношев (Game Insight) освещает проблему удержания игроков в мобильных играх и делится интересными психологическими приемами.

Андрей Ситник

Андрей Ситник

Фронтендер в Злых марсианах. Работал над русским Групоном, Рокетбанком и Ebay Social. Автор Автопрефиксера и PostCSS.

Андрей Ситник (Evil Martians) о том, что анимация и 3D - это не только промо, но и юзабилити.

Эсен Сагынов (Esen Sagynov)

Эсен Сагынов (Esen Sagynov)

Разработчик в NHN - крупнейшей IT-компании Южной Кореи.

Мы будем говорить о CUBRID и расскажем, как мы разработали эту платформу, зачем мы ее разработали, почему мы не пользовались уже существующими решениям.