Введение в Agile и Lean для SmartSourcing

Сегодня прошел вебинар, посвященный организации процессов разработки ПО (рассматривались подходы Lean и Agile). Вебинар стал рекордным: в пики нагрузки в он-лайне было 185 человек и редко в течение вебинара этот показатель опускался ниже 180.
Так же этот вебинар стал абсолютным рекордсменом по продолжительности: Никита непрерывно вещал в течение 2 часов (с учетом сессии ответов на вопросы).

Кстати, вопросы и ответы на них заслуживают отдельного внимания.

Предлагаем вам ознакомиться с записью и материалами вебинара.

AgileCamp'11 в Самаре - как это было

17-18 июня в прекрасном южном городе Самара, прямо на берегу Волги, с совершенно невероятным успехом прошла мини-конференция, организованная компанией ScrumTrek и посвященная практическим навыкам работы в Agile проектах - AgileCamp। Если вы, по какой-то причине, не смогли попасть на это мероприятие - читайте, смотрите фотографии и завидуйте тем, кто там был :)

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

Deep dive в мир Agile - это действительно то, что было нужно - ни единого теоретического доклада, только практические занятия по проектированию и разработке нового продукта с нуля: симуляция процесса разработки крупного продукта одновременно четырьмя командами, проектирование продукта с помощью innovation games (product box и vision canvas), анализ и проработка требований к продукту с использованием storymapping, проектирование интерфейса, анализ рисков - все эти практики каждый участник попробовал своими руками и готов начать применять в своих реальных проектах।

Инженерная секция так же получилась очень насыщенной - модульное тестирование, TDD, непрерывная интеграция с полной настройкой окружения с нуля, парное программирование и другие практики, интерес к которым буквально безвылазно держал около 50 разработчиков в зале все 8 часов первого дня конференции - вы когда-нибудь такое уже видели?

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

Попробуйте представить себе атмосферу небольших докладов (lightning talks) у флипчартов, стоящих на горячем песке островка на Волге, куда причалил корабль - при этом светит солнце, вокруг изумительная природа, люди сидят группами по интересам, пьют пиво и общаются - как вам? :)

Наверное, поэтому не стоит удивляться, что лента новостей в facebook уже вторую неделю после нашего кемпа каждый день показывает добавление десятков новых друзей - людей, которых объединил AgileCamp'11!

Присоединяйтесь к нам в Новосибирске, где пройдет следующий AgileCamp в первых числах ноября। На кораблике, конечно, зимой не поплавать, но что-то такое же необычное и интересное придумать обещаем!

Stay tuned! http://camp।agiledays.ru/

Команда ScrumTrek - ваш проводник в мире Agile процессов.

Usability Missunderstanding (IMHO)

Вообще конечно юзабилити это не про интерфейс.

Вообще, конечно, юзабилити это не про интерфейс . Нет вернее про него, но про интерфейс в последнюю очередь. (Капитан очевидность призывает Мистера Алана Куппера)

Это про то, как вы свой продукт делаете, не про иконки,css3, не про верстку, не про построение интерфейсов используя золотое сечение и так далее. Это про то, на сколько, вы понимаете, как живет %юзернейм в системе%. И вообще, кто этот %юзернейм%.

В большинстве своем люди, которые называют себя юзабилистами - это художники, которые рисуют хуже чем другие, поэтому решают "стать юзабилити/ux-чуваками"

Если вы хоть раз ходили на конференцию по юзабилити, то услышите там: «Разработчики вообще не понимают, как проектировать, мол, инженерам чуждо прекрасное». На самом деле - я видел много инженеров и менеджеров, которые проектируют лучше чем Юзабилити эксперты. Ибо юзабилити эксперт, это не тот, кто Купера почитал, а тот, кто знает как удобно, а для этого, нужно быть экспертом в контексте данного продукта. Юзабилистом может быть и тестер и аналитик или владелец бизнеса если это скажем стартап.

Юзабилити - это не результат, это процесс непрерывного взаимодействия ментальной модели заказчика и исполнителя. Да они сталкиваются на уровне интерфейса ну и что?

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

ScrumTrek starts SkillTrek: Краповые береты мира Agile-разработки

Друзья!
Хотим поделиться радостью. Мы запускаем первый поток проекта SkillTrek - дистанционной школы инженеров.

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

Формат сочетает в себе передачу знаний участникам и закрепление их тут же, в условиях реального проекта. Основной объем нагрузки приходится на технологическую часть (стек Java-технологий и современные инженерные практики Agile) и проектирование системы. Но мы ориентируемся не только на развитие технологических навыков, но и навыков командообразования, soft skills, коммуникативных способностей, эффективного управления временем.

Предстоящий летний проект ориентирован на прокачку основной массы участников с уровня Junior Java Developer до уровня Regular Java Developer. Но будут и ребята, тренирующиеся на архитекторов и тимлидов.
Формат первого летнего потока: дистанционный (практическая работа над проектом, теоретические вебинары, персональные консультации), загрузка 10 часов в неделю (по вечерам + пол-выходного), длительность проекта 4 месяца, объем практической работы над проектом не менее 60% времени.

Стартуем мы в в конце мая. Цена за весь курс 150 тыс. рублей, но первый пилотный поток мы делаем скидку в 50% на курс в 4 месяца. На выходе мы обязуемся сделать из вас твердостоящих на ногах Regular'ов (далее сеньоров), как говориться тяжело в учении - легко в бою.

Есть половина группы и если вам интересно поучаствовать пишите мне nfilippov@scrumtrek.ru. Cайт мы приземлим через недельку, а пока если есть вопросы по программе ее составу и графику пишите мне, я отвечу на все вопросы, кто наши тренера и так далее...

Переделки в тренинге по требованиям

Недавно практически полностью пересобрали тренинг по управлению требованию в Agile.

Включили туда новую часть по Product Vision и Release Vision, вкрутили туда Innovation Games,добавили туда новые технические детали по работе с UserStories.

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

Vision has changed!

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

И вроде бы все "по Agile'у" и бэклог вместе собрали, и демонстрации делаем и на ретроспективах рефлексируем и планы выполняем. Но потом оказывается демонстрации сделали, показали, но не тому :), - забыли заказчика, потеряли еще одной заинтересованное лицо.
...или неожиданно заказчик начинает заваливать вас тоннами новых идей, хотя 70% от нового скоупа идеалогически не предполагалось. В чем проблема?

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

16 апреля мы ездили в Киев на конференцию Agile BaseCamp и выступали с небольшим мастер-классом о том, как разрабатывать концепцию проекта коллективно и эффективно. Сам процесс мы обозвали Vision Crafting, он включает определенные практики организации коллективной работы над созданием концепции, основанные на создание бизнес моделей Alex'a Osterwalder'a, подходов Customer Development и нашего личного опыта работы с внутренней / продуктовой разработкой.

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

Ниже небольшое видео и слайды с данного мастер-класса.

Vision Crafting

View more presentations from Nfilippov.

Ссылка на шаблон Inhouse Vision Canvas (eng)

Product Owner превращается в Scrum Master?

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

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

Последнее время что-то сдвигается. Менеджеры понимают, что такое supportive leadership. То ли общий тренд, а может Саша Орлов так влияет :-)

Очень часто последнее время наблюдаю такую картину:

Есть менеджер проекта - который вроде как формально Product Owner. В команде есть Scrum Master. В общем, все по науке. Только скрам-мастер выполняет свои функции номинально: он рисует burndown charts, следит за доской задач. Он даже проводит ретроспективы - в смысле стоит у флипчарта и записывает то, что говорит команда.

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

Самое интересно, что и Product Owner из него тоже в общем-то нетипичный. Он старательно дистанцируется от самостоятельного принятия решений. Чаще всего он старается собрать всех заказчиков в группу и проводит встречу, заказчики коллективно договариваются о приоритетах и требованиях. Как правило, он устанавливает некоторую каденцию общения (уж простите термин, не удержался) - например, назначает еженедельные встречи. Забавно, но он точно также вкладывается в то, чтобы команда заказчиков стала эффективной, как и в команду разработчиков.

Если отбросить тонкости, то он становится скрам-мастером команды заказчиков и команды разработчиков, формально таковым не являясь.

Такая схема на практике часто является очень эффективной.

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

В общем, вопрос открытый! Может быть создать особую разновидность скрама? :-)