Agile *

Это слова Михаила Быченкова – генерального директора отеля «Порто Маре», который первым в мире начал Agile-трансформацию в гостиничном бизнесе.

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

Работая по 14 часов в день, мы точно психи. Изменим ли мир – покажет время. Но мы «горим» на работе. Честно: забываем нормально спать, есть. Наш чат гудит, как улей. Видели бы вы, насколько активно общаются спикеры и студенты в чате. На часах второй час ночи, но никто не расходится. Знаете, почему? Интересно всем: бизнесу, IT и организаторам.

Так проходят наши Ретро.

Давайте представим себе гипотетическую ситауацию (в которой мы регулярно оказываемся). Вас назначили на проект «запилить» автоматизацию. Вам дают огромный тест план с большим количеством (тысячи их!) «ручных» тестов, и говорят что надо что-то сделать, и вотпрямщас. А еще, чтоб быстро и стабильно.

Писать Unit тесты, или даже думать о TDD — уже поздно, код продукта давным-давно написан. Ваше слово, товарищ автотестер!



К счастью, есть небольшой трюк, который позволит и coverage повысить, и сделать тесты стабильными и быстрыми — Subcutaneous tests («подкожные тесты»), но обо всем по порядку.

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

Есть полно исследований, демонстрирующих эффективность 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?!!! В чём дело?!

10 лет назад у молодого и зеленого менеджера проекта случился удачный опыт внедрения чего-то похожего на скрам в одной из страховых компании. Энтузиазма хоть отбавляй. Коллеги айтишники всячески поддерживали. Помогало программистское прошлое. Но в какой-то момент появилась непробиваемая стена: Agile подход работал внутри ИТ, но со скрипом воспринимался вне няшного айти пространства. Нужна была синхронизация с другими отделами и смена уклада работы всей компании. Тогда полноценный переход не случился, но год назад удалось воплотить Agile трансформацию на другом проекте в финансовой организации с вовлечением более 100 человек. Возможно ли такое в природе?

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

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

Mobius bike — это сервис по прокату велосипедов и самокатов, разработанный для Таллина (на данный момент запланировано расширение географии).

Гипотеза первого релиза — «приложение по прокату велосипедов, будет востребовано на рынке Европы». В декабре 2019 была пересмотрена основная гипотеза и теперь она звучала так — «может ли сервис по прокату велосипедов и самокатов получить максимальное распространение за счет удобства для конечного пользователя и франчайзи?» Для того, чтобы ответить на этот вопрос, нужно было реализовать следующее:

• провести работы по оптимизации структуры приложения (как внутренней — backend, так и внешней — дизайн и frontend) для внедрения нового типа транспорта и возможного масштабирования в будущем
• сделать условия аренды регулируемыми в админке

Любовь Никифорук — менеджер проекта

Ключевые экраны приложения Mobius bike до редизайна

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

Привет, хабровчане! В этот внеочередной выходной день выходного месяца, хотим поделиться с вами интересной статьей, которая была переведена в преддверии старта курса «Team Lead 2.0».

---

Разработчикам нужна обратная связь, чтобы они могли совершенствовать навыки и получать новые знания. По словам редактора Inc. Magazine, Джеффа Хейдена, традиционные показатели могут быть обманчивы, поскольку они не всегда отражают четкую картину. Раньше оценка работы персонала представлялась сложной задачей, именно потому появились инструменты Git Analytics, такие как Waydev. Этот инструмент предлагает подход к разработке на основе данных, чтобы помочь вам выявить лучшее в своих сотрудниках.

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

Мы расскажем вам об алгоритме, который поможет оценить эффективность работы программистов:

Дисклеймер: Внимание, это не статья, а скорее тема для дискуссии в комментариях, если кому-то такая проблематика интересна!
Не уверен, зайдёт ли здесь такой формат, но попытка не пытка :)

Итак, сама мысль:

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

И если вы пытаетесь создать «фреймворк», предугадав и предсоздав и покрыв им все возможные нюансы и активности, то вы сажаете росток в банку или клетку. Дерево в этом фреймворке всегда вырастет точно по фреймворку, но это будет изломанный, сгорбленный уродец.

Работаем с рисками на глобальном уровне

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

Перевод статьи подготовлен в преддверии старта курса «Agile Project Manager в IT».

---

Когда я только начинал свою карьеру, программное обеспечение поставлялось в коробках. Если для вас это звучит странно, знайте, что, когда я был ребенком, мой отец приносил домой перфокарты, на которых программы записывались в 1970-х. У такого программного обеспечения было конечное состояние. Через 20 лет с того момента это уже казалось нелепым. Сегодня же мы создаем системы, которые можно совершенствовать бесконечно. Отсюда возникает вопрос: «Когда работа заканчивается?» — и на этот вопрос сложно дать ответ. Мы ищем ответ на этот вопрос, потому что он поможет нам дать ответ на другие, еще более важные вопросы. Получит команда свою премию или ее отчитают? Будет ли команда заниматься чем-то новым? Получит ли стейкхолдер свою выгоду?

Команды разработчиков, которые используют Scrum (или любую другую вариацию методологии Agile), имеют четкое представление о том, когда заканчивается разработка. Часто под этим подразумевается «набор минимальных критериев, которыми должен обладать продукт/услуга для удовлетворения потребностей бизнеса». В результате все сводится к списку функций, который утверждается стейкхолдером (или product owner’ом) и на момент завершения проекта должен быть полностью выполнен. Разработчики зовут это «работает, как было задумано».

Недавно я подсчитала, что за несколько лет работы в роли Скрам Мастера я провела более 100 ретроспектив в Agile-командах. О важности ретроспективы и том, как она отражает ситуацию в команде и влияет на ее развитие, хочу поговорить в этой статье.

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

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

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

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

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

Источник

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

Во вторник, 28 апреля в 20:00 мск открывается «Вечерняя школа Слёрма по Аджайл»: Как сберечь бизнес во время кризиса за счёт перехода на Аджайл.

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

На людей обрушивается пятерная доза стресса:

• от перехода на удаленную работу;
• от снижения зарплаты;
• от самоизоляции;
• от перехода на Аджайл;
• от тревожного настоящего и неизвестного будущего.

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

Курс «Вечерняя школа Слёрма по Аджайл» призван помочь владельцам бизнеса, управленцам и скрам-мастерам знаниями и советами. Мы будем еженедельно разбирать, как сберечь и усилить команду, как находить свое место на постоянно меняющемся рынке и наращивать продуктивность.

Курс открытый, участие в нем бесплатное. Мы проводим его для помощи, а не для заработка.

Как ваша организация внедряет accountability? Является ли она ценным заявлением вашей организации или частью корпоративной культуры? Большинство компаний и руководителей, с которыми я работал (по методологии Agile или нет) не очень хорошо справляются с accountability. В подавляющем большинстве они либо слишком снисходительны (то есть редко возлагают на людей ответственность за их действия или бездействие), либо слишком сильно все контролируют (то есть людям в команде не дают шанса продемонстрировать свою причастность).

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

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

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


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

Ну что, как там ваши планы на изоляцию? Зимние вещи убрали? Желанные киношки посмотрели? Пылящиеся книжки прочитали? А до полезностей, как всегда, нет времени. Да ладно, не оправдывайтесь — для тех, кто никак не выкроит часок для просмотра видео с нашего канала на Ютубе, мы сделали быстроусвояемую статью. Имейте совесть, всего-то 15 минут вместо 60:)


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