Agile *

Данный материал можно рассматривать, как продолжение, ретроспективу этого руководства и видео (для понимания материала желательно с ними предварительно ознакомиться): Google re:Work — Руководство: Постановка целей с помощью OKR (перевод).

Google OKR Video — видео с семинаром об OKR от Рика Клау (Rick Klau) — партнера Google Ventures, было записано еще в конце 2012 года и стало, фактически, первой презентацией OKR для широкой аудитории — до этого о информация о методологии просачивалась только небольшими фрагментами, через бывших сотрудников Intel и Google.

В ноябре 2017 года Рик решил отметил пятилетие этого знаменательного семинара серией твитов, где существенно поправляет некоторые моменты из своей презентации. Этот новый материал не представлен на официальных ресурсах Google, поэтому даже в 2018 году появляются все новые статьи по OKR, в том числе и на русском, основывающиеся на Google OKR Video, но не учитывающие эти важные поправки к нему:

Rick Klau @rklau 7 Nov 2017
Вот перевод этой серии твитов (форматирование текста немного изменено для читабельности):

*Scrum (Скрам (сущ.)) — это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью.

Почему я решил написать эту статью

«С этим Скрамом столько встреч! Когда работать то?!»;
«Хорошо, пусть это будет хоть Скрам, хоть Срам, только отвалите и дайте мне писать код!»;
«У нас тоже этот Скрам навязали, вообще непонятно для чего»;
«Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»
«Скрам-мастер вообще шут какой-то, ему бы всё хороводы водить, вместо управления проектом!»;
«Да, Скрам мы использовали: главное, что ретроспективы проводили».

Нам пишут:
«Хм, а дайте плиз совет.

Реальный кейс, три разработчика, один разработчик работает 100% времени удаленно, второй разработчик — шеф/соучредитель, третий — немного офигевающий новоприбывший.

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

Есть ли способы как-то улучшить ситуацию?»

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

Привет. Меня зовут Сергей, последние пять лет я работаю в Яндексе. За это время участвовал в разработке одиннадцати проектов. Писал код на JavaScript, Python и C++. Некоторые проекты делал в одиночку, другие разрабатывал в группе из восьми человек. Но в каждой команде, на всех проектах, вне зависимости от языка программирования я использовал код-ревью.

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

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

Мне на ревью приходили пулы из пяти тысяч строк. Я часами пытался разобраться в коде, по сотне раз скроллил от функции к тесту и обратно. Писал десятки бесполезных комментариев о пропущенной точке с запятой. Всё это жутко меня раздражало. Часто откладывал ревью на потом, и у меня накапливались десятки непросмотренных пулов.

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

Какой вообще смысл в этих ретроспективах?

В репрессивной модели управления лидер будет, как правило, подбирать сотрудников либо глупее себя, либо таких, которых он может «загипнотизировать» или шантажировать тем или иным образом. Тут ищут «псов», которыми легко управлять и которыми легко травить. Спускаемые сверху идиотские указания будут без изменений проксироваться вниз и те, кто сможет проксировать их ниже — выживают, остальные лопаются. habr.com/post/124716