AgileDays 2015

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.

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

Я расскажу базовые вещи о ценностях и принципах Agile, на основе которых развиваются современные Agile-методологии Scrum и Kanban. Мы рассмотрим вопрос, почему появилась гибкая разработка (на Западе и у нас), чем она отличается от традиционного подхода к разработке программного обеспечения и почему итеративные методологии стали фактически стандартом дефакто в софтверном мире.

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

Также будет затронута тема внедрения Agile и типичные проблемы, с которыми приходится сталкиваться на этом пути.

В докладе обсуждается как внедрить техники автоматизированного тестирования программного обеспечения с использованием технологий Behaviour driven development в традиционные процессы производства программного обеспечения в системообразующей финансовой организации. Речь пойдет об экономии денег, о повышении качества продуктов и об использовании технологий. Из доклада можно узнать как продать идею руководству, как поставить цели для участников процесса, как сделать первые шаги и как отслеживать прогресс.

На нескольких примерах расскажу про то, как мы двигали ИТ подразделения очень крупных финансовых компаний в сторону Agile. Что работало хорошо, с какими проблемами сталкивались и какие выводы из этого сделали.

Вне зависимости от того, в какой компании вы работаете (внутренняя разработка, продуктовая, аутсорс), общие паттерны внедрения процессных изменений могут показаться вам полезными.

Я расскажу о практике применения серверов Continios Integration для внедрения практик релиз-менеджмента в SCRUM командах разработки, специализирующихся на платформе 1С:Предприятие. Поговорим о способах замера и анализа ошибок и предупреждений компиляции, о расчете покрытия кода тестами, о расчете цикломатической сложности и конечно о «качестве кода» и соответствии его стандартам разработки. Все примеры будут показаны на стандартных для этого компонентах -Jenkins + Plugins, istanbul & etc.

В книжках мы читаем красочные описания того, как здорово живется в мире agile. Как все делается вовремя, никто не отвлекает от интересной работы, никто не требует на скорую руку воздвигнуть пирамиду Хеопса с костылями в качестве основного строительного материала. На тренингах нам даже удается попробовать и поверить в то, что все это работает и достижимо в рамках отдельно взятой реальности. А потом мы возвращаемся на свои рабочие места и... Ну, вы и сами прекрасно знаете, как оно бывает потом. Внедрение Agile - это не просто изменение процессов. Это - изменение культуры.

Это - новая глава в истории компании. Это - изменение отношения к бизнесу. И многие из вас были свидетелями колоссального сопротивления и напряжения, сопутствующего этим изменениям. Не важно, кто вы при этом - CEO, технический директор, Agile-коуч. Высокое сопротивление и колоссальное напряжение - это ваша среда. И вы в этой среде - Трансформатор. Как быть Трансформатором? Какие знания, умения и навыки позволяют совершать изменения? Мешают ли сопротивление и напряжение на самом деле? Как не перегореть в этом поле? Об этом я расскажу в своем выступлении.

Scrum, Kanban, XP или любой другой известный гибкий фреймворк/метод: для вашей команды уже давно не является чем-то новым. Многие многие месяцы вы регулярно проводите стендапы; ваши ретроспективы все так же интересны и эффективны; непрерывная интеграция и поставка - это что-то само собой разумеющееся; коллективное владение кодом, парная работа, ревью и стандарты кодирования - это, как чистить зубы по утрам. В общем, если вы уже давно и серьезно следуете не только букве, но и духу Agile, то может быть пришло время задуматься о чем-то большем? Как насчет того, чтобы сделать следующий заметный шаг по направлению к настоящей гибкости?

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

В современном мире разработки ПО мы не можем себе позволить такую роскошь как выделенное время на тестирование. Но при этом мы должны обеспечить своевременную поставку качественного продукта.
Чтобы этого добиться мы строим процессы, основанные на принципе нераздельности (параллельности) процессов разработки и тестирования. В своем докладе я расскажу о процессе, в котором нет стадии тестирования, о том, как нам удалось сделать тестирование абсолютно незаметным, но при этом только выиграть в качестве продукта.

Два года назад мы оказались в необычной ситуации. У нас большой и сложный проект (CAD система), несколько команд разработчиков, полный Agile (SCRUM), мы практикуем Test Driven Development, то есть пишем много unit тестов. И тут возникает казалось бы невозможная проблема: в конце спринта нет стабильной сборки, новый функционал работает, а старый отваливается.

Почему так произошло? Почему unit тестирование нас не спасло? Что делать в такой ситуации? Столкнувшись с этой проблемой мы выработали решение, которое до сих пор работает на проекте и все участники считают его одним из ключевых факторов успеха проекта.

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

Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering). Но развитие не остановилось. Непонимание места конкретных подходов, методологий и практик в контексте общего развития отрасли системе не позволяет эффективно их использовать и порождает множество пустых дискуссий среди разработчиков о том, как правильно.

За время доклада мы рассмотрим основные вехи развития подходов к управлению ИТ-проектами и эволюцию критериев качества ПО в мире и в России, которая в 90-х годах шла своим путем, но за последнее время приблизилась к общим трендам. А также разберемся, для каких проектов и команд уместны те или иные модели управления проектами, в чем могут крыться их преимущества и недостатки и какие формы организации разработки им соответствуют. Понимание этого позволит не только настраивать процессы в своем проекте, но и вести содержательные дискуссии с приверженцами иных форм организации, которые часто встречаются среди заказчиков и руководства.

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

Давайте раз и навсегда поставим в этой проблеме точку и разложим всё по полочкам.

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

- Как сбалансировать сроки и объем проекта?

- Как найти ответственного, если никто не в теме?

- Как менять команду: увольнять или оставить? - Что делать с перспективными сотрудниками?

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

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

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

Данный рассчитан на опытных Agile-практиков и коачей, которые имеют на своем минимум несколько внедрений Agile-методов и Agile-трансформаций компаний или отдельных подразделений.

Ваши проекты всегда выполнялись в срок? У пользователей никогда не возникало претензий? Сопровождение сданных проектов не было трудоемким? Новый функционал всегда удачно вписывался в существующую архитектуру?

Если ответы на все вышеперечисленные вопросы положительны, то вам не нужно ничего менять, ваша команда - пример редкой гармонии персонала, методологии и инструментария. В противном случае вы должны быть открыты для новых подходов к решению ваших задач, в том числе и к критическому взгляду на используемые технические средства и языки программирования.
В докладе на простых примерах дается представление о том, чем отличается моделирование предметной области и реализация функционала при использовании функциональных языков - таких, как F#, Scala и Clojure, в сравнении с объектно-ориентированными C# и Java. Какие типы задач наиболее подходят для функциональных языков? Как их лучше внедрять в проект? И как убедить руководство в практичности такого выборы? Обо всем этом пойдет речь в докладе.

Как выбрать наиболее подходящий вариант реализации продукта имеющий максимальный отклик у клиентов. Как вообще суметь подойти к решению одной проблемы с разных точек зрения.

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

Многие agile-команды используют в своей работе user story. Это отличный и простой в понимании инструмент. Однако, как это часто бывает, нельзя просто так взять и применить инструмент и сразу добиться нужного результата: фичи, которые были придуманы почему-то оказываются не нужны пользователям. Но не потому, что они (фичи) плохо реализованы, а потому, что эти фичи не удовлетворяют пользовательским потребностям.
В докладе я расскажу про инструмент под названием «дизайн история». Это user story на UX-стероидах, другой взгляд на привычный для многих инструмент. Мы поговорим о том, на основании чего создавать дизайн историю (точнее, как модифицировать user story). И самое главное, как эту историю использовать в дальнейшем, как на основании ее генерировать идеи и фичи для реализации.

Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах. Все удачные (прижившиеся в командах) решения он по старой-доброй традиции фиксировал в своем блокноте, который теперь носил имя UX на службе у Agile.

Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:

• как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
• как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
• как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
• как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич.Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
• как можно использовать любимый многими impact map для проработки целей пользователя;
• как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.

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

На основе собственного опыта создания рабочих групп, проектов, практик, а также преподавания в ВУЗе и интернатуре IT-компании, расскажу своё видение ответов на следующие вопросы.

• Что самое важное в обучении и почему.
• Чему и как надо учить людей приходящих в IT индустрию.
• Возможно ли научить чего-то хотеть и хотеть сильно?
• Чем отличается обучение и работа и как их состыковать.
• В чём отличие образование «западного» и российского.
• Как организовать эффективную систему обучения в компании.
  

Работая в интернет-индустрии, мы очень много знаем о процессе разработки, запуска, развития наших продуктов. И очень мало — о том, что предшествует созданию продукта, то есть — о появлении Идеи. Действительно ли успешный продукт можно создать только «под себя» (как это делают стартапы) или взяв уже доказанную модель? Можно ли придумывать идеи «на заказ», систематически? И как выбрать самые интересные, перспективные идеи?

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

Что внутри этого «черного ящика»? 

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

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

• Особая культура
• Автоматизация
• Изменения через измерения
• Распространение знаний и практик

В основе всего лежит культура. Что это за культура? Я расскажу о различных типах корпоративных культур, о том, как они влияют на IT.

• Почему важно фокусироваться не на технологиях и инструментах, а на человеческих ценностях?
• Как определить текущую корпоративную культуру в вашей компании?
• Какие ценности лежат в основе культуры DevOps?
• С чего начать культурные изменения?
• Как преодолевать сопротивление коллег и руководства?

Верещак Святослав автор публикаций и вебинаров, DevOps консультант в компании «Экспресс 42», мы меняем культуру внутри компаний, внедряем DevOps практики и инструменты. Прошел путь от технической поддержки до руководителя эксплуатации интернет проектов.

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

Здесь мы собрали ключевые тренды в архитектуре корпоративных систем – что нас ждет в ближайшем будущем. Эти тренды мы хорошо чувствуем по нашим заказчикам и доклад включает кейсы – реальные истории клиентов и трансформации их систем в соответствии с трендами.

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

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

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

Чеклиcты используются повсеместно. Ими пользуются врачи, строители, экономисты и многие другие, включая IT. Какими чеклисты бывают, как их писать эффективно, где их хранить удобно для всей команды - обо всем этом и поговорим. А еще будем много говорить про тестировщиков и их любовь к тест кейсам :) Нужно ли тратить так много времени? как сократить время и при этом не упустить тесты? Что показать заказчику, если не кейсы с шагами? Доклад для всех-всех-всех

В конце каждого спринта мы с коллегами идем на ретроспективу: обсуждаем что хорошо, что плохо, что оставить, что изменить, а что чуть-чуть улучшить. Но что делать, если надо продуктом работает уже не одна команда? Вроде бы и улучшения есть, а целиком системой производства никто не занимается. Опять локальные улучшения, будь они неладны! На помощь призывается межкомандная ретроспектива. На докладе я расскажу о нашем опыте проведения такой ретроспективы: как готовили, и чем подготовка ретроспективы на 30 человек отличается от того же, но для 7и, на что обратили внимание, а на что нет и во что это вылилось, к чему нужно было быть готовым во время проведения и как мы решали проблемы по ходу, какие выводы сделали.

Классики жанра учили нас, что тестирование и обеспечение качества подразумевает кипу документации.

Разработчики и тестировщики хотят подробное ТЗ.

А реалии бизнеса ожидают гибкость и мгновенную скорость реакции.

Где найти грань? Как обеспечить процесс? Как найти время на автоматизацию и юнит-тесты?

Как найти идеальное соотношение между фундаментальным процессом и проворным процессом?

Одно из значительных достоинств Agile в том, что он позволяет делать самое значимое из того, что заложено в бэклог. Но даже если мы делаем только самое значимое, и делаем это сопровождая ретроспективами, TDD, процедурами качества кода, может получиться, что продукт не будет ценным для бизнеса и не будет отвечать целям пользователя. Дело в том, что клиент не знает хорошо ли то что он просит, пока он это не попробует. Подход, называемый Dual-track Agile, еще до значительных инвестиций в разработку поможет понять, что же на самом деле нужно и полезно, измерить пользу, изменить начальные идеи на лучшие и совершенно неожиданные. В докладе вы увидите несколько кейсов применения этого подхода на реальном продукте в Лаборатории Касперского, а также, как значительно влияют на бизнес-результаты продуктовые «пивоты» и MVP.

В то время, как agile подходы ориентированы на получение полезного результата (value) в условиях возможных изменений требований и в определенных рамках проекта, бизнес-архитектура предлагает выстраивать сети или цепочки создания ценности и отслеживать, какое влияние оказывают изменения в рамках одного проекта на смежные проекты и операционную деятельность. Таким образом происходит прозрачное и естественное встраивание agile проектов в видение, цели, задачи, бизнес-модель и в целом контекст всей организации.
При этом, распространяя данный подход на несколько проектов, мы получаем возможность демонстрировать итерационно создаваемую ценность для определенных бизнес-компетенций и целых бизнес-направлений.

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

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

Расскажу как мы используем вместе множество инструментов и практик: trello, basecamp, доски, багтрекер, timetracker, yaware, slack и skype. Devops, ретро, коллективная оценка, уровни сервиса, предсказуемая поставка, личная ответственность, pull вместо push, отсутствие руководителей и приемка. И как мы планируем улучшаться дальше.

Менеджерские школы учат, как готовить проекты правильно. А реальность говорит про 30% успешного завершения проектов. Чувствуете проблему?

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

Почему хорошие agile практики не приносят ожидаемого результата в разработке корпоративного продукта? Как их все-таки заставить работать? Почему нужно меньше верить аналитике, как тратить меньше времени на реализацию ненужного? Если и у вас есть эти вопросы - вам будет интересно услышать об опыте борьбы за качественные корпоративные продукты в Лаборатории Касперского.

В докладе будет рассмотрена совместная работа продакт и сервис-менеджеров с бизнес-подразделениями (и/или конечным заказчиком) и экспертными командами над созданием продуктов и сервисов: от идеи до планирования доставки. Какие основные роли должны быть обозначены? Что делать, если компетенции по созданию концепта «распределены» между разными участниками, и никто в полной мере не владеет бизнес-логикой заказчика? Какие компетенции нужны для успешного управления концептом? Как найти правильного продакт оунера, и должен ли это быть один человек? Как быть с запросами бизнес-подразделений и требованием к скорости их реализации? Как построить совместную операционную работу день за днем, когда стартует новый продукт или сервис?

Визуализация - основной практический инструмент Lean, Agile, TOC и прочих современных подходов к разработке программного обеспечения. Например, Task board отображает процесс разработки, помогая понять статус работ и заметить возможные проблемы, а Burndown отображает прогресс по обязательствам спринта, помогая реагировать на риски отставания. Такие инструменты визуализации применяют команды в конкретных проектах, но применима ли визуализация на уровне целой компании? Я расскажу о визуализации на основе Microsoft Team Foundation Server, которая помогает согласовать возможности разработки, ожидания бизнеса и стратегию компании - разработчика программного обеспечения, ведущей 50 проектов по развитию 20 продуктов.

Вы внедрили Scrum в своей команде и пользуетесь лишь несколькими его инструментами, так как остальные вам не подходят? Или, может быть, вы следуете всем принципам, но классический стиль проведения ретроспективы приелся и вы не можете извлечь из неё пользу? Хотите получить реальные проверенные рецепты проведения ретроспективы и узнать, как она может влиять на рабочий процесс?
Моя команда прошла через все возможные этапы внедрения Scrum, вплоть до желания отказаться от него.
Изначально процесс внедрения Scrum был под постоянным контролем со стороны руководства, самостоятельности команды не было, а многие принципы Scrum не поддерживались. С течением времени Scrum модифицировался еще больше, и в конечном итоге следование ему стало утомительным и трудозатратным, новые идеи не появлялись, инициатива стремилась к нулю. Это была самая низкая точка, казалось, что Scrum просто не работает для нас. А нас уже было много 2 команды из 12 человек.
Как Scrum-мастера, меня всё это очень сильно беспокоило, было понимание, что нужно с этим что-то делать, но не было понимания, что именно. Я прошла обучение на курсе Certified Agile Professional, и это стало отправной точкой глобальных перемен.
Было сложно, честно, но всё получилось. Улучшилась атмосфера в команде. Менеджеры проектов планируют с уверенностью в том, что всё будет сделано в срок. Развились коммуникации внутри команды, раскрылись самые интровертные программисты. Команда стала самоорганизующейся, а Scrum-мастер перестал быть локомотивом, тянущим за собой команду. Команда сама поддерживает соблюдение Scrum.
Всё это было достигнуто во многом благодаря ретроспективам, не классическим ретроспективам, не простому подведению итогов спринта, а продуктивным таким, которые становятся двигателем прогресса, стимулируют инициативу и рождение новых идей.

Какие возникают ассоциации с ретро? Скорее всего «Давайте вспомним, что было хорошо? Что плохо? Как улучшить процесс?»

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

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

В начале 2011го года компания Skype купила небольшой стартап под названием Qik. На тот момент в компании Skype был официальный процесс на базе SCRUM. Вышло так, что после перехода на этот процесс, команда Qik сильно потеряла в скорости поставки. В своём докладе я расскажу, что именно произошло, и как следование правилам Scrum мешало команде быстро и качественно разрабатывать свой продукт.

Мы у себя в организации часто сталкиваемся с ситуациями, когда надо делать оценку сразу на весь проект. Как правило, применяем экспертную оценку с указанием 90%-го доверительного интервала. Это позволяет заложить в проект буфер на неопределенность. Ключевая проблема этого метода в том, что эксперты излишне сужают интервалы, а времени на их обучение (калибровку) не хватает. Анализ данных по оценкам подсказал идею по решению этой проблемы. Цель доклада рассказать об этой идее и результатах ее пилотирования в наших проектах.

На докладе постараюсь ответить на следующие вопросы: - Что делать, если в компании или команде есть ярые противники Agile? - Что делать, если никто ничего не хочет менять в процессах проекта, отдела, компании? - Как не «внедряя Agile» привнести Agile принципы и практики в проект?