Лабораторная работа№2. Тема 1 История и методология управления проектами. Тема 1 История и методология управления проектами Зарождение и становление управления проектами
 Скачать 1.1 Mb.
|
|
Ежедневные летучки - это возможность для всей команды собраться вместе и убедиться, что все хорошо (или обнаружить проблемы). Вместо того, чтобы фокусироваться на сделанном вчера (один из трех вопросов типичной «летучки»), я предпочитаю, чтобы члены команды рассказали остальным, что собираются сегодня сделать и попросили помощи, если это необходимо. Это позволяет всем остальным быстро определить, нет ли у них препятствий в работе и решить, могут ли они внести какую-то лепту в усилия других членов команды. Вы можете использовать тот же подход, чтобы масштабировать Agile применительно к крупным задачам с несколькими командами, множеством проектов (или рабочих потоков) и, возможно, даже разными часовыми поясами. Без планирования вы не сможете масштабировать. К несчастью, многие считают, что если вы масштабируете, то планировать не можете. Звучит так, как будто придется проделать кучу работы. Ну да, так и есть. Планирование требует дисциплины, и это показатель успешности проекта - не единственный показатель, но существенный. Вам нужно иметь способность фокусироваться на малом количестве задач и делать их хорошо, нежели применять более традиционный подход - планировать все подряд и быть рабом плана. Балансировать между потребностью знать лишь необходимое и желанием знать все (чего никогда не бывает) сложно, но если вы следуете принципам, описанным выше, то я знаю, что вы готовы к хорошему старту. Пол является экспертом и в гибких, и в традиционных методах разработки, а также в их влиянии на организационную структуру, но его главный приоритет - это создание высокоценного ПО, решающего проблемы бизнеса или имеющего преимущества на рынке. Это позволило ему стать лидером во внедрении новых подходов в разработке ПО, не теряя при этом из вида настоящих причин и потребностей этого внедрения - того, что устаревшие методы больше не работают, а более эффективные принципы и практики жизненно необходимы бизнесу в долгосрочной перспективе. Этот прагматичный и эффективный подход привел к тому, что Пол постоянно востребован большими и малыми IT-компаниями и в США, и в Европе, где он возглавляет формирование и тренинг команд разработки ПО, работая с руководителями над пониманием их перехода к более гибкой модели руководства и позволяя географически разрозненным командам укрепить сотрудничество и качество работы. Инструменты для ретроспективы Ретроспективы – один из самых важных инструментов Agile (и не только), который позволяет командам становиться лучше. А ещё это – совещание, требующие наибольшей открытости (и уязвимости) всех членов команды. По этой причине к ретроспективе следует готовиться очень тщательно. Выбор техник и инструментов для ретроспективы во многом определяет её успешность. Здесь я собрал краткое описание нескольких техник. Этот список не полный, и я не возьмусь утверждать, что эти техники – лучшие (в таком сложном вопросе вообще не может быть лучших техник – каждая ретроспектива уникальна). Все техники разделены на три группы: упражнения для открытия ретроспективы, для середины (основная часть ретроспективы) и вспомогательные техники. Дополнительную информацию можно найти по ссылкам, приведённым в конце статьи. Упражнения для начала ретроспективы Каждому члену команды предлагается назвать и записать на доске одно слово, лучше всего передающее его личные ощущения и впечатления от прошедшего спринта. Это упражнение можно также использовать в середине или в конце ретроспективы для оценки самой ретроспективы (“Назовите одно слово, наиболее точно описывающие ваши впечатления от ретроспективы”). На что обращать внимание. Посмотрите, есть ли какие- то паттерны в называемых словах. Если все они так или иначе связаны с успехом, помогите команде отпраздновать этот успех, в случае, если они связаны с проблемой – помогите выявить причину этого и найти способ для решения. Если одно или несколько выбранных слов указывают на возможные проблемы с ощущением безопасности, обязательно начните обсуждение и помогите команде раскрыть проблему и найти решение. Проверка безопасности Попросите участников оценить их ощущение безопасности ретроспективы по шкале от 1 до 5, анонимно записать оценки на стикере и передать вам. “5” означает, что я чувствую себя абсолютно безопасно, буду полностью открыт и честен во время встречи и готов обсуждать любые вопросы, “1” означает, что я не чувствую себя в безопасности и буду помалкивать. Можно также попросить участников при желании записать краткий комментарий, поясняющий поставленную оценку. На что обращать внимание. Если вы получили оценки меньше 3, возможно следует начать обсуждение и поискать пути к созданию более безопасной среды. Комментарии, написанные участниками могут помочь в поиске решения, однако не должны разглашаться, чтобы не нарушить анонимность. Выразить благодарность Это упражнение позволит улучшить настрой команды и укрепить их взаимное доверие. Предложите участникам по желанию выразить благодарность кому-то из членов команды. Необходимое условие: благодарность должны быть выражена в форме “Я благодарен <Имя> за то что…”. Вы можете предложить участникам выразить благодарность, или, в качестве побуждения, самостоятельно поблагодарить кого-то из участников. Важно не оказывать личного давления при этом; если все молчат – дайте команде помолчать, так чтобы инициатива благодарности исходила от команды. Будьте готовы выдержать паузу порядка 15 секунд, прежде чем завершить упражнение. На что обращать внимание. Если кто-то из участников выразит это в виде “Я хочу (хотел бы) поблагодарить…”, следует попросить его перефразировать высказывание. Важно, чтобы выражение благодарности было в личной форме (“Я благодарен”). Тот, кто принимает благодарность не должен благодарить за что-то в ответ, достаточно просто сказать “Спасибо”. Следует быть очень внимательным к шуткам в отношении выражающего благодарность – в этот момент говорящий более уязвим. Упражнения для середины ретроспективы Командный радар Рисуем командный радар с 7 осями: Владелец продукта, Инженерные практики, Тестирование и обеспечение качества, Командная динамика, Скрам мастер, Требования, Устранение препятствий. Каждая ось разделена на 10 делений. Каждый член команды выставляет оценки по каждой оси, передаёт листочек с оценками ведущему, который формирует общий график, указывая точками оценки каждого из участников. Упражнение позволяет выявить области, требующие наибольшего внимания со стороны команды: оси с минимальной оценкой как точка роста, оси с наибольшим разбросом оценок как области внутрикомандного несогласия. по результатам выполнения упражнения ведущий может предложить обсудить какие-то области либо выбрать 1-2 области, которые команда будет улучшать в следующем спринте. На что обращать внимание. Обратите внимание на оси, по которым наблюдается наибольший разброс оценок, либо есть 1-2 оценки сильно отличающиеся от остальных. Предложите команде обсудить причины такого положения дел, и выявить причины разногласий. Вариации упражнения. Вы можете использовать иные оси для этого упражнения, или предложить команде самостоятельно определить области, наиболее важные для успеха команды, которые лягут в основу их радара. Парусник На доске рисуется парусник, так чтобы примерно половина пространства доски была выше, а половина – ниже парусника. Ведущий объясняет, что парусник – это образ команды. Есть якоря, которые замедляют парусник (вещи, которые мешают команде), и ветер, который ускоряет парусник (вещи, которые помогают команде). Команде предлагается подумать о том, что ей мешает/помогает, и записать по одному якорю/дуновению ветра на стикере. Потом команда поочерёдно выходят к доске и клеят свои стикеры, поясняя своё мнение при необходимости. Далее команде предлагается совместно сгруппировать стикеры, зачитывая их вслух. После этого команде предлагается записать название для каждой из получившихся групп. После этого команда голосует за те стикеры или группы, над которыми команда хочет поработать. На что обращать внимание. На этом этапе группировки может оказаться, что кто-то из команды начинает продвигать свою точку зрения, подавляя остальных. В этом случае ведущему нужно вмешаться так, чтобы все имели возможность высказаться. Вариации упражнения. Вышеописанная схема описана Люком Хохманом (Luke Hohmann) в книге “Innovation Games”. Есть много вариаций этого упражнения, одна из наиболее известных описана в книге “Извлекаем пользу из Agile-ретроспектив” Луиса Голсалвес (Luis Gonçalves) и Бэна Линдерс (Ben Linders). В их варианте в упраженении присутствуют также подводные камни и острова (Острова символизируют цели/видение команды. Члены команды работают каждый день, чтобы добраться до этих островов. Подводные камни представляют собой риски, которые команда может встретить на своем пути.) Вспомогательные инструменты Кулачное голосование (Fist of Five) Этот способ голосования позволяет определить наличие консенсуса в группе. Голосование производится поднятием рук по команде ведущего (например, “раз-два-три”). Каждый показывает степень своего согласия с предложением/идеей количеством пальцев: Пять (раскрытая ладонь) – полностью согласен, готов вложить свои силы в её реализацию. Четыре – идея не идеальная, но хорошая, я её поддерживаю. Три – я вижу небольшие недостатки в предложенной идее, но для того, чтобы мы могли двигаться вперёд, принимаю её. Два – я вижу существенные недостатки в идее, и готов её поддержать только после того, как мы обсудим это и скорректируем идею, чтобы устранить эти недостатки. Один – я вижу слишком серьзные недостатки, и не могу поддержать идею. (Иногда применяется Сжатый кулак – я категорически против и не готов менять своё решение.) Если при голосовании нет оценок ниже 3, можно считать что в команде есть консенсус. Если кто-то из участников показал 2 или 1, можно инициировать обсуждение, в ходе которого команда постарается устранить разногласия. (С участником поднявшим кулак возможно потребуется персональная работа, чтобы выявить причину его категорического настроя.) Голосование точками Этот способ голосования позволяет выбрать из большого списка несколько идей, поддерживаемых большинством участников. Каждый участник получает фиксированное число голосов (обычно – три) и может отдать либо все три голоса за одну идею, либо распределить их каким-то иным образом. В качестве голосов могут использоваться небольшие наклейки, стикеры-закладки, либо просто точки, которые ставятся маркером для доски напротив идей. После того, как все участники проголосовали, подсчитывается число голосов за каждую идею, и дальнейшая работа идёт с идеями, набравшими наибольшее число голосов (обычно – 1-2 идеи). Ключевые моменты в применении Agile Agile-методология основывается, в первую очередь, на визуальном контроле. Чаще всего участники проекта, работая над достижением результата, пользуются специальными цветными карточками. Один цвет сигнализирует о завершении планирования какого-то элемента конечного продукта, другой – о завершении его разработки, третий – о готовности и т.п. Визуальный контроль позволяет команде иметь наглядное представление о текущем состоянии процесса и гарантирует одинаковое видение проекта всеми ее членами. Члены команды и клиент в большинстве случаев работают вместе и рядом. Благодаря этому существенно ускоряются многие рабочие процессы, которые связаны с информированием участников проекта. Кроме того, совместная работа способствует созданию здоровой атмосферы для плодотворного и эффективного сотрудничества и скорейшего достижения результатов. Когда руководитель проекта, команда и клиент действуют сообща, исключается опасность недопонимания целей и утери информации. Все рабочие процессы становятся максимально прозрачными, а это значит, что любые возникающие проблемы можно разрешать практически моментально и находить лучшие варианты их решения. Особое внимание нужно уделить руководителю проекта. Его нельзя назвать человеком, раздающим указания налево и направо. Руководитель здесь выступает скорее в роли лидера, который задает направление и определяет правила сотрудничества и работы. Другими словами, Agile-управление является адаптируемым. Еще одним важным моментом Agile-методологии является разделение всего объема проекта на несколько более мелких составных частей. Такой подход многократно упрощает процесс разработки, а отдельные группы команды могут фокусироваться каждая на своей конкретной задаче. Работая над одним циклом, участники проекта овладевают новыми навыками и получают новые знания, а также анализируют допущенные в процессе ошибки. Все это сводит вероятность совершения подобных ошибок в будущем (в следующих циклах и других проектах) практически к нулю. И, наконец, последний значимый элемент подхода – это спринты и ежедневные встречи. Спринтами называются ограниченные конкретными сроками (дедлайнами) отрезки времени, в течение которых команда успевает выполнить определенные задачи. Именно благодаря спринтам команда может видеть результаты своих действий. Если же мы разделим все время, отведенное на проект, на несколько спринтов, получим конкретное их количество; пусть их будет 15. Каждый спринт длится, к примеру, две недели. Вот как раз в течение этих двух недель (времени, отведенного на спринт) участники каждый день встречаются для обсуждения процесса и прогресса. Ежедневные встречи не должны превышать 15 минут. Организуются они для того, чтобы каждый член команды дал себе же ответ на три вопроса: Что я делал вчера? Чем я буду занят сегодня? Что мешает мне работать? Ответы на эти вопросы позволяют держать под контролем процесс, понимать, на какой стадии находится каждый из участников команды, и устранять потенциальные проблемы на пути к цели. Если же обобщить, то внедрение Agile-методологии возможно, если соблюдается несколько условий: 1. Четко обозначается значение проекта 2. В процессе реализации активно участвует клиент 3. Общий объем работ выполняется пошагово 4. Ориентироваться следует на конкретный результат 5. Численность одной рабочей группы: от 7 до 9 человек В настоящее время проект-менеджмент с поддержкой Аджайл по большей части распространен в IT-сфере, однако и деловая сфера его начинает осваивать. Эта система применяется в обучении, маркетинге, бизнесе. Гибкое управление проектами берется на вооружение множеством компаний и государственных структур. Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это). Эти и многие другие организации используют в работе самые разные методы управления проектами, основанные на Agile. И поговорить об этих методах не менее важно, чем о самой методологии. Популярные методы управления проектами Существует немало методов проект-менеджмента, которые применяются разными современными компаниями. Но самыми известными и востребованными среди них по праву считаются Scrum (Скрам) и Kanban (Канбан). Метод Scrum Среди всех методов системы Agile Scrum отличается тем, что делает основной упор на качественный контроль рабочего процесса. Впервые описавшие его японские специалисты по стратегическому менеджменту Хиротака Такуэти и профессор в области научно-технических знаний Икуджиро Нонака называют метод «подходом в рэгби», где Scrum является «борьбой за мяч». Метод заключается в том, что разработка проекта разделяется на спринты, по окончании которых клиент получает улучшенное ПО. Спринты строго фиксируются по времени, и могут длиться от 2 до 4 недель. Рабочий процесс в одном спринте включает в себя несколько стадий: Определяются объемы работы Каждый день проводятся 15-минутные встречи, чтобы члены команды могли скорректировать свою работу и подвести промежуточные итоги Демонстрируются полученные результаты Спринты обсуждаются для поиска удачных и неудачных решений и действий В большинстве случаев Скрам применяется в работе со сложным ПО и для разработки продукта с использованием инкрементных и итеративных методов. Благодаря ему серьезно повышается производительность команды и сокращаются временные затраты на достижение цели Scrum улучшает результаты, помогает адаптировать проект к изменениям, обеспечивает более точную оценку при меньших трудозатратах на анализ и позволяет эффективнее контролировать этапы работы и сценарий проекта. Все это как нельзя лучше соответствует бизнес-целям. Метод Kanban Канбан – еще один метод, делающий командную работу более результативной и продуктивной. Смысл его сводится к приданию процессу разработки максимальной прозрачности и равномерному распределению нагрузки среди участников проекта. Важная особенность Kanban еще и в том, что он мотивирует людей на постоянное сотрудничество, совершенствование и обучение. Работа по методу Kanban выстраивается на нескольких принципах. Во-первых, вся информация о проекте должна быть визуализирована, что позволяет видеть накладки, ошибки и недочеты и активно их устранять. Во-вторых, работа над одной задачей должна вестись одновременно всей командой – это помогает сбалансировать усилия и получаемые результаты, исключает неравномерное распределение нагрузки. И, в-третьих, время на выполнение всех задач строго контролируется, благодаря чему оптимизируется процесс и экономится время. В отличие от Скрам, Канбан обрел популярность намного позже, но это ни в коей мере не умаляет его достоинств и не делает менее эффективным. Метод полезен как в IT-области, так и в бизнес-сфере. Это лишь примеры основных методов управления проектами, основанных на Agile. Но не стоит пренебрегать и другими методами, такими как PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall и другие. К тому же у Аджайл, наряду с преимуществами, есть и некоторые недостатки. |