Как работают создатели Pivotal Tracker… О разработке, управлении и найме людей

На www.edx.org в рамках курса Software as a Service опубликована интересная лекция технического руководителя (engineering manager) Дэнни Бурка (DANNY BURKES) о том, как устроена их работа в Pivotal Labs. Выдержками из этой лекции, переведенными на русский язык, хочу с вами поделиться.

Лекция построена следующим образом. Сначала рассказывается о философии разработки ПО в Pivotal Labs. Затем даны более конкретные рекомендации для разработчиков и менеджеров проектов. В конце рассказывается о практике найма людей в их организацию.

Ссылки на видео:
www.youtube.com/watch?v=bXCNvGHeYEA – вступление.
www.youtube.com/watch?v=CFVGT98gebM – разработки ПО в Pivotal Labs.
www.youtube.com/watch?v=o4c_MKbRxNA – как мы нанимаем людей?

Философия Pivotal Labs (стратегия)


Разработка ПО — это общение. Способность общаться с людьми и учиться у них является ключевой.
Разработка ПО требует дисциплины и строгости. Мы используем следующие практики:
  • Постоянная работа в парах.
  • 100% использование методики TDD (Test-driven development).
  • Сильный фокус на рефакторинге.
  • Использование практики непрерывной интеграции (CI). Результаты всех тестов отслеживаются на мониторах. (Но большие мониторы главным образом для клиентов. На них это производит впечатление. Разработчики все отслеживают на своих машинах).
  • Совмещение команд (совместная работа с клиентом).
  • Standups. Ежедневные утренние стоячие совещания (10 минут) на всех, а затем разбиение на команды и такие же совещания внутри команд. Это важно, чтобы сохранить коммуникации. В основном эти совещания направлены на выявления проблем, блокирующих (отнимающих время) текущую работу. В масштабах всей компании обсуждаются проблемы проекта в целом.
  • Retrospectives. В рамках проекта еженедельно обсуждается выполненная работа. Обсуждение итогов недели занимает 1 час. На совещании присутствуют разработчики, РП (Руководитель проекта) и, возможно, представитель заказчика. Обсуждение открытое и прямое — говорится о хорошем, о том, что начинает выглядеть подозрительным и о плохом. Плохое обсуждается несколько подробнее (до часа), после чего составляется список шагов для решения проблемы. Внутри компании работа обсуждается раз в месяц (общие вопросы, например: «Мы все еще работаем в парах?» — «Это эффективно?»). Ничто не является каноном.
  • Близость РП к работе. Постоянное взаимодействие между РП и разработчиками. Взаимодействие должно быть с глазу на глаз, никакой «электроники».
  • Повсеместное использование Pivotal Tracker.
  • Использование демо-среды для приемки работ менеджером.
  • Планирование работы на следующую неделю. Выполняется один раз в неделю. Выяснение ожиданий/последствий/оценок/понимания задач между РП и разработчиками.
  • Inceptions/Outceptions (старт/финиш проекта). Первый день проекта должен полностью заниматься совещаниями. Нужно загрузить разработчиков работой на несколько недель вперед и в течение этих недель вы должны избегать совещаний любой ценой. Разработка ПО никогда не заканчивается. Вы должны реагировать на клиентов и пожелания людей. Это утверждение вступает в конфликт с разработкой ПО по спецификации. В этом случае вы предполагаете, что знаете, когда закончите. Но этот метод просто не работает.

Тактика


Для разработчиков

Особенности экстремального программирования (ЭП):
  • Социальная активность. ЭП не для человека в наушниках, который любит сидеть в углу и проворачивать тысячи строк кода.
  • Проектирование становится постоянной деятельностью. Начинать разработку без полной постановки задачи — нормальная практика.
  • Тестирование становится основной деятельностью процесса разработки. Вы не приступаете к кодированию до составления теста. Тестирование гораздо важнее для клиента, чем код. Код — скорее некий артефакт. Тесты говорят о том, что хочет сделать клиент и как он хочет, чтобы продукт себя вел, а код это способ осуществления этой задачи. А идея гибкой разработки ПО в том, что вы должны быть в состоянии изменить реализацию в любое время, пока все еще идут тесты. Да, через полгода у вас могут возникнуть проблемы с масштабированием и вам придется переписать большую часть системы, но печалиться не стоит, так как у вас все еще есть тесты. И эти тесты всегда смогут заверить вас, что поведение системы не изменилось.
    – Вы составляете какую-нибудь формальную документацию?
    – Тесты. Мы не делаем комментариев. Мы не делаем документов. Тесты наша документация… Spec (Ruby), Jasmine (JavaScript), Capybara — это все виды DSL (предметно-ориентированных языков). И не надо быть программистом, чтобы понимать их. Но и до них мы не писали документации, потому что она устаревает, как только вы ее публикуете.
    – Пишите ли вы комментарии?
    – Нет, у нас есть тесты.
    – Речь о комментариях типа «что этот код делает, почему код написан именно так»?
    – Единственная причина, по которой написан код (так или иначе), это пройти тест.
  • У нас в Pivotal нет собственных столов и компьютеров. Что мы имеем, так это трёх-парную команду (6 человек) и три разработческих станции (два 27 Mac и по паре устройств ввода). Есть также отдельные компьютеры для личных нужд и почты. Но сейчас они почти не нужны, так как все работают через телефоны. Людей беспокоит, что у них нет личных компов, но беспокоит их это только в первый день.
  • «Неуверенность».
    • У вас нет спецификаций
    • Вы не знаете, куда хотите прийти
    • То, что вы знаете сегодня, может измениться завтра
    • Вы не знаете, когда закончите
    • Вы должны отказаться от понятия «быть завершенным»
    Все это требует определенного типа личности, готовой жить с этим.


Для РП (руководителей проектов, менеджеров проектов)

  • РП должны отслеживать backlog(невыполненные задачи). Это очень большая работа.
  • РП должны каждый день следить за тем, что backlog точно отражает то, что они хотят получить, и второе – порядок, в котором они хотят это получить.
  • Чем больше команда, тем труднее. Хорошие РП на восемь пар очень редки. Нужно сильно потрудиться, чтобы постоянно занимать работой все восемь пар.
  • РП нужно своевременно принимать работу разработчиков. Они очень раздражаются, когда на следующий день после выполнения работа остается не принятой.
  • РП должен думать о краткосрочной и долгосрочной перспективе при планировании задач.
  • Разработчики хотят, чтобы РП сидел рядом с ними.

Найм людей


Что не нужно делать?

  • Принятые «лучшие практики» собеседования разработчиков полностью ошибочны.
  • Не нужно держать людей в комнате по 5 часов и проводить интервью с 10-ю вашими сотрудниками.
  • Не нужно проверять специфические технические навыки. Речь идет о знании специфичных технологий. То есть, если у нас проект под iOS и приходит сотрудник с таким знанием — это хорошо, но специально его искать не надо. Ровно из-за того, что завтра проект под iOS закончится, начнем писать под Android и что делать со спецом под iOS? Следует акцентироваться на способности человека к обучению и коммуникации.
  • Нельзя игнорировать коммуникативные навыки, если вы хотите заниматься ЭП. Даже в том случае, если кандидат выглядит суперспециалистом, но испытывает трудности в общении или не выглядит дружелюбным.
  • Найм не должен быть слепым. Часто собеседования проходят без проверки навыков кодирования. Как вы можете таким образом нанять человека? Это не имеет никакого смысла.

Как мы нанимаем людей?
Первая часть состоит из парного интервью. Около 45 минут. Может быть по скайпу, но лучше в живую за обычным рабочим столом.
  • Мы в паре решаем обычную рабочую задачу, которая есть на текущий момент. Речь идет об общих понятиях, не о специфичных технологиях, а скорее о навыках решения проблем.
  • Вы можете предложить хороший способ решения, но гораздо важнее эмпатия (слышит ли вас собеседник?) и коммуникации.
  • У нас очень строгий критерий отбора в первой части интервью. Кандидат должен набрать определенное количество баллов. Если набрал, то мы предлагаем прийти на второй раунд отбора.
Вторая часть — вы приходите и работаете целый день. Полдня с одним человеком, полдня с другим человеком в паре. Это будет работа в реальных проектах. Это не синтетические проблемы, не подделки, не маркерные доски. Вы садитесь и пишете код. Фактически — это собеседование с нашей командой.
  • Этот раунд направлен на выявление более специфичных навыков.
  • «Cultural fit» (проверка подходит ли кандидат «культурно»).
  • В конце интервью мы спрашиваем кандидата, готов ли он 6 месяцев сидеть в паре вот с этим человеком? Кандидат должен понимать, что его ждет. Мы хотим быть уверенными в том, что вы будете ладить с людьми.

Итак, три вещи, которые мы проверяем таким образом:
  1. Навыки программирования.
  2. Коммуникативные навыки.
  3. Навыки сотрудничества с разработчиками.

Что мы ищем в людях во время интервью?
  1. Фундаментальные навыки в программировании и разработке ПО.
  2. Любопытство и голод к освоению новых навыков. Это важная особенность личности, которая попадает в нашу область работы.
  3. Умение сказать «Я не знаю». Удобно ли вам это говорить? Вы должны понимать, что умение признать свое незнание – единственный способ учиться.
  4. Обратная сторона п.3: Желание сказать: «Давайте попробуем и посмотрим, что произойдет».
  5. Personability.
  6. Уверенность в том, что вы можете дать лучший совет, а также и понимание того, что клиент может проигнорировать его.

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

Подробнее
Реклама

Комментарии 19

    +7
    Всё конечно класно, но к сожалению в теории. Имел опыт «перебирания» проэкта клииента от PivotalLabs.
    Покрытие тестами было но далеко не идеальное, достаточно много устаревших тэстов и достаточно много кода, который ничего не делал и непоятно почему остался. Отдельная песня, это инструкция по поднятию проэкта, очень много специфических для машин разработчиков вещей, в результате удалось поднять только во время визита онсайт под присмотром ихнего человека.
    Pivotal Tracker ужасная система, сложно понять что происходит сейчас, а «интелектуальность» системы которая пытается всунуть в следующий спринт то что она считает реальным исходя из предыдущей скорости, а не то что нужно клиенту доставила много неприятных моментов.
    В остатке, отдали проект ребята конечно в значительно лучшем состоянии чем это обычно случается от других аутсорсеров, но если они бы действительно следовали всем перечисляемым практикам, он бы мог быть лучше. Pivotal Tracker — это то что случается когда преобладает догматизм вместо «здравого смысла».
      –2
      Может если правильно писать слова «проект» и «тест» этих проблем не было бы?
      –1
      А они там работают хоть или заняты лишь повышением ЧСВ таким образом? Лично меня очень сильно отвлекает от кодинга вся эта бюрократия, которая кстати характерна в большинстве случаев для продуктов из сша
        –1
        какой-то АД при приеме на работу… интересно, люди, которые сейчас работают, готовы взять за свой счет отпуск, чтобы целый день с вами поработать, а потом понять, что это не для них? Или этот 1 день всетаки оплачивается?
          –1
          Неужели так сложно инвестировать один день своего времени на улучшение своей работы и своего же благосостояния?
            0
            Хм, но ведь не факт, что улучшение будет.
            Если вам не понравится, то вы просто потеряли день на левый для вас проект, а значит и благосостояние ваше не улучшилось. Вы представляете, если все компании вот так начнут подбирать? Это же нереально будет искать новое место, не уволившись со старого.

            Приобрели опыт?
            Есть более оптимальные способы получить и более качественный, и более продуктивный опыт.
              0
              Есть более оптимальные способы получить и более качественный, и более продуктивный опыт.


              Какие, например?
                0
                Начиная от соревнования (выбирайте, сейчас IT-кэмпов полно), хакатона и заканчивая какой-нибудь конференцией.
          +6
          Мы пробовали нанимать на работу людей через парное программирование. Попробовали на человеках 10 где-то. Отказались. Причина проста — довольно сложно сразу человеку въехать в проект и делать там что-то серьезное. Не у всех есть навыки парного программирования, а без опыта можно и растеряться особенно в незнакомой среде. Решать тривиальные задачи в паре чтобы проверить коммуникацию? Ну это не сильно эффективно.

          У нас тоже два дня. Первый день разговор на 30 минут и тестовое задание на архитектуру на 2 часа — проверка на профпригодность.
          Если все ОК, то второй день глубокое интервью на 2-2.5 часа по разным темам.

          Ошибаемся мы очень редко. Может быть пропускаем хороших кандидатов, это да. Но из пары десятков человек, которых взяли, уволили только одного.
            0
            Зато какая добыча если человек может сходу подхватить и въехать в проект и даже сделать что-то серьезное :) ИМХО реально это.
              0
              И будете вы искать этого человека полгода, потеряв за это время и клиентов, и доходов из-за отсутствия необходимого кадра.
              Т.е. я хочу сказать, что на первый взгляд звучит это круто, но с точки зрения целесообразности и окупаемости (ведь эти полгода, что будут искать, ваши кадровики будут работать без результата) — как-то не очень.
            0
            Ну для американцев, наверное, такая методика хороша. Но точно не для нас.
              0
              Интересно, почему? Что такого особенного в американцах (или в русских)? Лично мне, например, подобный подход очень и очень импонирует. А чем он не подходит для остальных?
                0
                1. У меня действительно нет целого рабочего дня, который я могу посвятить непонятно какому проекту.
                2. Люди хотят, чтобы я за час в экстремальной обстановке разобрался в сложном проекте и решил боевую задачу по нему, а сами за тот же час (первый этап) не могут понять, подхожу я или нет (т.е. выполнить свою работу в своей привычной среде). Это уже говорит о профессионализме и компетенции проводящих интервью не в их пользу. По крайней мере, для меня.
                  0
                  1. Сначала ему придётся посвятить всего час (да ещё и с напарником), а потом уже только день. Если проект или компания не интересны, это можно и за час понять. А если интересны, то имеет смысл и ещё один день потратить. Разве не так?
                    0
                    2. Судя по пунктам, указанным в статье, они проверяют немного другое. Не как кандидат выполняет работу в привычной для него среде, а как команда в целом работает с этим кандидатом. Глядите:

                    Фактически — это собеседование с нашей командой.
                    * Этот раунд направлен на выявление более специфичных навыков.
                    * «Cultural fit» (проверка подходит ли кандидат «культурно»).
                    * В конце интервью мы спрашиваем кандидата, готов ли он 6 месяцев сидеть в паре вот с этим человеком? Кандидат должен понимать, что его ждет. Мы хотим быть уверенными в том, что вы будете ладить с людьми.


                    Это может быть выгодно и для самого кандидата. Ведь ему тоже будет неприятно, если контакт с командой не заладится после прохождения интервью.
                      0
                      Вот представьте себе, у вас собеседование, второй этап, вас сажают к человеку, а он сегодня не выспался, в автобусе на ногу наступили, он промок, от него ещё и девушка вчера ушла, а ещё он случайно разбил свой любимый чайник и отключили горячую воду. Ну и не сработается он с вами (т.е. вы, допустим, не принимаете к сердцу его игнор — ведь говорить настроения у него нет — и пофигистичное отношение к выполняемому заданию), и под конец дня скажет, что хз как с вами работать — он кайфа не получил и вы только напрягали его своим присутствием.

                      И что? Это разве значит, что вы никогда не сможете сработаться с этим человеком? Вполне возможно, что узнай он вас поближе, было бы всё по-другому. Не случайно есть мнение, что первое впечатление обманчивое.

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

                      Я, конечно, утрирую, но мысль, думаю, вы уловили.
                –1
                Не хочется читать статьи об эффективном программировании от компании, которая на свою крайне популярную open-source библиотеку (Jasmine BDD) положила болт. Пулл реквесты и багрепорты висят неотвеченными по несколько лет… Обидно. Когда-то была передовой библиотекой для своих задач, а теперь все давно уже перешли на Mocha — ее создателю явно не плевать на пользователей.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое