Оригинал статьи здесь.

Риски? Никогда не слышал

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

Любой проект связан с неопределенностью, рисками и возможностями. Простите за штамп — но согласно исследованию Standish Group - 66% проектов находятся на грани рисков (т.е. под угрозой сроки, бюджет, качество — другими словами Успех проекта), а 60% из них будут провальные. 

Один из основных процессов — Управление рисками проекта — имеет в традиционном подходе довольно строгую последовательность действий, присутствующих на всех стадиях его жизненного цикла:

• Планирование
• Идентификация
• Анализ
• Реакция
• Мониторинг и контроль

Однако, не смотря на всю строгость, с рисками в проектах на практике — просто беда. Попробую порассуждать почему.

Во-первых, как правило менеджеры проектов (далее ПМ) тратят много времени в начале проекта на попытки предсказать и идентифицировать ВСЕ возможные риски. И потом смело про них забывают. И “хорошо проработанная” матрица рисков становится предметом истории.

Во-вторых, “предсказания” ПМ-а — остаются только предсказаниями ПМ-а. Спросите команду – а знает ли она про риски? Для нее это скучно, академично и никак не интегрировано в жизненный цикл проекта.

Что в результате? А в результате — негативные воздействия, разные в частности, но во многом общие для большинства ИТ-проектов:

• Низкое качество (а в классике это переменная, к сожалению) — корневая причина провала многих проектов. Это разрушает продуктивность команд. Команды начинают жить с одной мыслью — только не трогать старый код. Дефекты копятся и копятся — и нет вариантов, как выйти из это ситуации.
• Рост бюджета — проект уже выбрал все доступные ресурсы, но все еще не закончен. И проекты становятся очень дорогие.
• Отложенная поставка — не успеваем реализовать проект в рамках предполагаемого времени. Многие проекты — очень чувствительны к срокам, и нарушение автоматически ведет к потери прибыли, места на рынке и даже штрафам.
• Разработка продуктов в рамках согласованных сроков-ресурсов-качества, которые к моменту готовности становятся никому не нужны.

Это в классическом подходе. А что же Agile? Как известно многие скептики считают, что Agile проекты недокументированные, не планируются, полны хаоса и анархии. И уж конечно, там нет места Управления Рисками. В Agile нет менеджера проектов, который отвечает за управление рисками, а раз нет, то нет и рисков. И часто, начиная мега-проект ХYZ в своей организации, мы говорим — он такой ВАЖНЫЙ, что на нем применять Agile слишком рискованно.

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

Часть 1. Почему в Agile рисков “нет”

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

• Приоритезация — умение фокусироваться на наиболее Ценных требованиях для клиентов
• Открытость и прозрачность
• Ограничение незавершенной работы — необходимость минимизировать количество одновременно выполняемых задач.
• Управление размером “пакетов”  - основа реагирования на изменении в наших проектах

Далее рассмотрим — как эти принципы  работают и чем они отличаются от классической модели управления рисками.

Как приоритезация помогает работать с рисками

Итак, обо всем по порядку.  Как известно (опять благодарность Standish Group) — 45% реализованных требований в ИТ-проектах никогда не используются. Это как строить дом, в левое крыло которого никто и никогда заходить не будет. Зачем нам такой дом? Более того, работа надо требованиями, которые несут низкую Ценность, влияет на мотивацию и моральный климат в команде. А доставка Ценности откладывается (иногда навсегда).

В Agile приоритезация  - это ключевой принцип, позволяющий ранжировать требования таким образом, чтобы в проекте мы начали реализовывать наиболее ЦЕННЫЕ — первыми. Как приоритезация влияет на риски:

• Приоритезируя требования — мы фокусируемся на самых важных в данный момент для клиента.
• Для коммерческих продуктов мы можем реализовать минимальную ценную часть продукта (MVP) для проверки рынка. Это позволит нам быстрее сделать корректировку курса или направления движения (т.н. Pivot) или вообще перестать работать в этой нише.
• Реализуя MVP мы можем передать это в руки заказчику, получить обратную связь (что используется для переоценки остальных требований).
• Согласно правилу Парето 80% ценности продукта содержится в 20 % требований. Если мы реализуем 20%, то повышается вероятность доставить что-то Ценное, при этом не увеличивая  бюджет.
• Регулярная переоценка позволяет в каждом цикле корректировать “направление” проекта.

“Отсутствие прозрачности приводит к недоверию и глубокому чувству незащищенности” Далай Лама

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

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

Что является примерами таких инструментов:

• информационные радиаторы команды
• канбан-скрам-доски
• визуализация митингов, мероприятий (от планирования до демо и ретроспектив)

Сделайте ваши проекты открытыми!

Многозадачность: почему проекты опаздывают

Не секрет, что многие проекты страдают регулярным переключением сотрудников между задачами. Мы любим использовать эксперта Петю на 25 % в одном проекте на 35 % и остаток времени в третьем. И на самом деле — Петя  работает 20 %,  а остальное время тратит на переключение из проекта в проект.

Во многих Agile фреймворках мы управляем количеством незавершенной работы:

• Количество работы ограничено временным интервалом (спринты) в Scrum
• WIP в Канбане
• Команда не берет работы больше, чем может сделать за это время
• А участники команды работают вместе — чтобы  очередное требование было  реализовано, протестировано, готово к перемещению , и только потом берутся за другое.

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

Почему размер имеет значение

Основа уменьшения чувствительности наших проектов к изменениям — уменьшение размера поставляемых партий (размеров релизов). В ИТ проектах принято считать — что весь проект это единое, которое может поставляться только единым моментом.

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

Уменьшение размера поставляемой части позволяет нам управлять Ресурсами проекта:

• Быть более продуктивными
• Уменьшить вариативность работы
• Более чаще инспектировать готовое

Работая инкрементально, мы уменьшаем количество переработок, получаем быстрее обратную связь от пользователей и клиентов. Это позволяет нам корректировать и уменьшать количество ошибок.  А главное — минимизировать последствия рисков, связанных с Качеством, Ценностью продукта и Сроками проекта.

Источник живет здесь.

Когда-то, в далеком феврале 2010-го, я опубликовалинтервью с Майком Коном, которое получилось из моего знакомства с Майком на тренинге. Одной из тем, которые мы обсуждали, был выход его книги “Succeeding with Agile”. Вскоре после статьи книга стала моей настольной (а потом и карманной, с покупкой Kindle). Она не раз помогла мне осуществить трансформацию компаний, которые обращались ко мне за консультацией, коучингом или тренингом, ну и конечно служила источником вдохновения для многих статей и докладов. 

Почти откровением для меня стал выход русской версии книги, это событие как-то прошло мимо меня. В русском переводе книга называется “Scrum. Гибкая разработка ПО”. Все-таки для многих людей, прочитать книгу на русском оказывается быстрее, а книга стоит того, чтобы ее прочитали.

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

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

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

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

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

Оставайтесь с нами, у нас еще есть много чем с вами поделиться.

Источник статьи здесь: http://dou.ua/lenta/articles/agile-love/

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

Попробуем разобраться в вопросе — почему же заказчики так любят Agile?

Оставим технические подробности, и переключимся на нечто более важное — на явные и скрытые ожидания клиента. Именно они, а не рациональные рассуждения и точные расчёты, зачастую определяют выбор способа работы (увы). Итак:

Во-первых, Agile — это дешево.

• Не нужен проектный менеджер (зачем? Мы же Agile!).

• Не нужно тратиться на проектирование архитектуры. Для большинства заказчиков, выходцев из бизнес-среды, архитектура проекта — это вообще непонятный зверь, и тратить на него время и деньги по возможности не стоит. Лучше сразу начинать делать что-то, что «вот прям сейчас работает».

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

Во-вторых, Agile — это просто. Просто для понимания человеком, далеким от проблем разработки ПО. Это можно объяснить и «продать» заказчику. Обычно набор артефактов, присутствующих в Agile-процессах (типа того же Scrum) вполне понятен для нетехнического человека, более того — он симпатичен. Там нет страшных слов, вроде «прототипирование», «архитектура», «план работ», «зоны ответственности» и тому подобного. Его можно выучить за пару дней и смело ездить на конференции, слушая таких же «специалистов», как и ты сам. J То есть Agile — это sexy.

В-третьих, Agile — это безопасно. Не нужно принимать на себя ответственность за решения. Сегодня я хочу одного, завтра — другого, и это нормально. Передумал — не проблема. Выбросить реализованное в корзину — запросто! Новое не налезет на то, что сделано на данный момент, и вообще приводит к краху системы? Это еще с чего вдруг? Зачем же ВЫ тогда ТАК писали код?

В общем, с какой стороны ни глянь, Agile — очень удобная система работы. Оптимальная ли? Это, как говорится, зависит. Говорю сразу: я знаю, что Agile работает. Не просто уверен — я ЗНАЮ. Так как он реально работал в некоторых проектах, в которых я сам участвовал.

Но работает он только тогда, когда соблюдаются хорошо всем известные условия:

• Небольшая, коллоцированная, кроссфункциональная команда высококлассных специалистов (до 9 человек).

• Реальная вовлеченность заказчика, его постоянная готовность к работе с командой.

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

Часто ли соблюдаются эти требования? Увы. Нечасто. А честно говоря — редко. Весьма и весьма.

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

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

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

• Уже никто не знает, как программа устроена в целом (что-ж вы доки не писали? Ай-яй-яй!).
• Часть людей уходит, новые приходят и долго не могут разобраться в продукте.
• Масштабируемость и производительность продукта исчерпаны, и без жесткого рефакторинга и проработки архитектуры (страшное слово) — с места не сдвинуться.

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

• Разработчики все громче и громче матерятся на качество кода. Это все бы ничего (пусть терпят, они же САМИ его писали), да вот беда — могут и уйти со словами «не могу так говнокодить, заказчик сам не знает, чего хочет». И новых набрать — непросто и затратно.

• Мотивация людей, вынужденных часто работать «на корзину», закономерно снижается. Это факт. Кто там чего про «вы должны быть всегда готовы к изменениям?». Ага, должны. Мы вообще много чего должны — зарядку там по утрам, зубы на ночь и т. д. Человеческая психика — штука неумолимая, и ее так просто не обманешь и не пересилишь. Доказано, что работа на корзину — один из главных демотиваторов для профессионала. Это не обсуждается.

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

Заказчики, в общем, люди неглупые, и убедить их можно. Но от них последует закономерный вопрос — почему это случилось именно сейчас, и почему раньше об этом не говорили и не планировали? Ведь сейчас может быть не лучший момент для рефакторинга, с точки зрения клиента. На это можно только пожать плечами... ну, мы же Agile. У нас-то и менеджера нету. Который по своей должности должен прикрывать свою задницу и задницу команды, постоянно и регулярно объясняя клиенту риски и коммуницируя сложности и возможности...

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

И все это как-то работает.

[От редакции: для полноты картины мы решили взять несколько комментариев у практиков Agile.]

Алексей Солнцев, Delivery Manager в Infopulse:

По-правде, в статье всё перевёрнуто с ног на голову. В первую очередь, заказчики любят Agile за счёт скорости вывода продукта или его новой версии на рынок. Во-вторых, те из них, кто когда-то встречался с процессами управления изменениями и такими понятиями, как «Change Request, Impact Analysis, Change Control Board», понимают, насколько дешево им может обходиться внесение изменений в требования, если они будут играть по правилам Agile.

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

Артем Сердюк, ScrumMaster и Agile Coach компании ISM Ukraine:

Если клиенты вмешиваются в выбор процесса (а им и кроме этого есть, чем заняться), в дело вступают не «предрассудки», а ценности: то, что для заказчиков важно в ИТ-проектах. А важна для них надежность, предсказуемость, стабильность. Любой стандартный процесс разработки для заказчика лучше, чем бардак. Неважно, как это называется — Scrum, RUP или CYADD, до тех пор, пока команда выполняет обещания и есть ощущение контроля, клиенту глубоко плевать на процесс.

Другое дело, что Scrum, который мы в этом случае внедрили, — ни в коем случае не Agile-процесс. Agile-процесс — это процесс, который рождается по ходу разработки. Повторю: не продукт эволюционирует (заказчик сам не знал, чего хотел), а процесс. Те правила, которые есть на старте, не работают и все время меняются. Роли меняются. Длина итераций меняется. Только очень-очень базовые вещи остаются... да и то не всегда.

В той среде, о которой говорит автор (кросс-функциональная команда профессионалов, и все в одной комнате, включая заказчика), Agile-процесс не нужен! Все стабильно, все правила известны — к чему тут адаптироваться? Будет работать абсолютно любой процесс.

А вот когда у вас распределенная команда, разница с клиентом в 12 часов, новая для него и для вас предметная область — вот тогда процесс будет и правда Agile. Эксперименты, провалы, эксперименты, успехи. И этот Agile ненавидят как заказчики, так и команды разработки, потому изобретение нового — это постоянный стресс, это невыносимо. Но Agile — единственный известный нам способ работать в таких сложных и непонятных условиях. Поэтому так и работаем.

Managers have become skilled at juggling changing priorities. What is different is that customer expectations have changed. People expect shops to be open earlier and later, to get answers on line 24 hours a day, seven days a week, and appointments outside of normal working hours. At the same time there is huge pressure to reduce operating costs, staff numbers and to do more with less.

Many traditional project management approaches are about attempting to limit change to 'keep the project on track'. This is fundamentally the wrong approach. If something needs to change with a project it should or you risk project failure.

There is no simple solution - but the ideas set out here draw on the approach of some of the most successful companies in the private sector and can really help deliver change which is sustainable, affordable and valued by customers and stakeholders.

Dr Penny Pullan, Director of Making Projects Work Ltd, said "Most of us who manage projects nowadays find ourselves operating in an environment of continual change. Our projects are full of uncertainty, complexity and ambiguity. So what can we do? What is the answer? How can we make things work? I think that this short book gives a big part of the answer. Tony draws on Lean and Agile to bring together the most useful ideas into a practical guide for project managers, whatever their field. Tony taps into his deep experience of running projects and programmes from both private and public sectors to come up with a very readable book, free from the jargon and buzzwords often found elsewhere."

При сравнении Waterfall и Agile необходимо осознание того, что Waterfall — это подход, хорошо описанный и детализированный. А вот Agile - это, скорее, набор практик и принципов, которые так или иначе поддерживают различные методологии гибкой разработки проектов.

Итак, предлагаем Вашему вниманию сравнение, предложенное Максимом Довгополым.  

Оригинал статьи здесь.

Сильные стороны

Слабые стороны

Когда использовать

Какой вывод можно сделать?
Два подхода со своими плюсами и минусами, каждый из которых прекрасно подходит для применения в проектах с совершенно разными входными данными и требованиями.

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

Задача руководителя проекта — выбрать наиболее подходящий способ для достижения целей проекта. Waterfall, RUP, Scrum, RAD, XP, FDD, TDD и другие методологии вам помогут этого добиться, если вы понимаете разницу между ними, их принципы, слабые и сильные стороны. В некоторых случаях, это не выбор между методологиями, а правильная комбинация подходов для каждого из этапов проекта.

И, как утверждает автор анализа, Waterfall и Agile могут быть оптимально применены в рамках одного проекта.

Хорошая онлайн-программа-manager для Scrum или Kanban. Богатый функционал и удобство использования. И, что приятно, команде из 5-ти человек пользование обойдется бесплатно!

Ресурс скрывается здесь.

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

Эта книга предназначена для гибких тестировщиков, гибких команд, их менеджеров и заказчиков.

На правах инфопартнера: сообщаем Вам, что 4-5 октября - конференция «AGILEEE 2013» в Киеве.

Agile Eastern Europe в 2013 исполняется пять лет! Праздновать успех и учиться новому - вот минимум два повода присоединиться к конференции в этом году.

AGILEEE 2013 – горячие темы на главных сценах

На конференции вы узнаете, что сможете сделать именно вы, от Тобиаса Майера, подумаете о результатах вместе с Дэвидом Хассманом, выйдете за рамки обычного менеджмента с Бьярте Богснесом, будете учиться умнее с Алистером Кобурном, расскажете о Скраме сотрудникам за пределами IT с Борисом Глогером, и многое другое.

AGILEEE 2013 – возможность погрузиться в практику

Во второй день конференции несколько потоков с практическими занятиями. Некоторые из них:

•  Kanban —     Isn't It Just Common Sense?.Карл Скотланд научит применять эвристику в решении сложных комплексных  проблем.
•  BDD Clinic — принесите Элизабет Кеох проблему, узнайте диагноз и получите пилюли.
•  Leading Self-Organizing Teams – о том, как организовать и мотивировать команду, поговорит Андреа Провальо.

Короленко сообщил, что проект Ostriv.TV не похож на другие существующие ресурсы, поскольку дает возможность не только заявить о себе, но и получить вознаграждение за таланты. По его словам, у зарегистрированных пользователей существуют три возможности заработка - от рекламы (порядка 50% возможного заработка), от так называемой реферальной системы (ок. 10%) и посредством конкурсов.

Короленко подчеркнул также, что модераторы ресурса Ostriv.TV будут модерировать загружаемые материалы, что обеспечит защиту авторских прав. Однако это касается преимущественно текстов и фотографий. "Проверить остальные материалы невозможно", - считает Короленко.  

Американский апелляционный суд в Сан-Франциско во вторник заявил, что Google "ушла слишком далеко" от простого сбора картографических и радиографических данных, когда попыталась собрать данные о WiFi-сетях пользователей при помощи Google-мобилей.

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

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