Пару недель назад в Москве прошла AgileDays-2015 — самая крупная в РФ конференция по современным методам управления в разработке.
- Два дня, пять треков, огромные залы московского Центра Международной Торговли (не путать с WTC).
- Темы:
- Agile-менеджмент — от высокоуровнего управления разработкой в неповоротливых компаниях-монстрах, до «бережливого старта» в стартапах.
- Продуктовый аспект — как не только правильно разрабатывать, а творить именно нужное и правильное.
- Специфические вопросы процессов и технологий — тестирование и бизнес-анализ, юзабилити и проектирование.
- Современные архитектурные практики — *DD, и даже немного о функциональном программировании.
Вращаясь в «продвинутых» кругах часто кажется, что Agile-подходы уже «захватили весь мир», и хватит уже говорить о понятном и общеизвестном. Но в реальной жизни, все конечно гораздо запущенней — есть успешная когорта «early adopters», и как видно в широко известной картинке «дилеммы инноватора», далее идет большая пропасть, и либо те, кто совсем не в курсе, либо кому про Agile «все понятно, ибо сосед-Рабинович напел». Это видно даже по ряду недавних публикаций на мегамозге. Поэтому реальный, и даже не всегда успешный, опыт от тех, кто в теме и нашел и все грабли, и кучу ништяков — очень полезен, и гораздо более актуален, чем даже книги, как правило уже устаревающие к моменту публикации. Докладчики — не евангелисты, а практики, из крупных компаний и стартапов, хотя да, были и консультанты, рассказывающие о «сгибании несгибаемого» — типа аджайлизации банков.
Там было круто — вы многое пропустили, если вас там не было. Но. Видеозаписи и прочие материалы докладов публикуются и будут доступны всем. Запись моя, добротная, все как обычно — монтаж, несколько камер, экран, звук с микрофона, технологии оживления.
И я, как член программного комитета, заботящийся о том, чтобы докладчики донесли свои знания до всех заинтересованных, попробую сделать серию публикаций, включающих и видео доклада, аннотации и слайды, и мой очень краткий постобзор. Слона надо есть по частям — еще готово не все видео, смонтированное надо еще отсмотреть и отрефлексировать, да и большие статьи отпугивают своим объемом и читателей и писателей — стыдно признаться, что я, за несколько заходов, но так и не смог дописать за год эпический обзор 72 видеодокладов с прошлого AgileDays-2014, а обзор 2011 осилил только через полгода. Конечно же, обзор Agile-конференции надо делать итеративно, максимально быстро отгружая value потребителям. И, как принято в Agile, возможно даже прекратить поставки, если продукт не понравится пользователям…
Итак, смотрите и решайте — такой формат ОК или нет…
Основы Agile
Данный доклад предназначен для тех, кто только начинает изучать гибкие методы разработки программного обеспечения, которые обычно называют Agile.
Я расскажу базовые вещи о ценностях и принципах Agile, на основе которых развиваются современные Agile-методологии Scrum и Kanban. Мы рассмотрим вопрос, почему появилась гибкая разработка (на Западе и у нас), чем она отличается от традиционного подхода к разработке программного обеспечения и почему итеративные методологии стали фактически стандартом дефакто в софтверном мире.
В дополнение к управленческим практикам мы добавим инженерные практики из экстремального программирования, и поймем поймем почему без гибкой архитектуры не бывает гибкой разработки.
Также будет затронута тема внедрения Agile и типичные проблемы, с которыми приходится сталкиваться на этом пути.
Каждая конференция AgileDays всегда включала в себя краткое введение в Agile-разработку, некий crash course, с одной стороны для тех, кто оказался внезапно совсем неподготовленным, с другой — помогающий правильно уложить в голове даже известное. Кстати, эти введения всегда были популярны, несмотря на то, что их пускали в параллель с ключевыми и приглашенными гуру, и эти доклады всегда были добротны — рассказывали о них те, кто на аджайле «крокодила сьел, собакой закусил».
Борис Вольфсон явно имеет на это право, ибо написал книгу, аджайлизировал несколько крупных компаний, и вообще выглядит солидно.
Впрочем, можно посмотреть более короткое прошлогоднее введение или даже сравнить с введением 2011-года.
Основы есть основы, пересказывать глупо, но в некотором смысле, продолжением этого «Agile 101» курса, был следующий доклад Бориса…
Построение собственного Agile-фреймворка в рамках компании
Данный доклад предназначен для тех, кто только начинает изучать гибкие методы разработки программного обеспечения, которые обычно называют Agile.
Я расскажу базовые вещи о ценностях и принципах Agile, на основе которых развиваются современные Agile-методологии Scrum и Kanban. Мы рассмотрим вопрос, почему появилась гибкая разработка (на Западе и у нас), чем она отличается от традиционного подхода к разработке программного обеспечения и почему итеративные методологии стали фактически стандартом дефакто в софтверном мире.
В дополнение к управленческим практикам мы добавим инженерные практики из экстремального программирования, и поймем поймем почему без гибкой архитектуры не бывает гибкой разработки.
Также будет затронута тема внедрения Agile и типичные проблемы, с которыми приходится сталкиваться на этом пути.
Тут уже продвинутый Agile-курс для тех, кто уже в теме, и кому точно надо, чтобы все работало, внедрилось в компанию, местами адаптировавшись под существующие процессы и технологии, а местами — неизбежно адаптировав культуру и оргструктуру. Тут уже не только заповеди Agile-манифеста и простые гигиенические правила Scrum/Kanban, тут все это рассматривается и в контексте новомодных Lean-фреймворков продуктового управления, рассказывается и об инженерных Agile-практиках, и о менеджерских аспектах изменений — теории игры и лидерство. Разумеется, в конце много вопросов от тех, кто реально «пошел в бой за аджайл» в своих компаниях и ответы гуру на непростые вопросы («а-а-а, что делать с закостенелыми компаниями?…» — «Убеждать заказчика. Или работать как он хочет.»).
Кстати, Борис есть и на мегамозге, так что если доклады понравились, можно поблагодарить понятным образом. :) И у меня есть еще докладов Бориса, рекомендую.
Развитие управления проектами и критериев качества в ИТ
Это отличное продолжение тему «гуру о истории, философии и культуре Agile», от широко известного в узких кругах Максима «Гендальфа» Цепкова.
Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей.
Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР.
Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки.
А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).
Но развитие не остановилось.
Непонимание места конкретных подходов, методологий и практик в контексте общего развития отрасли системе не позволяет эффективно их использовать и порождает множество пустых дискуссий среди разработчиков о том, как правильно.
За время доклада мы рассмотрим основные вехи развития подходов к управлению ИТ-проектами и эволюцию критериев качества ПО в мире и в России, которая в 90-х годах шла своим путем, но за последнее время приблизилась к общим трендам. А также разберемся, для каких проектов и команд уместны те или иные модели управления проектами, в чем могут крыться их преимущества и недостатки и какие формы организации разработки им соответствуют. Понимание этого позволит не только настраивать процессы в своем проекте, но и вести содержательные дискуссии с приверженцами иных форм организации, которые часто встречаются среди заказчиков и руководства.
Если на прошлом AgileDays Максим рассказывал о фантастических концепциях Спиральной Динамики, то в этот раз все достаточно исторично и научно.
История разработки, от времен промышленных НИОКРов, через мир «человеко-месяца Брукса», к взлету и окончательному падению waterfallа, от «eXtreme Programming», как отчаянного и провалившегося бунта программистов, к вполне работающим менеджерским SCRUM-ам. Все это Agile-движение вполне обосновано, и не могло не появится, по куче причин — и «Природа IT не терпит пустоты мешает процедурам ©», и дороговизне классического масштабирования с кучей менеджеров-сержантов (не говоря уже о идеальных дико дорогих PMBOK-менеджерах, которых исчезающе мало), и изменчивости природы IT-разработки — «пока мы наступаем противник меняет ландшафт ©»… Ну и вообще, сейчас «вменяемые разработчики не идут в бюрократизированные конторы ©».
Будущее туманно, возможно там OMG «омайгот!» Essence от SEMAT, где вырубают старые концепции на уровне слов (вычищают все упоминания «проекта»), в глоссарии же сплошные «stakeholder-ы» и «opportunity», но … «стандартописатели не успевают за развитием отрасли — они тоже старые ©».
Российский путь к Agile, в некотором смысле простой, ибо к нему шли не «от бунта на заводе», как на западе, а в основном от «научной культуры» разорившихся НИИ, давших старт российской IT-индустрии. Мне было приятно, что Максим цитировал мою рецензию на «Культуры программных проектов»
А поспорить с Максимом можно в его посте с отзывом о конференции.
Это что еще за Dual-track Agile?
Одно из значительных достоинств Agile в том, что он позволяет делать самое значимое из того, что заложено в бэклог.
Но даже если мы делаем только самое значимое, и делаем это сопровождая ретроспективами, TDD, процедурами качества кода, может получиться, что продукт не будет ценным для бизнеса и не будет отвечать целям пользователя. Дело в том, что клиент не знает хорошо ли то что он просит, пока он это не попробует.
Подход, называемый Dual-track Agile, еще до значительных инвестиций в разработку поможет понять, что же на самом деле нужно и полезно, измерить пользу, изменить начальные идеи на лучшие и совершенно неожиданные.
В докладе вы увидите несколько кейсов применения этого подхода на реальном продукте в Лаборатории Касперского, а также, как значительно влияют на бизнес-результаты продуктовые «пивоты» и MVP.
В докладе Илья Кузнецов сходу дерзко наехал на Agile, что он де, поставляя эффективные процессы «как делать быстро и эффективно», совсем не задумывается о том, что надо в первую очередь «делать правильный продукт». Вероятно, это был такой полемический прием, ибо прифигела и аудитория, даже пытавшаясь спорить с докладчиком, и члены программного комитета («WAT? Что он несет? Кто его пустил? Кто ревьювил его доклад?»). Ведь труѣ-Agile именно про то, чтобы делать нужное и правильное, и выигрыш всегда происходит именно от более точного попадания в цель, а экономия — именно на деприоритезации неважного, а то, о чем он рассказывал — по сути «Product Discovery», известные продуктовые практики из Agile и Lean подходов.
Но соглашусь, для тех, у кого Agile ассоциируется с выученными в режиме «не думай, делай так» за час Scrum & Kanban, действительно может сложится впечатление, что как-то о продукте-то и забыли, и об этом полезно напомнить.
По сути, это был пересказ, с некоторыми вариациями, его же доклада «Разрыв шаблона — Lean Product Management и MVP в большой компании» с SECR-2014, с теми же кейсами («баг инсталлятора в триальном антивирусе» и т.п.), те же гибкие практики Lean Startup-а, симбиотично прорастающие внутри жесткой махины огромной компании. В любом случае, доклад отличный, бодрый, с хорошими оценками (его SECR-овская версия вообще заняла первое место), рекомендую к просмотру. Немного правда жаль, что такие таланты и силы тратятся на антивирусный бизнес «торговли страхом».
Если тема оказалась близка, в догонку предлагаю и другие доклады Ильи + [1], и более более сотни докладов по управлению продуктами
Три ключевых навыка успешной Agile-команды
На нескольких примерах расскажу про то, как мы двигали ИТ подразделения очень крупных финансовых компаний в сторону Agile.
Что работало хорошо, с какими проблемами сталкивались и какие выводы из этого сделали.
Вне зависимости от того, в какой компании вы работаете (внутренняя разработка, продуктовая, аутсорс), общие паттерны внедрения процессных изменений могут показаться вам полезными.
Дмитрий Лобасев известный консультант, с долгим опытом «аджайлизации и канбанизации» инхаус-разработки в крупных банках, как раз по сути оппонирует Илье из предыдущего доклада, напоминая об основных принципах Agile — удовлетворенность потребителя и заказчика.
Что тут нельзя механически делать то, что бизнес-небожители спускают с Олимпа своих уровней в трюм к разработчикам, надо пытаться взлететь, или хотя бы подпрыгнуть в сторону стейкхолдеров и пользователей, узнать, что им важно, как это должно выглядеть, и даже, как с казано — «в понятие современной разработки входит консультирование заказчика на тему, что ему на самом деле нужно, и как это сделать правильно ©». Разумеется, рассмотрено и множество других вопросов, все в очень живой манере, оценка по анкетам и мобильному приложению — 4.5, рекомендуем.
Я, трансформатор
В книжках мы читаем красочные описания того, как здорово живется в мире agile. Как все делается вовремя, никто не отвлекает от интересной работы, никто не требует на скорую руку воздвигнуть пирамиду Хеопса с костылями в качестве основного строительного материала.
На тренингах нам даже удается попробовать и поверить в то, что все это работает и достижимо в рамках отдельно взятой реальности. А потом мы возвращаемся на свои рабочие места и… Ну, вы и сами прекрасно знаете, как оно бывает потом. Внедрение Agile — это не просто изменение процессов. Это — изменение культуры.
Это — новая глава в истории компании. Это — изменение отношения к бизнесу. И многие из вас были свидетелями колоссального сопротивления и напряжения, сопутствующего этим изменениям. Не важно, кто вы при этом — CEO, технический директор, Agile-коуч. Высокое сопротивление и колоссальное напряжение — это ваша среда.
И вы в этой среде — Трансформатор. Как быть Трансформатором? Какие знания, умения и навыки позволяют совершать изменения? Мешают ли сопротивление и напряжение на самом деле? Как не перегореть в этом поле? Об этом я расскажу в своем выступлении.
Максим Гапонов, с 1001 историей штатного корпоративного пастора-псайкера, всю жизнь евангелизирующего язычников и Agile-еретиков в крупных компаниях. От техник боевого православного НЛП («прогрев… выход на режим… контакт… постконтакт…»), до эзотерики — карты Таро cпиральная динамика и всего такого. В кулуарах кстати, злые языки даже предлагали измерять аджайл-псайкер-силу в гапонах.
Название доклада вызывает электротехнические метафоры… и да, не зря — ибо профессиональный риск, там именно такой — перегореть («я устал, я мухожук ©»). Автор перегорал уже четыре раза, профессиональный рецепт Феникса — главное не дать сгореть дотла.
Пикрелейтед:
Почему юнит тесты не работают
Два года назад мы оказались в необычной ситуации. У нас большой и сложный проект (CAD система), несколько команд разработчиков, полный Agile (SCRUM), мы практикуем Test Driven Development, то есть пишем много unit тестов.
И тут возникает казалось бы невозможная проблема: в конце спринта нет стабильной сборки, новый функционал работает, а старый отваливается.
- Почему так произошло?
- Почему unit тестирование нас не спасло?
- Что делать в такой ситуации?
Столкнувшись с этой проблемой мы выработали решение, которое до сих пор работает на проекте и все участники считают его одним из ключевых факторов успеха проекта.
Хотите узнать нашу историю избавления от страданий?
Доклад рассчитан на широкую аудиорию, поэтому буду рассказывать о сложных вещах простым языком, с картинками, так, чтобы было понятно всем. Рассматриваемые в докладе проблемы и решения носят универсальный характер и могут применяться в большинстве программных проектов. Обещаю, будет интересно.
Александр Мартюшев, постоянный докладчик AgileDays в этот раз рассказал что TDD — отстой и не работает, шутка. Работает конечно, но в многолетнем эпичном проекте с GUI, таком как CAD-система, которая должна пережить смену кучи технологий и фреймворков, важнее сделать гибкую платформу, и сконцентироваться именно на интеграционных тестах, включая GUI-тестирование. Чтобы оно было нехрупким, разумеется, классическим индусским подходом с записями экранных макросов TestComplete, задачу не осилить, нужна и гибкая GUI-платформа, и написании в ее основе визуальных тестов. Так собственно делают много кто, точно помню, что так разрабатывается и тестируется Netbeans, и ряд менее известных продуктов. Но задача эта не только техническая, а, как всегда, скорее социотехническая, чтобы донести необходимость написания автоматических тестов до разработчиков и поддерживать «зеленый статус» несломанной сборки.
Developing the Agile Mindset for Organizational Agility
Agile development methods continue to gain popularity with the increasing pace of change in today's global business environment.
Modern automated tool suites enable collaboration and rapid software solutions delivery in response to emerging priorities. However, as organizations embark on agile transformations, many fail to harness the full potential of agile because they focus on process change while neglecting the underlying agile values and principles.
This presentation emphasizes the importance of adopting an agile mindset and highlights the organizational paradigm shifts and commitment to continuous learning that are essential for sustainable agility.
Разумеется, нельзя не выложить в первую итерацию и keynote приглашенного зарубежного гуру. Доклад на английском (из русского доклачица успела выучить только «Spaciba»), и я его еще не успел посмотреть, буду еще делать версию с русским синхронным переводом. Так что пока — посмотрите его сами, если все ОК с английским.
Как UX-специалист делился своими инструментами с agile-командами
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку. И Семен решил попробовать Сначала на своей команде, а потом и на кошках, то есть на знакомых командах. Все удачные (прижившиеся в командах) решения он по старой-доброй традиции фиксировал в своем блокноте, который теперь носил имя UX на службе у Agile.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
- как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Да, Agile — это еще и юзабилити. Впрочем юзабилисты такие юзабилисты — изначально доклад назывался «Семен из back», как будто кто-то в реальном мире помнит про доклад автора на AgileDays-2013. И это юзабилити-увлечение «персонами», когда о понятных вещах надо рассказывать с помощью специального «персонажа», Семена, очевидного альтер-эго автора, но упоминаемого в третьем лице. Неужели и личной жизни юзабилисты видят окружающих «персонажами»? Бррр. Что-то в этом есть от классического западного стендап-выступления чревовещателя с куклой, подкидываю идею спикерам для будущих докладов.
А вещи рассказывались правильные — как в Agile-разработке, юзабилист должен проявить активность, и не дожидаясь санкции отделов маркетинга внедрять непосредственно в команду разработчиков современные инструменты юзабилити и бизнес-анализа — User Story Map, Customer Journey, карты эмпатии, диаграммы Кано…
Доклад отлично принят, «фдисятке», и вообще, Никита Ефимов известный спикер, по ссылке еще десяток его докладов.
Также рекомендуем в догонку более подробные доклады про Customer Journey, Кано-анализ, и Impact Mapping, да и вообще сотню докладов по юзабилити.
А нам-то зачем функциональное программирование?
- Ваши проекты всегда выполнялись в срок?
- У пользователей никогда не возникало претензий?
- Сопровождение сданных проектов не было трудоемким?
- Новый функционал всегда удачно вписывался в существующую архитектуру?
Если ответы на все вышеперечисленные вопросы положительны, то вам не нужно ничего менять, ваша команда — пример редкой гармонии персонала, методологии и инструментария. В противном случае вы должны быть открыты для новых подходов к решению ваших задач, в том числе и к критическому взгляду на используемые технические средства и языки программирования.
В докладе на простых примерах дается представление о том, чем отличается моделирование предметной области и реализация функционала при использовании функциональных языков — таких, как F#, Scala и Clojure, в сравнении с объектно-ориентированными C# и Java.
- Какие типы задач наиболее подходят для функциональных языков?
- Как их лучше внедрять в проект?
- И как убедить руководство в практичности такого выборы?
- Обо всем этом пойдет речь в докладе.
Если кто-то подумал, что на конференции было только менеджерское «blah-blah-blah», то вот, пример вполне технического доклада — функциональное программирование, монады, и вот это все, от Вагифа Абилова, уже не в первый раз прилетающего из Осло на AgileDays — в прошлом году рассказывал об автоматическом тестировании и TDD.
На докладе игрались с «Жизнью Конвея», крутили F#, пытались вкурить монады… казалось бы, зачем функциональное программирование в аджайле и вообще в реальном мире, как пишут злые языки, не смотревшие доклад.
С одной стороны, причины архитектурные — функциональная реализация дает и распараллеливание и гибкость, компактность и верифицируемость. С другой — функциональные спецификации часто могут использоваться, благодаря компактности и мощности, как предметные DSL-языки для спецификации бизнес-логики, или тестов приложения, и кто знает, может быть будущие бизнес-аналитики уже будут не только двигать квадратики мышью в Visio, но и смогут писать целостные функциональные спецификации, либо тестирующие, то, что накодят программисты, либо вовсе, выключая программистов из процесса.
Так что, несмотря на вроде бы некоторое несоответствие теме конференции, доклад был отлично принят, зал пел с докладчикам гимны Монадам, и доклад получил пятое место среди всех. Обсудить же доклад с автором в соответствующем блогпосте.
Да, в этом году у нас было к сожалению меньше технических докладов, ибо часть наших традиционных экспертов по инженерным практикам не приехала с Украины, часть — перешли в менеджмент и вовсе открыли собственные компании — да, в России старых программистов почти не бывает, признается только менеджерская карьера. Или нет?
Посмотрите и — технологические практики прошлогодние доклады по технологическим Agile-практикам, и может попробуете что-то новое и интересное рассказать на следующих AgileDays — мы будем ждать.
Итак, пока все, очень ждем ваших просмотров и комментариев.
Можно комментировать здесь, или в своих блогах и сбрасывать сюда, или, если вы это читаете, а на мегамозге не зарегистрированы (а комментов тут обычно как-то маловато) — по ссылке «допматериалы» есть где комментировать обычным Discus-ом.
Ибо осмысленный фидбек — штука очень ценная и для авторов, и для программного комитета — мы обязательно все учтем, чтобы следующую конференцию сделать лучше. По ссылкам вы также найдете контакты докладчиков, и сможете обсудить заинтересовавшие моменты непосредственно с ними.
Видео пока бета-версии — возможны ошибки и проблемы (пропал звук, или нужен слайд на полный экран, чтобы рассмотреть мелкий текст) — если вы видите такое, плиз, сообщайте тоже. Ибо все это пока можно поправить. Вернее даже такие проблемы точно сейчас есть, сам нашел пару, интересно, найдете ли вы их быстрее, чем я их исправлю. Также, я раздумываю — может для совсем занятых менеджеров, сделать для нетехнических докладов аудиозаписи, ускоренные на 70% (для гуманитарных докладов, где на слайдах некритичная инфа, большую часть информации можно прослушать, а скорость дает бодрость и экономию времени)?
Ну и от вашей активности конечно зависит, стоит ли продолжать поставку продукта «AgileDays» на мегамозг, или… стоит репивотится и заняться чем-то другим.
Если же наоборот «мало!, давайте еще и быстрей!» — вот более сотни докладов по Agile с прошедших конференций, тут появляются изначально доклады с AgileDays-2015, причем можно подписаться по RSS.
Автор: belonesox
