AgileDays

The patterns & practices group has the reputation of being early adopters of agile methods at Microsoft. With his insight and enthusiasm, Grigori will take you through his personal journey from the times when agile methods were only known as light-weight. He will give you a taste of his team’s agile process, challenges they faced and present lessons learnt from several projects. He’ll discuss the topics of customer-connectedness, agile planning, dealing with distribution, and others. He’ll also share his thoughts on the impact of economic frugality on agile adoption.

Капитан Очевидность: Многим известен управленческий фреймворк Scrum, уже ставший стандартом де-факто в IT-индустрии.

Однако есть одно очень важное упущение.
Абсолютно все, с кем мне приходилось общаться на тему особенностей Scrum не смогли дать полного ответа на вопрос: Почему Такеути и Нонака, для названия своей методики выбрали такой регбийный термин?

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

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

Из доклада вы узнаете:

• Правила игры Регби и их масштабирование на проектную деятельность;
• Чем игрок первой линии отличается от крайнего трехчетвертного и что такое кросс-функциональность верстальщика;
• Как полузащитник схватки может привести проект к успешному релизу;
• Почему после 20 спринтов сложно положить попытку;
• Что общего между «огнетушителем» и противоречивыми требованиями;
• Какие практики международного союза Регби заимствовал наш департамент разработки;
• В чем сила Регби для бизнеса.

Итак, вы прочитали про Agile и у вас загорелись глаза. Вы хотите работать по Scrum. Однако одному Agile не внедрить. Вам нужно убедить заказчика, начальника и коллег. Каждый день с горящими глазами вы рассказываете им по Scrum и Agile, но вот беда - в какой то момент они могут начать вас избегать :-)

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

The time has come to once again shift our focus away from process to products and people. Ten years into the agile movement, the original ideals around lightweight process are gaining weight and calcifying in dangerous ways. More and more people spend time talking about “doing agile” instead of simply using agile methods to their advantage. Where meaningful and lasting agility thrives, agile practices are powerful tools, but they are not the focus of daily discussion. Is companies where rich value flows, development agility augments design thinking to continually learn and discover your product context: the users, their use, and the market. From design thinking to lean start-ups to the value of simple checklists, David Hussman challenges you to stop focusing on improving your process and start focusing on improving your product, or “that thing you produce”. Come ready to think, question and rethink your use of agile practices.

Участвуя в различных дискуссиях, посвященных процессам разработки ПО можно заметить, что Scrum постоянно находится в центре внимания, вызывая множество споров и обсуждений.

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

Один из наиболее интересных вопросов, обсуждающийся IT-сообществом - кем становится сегодня самая одиозная личность в Scrum – Scrum-Мастер! Должен ли он обладать выраженными техническими скилами или, напротив, они ему не нужны, в то время как без коуч-скилов ему никак не обойтись? Какие метаморфозы претерпевает эта роль, когда мы используем наиболее успешный «тендем» - Scrum+XP?

Have you noticed that similar stories appear over and over again as you develop a system? According to Dan Rawsthorne, stories—those small chunks of work that make up your backlog and provide demonstrable value to the project—can be categorized by purpose as: Production, Analysis, Cleanup, Infrastructure/Environment, Business Support, or Other. Within each of these categories are different "storyotypes"—patterns that define the commonalities among the stories themselves. Dan defines and describes some of the most prevalent storyotypes, explains why they are useful, and demonstrates the concept with examples. These examples include "Alternate Path" and "Clean-Up Interface" for the production category, "Talk to Stakeholders" and "Exploratory Testing" for the analysis category, among others. For each storyotype, Dan provides sample tasks and canonical "doneness" criteria that make planning and backlog grooming easier and more consistent. By employing storyotypes in developing your stories, your team will produce more consistent, higher quality requirements that are easier to work with.

Lean-разработка, система Kanban, Scrumban - все эти слова всё чаще звучат на специализированных конференециях и вебинарах. Изначально появившаяся в недрах "Тойоты" система производства с успехом перекочевала в мир разработки программного обеспечения.

Какие преимущества может дать эта системы вашей компании? Что же такое Lean? Как команда разработчиков может использовать в своей деятельности принципы Kanban? Как можно скрестить Scrum с Kanban и что получится? С чего начинать?

Алексей Корсун, agile-тренер и консультант по управлению проектами, проведёт обзор этих систем, а также расскажет о месте этих инструментов в структуре управления.

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

• Мой вид сверху на вопрос ответственности.
• Что значит быть настоящей леди?
• Перемены и боязнь перемен.
• Нелегкий путь к ответственности в нашем подсознании (Avery)
• Как разрабатывается софт?
• Кто ответсвтенный за то и за это?
• Ты не знаешь, чего ты не знаешь.
• Как же решить все проблемы в корне в три нелегких шага?

Release planning in larger settings (12-15 teams) is not part of the basic, Scrum-based Agile methodology. Further, there is no higher level intermediate event on the timeline between the iterations and the release date. Dean Leffingwell has established a method to solve these issues in his book Scaling Software Agility: Best Practices for Large Enterprise. Dean has been consulting and facilitating these joint release planning events for a high-priority project at F-Secure. Based on his method the F-Secure teams have further developed the method providing novel concepts not covered in Dean’s methodology.

The method is based on multiple layers of abstraction in all key dimensions of the project: content, time and organization. In this presentation we’ll explain these layers of abstraction, i.e., story, feature and epic in the content dimension, iteration, business iteration and release project in the time dimension and the individual, team and project team in the project organization dimension. Then we’ll elaborate on the relations of these to manage the project. Then we’ll explain the release planning method based on our experience with large scale (12-15 teams) and smaller scale (2-3 teams) settings where up to 140 people spend 2-3 days together in one space off-site in a joint planning event to prepare for the next “business iteration”, the time horizon relevant for the business managers. Finally we’ll explain the new concepts that the F-Secure teams have developed to enhance the joint planning method.

Где и как закладывается архитектура решений разрабатываемых c участием нескольких Agile команд? Зачем нужны Архитекторы и какова их роль в Agile проектах? Какие существуют принципы Agile архитектуры? Как собирать, анализировать и реализовывать идеи и требования влияющих на архитектуру? Что такое и зачем нужна "Архи-ВВП" (Architecture runway)? Эти и другие вопросы будут обсуждаться в данном докладе.

Весь мой предыдущий опыт управления agile проектами базировался на одном из главных принципов SCRUM, озвученном Кеном Швабером еще в 2001 году - команда должна базироваться в одном месте, или, говоря его языком, "be collocated".

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

В своем докладе я расскажу о том, как трансформируются паттерны SCRUM для работы с распределенной командой. Для этого мы еще раз посмотрим на стандартный жизненный цикл agile проекта, начиная с фазы планирования релиза и заканчивая maintenance фазой и передачей готового продукта заказчику. Поскольку наш проект еще только находится в стадии развития (на данный момент мы находимся в середине первого релиза), в качестве примеров я также буду ссылаться на успешный проект Sirsi-Dynix, выполнявшейся в нашей компании 5 лет назад, а также на опыт компании IBM, описанный в книге 'A practical guide for distributed agile project management'.

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

Из доклада Вы узнаете:

• команда какого размера наиболее оптимальна для проектов по разработке ПО;
• какие методы разработки ПО наиболее часто используются и какую долю занимают Agile методы;
• с какими главными проблемами встречаются участники процесса создания ПО;
• насколько распределенные проекты являются более опасными, чем локальные;
• и, наконец, ответ на главный вопрос - какова доля успешных проектов на территории постсоветского пространства.

Выполнение agile проектов с корпоративным заказчиком, слабо знакомым или незнакомым с agile, имеет ряд характерных особенностей. В результате практического опыта работы над рядом SCRUM проектов с таким заказчиком определены основные ‘тонкие места’, которые целесообразно учитывать при кастомизации agile для подобных ситуаций:

• Корпоративный не-agile заказчик, как правило, хочет оценки всего проекта до его начала
• Заказчик не способен самостоятельно определять Пользовательские истории
• Заказчик хочет отслеживать ход выполнения проекта в терминах классических функциональных спецификаций, а не по Product Backlog’у
• Процессы на стороне заказчика достаточно строго определены, но плохо стыкуются с agile методологиями
• Заказчик требует поддерживать актуальную документацию по архитектуре проекта
• Сложное фиксированное окружение заказчика накладывает множество ограничений на выбор технологий, библиотек, версий
• Выполняемый проект необходимо согласовывать с другими проектами заказчика, выполняемыми не по agile
• Психологически участники команды на стороне заказчика не готовы менять привычные методы работы
• Взаимодействие с внешними системами заказчика требует большого количество Технических историй, не имеющих хорошего графического проявления
• Процесс внесения изменений в agile стиле конфликтует с фиксированным бюджетом
• Быстрый и независимый темп разработки требует написания множества эмуляторов и соответствующих историй
• У заказчика недостаточно времени для полноценного участия в Играх в планирование, standup’ах и т.п.
• Множество политических моментов конфликтуют с требованиями agile разработки
• Процесс deployment’а на стороне заказчика очень долог и трудозатратен

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

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

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

В традиционно используемой модели контрактной работы в Agile проектах, Time and Material, заказчик может видеть результат и вносить изменения в любой момент и просто оплачивает усилия по выполнению этого запроса. Но особенно в последние несколько лет даже крупные компании тяготеют к лучшей предсказуемости и стабильности бюджета и ищут возможность заключения Fixed Price контрактов, при этом не желая терять все преимущества контроля и вовлеченности предлагаемые гибкими методологиями разработки ПО.

Exigen Services является первопроходцем в комбинации Agile методологий, взаимодействии сфокусированом на заказчике и Fixed Price контрактной модели. Это предложение позволяет заказчикам менять требования по ходу разработки не меняя изначального бюджета или расписания проекта, в то же время получая наиболее приоритетную с точки зрения бизнеса функциональность.

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

Работая с Fixed Price Agile проектами, мы обнаружили, что если структура Пульса построена до фактической разработки, то есть во время высокоуровневой оценки и определения границ проекта, то это позволяет повысить точность оценки стоимости и объема работ для таких контрактов, причем в данном случае точность оценки на ранних этапах (до оценки Спринта) является наиболее критической частью проекта.

В данном докладе я опишу подход к построению структуры Пульса а так же использованию ее для оценки в Fixed Price Agile проектах, как она может помочь в прояснению дополнительных расходов которые могут влиять на проект. Также через эту структуру можно проследить насколько выгодно обучение в процессе и работа с объемами, что позволяет определить цену проекта на ранних стадиях, которая достаточно точна и привлекательна как для заказчика так и для исполнителя заказа по разработке ПО.

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

"Don't change Scrum!" говорят нам гуру и лукавят конечно. "Скрам, бла-бла-блам, мне виднее, как мою программу писать" говорит программист Вася и тоже не прав.

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

На опыте команды покажем куда нас может завести процесс адаптации Скрама и рассмотрим полезные наработки сработавшие в суровых реалиях fuck-up разработки.

При проведении практических исследований ни один программист серьёзно не пострадал.

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

Общее стремление одновременно повысить скорость и качество разработки, приводит к тому, что специалисты в области UX и UI всё чаще включаются в agile-команды. Как лучше устроить процесс с этом случае. Что следует проектировать сначала, что можно проектировать независимо и что можно отложить на будущие итерации без страха получить несочленимые компоненты. Как без ущерба разделить то, что, по определению, должно быть целостным.

В докладе освещены методологии, применяемые командами в Adaptive Path, Autodesk и компании докладчика. Автор доклада — проектировщик интерфейса и консультант, входящий в продуктовую команду, разрабатывающую преимущественно веб-сервисы в области интернет-рекламы.

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

Редизайн портала произведен с привлечением профессиональных дизайнеров, полностью переработана структура навигации, расстояние между элементами контента не превышает 4-х кликов… Но пользователей стало меньше на 30%.

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

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

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

Год назад мы начали внедрять Kanban, который выглядел как самая простая из существующих Agile практик. В теории. На практике мы столкнулись с массой подводных камней, и убедились, что для успешного внедрения нужно менять культуру организации в целом, используя философию Kaizen и Lean.

Основной фокус данного доклада будет посвящен реальному опыту внедрения тех или иных практик.

• Зачем, и с какой целью, мы решили внедрять Kanban.
• Как выглядит процесс тестирования (встроенного качества) в Kanban.
• В каком формате мы проводим daily stand up meeting с Kanban.
• Hansei, poka-yoke, Cumulative flow diagram (CFD), Lead and Cycle Time, WIP, Stop the Line, 5Whys, etc - wtf!? Чем вообще отличается Lean oт Kaizen?!
• Постараюсь ответить на вопрос почему практики, которые так хорошо приживаются в Японии, могут потерпеть неудачи у нас.
• Как Lean проникает в культуру организации ни только в разработке, но и на бытовом уровне