Лабораторная работа№2. Тема 1 История и методология управления проектами. Тема 1 История и методология управления проектами Зарождение и становление управления проектами
 Скачать 1.1 Mb.
|
|
Команда разработчиков Командой разработчиков называется группа из 5-9 инициативных и самостоятельных человек – членов команды. Ее первостепенная задача состоит в постановке реально достижимой, прогнозируемой, интересной и значимой цели для каждой итерации. Следующая задача состоит в достижении поставленной цели в указанные сроки и в надлежащем качестве. Цель итерации можно считать достигнутой лишь тогда, когда реализованы все поставленные задачи, прописаны коды (если это IT-разработка), протестирован рабочий вариант продукта, установлены и устранены все дефекты. Члены команды разработчиков должны быть в состоянии планировать и оценивать свою работу, уметь работать в команде , систематически анализировать качество своего взаимодействия и работы и улучшать его. Краткий перечень обязанностей команды разработчиков: Оценка элементов бэклога продукта (см. ниже) Разработка продукта и предоставление его заказчику Отслеживание своего прогресса (совместно со скрам-мастером) Предоставление результата владельцу продукта Все вместе участники проекта проделывают не только основную работу, но и реализуют скрам-практики. Практики в Scrum Как и ролей, практик в Scrum-управлении проектами существует три: Ежедневные Скрам-встречи (Daily Scrum Meeting) Встречи по обзору спринта (Sprint Review Meeting) Аварийная остановка спринта (Sprint Abnormal Termination) Все эти практики имеют самое прямое отношение к спринтам, поэтому сначала скажем несколько слов о том, что вообще такое спринт. Спринт Спринтом в Scrum-проекте называется одна итерация (фаза) проекта. В большинстве случаев спринт длится 30 дней. В результате каждого спринта команда должна получить рабочую версию продукта, которую уже можно демонстрировать заказчику. Подготовка к самому первому спринту начинается после подготовки владельцем продукта плана проекта, определения требований и их сортировке в объеме, подходящем для одной итерации. Этот список и называют бэклогом (или журналом) продукта. В процессе планирования спринта детально разрабатываются сессии его планирования. Спринт всегда начинается с разработки владельцем, скрам-мастером и командой разработчиков плана развития продукта, плана релизов и требований. Команда разработчиков определяет оценки требований, чтобы убедиться, что они точны в степени, необходимой для начала работы. Затем определяется объем работ, который может быть успешно выполнен за один спринт. При этом нужно исходить из численности команды, доступного времени и производительности. Очень важно, чтобы команда разработчиков внимательно изучала журнал продукта и выбирала требования, первые по приоритету. Как только команда разработчиков объявляет о своей готовности к реализации выбранных требований, скрам-мастер планирует спринт. Затем команда делит выбранные требования на задачи, которые нужно реализовать для успешного окончания спринта. В идеале на этот этап (разделение на задачи) не должно уходить более 4 часов, а в итоге нужно получить перечень разбитых на задачи требований, т.е. журнал спринта. Все участники команды разработчиков в обязательном порядке должны взять на себя ответственность по достижению поставленной цели На протяжении спринта должны выполняться все работы, которые нужны для получения рабочей версии продукта. Объем работ спринта должен быть фиксированным. Благодаря этому команда может взять ответственность за его реализацию. Исходя из этого, журнал спринта не может изменить никто, кроме команды. В деталях обо всем этом вы можете узнать из книги «Scrum – революционный метод управления проектами» Джефа Сазерленда, а мы продолжим разговор на тему практик. Познакомившись с ними, вы сможете понять, как реализуется Scrum-проект. Ежедневные Скрам-встречи Ежедневные встречи проходят по утрам перед началом работы. Они необходимы, чтобы каждый член команды знал, кто и конкретно чем занимается в текущем проекте. Оптимальная продолжительность таких встреч составляет 15 минут. В процессе не решаются никакие проблемы, т.к. участники просто делятся информацией. Если есть вопросы, требующие разрешения, они выносятся за пределы встречи. Проводит ежедневные встречи скрам-мастер. Поочередно каждому участнику он задает вопросы: Что ты сделал вчера? Что ты сделаешь сегодня? С какими проблемами ты столкнулся? Все открытые вопросы скрам-мастер заносит в список «Пункты действий». Здесь очень подходит формат «Что? Кто? Когда?». Вот простой пример такого списка: Обсудить детали дизайна бэкграунда Толя и Коля Сразу после обеда Участвовать в ежедневных встречах может любое заинтересованное лицо, однако все решения принимаются только членами команды разработчиков. Причиной этому служат обязательства участников по достижению цели спринта. Если кто-то иной будет вносить свою лепту в принятие решений, тем самым он снимет ответственность с членов команды. Встречи по обзору спринта По окончании каждого спринта принято проводить демонстрационную встречу, на которой происходит обзор спринта. Оптимальная продолжительность этих встреч – не более 4 часов. В начале встречи команда разработчиков показывает владельцу продукта его рабочую версию (демонстрирует результаты проделанной работы). Встреча проходит под контролем самого владельца, причем он имеет право пригласить на нее всех заинтересованных людей и их представителей. В процессе встречи владелец продукта оценивает, какие требования из журнала спринта выполнены, а также обсуждает результаты с командой и заказчиком, и вместе с ними планирует задачи для выполнения в новом спринте. Во второй половине встречи скрам-мастер вместе с остальными участниками анализирует прошедший спринт. Команда разработчиков определяет эффективные и неэффективные методы совместной работы , проводит их анализ, делает выводы и принимает решения, которые улучшат дальнейшую работу. По окончании встречи резюмируются итоги, и планируется следующий спринт (это происходит по уже рассмотренному нами обычному алгоритму планирования спринта). Закончив второй спринт, проводится новая демонстрационная встреча, и так по кругу вплоть до полного завершения Scrum-проекта. Аварийная остановка спринта Аварийная остановка спринта необходима только для особых случаев. Команда может остановить спринт до наступления дедлайна (крайнего срока завершения спринта), если осознает, что добиться поставленных в этом спринте результатов не получается. Также спринт может остановить владелец продукта в случае, когда необходимости в достижении цели спринта больше нет. Если спринт остановлен, все участники проекта собираются на общей встрече, обсуждают причины остановки и дальнейшие действия. После этого дается отмашка к началу нового спринта и его планированию, для чего используются все те же алгоритмы. Несложно заметить, что скрам-практики достаточно просты. Но кроме ролей и практик в Scrum-управлении проектами существуют еще и важные документы, называемые артефактами. Вкратце мы о них уже упоминали, но будет лучше, если немного углубимся в эту тему. Артефакты в Scrum В любом Scrum-проекте есть три основных артефакта (документа): Журнал продукта (Product Backlog) Журнал спринта (Sprint Backlog) График спринта (Burndown Chart) У каждого из артефактов есть свои особенности. Журнал продукта Журнал продукта готовится еще в самом начале проекта. Он представляет собой перечень требований, отсортированных по значимости. Составляет его владелец продукта, а команда разработчиков дополняет его, включая оценки стоимости реализации каждого требования. Журнал продукта должен включать в себя технические и функциональные требования, необходимые для его разработки. Эти требования необходимо приоритизировать, а самые приоритетные нужно детально прописать – так команда получает возможности их оценки и тестирования. Своевременная и подготовленная детализация проектов, а также предоставление их в полном объеме и в нужное время – это задачи владельца продукта. Журнал спринта Журнал спринта отражает функциональность, которую выбрал владелец продукта из составленного ранее журнала продукта. Каждая из функций разбивается на задачи. Разбивка же делается так, чтобы на выполнение одной задачи не уходило более двух дней. Благодаря качественной разбивке функций на задачи спринт может быть спланирован таким образом, чтобы к его окончанию не осталось ничего не выполненного, а значит, чтобы была достигнута цель итерации. Как только детализация завершена, оценивается журнал спринта, и эта оценка сопоставляется с первичной оценкой журнала продукта. При выявлении существенных расхождений команда разработчиков вместе с владельцем продукта устанавливает объем работ, которые необходимо выполнить в течение конкретного спринта, а также объем, который можно перенести на следующую итерацию. Из журнала спринта исключаются незначительные задачи, которые не оказывают особого влияния на достижение цели итерации. График спринта График спринта необходим для отображения ежедневного изменения общего объема работы, который остался до окончания спринта. С помощью него команда может анализировать текущую ситуацию и вовремя реагировать на изменения. Ко всему прочему, с помощью графика спринта владелец продукта может отслеживать прогресс итерации. Поэтому ему очень легко установить: если объем работы не становится меньше с каждым днем, значит, в процессе есть какие-то отклонения и срочно нужно корректировать действия команды. Таковы общие особенности Scrum-методологии. Если у вас возникло желание разобраться в этом методе более детально, то вам поможет в этом Джеф Сазерленд – познакомьтесь с уже упоминаемой книгой «Scrum – революционный метод управления проектами». А нам остается только подвести итоги этого краткого обзора Скрам. Выводы о Scrum Итак, относящийся к системе методов гибкого управления Agile, Scrum можно смело назвать настоящей находкой для людей, чья деятельность связана с проектами. Среди его достоинств выделяется, в первую очередь, ориентированность и адаптивность. Метод позволяет изменять требования к проекту в любое время (пусть и не дает гарантии того, что эти изменения будут реализованы). А такая возможность очень привлекает заказчиков. Во-вторых, Скрам очень легко освоить. К тому же метод не отнимает огромного количества времени. А благодаря тому, что система работы построена по итерационному принципу (и у каждой итерации есть своя цель), с помощью Scrum-метода можно получать рабочие версии продукта по окончании каждого спринта. В-третьих, упор в методе делается на многофункциональную и самоорганизующуюся команду, которая способна решать большинство задач с минимумом координации. Именно по этой причине Scrum-проекты подходят для стартапов и небольших компаний, избавляя их от необходимости обучать специализированный штат руководителей или нанимать профессионалов со стороны. Но не стоит думать, что Scrum-методология – это решение всех проблем и гарантия успеха. У нее есть и несколько минусов. Например, ее минималистичность и простота обуславливают, пусть и немногие, но все же жесткие правила, в частности – правила взаимодействия внутри команды, которые в некоторых случаях могут доставлять заказчику определенные неудобства. Еще один недостаток состоит в отсутствии плана реагирования на непредвиденные риски , ведь все действия участниками проекта осуществляются в режиме реального времени. И, наконец, упор на команду тоже не всегда полезен. Несмотря на то, что в координации команды нет особой необходимости (а значит, и нет затрат на нее), могут увеличиться затраты на подбор персонала, его обучение и мотивацию. Если, например, на рынке труда не хватает подходящих специалистов, придется нанимать либо дорогостоящих профи, либо не нанимать вообще никого. Однако преимущества Скрам-методологии не идут ни в какое сравнение с ее недостатками, и при определенной доле упорства овладеть ей не составит никакого труда. Использование же Scrum помогает компаниям реализовывать самые разные проекты и становиться более конкурентоспособными. Метод ориентирован на изменения и постоянное развитие, а его гибкость достигается посредством непрерывного взаимодействия участников проекта друг с другом. Железный треугольник управления проектом Бюджет, возможности и график образовывают так называемый железный треугольник управления проектом. Между ними важно научиться балансировать. Ведь, наверное, каждому известны примеры, когда для завершения работы необходим дополнительный бюджет или горят все сроки. Как быть в таких случаях, от чего отказаться и чем пожертвовать? Данная статья может помочь в поиске ответов на эти вопросы. При этом не только тем, кто ведет в компании сложнейшие проекты, но и обычному человеку, работающему на себя. Железный треугольник Устав проекта — это документ, который определяет цели и требования, необходимые для его воплощения в жизнь. Требования формируют железный треугольник, который ограничен возможностями, бюджетом и графиком (дедлайном). Треугольник называется железным по той причине, что если вы меняете один из его элементов, то это приводит к изменению двух остальных. И то, насколько эффективно вы справитесь с требованиями повлияет на качество в позитивную или негативную сторону. Предположим, вы разрабатываете проект новой автономной IT-системы. На этапе создания и проектирования вы понимаете, что треугольник трещит по швам, а это не позволит довести проект до завершения. Вы можете предпринять следующие действия: Продлить время работы над проектом. Вы понимаете, что не сможете создать качественный продукт, поэтому решаете выделить дополнительное время . Это приведет к дополнительным затратам на рабочую силу, однако так как качество — ваша главная цель, вы идете на это. Сократить длительность отдельных этапов. Такой подход может повысить риск неудачи или повлиять на качество продукта. Тем не менее, если к делу подойти творчески и выйти за рамки привычного мышления, можно обнаружить, что некоторые этапы можно объединить или и вовсе убрать без ущерба для проекта. Изменить возможности. Вы можете убрать из своего проекта некоторые функции, интерфейс и прочие возможности, которые посчитаете менее важными. Это позволит сэкономить бюджет и снизить время работы. При работе с любым проектом будут возникать проблемы и вам придется чем-то жертвовать. Нужно действовать решительно, предварительно все обдумав. Также попытайтесь понять разницу между лучшим и идеальным решением. В области деятельности под названием «управление проектами» существует правило- поговорка о том, что при рассмотрении трех факторов — быстро, дешево и хорошо — вы можете выбрать только два: Если вы создаете продукт дешевым и при этом быстро, то жертвуете качеством. Если продукт дешевый и качественный, значит вам потребуется значительно больше времени на его создание. Если продукт создается быстро и при этом он качественный, вам придется завышать на него цену. Структура принятия решения Используйте эту структуру всякий раз, когда вам нужно принять решение о том, что трансформировать в железном треугольнике. Важный совет: сделайте свой проект гибким, чтобы вы могли в максимально короткие сроки принять решение об изменении курса и добиться этого. 1Давление графика Есть ли задания, от которых можно отказаться без вреда? Если нужно, создайте новый план и подумайте над тем, можно ли добиться промежуточных целей при меньших усилиях и затратах. Есть ли у вас план на случай непредвиденных обстоятельств? Можно ли перенести некоторые из ваших целей в свой следующий проект? Какие этапы можно объединить? 2Давление возможностей Насколько критичны для вас бизнес-ограничения? Можно ли приостановить проект и пересмотреть бизнес-ограничения? Можно ли объединить два параллельных проекта и добиться поставленных целей? Можно ли переместить некоторые цели в список желаний и достичь их позже? 3Давление бюджета Можно ли выполнить задачу с меньшими тратами? Можно ли использовать более дешевые компоненты и ресурсы? Пострадает ли при этом качество продукта и будет ли это критично? Все ли этапы задачи необходимы для того, чтобы выполнить проект? Можно ли убрать некоторые из них? Можно ли снизить расходы на команду? Например, ограничить траты на командировки. Есть ли что-то из неучтенного вами, что можно использовать? Всегда помните о том, чего вы пытаетесь достичь. За рутиной и огромным трудом можно забыть, зачем делаешь то, что делаешь, и начать тратить деньги и ресурсы впустую. Подумайте о том, можно ли найти спонсора для вашего проекта. Как его заинтересовать дать вам деньги? Какую выгоду он получит? Не забывайте и о том, что иногда маленькие изменения дают большие результаты, а большие траты приводят к минимальным результатам. Изучите принцип Парето Бережливое производство Основная задача производственной системы состоит в постоянном совершенствовании так называемого «потока создания ценности» для целевой аудитории. Его основой служит рациональное сочетание всех процессов. Благодаря этому продукция может выпускаться с минимальными трудовыми затратами. Кроме того, это воздействует и на экономические показатели, а также на результаты производственно-хозяйственной деятельности организации, включающие в себя и себестоимость продукта, и рентабельность производства, и прибыль, и размер оборотных средств, и объемы незавершенного производства. Одновременно с этим, для многих организаций важнейшим остается вопрос эффективности производственных процессов с позиции сложности и продолжительности производственного цикла. Чем он длиннее, тем больше задействовано в нем дополнительных производств, тем меньшей эффективностью отличается производство вообще. К тому же приходится прилагать массу усилий, чтобы координировать процесс и обеспечивать бесперебойную работу. Именно для решения этой проблемы многие компании внедряют в свою деятельность систему бережливого производства, позволяющую оптимизировать производственный процесс, повышать качество производимого продукта и сокращать издержки. Ему и посвящена эта статья. |