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

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

Философия 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. Уверенность в том, что вы можете дать лучший совет, а также и понимание того, что клиент может проигнорировать его.

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

Автор: Shaxmatist

Источник