Резюме докладов на AgileDays’12

milan_hotel

23-24 марта в Москве прошла 6-я глобальная русскоязычная конференция компании ScrumTrek и сообщества AgileRussia по гибкой разработке программного обеспечения – AgileDays’12.

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

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

За неделю до конференции AgileDays’12 на весеннем форуме для компаний-разработчиков программного обеспечения Microsoft Innovation Day 2012, где фокус был сделан на технологии облачных вычислений, генеральный директор ОАО “Русские навигационные технологии” Иван Нечаев рассказывал о полной реорганизации компании вследствие смены бизнес-модели системной интеграции, в частности работы по проектам (заказная разработка), на предоставление программного обеспечения в виде сервисов, а Иван Бодягин, заместитель директора департамента разработки технологий ABBYY, говорил о возникшей необходимости внедрения гибких процессов в компании вследствие начала предоставления части продуктов компании как облачных сервисов. Технология облачных вычислений сделала возможной новую модель предоставления программного обеспечения клиентам в виде сервисов, но предъявила новые требования к обеспечению этого процесса. К примеру, продуктовым компаниям, традиционно работающим с жизненным циклом продуктов в 1-2 года, теперь необходимо сокращать время вывода сервисов продуктов на рынок (TTM, time to market). Представьте, что продуктовый менеджер просит выкатить новую конкурентную возможность сервиса в течение месяца, а разработчики не могут это обеспечить, так как действующие процессы разработки предполагают расходование месяца только на стабилизацию продукта. Как следствие, во внедрении гибкой разработки, обещающей снижение TTM, теперь может быть заинтересован бизнес, а не только разработка. Таким образом, виден переход от интуитивного внедрения гибких процессов “снизу вверх”, закрывающего текущие проблемы (PULL-модель), к осознанному стратегическому внедрению гибких процессов “сверху вниз” (PUSH-модель) для обеспечения возможности изменения бизнеса под текущие реалии рынка. Ровно об этом в конце второго дня конференции AgileDays’12 рассказывал Алек Козлов: про реорганизацию и успехи внедрения Scrum в Skype Inc.

Кроме того, мы начали обдуманно подходить к выбору методологий в соответствии с решаемыми нами задачами. К примеру, если раньше перечень предложения гибкой разработки ограничивался низкоуровневыми методологиями вроде XP (eXtreme Programming) и Scrum, то теперь этот список расширился: из Toyota к нам принесли принципы бережливого производства Lean и методологию Kanban – которые значительно расширили область применения гибких методик в нашей отрасли. Более того, мы начали искать такие комбинации практик знакомых нам методологий, которые подходят для решения стоящих перед нами задач, а не бездумно натягивать методологии “as is” на задачи, тем самым видоизменяя последние. Так, к примеру, на конференции рассказали про комбинацию Scrum и Kanban – Scrumban. Также я впервые услышал доклад про возможные исключения из строгих правил Scrum, о чем раньше тренеры говорили: “Ни-ни!”. Наконец-то тренеры стали говорить про место, которое гибкие методологии занимают по отношению к классическим методологиям вроде водопада, а также комбинациям традиционных и гибких методологий вроде RUP (Rational Unified Process) и MSF (Microsoft Solution Framework).

Итого, наконец-то отрасль разработки программного обеспечения перестала воспринимать Agile как религию или модное веяние.

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

23 марта

The Power of an Agile Mindset

Linda Rising

I’ve wondered for some time whether much of Agile’s success was the result of the placebo effect, that is, good things happened because we believed they would. The placebo effect is a startling reminder of the power our minds have over our perceived reality. Now cognitive scientists tell us that this is only a small part of what our minds can do. © Linda Rising

Рекомендую обязательно посмотреть выступление Линды, в котором она говорит о “гибком мышлении”, которое подразумевает ориентированность на результат и постоянное обучение, в том числе и на ошибках, и которое является результатом опровержения мифа о фиксированности таланта и невозможности развития интеллекта.

В качестве доказательства существования Agile-мышления в докладе приводятся результаты эксперимента, проведенного на группе студентов.

  1. На первом этапе посредством психологических тестов студентов разделили на предполагаемые в рамках гипотезы существования “гибкого мышления” 2 группы: “fixed”, которых далее я буду называть “ленивыми” (хотя это слово более корректно переводить как “консервативные”), и “effort”, которых буду называть “усердными”. Насколько я понял, сами студенты об этом разделении не знали на протяжении всего эксперимента.
  2. На втором этапе студентам предложили решить на выбор простые или сложные тесты. 80% ленивых студентов выбрали простые тесты, а 90% усердных выбрали сложные. Вера в фиксированность интеллекта очень удобна, так как позволяет оправдать стабильность текущего состояния и лень, не позволяющую его изменить. Действительно, зачем лишний раз напрягаться? Противоположная точка зрения подстегивает человека к поиску сложных задач, на которых можно развить интеллект.
  3. На третьем этапе все студенты решали сложные тесты. Усердные получили удовольствие, в то время как большинство ленивых студентов вообще не смогли решить тесты, но не потому, что им не позволили их интеллектуальные способности, а потому что они сами разрешили себе лишний не напрягаться, опустили руки: “мне не дано”.
  4. На следующем этапе каждому студенту предложили ознакомиться с результатами тестирования других, но на выбор: или с получившими более высокие результаты, чем они сами, или более низкие. В итоге, усердные учились у более сильных, а ленивые самоутверждались основываясь на том, сколько тех, кто еще глупее них.
  5. В конце каждому студенту дали возможность дать советы тем, кто получил более низкие результаты. Организаторы эксперимента отметили, что ленивые при этом советовали откровенные глупости и пытались принизить своих коллег.

Линда указала, что психологи на самом деле уже давно исследуют этот вопрос: к примеру, этот и многие другие подобные эксперименты описаны в книге Carol Dweck Self-theories: Their Role in Motivation, Personality, and Development.

Разумеется, Agile – это лишь принцип мышления: в нас всегда комбинируются составляющие как effort, так и fixed – все определяет пропорция.

Слушая все это, я вспоминал, как “засовывал” свою дочь в физико-математическую школу, руководствуясь цитатой Ницше: “все, что нас не убивает, делает нас сильнее”. Ребенок ничего не хотел менять в своей жизни, ее устраивала спокойная размеренная учеба в обычной школе, поэтому она и жена со слезами и соплями, криками и обвинениями отговаривали меня, утверждая что это не наш уровень, что нам это не дано и не нужно нам это. После 3 неудачных экзаменов и определенного количества моих нервов мы все-таки поступили. Я могу ошибаться, но по прошествии нескольких лет именно это изменило самооценку ребенка: она относительно просто поступила в университет и обнаружила, что по сравнению со сверстниками достаточно неплохо владеет точными науками – и откуда интеллект пророс?

Также Линда привела мнение психологов о том, почему в ИТ мало женщин, связывая это с “комплексом отличницы”. А также предостерегла об опасности ситуации, когда начальник сомневается в ваших способностях: психологами замечено, что в такой ситуации вы действительно можете приостановиться в развитии – психологи называют это эффектом Пигмалиона.

  • Содержание доклада: 5
  • Мастерство докладчика: 5

Секреты Lean в разработке ПО

Асхат Уразбаев, ScrumTrek

Презентация: http://www.slideshare.net/agiledays/lean-vsm-12164878

В компании Toyota разработали концепцию менеджмента Lean (lean production, бережливое производство), основанную на максимальной ориентации на потребителя, неуклонном стремлении к устранению всех видов потерь и предполагающую вовлечение в процесс оптимизации бизнеса каждого сотрудника. И в этом докладе Асхат рассказал про одну из методик Lean – систематизацию потока ценности (VSM, Value Stream Mapping), а также ее адаптацию к разработке программного обеспечения.

Если у меня в проекте вырастет “узкое горлышко”, которое будет препятствовать каким-то целям проекта и команда не сможет его вычислить или устранить посредством ретроспективы, пожалуй, я попробую применить VSM.

  • Содержание доклада: 4
  • Мастерство докладчика: 5

Scrum: the Big Picture

Dan Rawsthorne, 3Back

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

В Software Development разработчики управляют качеством кода, используя для этого методики вроде критериев готовности (DoD, Definition of Done) и защищая стоимость качества перед бизнесом.

На уровне Project Management менеджер, отвечающий за реализацию цели в срок в рамках бюджета, обеспечивает оптимальную нагрузку на команду разработки, балансируя рамками проекта, сроками и ресурсами, к примеру, прорабатывая план изменения сроков. Всем слушателям понравился слайд “bad manager”, на котором показан до боли знакомый всем стиль менеджмента разработчиками, а не проектом. За ним следовал слайд “good manager”, на котором менеджер сидит перед весами, на одной чаше которых лежат рамки проекта, а на другой – сроки. Разработчики, обязательно перешлите это своему менеджеру: если он “плохой”, то пусть наконец-то узнает об этом от авторитетов, а если “хороший”, то продолжит совершенствоваться.

И на последнем уровне Portfolio Management предполагается балансирование между сроками проектов и создаваемыми при этом ценностями. Здесь Дэн приводит плохие примеры управления портфелем проектов вроде того, что вместо планов на этом уровне формулируются просто надежды (“хотелки”) и фигурируют детсадовские цели “нам это нужно”.

  • Содержание доклада: 4
  • Мастерство докладчика: 4

Как нужно уметь думать техническим и процессным специалистам

Евгений Кривошеев, ScrumTrek.

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

  • Содержание доклада: 3
  • Мастерство докладчика: 4

Что должен еще уметь делать Product Owner, чтобы стать Product Manager

Дмитрий Безуглый, System-Approach Ltd

Пожалуй, этот доклад был самым интересным для меня. Текущий проект мы стартовали по методологии MSF (Microsoft Solution Framework), используя шаблоны разделения ответственностей в команде и типовых работ, выполняемых на определенных этапах зрелости проекта, но при этом не стали отказываться от бонусов Scrum, легко встроив его внутрь обобщенного MSF. В Scrum я стал выполнять обязанности Product Owner (PO), которые относительно просты и незатейливы: веди BackLog и играй приоритетами в нем, общаясь с заинтересованными лицами. Но вот MSF с его ролью Product Manager (PM) обязал меня к намного большим обязанностям. Честно говоря, мне тогда просто очень хотелось освоить новую давно интересовавшую меня методологию, то есть выбор MSF прошел достаточно неосознанно. Но теперь по прошествии времени я благодарю этот случай, определивший правильный выбор: на голом Scrum, ориентируясь на незатейливые обязанности PO, я попросту бы не запитал команду той критически важной информацией, которую удалось собрать ориентируясь на обязанности PM, и запутался бы в клубке конфликтов интересов нескольких заказчиков, не обеспечив себя инструментом для принятия решений. И теперь из уст Дмитрия я услышал теоретическое обоснование и оправдание моих мучений.

Кто такой PO? Agile говорит, что было бы отлично, если это конечный заказчик. Но почему нет успешных историй такого? Потому что у представителя со стороны заказчика обычно хватает своей работы, кроме работы внутри команды разработки. В итоге, Agile придумал использовать в качестве PO прокси, то есть представителя интересов заказчика внутри команды разработки. И все это хорошо и просто работает (прокси – не такая уж и сложная работа), пока заказчиков не становится больше. Как принять решение о приоритете элементов BackLog, если у вас несколько заказчиков, каждый из которых имеет различные ожидания от вашего продукта?

Дмитрий рассказывает про стадии эволюционного развития от PO, который отвечает за поставку правильного продукта только с точки зрения R&D, до PM, который формирует бизнес-кейс, в рамках которого продукт может развиваться и приносить деньги.

Прежде всего PM формирует концепцию проекта (Vision, Project Charter), включающую ничем не ограниченное видение того, каким должно быть решение, а также четкие границы того, что будет реализовано в условиях существующих ограничений. В итоге, Vision по сути и становится недостающим PO инструментом, который обеспечивает возможность принятия решения в случае конфликта интересов заказчиков. Таким образом, с одной стороны, PM как и PO умеет “влезть в шкуру заказчика”, но, с другой стороны, кроме того может, точнее умеет ему отказывать в случае конфликта его интересов с интересами всего проекта в целом. Более того, PM участвует на всем пути продукта к заказчику, на котором кроме стадии создания ценности, за что отвечает R&D и PO в частности, есть множество стадий, включая сбор информации, оценку конкурентов и позиционирования продукта по отношению к ним (я был поражен, к какому перетряхиванию нашего BackLog привел проведенный мною конкурентный анализ), продажу и поддержку.

Если эта тема вам близка, рекомендую посмотреть доклад и методологию MSF: Microsoft Solution Framework 3.1.

  • Содержание доклада: 5
  • Мастерство докладчика: 4

Откуда в Agile рост производительности команд

Анна Обухова, Luxoft

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

Не знаю, то ли мне нужно было ответить на одно из “срочных” писем по работе, то ли духота в набитой битком аудитории так подействовала, то ли доклад и лектор были такими… Тем не менее, я прослушал большую часть и остался при своем старом убеждении, что производительность работы команды очень слабо напрямую связана с используемой методологией. Помню, студентами мы работали на гора, а потом умудренные опытом и какими-никакими методологиями вроде XP работали, но точно в половину силы по сравнению со студенчеством. Факторы, влияющие на производительность, находятся в иной плоскости, нежели методологии. И потому выбирать, к примеру, между Waterfall или Scrum, имея целью именно повышение производительности, я бы не советовал.

  • Содержание доклада: 3
  • Мастерство докладчика: 3

Блиц-доклад: 2 морковки или мотивация в Agile

Руслан Мартимов, General Satellite

Если у вас маленькая компания, которая не занимается целенаправленно взаимосвязанными системами компетенций и мотиваций сотрудников, то посмотрите данный 15-минутный доклад. В ином случае менеджерам рекомендую изучать стандарты своей компании и материалы по теме мотивации на ресурсе Стратоплан.Ру.

  • Содержание доклада: 2
  • Мастерство докладчика: 3

Блиц-доклад: Agile для девочек

Антон Зотин, Luxoft

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

  • Содержание доклада: 1
  • Мастерство докладчика: 4

Блиц-доклад: 7,5 примеров того, что не стоит делать при внедрении Agile

Никита Филиппов, ScrumTrek

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

  1. Product Owner и Scrum Master (SM) – 1 человек: эти роли совмещать нельзя, так как это приводит к конфликтам интересов продукта, которые отстаивает PO, и команды, которые должен защищать SM. Но, говорят, что можно, если у PO есть опыт работы SM, а также доверительные отношения с командой.
  2. Нестабильные команды: нельзя постоянно перекидывать разработчиков между командами, делая их нестабильными. Тем не менее, говорят, что и это не так страшно, лишь бы ядро команды (50% членов команды) оставалось стабильным.
  3. Распределенные команды: на вопрос, что делать с распределенной командой, Хенрик Книберг упорно советовал ее объединить. Но, вот говорят, можно и так, только советуют провести совместный (в одном месте) старт проекта для сплочения, чтобы снизить вероятность возникновения в дальнейшем эффекта: “они” и “мы”.
  4. Замкнутый круг “Demo, Feedback, New requirement”: Scrum проповедует взаимосвязанную цепочку: демонстрация, по итогам которой получается обратная связь (отзывы), порождающая новые требования, которые сразу же поступают в работу и далее по кругу – что может легко привести к тому, что вы будете очень медленно развивать функционал, постоянно исправляя мелкие недочеты, замеченные заинтересованными лицами на демонстрации. Ну, так балансируйте при выборе работы в итерацию между отзывами на демонстрации и целями грядущего релиза.
  5. “Самоделкины”: не меняйте процесс до тех пор, пока не проработаете, не внедрите все практики в том виде, в котором они рекомендуются.
  6. Бесконечная итерация: не успели что-то доделать на итерации, потом кто-то заболел или праздники неожиданно нагрянули, потом тушили критический баг, потом еще что-то – потом не смогли вспомнить, почему итерация стала бесконечной. Но на день задержаться вполне нормально.
  7. “Мусор на вход, мусор на выход”: требование не код, не обязательно к нему так уж педантично относиться. В итоге, какое качество подали на вход, такое же получили и на выходе.

Но помните: право на гибкость, в частности исключения из правил, имеют только опытные.

  • Содержание доклада: 5
  • Мастерство докладчика: 4

24 марта

Бодрое планирование

Антон Бевзюк, Intel

Антон рассказал про весь цикл планирования по Agile. Я узнал мало нового, тем не менее, при первом внедрении Scrum материал должен быть очень полезным.

  • Содержание доклада: 4
  • Мастерство докладчика: 3

Scrum + Kanban = Scrumban. Лучшее из обеих методологий

Дмитрий Овечкин, Иннова

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

  • Содержание доклада: 5
  • Мастерство докладчика: 4

Создание инструментов повышения качества со стороны тестирования

Юлия Нечаева, Наталья Курашкина, Иннова

Девушки рассказывают про идеального тестировщика в аллегории “старательной девочки”, которая работает не на одном только этапе классического конвейера: “requirement, design, development, test, support” – а участвует практически во всех активностях проекта, выступая, как они сами описали, в роли “очень критичного PO”.

  • Содержание доклада: 3
  • Мастерство докладчика: 5

Блиц-доклад: Фрактальная природа IT-проектов

Андрей Бибичев, iPi Soft LLC

Андрей рассказывает про уточнение сложности ИТ-проектов, которая похожа на фрактал: при уменьшении масштаба фрагменты этой бесконечной фигуры начинают повторяться. Вот, казалось бы, завершили определенную работу, так в итоге всплыли какие-то неучтенные мелкие детали, требующие доработок. Доработали доработки, так всплыли необходимые доработки доработок. Хорошо, хоть работы имеют предел, то есть атомарные, в отличие от бесконечных математических фигур.

Посмотрите: интересный доклад с отличным юмором.

Упоминанием термина “люди-снежинки” Андрей напомнил мне и моим разработчикам слайдкаст Максима Дорофеева: Шухарт, 6-сигм и люди-снежинки.

  • Содержание доклада: 4
  • Мастерство докладчика: 5

Блиц-доклад: Инвалиды офисного труда или как не умереть в офисе

Стас Калканов, Luxoft

Аннотация: http://msk12.agiledays.ru/reports/view/25/

Всему офисному планктону стоит посмотреть это, чтобы испугаться – и наконец-то заняться спортом.

  • Содержание доклада: 3
  • Мастерство докладчика: 4

Блиц-доклад: Когда компания мешает работать

Дмитрий Лобасев, ScrumTrek

Дмитрий рассказывает про признаки негативного влияния компании на ваше развитие. Вам кажется, что ваши коллеги думают о вас примерно так: “Какой-то от слишком бодрый, но ничего, скоро станет нормальным”? Тогда посмотрите доклад: возможно, вы узнаете знакомые “корпоративные запахи” и поймете, что вам стоит сменить работу.

  • Содержание доклада: 4
  • Мастерство докладчика: 4

Блиц-доклад: Процесс улучшения процесса улучшения

Асхат Уразбаев, ScrumTrek

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

Асхат рассказывает, как можно применить Lean-методику WSM для выявления проблем и Kanban для отслеживания потока их решения.

Когда-то Асхат рассказывал и помогал внедрять Scrum, в прошлом году поведал о Kanban, а теперь принес Lean – и начал все это комбинировать под различные задачи. Интересно, что еще из новенького он принесет нам в этом году?

  • Содержание доклада: 5
  • Мастерство докладчика: 5

Командная работа над качеством в Agile

Наталья Руколь, Quality Lab

Аннотация: http://msk12.agiledays.ru/reports/view/12/

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

Послушал я весь этот клубок взаимосвязанных проблем:

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

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

  • Содержание доклада: 4
  • Мастерство докладчика: 4

Инструменты кайзена для процесса непрерывного совершенствования

Борис Вольфсон, Softline

Борис рассказывает про Lean-методику Кайзен (изменение-улучшение), ориентированную на постоянное внесение мелких изменений, а также инструменты, поддерживающие этот процесс.

  • Содержание доклада: 3
  • Мастерство докладчика: 3

Skype Agile – успехи и проблемы большой корпорации

Алек Козлов, Skype Inc

Аннотация: http://msk12.agiledays.ru/reports/view/21/

Алек поведал результаты реорганизации компании и внедрения Agile “сверху-вниз” в компании, контролирующей 25% всех звонков в мире, Skype Inc.

Очень интересным показалось, что после реорганизации в Skype Inc полностью отказались от офиса проектных менеджеров, расформировали. Я думал, что это только идеал, о котором в методологиях вроде MSF пишут: мол, распределите полномочия и ответственность между функциональными кластерами – и функции менеджера проекта окажутся на уровне функций секретаря или администратора проекта.

  • Содержание доклада: 4
  • Мастерство докладчика: 4
Реклама

6 thoughts on “Резюме докладов на AgileDays’12

  1. >> И все это хорошо и просто работает (прокси – не такая уж и сложная работа), пока заказчиков не становится больше

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

    Нравится

    • Да, заинтересованных лиц в крупном проекте всегда много. Но, во-первых, среди них (stakeholders) надо разделять клиента (customer), который получает выгоду от проекта и который обычно его оплачивает тем или иным образом, и пользователей (users), которые будут использовать результаты вашего проекта в своей работе. Так вот, сложности у PO начинаются, когда много клиентов, а не пользователей.

      Если клиент один, то все разношерстные «хотелки» пользователей очень легко фильтровать через генеральные «хотелки» клиента, отсекая то, за что клиент не хочет платить, а пользователь попросту не сможет. В заметке, когда я писал, что PM в отличие от PO «умеет отказывать в хотелках», я подразумевал возможность и умение отказывать в «хотелке» клиента, а не пользователя: отказать ИТ-службе (это один из пользователей продукта), которая просит повысить удобство UI консоли администратора обычно очень легко, так как бизнес, оплативший проект (клиент), обычно не готов оплачивать подобное.

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

      Нравится

  2. Уведомление: Не место красит человека, или Работать должно быть комфортно « Shostakovich-Cover-Blog

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s