Agile *

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

Лучше зажечь одну свечку, чем проклинать темноту.

За последние 24 часа, две мои статьи «Почему ваш программист просто хочет кодировать» и «Менеджерам пора проснуться» прочитаны более 96 000 раз на Medium и получили более 900 комментариев на Reddit.

Похоже, проблема серьёзнее, чем я думал.

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

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

Кажется, что гештальт подход в психотерапии и гибкие методологии разработки очень близки. Это статья — попытка развернуть эту мысль, имея в виду читателей habra. Что такое agile здесь должно быть понятно, а вот что такое психотерапия вообще и гештальт-подход в частности наверняка требует пояснения. Разобравшись с тем и другим, можно посмотреть на знакомые вещи под новым углом и, как всегда, что-нибудь понять про себя, про мир и ещё что-нибудь.

Disclaimer: Статья Мартина Фаулера была опубликована в 2003 году

в журнале IEEE Software. В сети (но не на Хабре) есть замечательный перевод пятилетней давности от Сергея Теплякова (SergeyT).

Недавно я встретил в коридоре явно раздраженного коллегу, Дэйва Райса (Dave Rice). Мой вводный вопрос вызвал резкое заявление: «Нам надо игнорировать любого кандидата, имеющего пункт «Архитектор» в резюме». Смущало в этой странной фразе то, что мы же сами, обычно, представляем Дейва как одного из наших ведущих архитекторов.

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

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

Предисловие

Данная статья очень субъективна и основана на моём опыте в ИТ-индустрии (Я разработчик с 10-и летним стажем и опытом работы в различных проектах, командах и странах (Казахстан, Канада)). Уверен, что многие не поддержат мою точку зрения и могут назвать эту статью «плачем динозвара», но всё-же хочу поделиться ею…

Что такое DevOps

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

С моей точки зрения основная задача DevOps — снижение затрат для бизнеса (что хорошо, но часто это идёт в ущерб качеству продукта).

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

Мотивация в команде упала. Заказчики в растерянности от того, что предполагаемые «волшебные» сроки не сбываются, и вообще заявляют, что Agile не место в приличном обществе. В результате маленькая группка «Agile-трансформаторов» села и устроила мозговой штурм, почему же у нас ничего не выходит? Начали выписывать любые мешающие нам ограничения. Их оказалось очень много, и мы назвали их драконами.

Приветствую, коллеги. Сегодня я хочу поделиться с вами своей мечтой.

Я работаю в сфере разработки ПО примерно 12 лет. За это время я сменил более 10 организаций. Были только два места, где я задержался надолго — на 3 и 5 (привет, Валера) лет, а в остальных компаниях я отработал от двух до восьми месяцев.

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

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



Под катом — полный драматизма рассказ о попытке внедрения гибкой методологии управления в крупной enterprise-компании.

Да много где: Омск, Томск, Красноярск, Барнаул и, конечно, столица Сибири — Новосибирск, где ежегодно проходит крутейшая за Уралом ИТ-конференция CodeFest.

Каждый год на CodeFest слетаются 1500—2000 айтишников, обеспечивая тем самым всю туристическую выручку Новосибирска на несколько месяцев вперёд.

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

Используя термин Agile, люди часто имеют в виду не что-то конкретное, но то что они правы. Например, не написал тесты — не Agile, не провел митинг с командой — не Agile, не заполнил тайм-трекинг — опять не Agile. Тому, что каждый трактует термин Agile по-своему, есть объективные причины, связанные с его происхождением.

22 и 23 марта в Москве в Центре Международной Торговли состоится конференция AgileDays’18. В этом году она проводится 12-й раз. В очередной раз докажем, что наша конференция самая крутая по тематике Agile в России и Восточной Европе!

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

Этот вводный текст мы пишем почти каждый год. А теперь о том, что новенького ожидается в этом году.

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

Где можно в это втянуться и набрать критическую массу знаний молодому разработчику? В Java-школе Райффайзенбанка: здесь быстро всему научат, расскажут, покажут, да ещё и заплатят.

Что из себя представляет наша Java-школа? Это трехмесячная оплачиваемая стажировка в одном из крупнейших банков России для студентов последних курсов бакалавриата и магистров. В короткие сроки вы научитесь работать в команде по методологии SCRUM, получите/отточите свои навыки в Enterprise девелопменте, повысите ораторские способности, споткнетесь обо все подводные камни командной работы над одним проектом с применением систем контроля версий и поспорите с командой, что же лучше, GIT или Subversion.


Далее — рассказ очевидца. Из первых, так сказать, рук.

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

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

• на ретро тратили по 2 часа и сильно выматывались
• обсуждения периодически уходили в затяжные бесполезные споры
• некоторые мелкие проблемы не успевали решить и постоянно переносили на следующее ретро
• отдельным членам команды надоедали ретроспективы из-за однообразия

Первую и вторую проблему мы считали данностью, что делать с третьей не понимали, а о последней я даже не знал.

Прошлой весной я сходил на Okademy от ScrumTrek. Это обширный курс, включающий в себя много полезного для скрам-мастера, но для меня самым полезным оказалась часть о том, как эффективнее проводить ретроспективы. Хочу рассказать, как это нам помогло.

В конце декабря на площадке Райффайзенбанка состоялся Рождественский Agile MeetUp. В предновогоднем настроении участники поговорили о том, сколько нужно программистов, чтобы оценить фичу, развеяли мифы об Agile и трансформации, и, конечно, затронули больную тему дедлайнов. О том, как это было, читайте под катом.

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

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

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

В таких условиях у разработчика есть два пути: продолжать терпеть или брать инициативу в свои руки.

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

Генеральные цели перехода на #Ускорение4X мы обсудили. Теперь нужно сделать еще более важную штуку — учесть цели каждого участника команды. Мы же ускоряемся сами для себя, а не для начальника.

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

Итак, зачем кастомизировать цели? Вроде нормально они звучат — ускориться, научиться работать на форсаже, научиться переводить на форсаж.

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

Такое сплошь и рядом есть во всех компаниях, от всех собственников и менеджеров. Что они там обычно говорят? Давайте увеличим продажи вдвое! Наша цель — войти в список Forbes! Мы хотим через 5 лет выйти на IPO! Наша цель — 5 новых продуктов через год! Ну и т.д. Еще там непонятные миссии добавляются,ценности сейчас модно стало писать, и подобную ересь.

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

Все, вступления закончились, начинаем изучать практические приемы, из которых состоит #Ускорение4X.

Если вы — тот человек, который берется за внедрение #Ускорения4X в команде, то первый шаг придется сделать вам.

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

Я постараюсь объяснить цели, и дам пример согласования — его можно использовать в качестве подсказки. А можно не использовать, главное — результат. Но разговаривать с людьми придется вам. Не лишним будет всем дать ссылку на эту публикацию — если переживаете за свое красноречие.