Вчера прочитал интересную статью на тему применения гибких методологий в контексте аутсорсинга от Алексея Кривицкого и в большинстве пунктов поддерживаю сказанное автором. Попытаюсь сформулировать свои наблюдения на эту тему из собственной практики.
Обычно люди не хотят меняться. Им очень нравится оставаться в своей зоне комфорта, даже если нахождение в ней не приносит позитивных результатов. Меняться и пробовать что-то новое сопряжено с рисками и требует дополнительных усилий и вложений. Поэтому проще всего найти оправдания почему мы НЕ МОЖЕМ МЕНЯТЬСЯ. В мире аутсорсинга таким оправданием становятся фразы наподобие: “никто на нашем рынке так не работает”, “клиент никогда не пойдет на такой способ работы”, “гибкие методологии неприменимы в нашем контексте”, “у нас нет вообще доступа к заказчику”…
Это третья и моя любимая часть серии статей со сравнительным анализом классического PM и Agile менеджера. Напомню, что в первой части мы рассмотрели базовые определения и обязанности, которые лежат в основе работы классического PM. Во второй части речь шла об управлении объемом работ (scope management). Пришло время коснуться технологического вопроса.
Большая часть классического менеджмента со всеми практиками и подходами строится на Теории X, утрированная версия которой гласит, что люди по умолчанию не любят работать, очень неорганизованы и не стремятся делать свою работу хорошо и вовлекаться в процесс достижения конечной ценности. Отсюда берется необходимость в отчетности, координации, мотивации, контроле, командовании и прочих “ценностях” классического менеджмента. При чем тут технологии? Да при том, что на них просто не остается времени. Нужно столько всего другого “полезного” знать и уметь, что не до технологий.
(далее…)
Это вторая статья из цикла сравнительного анализа классического PM и менеджера в Agile. В первой части мы рассмотрели базовые определения и обязанности, которые лежат в основе работы классического PM. Вторая часть будет посвящена управлению объемом работ (scope management). Это одна из областей, где задачи и мышление Agile менеджера сильно отличаются. Давайте разбираться.
Agile подходы пропагандируют своего рода минимализм как искусство достигать цели минимальными затратами и не делать лишнего. Поэтому в Agile мире так популярны концепции MVP (Minimum Viable/Valuable Product) и MMP (Minimal Marketable Product). Задача бизнеса заключается в том, чтобы как можно быстрее выполнять следующие активности:
(далее…)
Вопросы по поводу необходимости и роли менеджера в Agile подходах поднимаются давно и ответы очень сильно варьируются от контекста и компании. За время работы в множестве проектов в различных ролях и за годы консалтинга в множестве компаний совершенно разного типа у меня сложилось личное понимание основных отличительных особенностей Agile менеджера по сравнению с классическим PM. Постараюсь их сформулировать в серии статей, а в конце вернуться к вопросу о потребности в таком менеджере.
Давайте начнем с любимого вопроса на всех PM собеседованиях и тематических конференциях: “что же такое проект?”. Приведу несколько определений, взятых из разных источников:
Проект – это одноразовая, не повторяющаяся деятельность или совокупность действий, в результате которых за определенное время достигаются четко поставленные цели.
В субботу мы с Тимом Евграшиным вернулись с очередной конференции AgileDays, которая прошла в Москве 21-22 марта. Мы ездим на эту конференцию каждый год и в этот раз ребята из ScrumTrek собрали самую большую Agile тусовку за все годы – почти 900 участников и 5 параллельных потоков выступлений.
Я обычно начинаю отчеты с того, что было не так и что мне не понравилось на месте проведения. В этот раз мне нечего сказать. Это лучший конференц-центр, в котором мне удалось побывать за все время. Кофе, чай и печеньки не кончались, очередей нигде не было (даже на обеде), гардероб на 2000 человек, эскалатор на второй этаж, обед был вкусным с фруктами и сладостями на закуску, места хватало для всех участников, залы отлично оснащены технически и очень просторные (ни разу не было переполнение зала). В общем, я завидую белой завистью. Очень бы хотелось иметь такое место в Киеве. Нереально круто! Я бы советовал всем организаторам конференций в Москве обратить внимание на это место.
Организация тоже была просто отличная – отлично организованные стенды спонсоров, классные рюкзаки в подарок участникам, интересный конкурс с ключами для получения призов, раздача клевых футболок. Еще порадовала качественная печать фотографий на магнитной бумаге на фоне конференционной стены. Я думаю каждый увез хотя бы одну фотку. И все как-то уютненько и по-домашнему. Очень порадовали, спасибо!
Теперь немного о выступлениях. Мое мнение тут совершенно не показательно, потому что большая часть тем для меня уже давно глубоко изучена на практике. Но я все равно нашел для себя что-то интересное и полезное.
После открытия я остался на доклад David Anderson про Kanban, о чем сильно пожалел. Доклад был без эмоций, ничего нового, хотя я ожидал большего. Сбегал послушать Сергея Дмитриева про то, как Waterfall сожрет Scrum. Сергея слушать было куда приятнее, но тема была заявлена провокационная, а на деле снова обсудили Agile ценности и затронули пару фундаментальных понятий. После этого порадовал доклад Ahmed Sidky – энергично, достаточно интересно, полезно. Тема внедрения и распространения Agile подходов в больших компаниях сейчас беспокоит многих.
После обеда я посетил технические доклады про технический долг и CQRS. Из первого было интересно послушать, какие варианты использовали ребята в своем проекте для организации борьбы с техническим долгом. Мы когда-то давно прошли этот путь в одном проекте. Доклад по CQRS был интересным, но малополезным с технологической точки зрения. Больше было похоже на введение в CQRS.
В последней секции докладов я заглянул на мотивационный поток, но как-то не проникся. Идеи интересные, но слабо применяются в реальной жизни, да и мотивация высокооплачиваемых профессионалов для меня всегда была странной темой. Если тебе нравится твоя работа, тебе комфортно работать в компании и платят неплохо, то ты работаешь. Нет – не работаешь. Затем принял участие в продуктовом мастер-классе от Никиты Филиппова. Мы составляли продуктовые идеи, проверяли их на соседях, составляли план реализации их в жизнь. Было интересно. Мы придумали “контролер депутатов”, который многим очень понравился.
А дальше было виски-пати, где можно вдоволь наобщаться со старыми и новыми знакомыми, выпить виски и посмеяться вместе над программистскими шутками. Спасибо всем участвовавшим за классную компанию!
На второй день первым докладом я попал на Антона Волкова. Как по мне, его выступление в прошлом году было гораздо более полезным. Там он рассказывал о безумно интересной системе мотивации и оценок сотрудников через систему набора баллов. В этом году была тема людей, не менее важная, но более узкая и специфическая для каждой компании. В продуктовых компаниях его идеи правильные, но и то не для каждой компании. В других направлениях они слабо реализуемы.
Дальше был интересный отчет от Димы Лобасева на тему внедрения Kanban в банке. Всегда круто слушать о реальном опыте, проблемах и способе их решения. Тем более под классные и яркие слайды с множеством шуток и приколов. Я остался очень доволен. Следующим был Асхат Уразбаев с докладом про новый современный подход #NoEstimates. Мне этот подход очень нравится для опытных команд, но есть одно НО. Его стоит позиционировать как следующий шаг после хорошего процесса оценок, а не как замену ему. Цепочка ХАОС->ПРЕДСКАЗУЕМЫЕ ОЦЕНКИ->#NoEstimates. Такой подход многого потребует от команды взамен – постоянных надежных поставок ценности заказчику.
Дальше был мой технический доклад про TDD для интеграции с БД. Немного теории, а потом живой кодинг. Надеюсь немногочисленной аудитории понравилось. Вот слайды:
На завершающий блок я пошел послушать про ретроспективы. Сначала Тим сделал вводную, рассказав много полезностей и раздав кучу советов по проведению ретроспектив. А потом Макс Дорофеев поведал интересные истории “с полей”, показав как использовать инструменты теории ограничений для улучшения ретроспектив и получения максимальной пользы от них. Ретроспективы – это круто и доклады были очень живые.
В скором времени организаторы выложат материалы в открытый доступ. На всех докладах снималось видео, поэтому вы сможете пересмотреть понравившиеся выступления.
Из программы и общения в кулуарах я вынес для себя одну особенность – на конференцию стало ходить значительно меньше технарей. Если когда-то мы рассказывали про Code Review и доклад собирал полный зал, то теперь на всех технических докладах залы были полупустые. При этом очень забавно на многих докладах звучали вопросы: “Как вовлечь в это разработчиков? Как продать разработчикам эти ценности?”. У меня появлялся к ним встречный вопрос: “А почему на этой конференции находитесь вы, а не ваши разработчики? Экономите? Пусть они пока поработают, пока вы узнаете как их организовывать?”. 🙂 Мне кажется, на следующей конференции при такой тенденции можно будет запросто избавиться от инженерного трека и никто не пострадает.
Подводя итоги, мне очень понравилось в этот раз. Я бы сказал, что было гораздо круче чем во все предыдущие годы. Так держать! Огромное спасибо организаторам за приглашение!
Компания ScrumTrek и сообщество AgileRussia уже начали готовить для всех поклонников Agile подходов очередную конференцию Agile Days 2014 — крупнейшую восточно-европейскую конференцию Agile и Lean сообщества. Основная цель конференции — обмен передовым опытом использования гибких методологий разработки программного обеспечения. В прошлом году мероприятие посетили 700 участников из более чем 300 различных компаний, а в этом планируется еще больше.
Благодаря неформальной обстановке, все, начиная от менеджеров проектов и скрам-мастеров и заканчивая теми, кто только присматривается к этим методам, получили возможность обсудить любые проблемы и вопросы. Конференция позволяет встретиться с коллегами, изучить передовой мировой опыт гибкой разработки и даже открыть новые возможности карьерного роста.
Как и во все предыдущие годы, на конференции выступают с докладами специалисты мирового уровня. Например, в главной секции Agile и Lean выступит David J. Anderson, глава Lean Kanban INC. Сцену с ним разделят Dragus Dimitriu и Bjarte Bogsnes, признанные профессионалы в области методов Kanban и Agile.
В этот раз на конференции запланировано 5 параллельных потоков, посвященные отдельным аспектам разработки ПО: Agile/Lean Mindset, Experience Reports, Product Development, DevOps. Отдельная секция отведена под игрофикацию процессов, являющуюся мировым трендом.
Вот несколько отзывов от участников прошлого года:
«Очень позитивное впечатление. Будто-то очень хорошую книгу прочитал по Lean/Agile за 2 дня. Очень хорошо видна сходимость основных проблем зрелости Agile в РФ» – Илья Кузнецов, зам. руководителя управления разработки, Лаборатория Касперского.
«Среди участников AgileDays очень много людей, разделяющих близкие нам ценности» – Виктор Ламбурт, директор по разработке, Объединенная компания Афиша—Рамблер.
У меня с прошлого года остались тоже очень позитивные эмоции, поэтому в этом году я снова подал заявку на доклад. Возможно, буду очередной раз одним из представителей Agile тусовки Украины на AgileDays’14. 🙂
Мы работаем над тематикой следующей встречи «Клуба анонимных разработчиков», которую анонсируем на следующей неделе. Пока же мы решили опубликовать расписание инженерных тренингах, которые пройдут в ноябре-декабре этого года.
Тема архитектуры и дизайна собирала больше сотни участников на встречах клуба, поэтому мы пригласили опытного тренера из Москвы Евгения Кривошеева прочитать отличный курс на эту тему. Тренинг называется “Дизайн и архитектура в Agile” и предназначается для разработчиков, архитекторов, лидеров команд и менеджеров проектов. Это отличный способ закрыть все пробелы в архитектуре и дизайне современных приложений. Ознакомьтесь с детальной программой, оно того стоит. Тренинг состоится 10-11 декабря, стоимость 2500 гривен.
Опытный TDD-гуру и .NET-практик Сергей Калинец в очередной раз соберет .NET разработчиков на свой тренинг “TDD в .NET”. Сергей построил действительно очень практический тренинг, на котором большую часть времени участники пишут код под руководством тренера. Через практику TDD дается гораздо проще. При этом есть возможность узнать много нового от профессионала своего дела. Тренинг пройдет 15-16 ноября, стоимость участия составляет 2000 гривен.
Это один из самых информативных наших тренингов. Его проводит Николай Алименков и он приготовил для участников увлекательный рассказ о 8-ми инженерных практиках. За два дня тренинга вы можете получить целостную картину эффективного процесса разработки с точки зрения его технической составляющей. В программу вошел весь многолетний опыт и знания тренера в области применения и внедрения инженерных практик. Вы можете оценить программу тренинга. Он состоится 6-7 декабря, стоимость участия 2000 гривен.
Тематика DevOps в последнее время обретает все большую популярность. Автоматизация настройки окружения стало обыденной работой, особенно в случае развертывания приложения в облачной инфраструктуре. Chef является одним из самых популярных инструментов в этой области. Андрей Самиляк уже выступал в клубе на эту тему. Но теперь он решил собрать весь опыт воедино и подготовил практический курс из 5-ти занятий по 3 часа. Занятия будут проходить по средам с 19:00 до 22:00, начиная с 20 ноября, и ориентированы сугубо на практическое применение техник и инструментов. Стоимость 2000-2400 гривен в зависимости от даты регистрации.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Много кто меня спрашивает, почему я в последнее время не хожу на разнообразные Agile тусовки и конференции. И я решил поделиться своей историей по этому поводу. Сами Agile, Scrum, Kanban, XP, Lean тут вовсе ни при чем, я по-прежнему считаю эти подходы к разработке самыми современными и правильными. Возможно, кто-то тоже заметил определенные изменения в самой Agile тусовке и разделит мое мнение.
Итак, когда-то давно мне очень нравилась одна фишка – мы собирались на встречи, участвовали в различных Agile мероприятиях и везде были реальные проблемы от реальных людей. Собирались и выступали люди, которые действительно работали над реальным внедрением гибких подходов и практик у себя на проекте. Было круто услышать реальные истории из нашего мира аутсорсинга, какие трудности испытывают команды в реальных условиях на реальных проектах в нашей стране. Сами темы выступлений и обсуждаемых проблем были гораздо интереснее и ярче, люди делились своими успехами, победами и поражениями. И создавалось приятное ощущение, что все движется вперед, развивается, не стоит на месте. Можно было на следующей конференции встретить тех же докладчиков и послушать как изменилась ситуация у них, чему они научились, что нового применили. Это давало толчок к собственному развитию, а также возможность поделиться своими опытом и знаниями с увлеченной аудиторией.
А что происходит теперь? В подавляющем большинстве выступают консультанты, коучи, тренера и евангелисты. Серьезно, около 90%. Кроме шуток, эта тенденция прослеживается не только в Украине, но и за границей. Только в Украине она более усугублена погоней за известными именами в программе – ведь мы все еще страна третьего мира, жители которой сильно ведутся на блестящие бусики (вспоминаем туземцев, а также как наш народ “хавает” золотые айфоны по невероятным ценам). Изредка консультанты разбавляются менеджерами (которых в грамотно построенном Agile процессе вообще и быть не должно, по крайней мере в этой роли). И что при таком составе выступающих можно услышать? Чем могут поделиться зарубежные “гуру”? Обычно, своими измышлениями и философскими рассуждениями, которые они вынесли из опыта консультирования НЕ В НАШЕЙ СТРАНЕ.
Я каждый раз смотрю на список тем докладов и задаю себе вопрос о практической применимости для меня лично и для людей, которых я знаю. И не вижу ее. Все философствования и идеи консультанты давно описали у себя в блогах, поэтому с ними я давно знаком. Вероятнее всего, видео подобного выступления проскакивало у меня в RSS ленте и я его уже видел, если конечно оно хоть чем-то меня заинтересовало. Так что мне там делать? Я теперь даже не подаю заявки на доклады – мои темы не вписываются в тематику. Я люблю рассказывать практические вещи, которые помогают людям что-то менять у себя и которые я попробовал сам.
Я в какой-то момент даже задумался, может реально уровень сильно вырос в Украине и у всех все хорошо. Но, общаясь с очень многими представителями различных компаний, я понимаю, что это не так. У многих как были проблемы с внедрением Agile, так и остались. Средняя температура по палате немного улучшилась, но незначительно. Зато сильно выросло число разочаровавшихся в Agile. И неужели им помогут очередные философские рассуждения от зарубежных “гуру”? Сомневаюсь.
Вот такая вот история… А вы что думаете по этому поводу?
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Недавно прочитал любопытную статейку от Максима Дорофеева с письмом от одного из его знакомого менеджера. В двух словах проблема примерно выглядит так:
Как и практически любой человек, который прочитал книжку Голдратта, менеджер из письма во всем видит потенциальное поле для улучшения эффективности. Причем, сразу и с текущего положения. В разы, чтобы как в книжке…
Лирическое отступление. Я когда-то давно прочитал “Цель” и “Цель-2” (кстати, всем настоятельно рекомендую) и до такой степени проникся идеями эффективности, что планировал чуть ли не по руководителям IT компаний ходить и “открывать им глаза” на неэффективность. Но когда начал больше расспрашивать в процессе консалтинга о деталях работы некоторых компаний, команд и проектов, осознал, что не все так просто и быстро. У некоторых царил полный хаос и они не были готовы к культуре “экономного эффективного производства”. Низкий уровень квалификации, бюрократия, навязанные извне правила и обязательства, специфические детали культуры компании и ситуация на рынке – все это требовало гораздо более примитивных мер на первых этапах борьбы за эффективность…
Scrum со своей итеративностью разработки позволяет перейти от хаоса к чуть более контролируемому процессу. Scrum далеко не идеален и, чем быстрее двигается бизнес, тем более очевидны становятся недостатки той же итеративности. Но когда у вас нет ничего, никто не может дать ответ о сроках выполнения задач, в команде разброд и шатание, заказчик не понимает что творится в команде, невозможно сделать хоть немного реалистичный план, команда не готова работать как команда, то “прогрессивные подходы” наподобие агрессивного планирования с отслеживанием выполненных работ и добавлением новой по факту или перехода на Kanban просто обречены на провал.
Scrum пытается научить команду давать осязаемые оценки своей продуктивности, выбрать самостоятельно объем работ на итерацию и сделать его успешно. Это очень важно! Во-первых, появляется предсказуемость для представителей бизнеса. Они теперь могут хоть как-то планировать. Во-вторых, появляется понятие командной ответственности за свои собственные решения и обратная связь по результатам выполнения работ (успели или нет, была ли возможность взять еще работ, нет ли проблем с качеством). Команда начинает работать как команда. И тут очень важно, чтобы начало хоть что-то получаться. Для некоторых команд непростой задачей является взять одну User Story и довести ее до конца в итерации. ОДНУ! Scrum же не исправляет ваши проблемы, а показывает их как в зеркале. Он дает вам данные, чтобы задуматься о причинах провала и неудач. Поэтому нет ничего зазорного или плохого в том, что команда ввела для себя (или кто-то другой ввел) жесткий критерий “все к концу итерации должно быть готово и качество должно быть на уровне”.
И вот, когда команда научилась давать нормальные оценки и делать хоть какую-то работу в срок от итерации к итерации, стоит задуматься об эффективности. Для этого в Scrum есть замечательные инструменты – burndown chart и ретроспектива. Первый может подтвердить описанное в статье подозрение, что команда первые две трети времени занимается чем угодно но не работой. А второй позволяет задать вопрос об эффективности и обсудить картину burndown chart за предыдущую итерацию. И команда сама примет решение, может ли она увеличить количество задач на итерацию или это слишком рискованно. В конце концов иногда проще брать на себя надежные обязательства и, если остается время, добавлять новые задачи. Чтобы ни при каких обстоятельствах не поломать ожидания представителей бизнеса. Все проекты разные и для некоторых это ну оооочень важно.
Все перечисленное будет работать, если в команде есть хотя бы кто-то ответственный. Если вся команда безответственная, то она будет филонить при любом процессе. Любая задача может быть искусственно затянута и оценки повышены. Поэтому сам процесс или подход не является решением. В Agile очень многое зависит от “правильных людей”, а иначе просто не работает, как бы грамотно не насаживались сверху практики замера и улучшения эффективности… 🙂
Через некоторое время необходимость в итерациях перестанет быть такой острой, и тут уже можно начать применять другие подходы к планированию. Еще через некоторое время итерации начнут просто мешать работать более эффективно для хороших команд. И тут время искать или строить более эффективный процесс разработки, например Kanban. Но рубить с плеча сразу может быть очень вредным для команды…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Осталось полтора месяца до отличной инженерной конференции XP Days Ukraine, которую мы организуем вот уже третий год. Традиционно конференция разбита на дни тренингов (9-10 октября) и конференционные дни (11-12 октября). Мы решили в этом году не увеличивать количество потоков – их будет по-прежнему два. Поэтому нам пришлось более тщательно поработать над программой, чтобы все интересные на наш взгляд темы были раскрыты.
Все знают, что XP практики очень полезны и позволяют разрабатывать более качественный продукт с большим контролем над техническими аспектами разработки. Но на деле их применение оказывается не такой простой задачей. Поэтому практические отчеты из разных сфер разработки на наш взгляд так важны.
DevOps – это современный тренд в разработке. Кто-то считает его очередным “ярким слоганом”, за которым ничего не скрывается, кто-то наоборот уверен, что за этим подходом будущее разработки. Мы не могли пройти мимо этой темы.
Не стоит забывать, что важной частью практически любого приложения является БД. В Agile методологиях много говорят о гибкости дизайна и архитектуры, откладывании критичных решений на момент, когда они будут действительно необходимы. А как же быть с БД? Как развивать ее параллельно с эволюцией вашего продукта? Это очень важные вопросы, на которые мало кто дает вразумительные ответы. Поэтому данная тема также попала в область нашего внимания.
Без тестирования трудно добиться качества кода, так же трудно, как если не отслеживать это качество и не пытаться его контролировать. Мы считаем, что в современной разработке этим процессам нужно уделять большое внимание.
Так как большая часть практик будет обсуждаться в практических отчетах, то мы решили сосредоточиться на самых важных и сложных для большей части разработчиков.
Вот такая вот программа ждет участников в этом году. Еще будут доклады на тему архитектуры в Agile, применимости фреймворков, важности роли Tech Lead и некоторые другие. Финальная версия программы будет опубликована 1 сентября.
У нас осталась последняя сотня билетов, а это значит, что уже более 200 участников зарегистрировались на конференцию. Присоединяйтесь и не пропустите эту интереснейшую техническую конференцию!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
