Agile *

В конце есть краткое содержание, если что.

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

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

Поначалу думал, что дело во мне. Ну, такой вот я дурак, не могу стабильно работать. Потом стали бросаться в глаза скачки в работе команды, которой руковожу – опять же, дикие, в 2-3 раза. Не говоря уже о перепадах эффективности отдельных программистов.

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

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

Ответ пришел случайно. Всё дело в настроении.

Во время интересной дискуссии, один очень уважаемый человек «козырнул» «неубиваемым» аргументом:

Есть полно исследований, демонстрирующих эффективность TDD

Действительно. Если зайти на Google Scholar, забить ключевые слова «TDD» и «Эффективность» — будет много научных статей, но так ли все просто? Хоть я сам и являюсь большим фанатом TDD, но я так же считаю себя скептиком, и решил проверить, доказано ли научно, что TDD так крут.

Привет!

Удалёнка это хорошо, но демо-дни никто не отменял. И если с общими коммуникациями команд еще можно как-то справиться с помощью того же Zoom / Microsoft Teams / прочего подобного софта, то с демо-днями ситуация обстоит немного сложнее. Во-первых, демо-день обычно ощутимо длинее стандартной планёрки или совещания, и занимал у нас в среднем часов 5. Во-вторых, у демо-дней есть ряд особенностей в плане организации, очередности выступления команд и прочего. Ну да вы знаете.

Так вот. Это был первый демо-день, который мы решили провести в онлайне, но в привычном для всех составе. В итоге собрали 250 человек, включая спикеров из дружественных компаний (A1, X5 Retail Group, Альфа-Капитал и других).

Как всё прошло, о чём говорили, зачем в демо-днях геймификация и пара опросов — под катом.

Проекты и участники

На этот демо-день собралось 11 команд, каждая из которых представляла новые фичи в своём направлении.

Две недели, четыре вебинара, десятки часов подготовки, планирования и ретроспектив,
40 улучшений и…. большие потери.

Поворотное Ретро

Итак, 28 апреля стартовала Вечерняя школа Слёрма. Вместе с нашими студентами на основе обратной связи мы создаём курс про Agile и по принципам Agile. За две недели отработали технические вопросы, внедрили более 40 улучшений, продолжили наполнять копилку полезностей, постоянно получали обратную связь от студентов. В общем, улучшались, собой и продуктом были довольны.

На Ретро после 4 вебинара пригласили студентку, чтоб от народа услышать, какие мы крутые. Обратная связь оказалась неожиданной, словно холодная вода в лицо. И много непонятных терминов, английских слов в речи спикеров. И в личный кабинет не получается зайти, и в чат в Телеграм не попала. И темы вебинаров «размазаны», непонятно, на какую целевую аудиторию рассчитаны.

Невесёлая воронка

Начался анализ. Глубокий инсайт изменил наше сознание. Дойдя до 4 вебинара – до четвёртого!!! – мы только узнали, что теряем людей. Мы забыли о цифрах, смотрели на них, но не видели. Сами судите:

Вот такая невесёлая воронка при полной уверенности, что наш курс имеет огромную ценность. Уже две недели мы даём людям сотни полезностей, рассказываем, как в кризис не утонуть, увидеть новые горизонты, поймать возможности, запастись эффективными Agile-инструментами.
Но народ-то уходит…

WTF?!!! В чём дело?!

Демо в конце спринта (будь то внутреннее, заказчику или крупному клиенту) — это настоящая проверка знания английского для не носителя языка, так как эта небольшая презентация показывает:

• беглость речи (fluency)
• точность (accuracy) — много или немного ошибок в речи в целом
• спонтанность языка (особенно, когда задают вопросы)
• произношение
• владение грамматикой
• богатство или бедность лексики
• насколько правильно человек умеет составлять предложения (структуры русского и английского предложения отличаются)
• умение структурировать речь с помощью связующих слов (linking devices: e.g. firstly, secondly, finally, in addition, what concerns, etc.).

Хабр, привет!

Многие компании сегодня предложили своим сотрудникам работать из дома. Однако возможность трудиться удаленно есть не у всех. Часть специалистов не покидают свои боевые посты в офисных пространствах.

Команда Artezio решила разобраться, как можно построить работу в «смешанной» команде, которая одновременно трудится и дома, и в офисе. Мы написали этот текст на примере того, как выстроен подобный процесс внутри нашей компании. А ещё порассуждали о наболевшем об актуальном: какие есть плюсы и минусы в удалённой работе. 

Источник

Представьте, что вам надо разработать операционную систему, которую переведут на десятки языков, продадут миллиардным тиражом, дата выхода релиза уже публично объявлена самим Биллом Гейтсом. Одна незадача — ТЗ с полным списком функций и то, каким будет интерфейс новой Windows — этого не только нет, но и не будет почти до самого релиза. Вот она — суть Аджайл, не так ли?

Асхат Уразбаев был программистом, руководил IT-командами, но заинтересовался Agile и основал компанию ScrumTrek, которая помогает компаниям внедрять гибкие подходы.

Однажды в ScrumTrek за помощью обратилась компания с data science-продуктами. Казалось бы, работа понятна и схема отработана: рассказать, что такое Agile, собрать бэклог, запустить спринт — 3 дня работы. 3, не 3, но через 3 месяца точно что-то начнет получаться, а через 3 года вообще все будет отлично.

Оказалось, не так все просто.


87% data science-проектов никогда не попадают в прод. То есть не просто не укладываются в бюджеты и сроки, а вообще не доходят до использования в продакшене. Почему так происходит и как все-таки можно внедрить гибкие методологии в data science, Асхат Уразбаев рассказал на TeamLead Conf, а мы сделали из этого статью.

Друзья, привет!

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

За три года консультирования и тренерства, у разных людей, которые решают «начать работать по Канбану», я наблюдал одинаковые «этапы» изменения восприятия знания, через призму которых они выбирали ту или иную часть инструментария. В статье я кратко структурировал свои наблюдения, и, надеюсь, что этот обзор поможет вам чуть глубже понять всю мощь современного Канбана.



Если интересно — добро пожаловать под кат.

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

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

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

Я вернулась из NYC две недели назад с конференции Business Agility Conference, сейчас заканчивается мой двухнедельный карантин — есть время поделиться наблюдениями, как всё происходило в США и как у нас. А заодно, что стоит делать и чего не стоит с точки зрения Agile. Даже в случае пандемии такой инструмент может помочь — упорядочить мысли и действия. Чтобы не метаться бессмысленно, как курица с гречкой вместо головы — что в жизни, что в бизнесе.

Лично я продолжаю работать, минимизирую общение с паникёрами вокруг. Но в моем мире не всё хорошо и не всё спокойно, как раньше. Сейчас я, как военный врач, спасаю компании во время войны — я словно на военном поле спасаю раненых, работаю больше, чем раньше, словно на передовой. Да, я улыбаюсь, но не радуюсь, что появилось время на самореализацию, я стараюсь помочь спасти бизнес. В тексте не будет «ценных советов», как адаптировать обучение под онлайн — об этом все пишут, скукотища. То, что все бездумно в онлайн ударились — это как за туалетной бумагой в очередь выстроиться или за гречкой.

У меня за время путешествия между континентами сформировался чёткий план действий, которым я с удовольствием поделюсь с вами.

Мне «повезло» увидеть, как начался коронавирус в США — и только я вернулась в Россию, а здесь уже было продолжение. И могу поделиться, в чём разница.

Начало истории: я выступала на конференции в Нью-Йорке, на Business Agility Conference. Это крупнейшая конференция по Agile — проходила она 11-12 марта. Я была единственной русской. И вообще единственным иностранным спикером на сцене.

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

Манифест про манифесты

• В манифестах пишут очевидные вещи. Это одна из них.
• Предыдущий пункт — шутка про рекурсию.
• Прежде чем пользоваться советом из чужого манифеста, найди доказательства, что совет работает.
• Это касается и предыдущего пункта.
• Если в манифесте написано что-то правильное, это не означает что все пункты правильны.
• Если вы нашли в манифесте ошибку — он бесполезен.
• Предыдущий пункт — пример ошибки.
• Манифесты склонны становиться карго-культом.
• Добавьте по 1 очку культиста, за каждый непонятный вам пункт. Включая предыдущий и этот.
• Этот манифест подписали: Боб Мартин, Линус Товальдс и Дональд Кнут.
• Конечно, нет. Но если бы от этого манифест стал для вас более ценным, добавьте себе еще 2 очка культиста.
• Добавьте еще 5 очков.
• Если вы склонны объяснять вещи с конца и вас злит, что они не очевидны другим.
• Если вы не вели хотя-бы приблизительный подсчет очков, еще 3 очка штрафа.
• Посчитайте очки и сделайте выводы.

Готовил его специально к 1 апреля. А теперь, хочу пригласить вас обсудить манифесты.

На вопросы отвечал Павел Зыков, СТО DomClick.ru

ДомКлику скоро 5 лет. Давайте немного вспомним историю и заодно познакомимся. Компания была основана в 2015 году. Ты помнишь день, с которого все начиналось?

Еще как помню. Я входил в число основателей, поэтому помню все в мельчайших деталях – как собеседовали первых людей, как в августе 2015 года сняли первый офис на улице Рабочая, который устраивал нас по цене, несмотря на то, что подоконники кабинетов всегда были в пыли от проходящих рядом поездов. Сейчас, сидя в максимально комфортном Agile Home в 2 минутах от ст. метро Кутузовская, с теплотой вспоминаем о тех временах, когда два интернет — провайдера в здании считалось нашим уникальным преимуществом.

Тема OKR (Objectives and Key Results) сейчас становится все более популярной в бизнесе. Во многих компаниях рассматривают возможность внедрить у себя эту методологию. Мы в Wrike перешли на OKR в 2015 году, и на тот момент это была достаточно новая и малоизученная тема, по крайней мере в нашей стране. Теперь по прошествии нескольких лет кажется полезным рассказать о нашем опыте работы с OKR. И о наших ошибках, которых можно было бы избежать. Оценить общий результат, который мы получили от внедрения OKR в компании. Возможно, наш опыт окажется полезным для тех, кто задумывается о том, стоит ли переходить на OKR.

Есть замечательное приложение T-REC позволяющее трэкать время, потраченное на задачи в Youtrack, и записывающее его в таску. Но автор забросил его больше двух лет назад, плюс старые зависимости, постоянная загрузка одного ядра (тут видимо виноват electron) и периодические падения привели к тому, что пользоваться им стало «неудобно». Решил написать свой, с тем же функционалом, только на плюсах, так появился Honsu…

Сел я тут систему управления выбирать для нашего отдела. Мы – вторая линия техподдержки, закрываем косяки, которые не успели исправить наши разработчики. Помогаем клиентам настроить ПО для защищенного документооборота.

В отделе у нас 17 человек. Дела ведем в 1С, а вот системы управления для общения по задачам явно не хватает. Надоело, что все рабочие коммуникации ведутся в Telegram. Куда валится и важная информация, и мемасики. Зачастую — одновременно.

Задумался: как выбрать нормальную систему? Особых требований пока нет. Заглянул в обзоры – один пафос: «Помогаем бизнесу работать», «Увеличиваем эффективность», «Лучший инструмент для agile-команд».

Решил выбирать по отзывам. Уже другая картина, менее радужная: «Самая худшая техническая поддержка в мире», «Дикие тормоза» и т.п. В общем, почитал, что люди говорят, каталогизировал немножко.


Собрал и обобщил мнения по 8 системам управления. Начал с наименее известных, закончил самыми популярными. Разделил на два блока – что «заходит», а что бесит. Заодно и таблицу цен сделал в конце. Делюсь, вдруг кому-то пригодится. Ну а мы будем тестить и выбирать уже на деле всей командой.

Эффективность – красивое слово. Удобно вставлять его в фразы типа: "я работаю максимально эффективно", "нужно найти эффективное решение", "повышаем эффективность процессов", "наша цель – эффективный код", "Вася – эффективный менеджер". Но что конкретно при этом мы имеем в виду?

У слова "эффективный" есть два значения:

1. дающий эффект, действенный, позволяющий достичь желаемого результата, далее в тексте – результативный
2. оптимальный, позволяющий достичь желаемого результата с минимальными затратами, наименьшими нежелательными эффектами/ошибками, рентабельный, организованный, с высоким КПД, далее в тексте – производительный

В английском языке – это два разных слова: effective и efficient.

• Being effective is about doing the right things, while being efficient is about doing things right.

Различиям между этими словами посвятили свои работы многие теоретики и практики менеджмента. Давайте посмотрим, что писали по этому поводу Питер Друкер и Ицхак Адизес.

Стоп, хватит, уберите немедленно! Для того чтобы закрыть провалившийся проект, нужны две вещи: нужно понять, что проект провалился, и нужно его закрыть. Но не все так просто.

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

В стратегиях большинства компаний все чаще упоминается цифровизация: одни компании пытаются внедрять современные технологии (например, Big Data, IoT, AI, blockchain), другие — повсеместно автоматизируют свои внутренние процессы. Несмотря на растущие усилия и инвестиции во внедрение систем, многие считают результаты посредственными. В идеале современным организациям надо уметь быстро создавать новые цифровые продукты или интегрироваться с популярными сторонними сервисами; выводить процессы за пределы своей организации; уметь эффективно взаимодействовать с партнерами, сохраняя при этом обособленность своих процессов. Также надо уметь не только собирать данные, но и быстро получать к ним доступ и управлять ими. Тем не менее даже «зрелые» компании сталкиваются со сложностью преобразования и управления данными, с постоянной конкуренцией бизнес-приоритетов. Что же мешает им достичь совершенства? 

Опыт нашей команды DTG в создании цифровых продуктов и сервисов позволяет утверждать — решению перечисленных задач мешает проблема трех монолитов: монолита приложений, интеграционного монолита и монолита данных. Они являются результатом унаследованных парадигм традиционной архитектуры, культуры полагаться на имеющиеся данные и работать в «слоеной» системе, где обособленность IT-департамента и бизнеса ведет к потере данных и знаний о них. Решением же данной проблемы мы видим переход от традиционных подходов разработки и управления к распределенным, что предполагает серьезные технические и культурные изменения в организации.

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