Журнал LinuxFormat - перейти на главную

LXF144:projects

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Новая страница: «=Управление проектами ''на примере проектов сообщества открытого ПО''= : '''Джоно Бэкон''' д…»)
 

Текущая версия на 19:39, 27 июня 2014

Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

[править] Управление проектами на примере проектов сообщества открытого ПО

Джоно Бэкон делится опытом и советами по ведению проекта открытого ПО или сообщества.

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

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

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

В нашей статье мы обсудим ряд подсказок, технологий и подходов к выполнению проекта. Эти предложения применимы к проектам любого типа, не только к разработке ПО, хотя, конечно, основной упор будет на ней. Для проекта другого типа просто смените терминологию, и совет будет отвечать вашим нуждам (например, если вы готовите встречу, то вместо Релиза у вас будет стоять Мероприятие)

Как мы вывели из материала прошлого номера Работа вашей мечты, LXF143, опыт участия и управления проектами открытого ПО – прекрасный пункт в вашей биографии или резюме, и методики статьи направлены на это. Если вы сумеете предъявить сильные, организованные и подтвержденные качества руководителя проекта, все работодатели будут ваши. Итак, пристегните ремни безопасности – выезжаем на трассу хорошо управляемых проектов.

[править] Ключ — планирование

Ключевыми моментами в успешном управлении проектом являются a) организованность, b) задание ожиданий, и c) убеждение людей поверить в ваш проект и вступить в него. К счастью, начав с пункта a, вы попадете в пункт b, а тот, в свою очередь, вдохновит вас на пункт c. Другими словами, хорошая организованность помогает задать цели и убедить людей поверить, что ваш проект стоит участия. Для достижения этого требуются три положения:

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

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

[править] Видение

Решить, что вы хотите сделать, звучит проще, чем есть на самом деле. Определяя жизнеспособность функции, нужно оценить не только то, хватит ли вашей команде умения для ее воплощения, но также объем трудозатрат, чтобы завершить ее одновременно со всем остальным. Также нужно убедиться, что определив цель, вы сплотите команду вокруг этой цели и предотвратите дублирование усилий. Планирование также эффективно устанавливает ожидания у потребителей вашего труда (пользователей программы, посетителей мероприятия и т. п.).

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

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


На встрече документируйте эти планы с помощью следующего шаблона, который поможет вам четко определиться с видением проекта:

  • Задача Укажите цель.
  • Критерий успеха Приведите утверждение, на которое можно ответить «да» или «нет», определяющее, выполнена ли работа.
  • Действия Добавляйте действия высшего уровня. Не следует мельчить; подробности появятся позже. Действия не обязательно назначать каждому.
  • Срок Когда вы хотите завершить проект.
  • Спецификация Более детальное описание цели и как она сформировалась.
  • Владелец Человек, который будет координировать всех участников проекта.

Наличие этих целевых блоков создаст вам твердое представление о целях проекта и координаторах для каждого из блоков задач.

[править] Планирование

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

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

К концу этого шага у вас должен быть набор целей в одном документе и другой документ, со всеми действиями. Сейчас вы в положении, когда вся работа согласована и роздана исполнителям. Хороший лидер должен пройтись по плану еще раз и убедиться, что никто не перегружен работой. Если это так, спросите, можно ли передать некоторые действия другим, рассредоточив нагрузку.


[править] Слежение за прогрессом

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

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

Справляться с подобными непредвиденными обстоятельствами – значит иметь a) отличное видение завершенной работы и b) хорошее чувство того, кто над чем работает – где гибкие места, а где проблемы. Существуют утилиты, способные помочь вам с a, одну из которых мы обсудим ниже (см. Диаграмма догорания), но b включает проведение времени с командой, обзор текущей работы, да обычно и пребывание в той части группы, которая органично работает и взаимодействует. При хорошем видении проекта и людей вы сможете гарантировать успешное завершение, невзирая на непредвиденные обстоятельства.

[править] Делиться опытом

Перенимание опыта других людей и опробование новых техник – лучшие способы развить и усовершенствовать собственные навыки. Прекрасный шанс для этого – спросить людей, как они управляют проектами, и изучить их подходы. Раз так, я решил, что будет полезно показать вам, как я управляю командой из Canonical: эти методы могут пригодиться в ваших проектах и ваших командах.

Ubuntu Community Team состоит из четырех человек: Даниэля Холбаха [Daniel Holbach], Хорхе Кастро [Jorge Castro], Давида Планеллы [David Planella] и Ахмеда Камаля [Ahmed Kamal]. Совместно эта команда работает над проектами сообщества. Эти проекты способствуют росту, новым возможностям и производительности в сообществе Ubuntu. Я управляю командой, разбивая шестимесячный цикл релизов Ubuntu на серию задач по управлению проектом:

  • Сбор требований
  • Планирование целей
  • Запуск работы
  • Отслеживание прогресса


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

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

Обычно такой процесс приводит к появлению на странице wiki громадного списка с маркированными пунктами, указывающего на то, сколько всякого-разного хочется людям. Следующий шаг – расставить приоритеты в этом списке, выделив задачи, которые при текущих ресурсах достижимы за шестимесячный цикл релизов. При управлении проектом открытого ПО определитесь, чего, на ваш взгляд, можно достичь за данный временной интервал с данным количеством участников.

Это очень сложная задача. Если вы человек того же склада, что и я, вы будете пытаться сделать больше, чем позволяет ваше время, и здесь нужно принимать трудные решения. По мере моей работы со списком маркированные пункты преобразуются в целевые блоки, которые мы рассматривали ранее, и они тоже размещаются на странице wiki. Этот документ будет нашей дорожной картой. Страница служит двум полезным целям: помогает команде понять, на чем следует сосредоточить усилия, а также поясняет заинтересованным сторонам, чего ожидать от команды на данном цикле релиза.


Дорожная карта удобна для просмотра задач, над которыми бьется команда, но ее недостаточно, чтобы группа разобрала проекты на более мелкие куски для планирования своей работы На этом этапе Давид Планелла, координатор Ubuntu Translations, хотел запустить серию сеансов тренинга переводчиков. Четырех пунктов на карте про эту задачу не хватало для планирования работы, и он разбил ее на такой набор действий:

  • Сделать запись в блоге, приглашающую сообщество дать обратную связь по темам, которые они хотели бы видеть в сеансах тренинга, и принять участие в этих сеансах.
  • Создать имя http://wiki.ubuntu.com/Translations/Training для информации, связанной с сеансами тренинга.
  • Записать документ в Ubuntu wiki со списком тем, желательных в сеансах тренинга.
  • Выбрать несколько тем оттуда для сеансов тренинга переводчиков и приготовить набросок для каждого из них.
  • Создать проект Launchpad (http://www.launchpad.net) в качестве площадки для сеансов тренинга переводчиков.
  • Начать сеансы тренинга переводчиков согласно выбранной схеме.

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

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

[править] Диаграммы догорания

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

(thumbnail)
Рис. 1
Диаграмма выгорания


Эта технология называется «диаграмма выгорания» [Burndown chart] (см. Рис. 1). Мой коллега Мартин Питт [Martin Pitt] написал программу, которая берет все действия, занесенные в планы-копии команды, и выдает график, показывающий их состояние. Когда команду просят поместить действия в план-копию, она добавляет его в стандартном формате, где указывается, кому приписано действие, и его состояние. Например, «[dpm] написать документ в Ubuntu wiki со списком тем, которые мы хотели бы охватить в сеансах для переводчиков: Сделано».

Здесь приведено действие, приписанное Давиду Планелле («dpm»), и он завершил это действие («Сделано»). Состояние действия может принимать значения To Do, В процессе и Отложенное.

Скрипт Питта считывает все пункты действий, вместе с приписками и статусами, и рисует диаграмму на Рис 1. По оси X отложена продолжительность 6-месячного цикла, по оси Y – полное количество действий в цикле. Каждый день на диаграмме появляется новая полоса, которая разделяет все действия на To Do [Надо сделать] (красный), Done [Сделано] (зеленый), Postponed [Отложено] (желтый) и In Progress [В процессе] (оранжевый). Из левого верхнего угла в правый нижний угол протянута жирная черная линия тренда. Задача менеджера – следить, чтобы красный цвет был ниже этой линии: это показывает, что во всех действиях происходит согласованный прогресс.

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

[править] Заключение

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

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

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


Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF144:projects&oldid=15084»
Персональные инструменты
купить
подписаться
Яндекс.Метрика