управление процессом разработки ПО небольшой командой специалистов
В любой организации существует необходимость в том, чтобы автоматизировать некоторые, свойственные только ей процессы. В случае, когда потребность в создании специального ПО существенно влияет на бизнес, такое ПО может быть заказано для разработки в сторонних компаниях. Однако зачастую организация вполне способна справится с автоматизацией своими собственными силами - с помощью небольшой группы разработки (от одного до трех человек).
Риск заключается в том, что управление процессом разработки в этом случае может лечь на плечи людей, основная специальность которых не связана напрямую с такой деятельностью - программистов, инженеров других специальностей или менеджеров, не знакомых со спецификой разработки ПО. Это может быть первый опыт такого рода для данной организации. При этом не менее важно обеспечить приемлемый уровень качества процессов, связанных с разработкой.
Эта статья написана на основе опыта, полученного мной за год работы менеджером проекта и разработчиком ПО в небольшой телекоммуникационной компании. В ней рассматриваются основные процессы, связанные с разработкой ПО, которые я смог выделить и формализовать. Я стараюсь дать основные рекомендации, которые могут быть полезны при управлении разработкой ПО в такого рода компаниях.
Чтобы стало более понятно, о чем идет речь, для начала я постараюсь дать общую картину производства в области разработки и сопровождения ПО в компаниях, профиль которых не связан напрямую с разработкой ПО.
1. Большое число задач (более половины) связано с сопровождением, поддержкой и доработкой существующего ПО.
2. Задачи, связанные с сопровождением существующих систем, практически независимы друг от друга, могут быть решены за небольшое время, но возникают часто и требуют оперативного решения.
3. Разработка и сопровождение ведется небольшой группой специалистов, а зачастую и вообще одним человеком.
4. Как следствие, отсутствует явное разделение ролей в процессе: один и тот же человек может совмещать позиции разработчика, аналитика, архитектора, тестера, системного администратора, менеджера проектов и т.д.
5. Проекты чаще всего не выходят за рамки внутреннего использования.
Как следствие, процесс разработки ПО в таких компаниях в силу объективных причин достаточно примитивен. Многие технологические процессы отсутствуют или присутствуют в сильно упрощенном варианте. Тем не менее, и такими процессами необходимо управлять и гарантировать приемлемое качество их выполнения.
общие рекомендации по организации процесса разработки
Прежде чем озаботиться созданием основ технологии, необходимо по максимуму решить все организационные проблемы. В литературе часто
рассматривается вопрос организации рабочей среды в компании-разработчике ПО, однако, для компании, в которой отдел разработки совсем небольшой (1-3 человека), многие из этих рекомендаций покажутся излишними. Тем не менее, таким компаниям рекомендации нужны не меньше. Из своего опыта я могу рекомендовать следующее.
1. Постарайтесь, насколько возможно, разделить территориально разработчиков ПО и других специалистов. При современном подходе к разработке ПО весьма высоко ценится легкость коммуникации. Несомненно, прекрасно, когда разработчик может, сделав два шага, уточнить у непосредственного заказчика способ решения проблемы, входные данные или что-либо еще, но, посадив менеджера по продажам и разработчика за соседние столы, вы самое малое в четверть снизите продуктивность труда последнего.
2. Запретите кому бы то ни было, кроме менеджера проекта, непосредственно давать указания разработчикам. Проект с большой долей вероятности выйдет из-под контроля, если разработчики будут выполнять такие, пусть даже срочные, распоряжения. Требования не будут фиксироваться, тесты не будут производиться, модификации будут осуществляться на ходу, разработчики будут вынуждены под давлением давать слишком оптимистичные оценки трудозатрат и всегда чувствовать себя неуспевающими, так как никто не будет знать, сколько работы они выполнили.
3. Выделите либо человека, либо время на обсуждение задач. Практика показывает, что задачи по сопровождению-разработке ПО возникают постоянно в течение дня, обстоятельства почти всегда требуют немедленного выяснения. Если вы имеете двух разработчиков, пусть они по очереди общаются с представителями заказчика, если у вас есть специально выделенный для этого менеджер - пусть общается он. Проблема здесь в том, что административные функции (выяснение обстоятельств проблем, степени их важности, взаимодействие с заинтересованными лицами) требуют оперативности, в то время как техническая реализация запросов, наоборот, наиболее эффективна при возможности сосредоточиться на проблеме на длительное время. Постоянное отвлечение внимания разработчика, кроме снижения эффективности работы, имеет еще один отрицательный результат: трудность адекватной оценки фактических трудозатрат. Между тем, без фиксирования фактических затрат, разработчик теряет навык делать правильные оценки.
4. Выделите для разработчиков отдельный телефонный номер. Не привлекайте разработчиков к секретарской работе. Разработчики часто ответственные и пунктуальные люди, а у менеджеров, при всем к ним уважении, часто нет времени. Не чувствуя характер труда разработчика они могут, безо всякой задней мысли, скинуть половину звонков на них.
5. И вообще, никогда ни при каких обстоятельствах не привлекайте разработчиков к неквалифицированному труду. Если вы, конечно, не боитесь потерять разработчика. Помните, разработчик чрезвычайно ценит свою квалификацию. Хороший разработчик всегда сможет найти себе новую работу, а вы вряд ли легко найдете нового разработчика. Это в крупных организациях с развитым процессом разработки программиста можно заменить без значительных затрат - а в такой небольшой компании, которая описывается здесь, разработчик может быть единственным носителем знаний о функционирующих программных продуктах, или вообще их единственным автором.
6. Считайте и учитывайте занятость разработчика. В изменяющемся мире бизнеса, например, в телекоммуникационном бизнесе, число задач, связанных с поддержкой существующих систем остается примерно постоянным. Небольшие изменения в существующем ПО требуются регулярно. В процессе разработки нового ПО число систем, которые необходимо сопровождать, растет. Что получается? Суммарное число задач растет со временем. Если разработчик говорит, что он перестает справляться с объемом задач, скорее всего это так. Возьмите еще одного человека, либо закажите разработку и сопровождение части ПО другим организациям.
7. Обеспечьте для разработчиков обучение и обмен опытом. Как руководитель, вы не можете быть в курсе всех последних изменений в мире разработки ПО. Вы можете считать, что человеку, который умеет программировать, учиться больше не надо, вполне достаточно опыта, получаемого в процессе работы. Однако если разработчики не будут в курсе последних технологий, ваше ПО устареет очень быстро.
8. В конце концов, создайте документ, описывающий организационную структуру предприятия. Какой бы небольшой ни была ваша компания, такой документ просто необходим. Как минимум, он необходим разработчику, для того, чтобы знать, с кем контактировать по какому вопросу.
Я не могу утверждать, что данный список является полным, и вполне вероятно, что можно дать еще некоторые рекомендации, например, обеспечить разработчиков всем необходимым аппаратным и программным обеспечением. Однако дело в том, что я даю рекомендации относительно лишь тех пунктов, которые вызывали наибольшие проблемы в период моей работы в компании описываемого уровня.
выделение основных процессов
Когда организационные проблемы решены на достаточном уровне, можно сконцентрироваться на процессе разработки.
Несомненно, вряд ли в этом случае удастся реализовать какой-либо тяжеловесный процесс разработки, и литература по данному вопросу, скорее всего, не сильно поможет, но формализовать существующие процессы и сделать их более эффективными постараться стоит.
Мое мнение состоит в том, что основная рекомендация, которую здесь можно дать, звучит так: "Ничего лишнего". Если вы имеете возможность начать с малого, формализуйте только те процессы, которые можете формализовать и создавайте только те документы, которые будут использоваться. Наиболее вероятно, что вы сможете выделить следующие процессы:
- разработка требований;
- планирование реализации требований (планирование итераций);
- реализация требований;
- планирование и реализация запросов на поддержку существующего ПО;
- тестирование.
На каком-то этапе даже этих процессов будет достаточно. Далее в статье я более подробно разберу процессы, связанные с планированием и управлением проектами и процессом разработки в целом, и попытаюсь дать рекомендации по формализации этих процессов.
разработка требований
По данному вопросу существуют хорошая и гораздо более подробная и глубокая, чем данная статья, литература. Здесь я опишу тот минимум работы, который, по моему мнению, нужно выполнить для того, чтобы в организации появился повторяемый процесс управления требованиями.
1. Определите источники требований. В качестве таких источников могут выступать:
- начальники любого уровня;
- сами разработчики;
- инженеры других отделов;
- сотрудники коммерческого отдела, менеджеры;
- представители сотрудничающей организации;
- отдел клиентской поддержки (customer service);
- конечные клиенты (retail customers).
2. Определите, кто, как и когда может вносить на рассмотрение требования к ПО. При этом не следует ограничивать всех вышеперечисленных действующих лиц какими-либо форматами или средствами. Будьте готовы, что при необходимости требования будут озвучены устно или по телефону, будут отправляться письмом или по ICQ, при чем в том виде, в котором удобно тому, кто данное требование высказывает. В разработке требований будут участвовать самые нетехнические специалисты или даже не специалисты. Главное здесь добиться следующего:
- чтобы разработчик мог работать, не отвлекаясь (см. общие требования по организации процесса разработки);
- дать понять всем участникам процесса, что тот факт, что требование зафиксировано, не означает того, что оно будет выполнено.
3. Участвуйте в разработке требований. Может случиться так, что по разным причинам, вы окажетесь не вовлеченными в процесс обсуждения разрабатываемой системы, и не будете иметь информации о проводимых совещаниях и их результатах. Вместо этого вы будете иметь дело с уже написанными документами. Такое вполне может произойти, если ваша основная позиция - разработчик и считается, что ваша задача - исполнять требования, а не тратить время на их обсуждение. Такое может случиться, если компания имеет несколько территориально удаленных филиалов. В любом случае, постарайтесь убедить руководство в том, что вам, как лицу, осуществляющему планирование и управление процессом разработки, необходимо участвовать в таких обсуждениях.
4. Фиксируйте требования! Насколько этот пункт важен, настолько же часто им и пренебрегают. Еще раз о том, для чего нужно фиксировать требования:
- чтобы формально утверждать;
- чтобы планировать работу;
- чтобы проверять работу;
- чтобы аргументировано спорить с заказчиком;
- чтобы обучать разработчиков и пользователей;
- чтобы иметь возможность проверить правильность работы системы при модификациях;
- чтобы иметь возможность заменить одну часть системы другой.
5. Фиксируйте источники требований. Это касается как высокоуровневых требований, так и конкретных технических деталей. Если требование или пожелание к системе принято в процессе дискуссии, фиксируйте, кто принимал участие в дискуссии. Это позволит при необходимости выяснить детали, причины требований непосредственно с тем, кто данное требование высказал. Кроме того, вы сможете проанализировать, чьи требования учтены, а чьи - нет.
6. Утверждайте требования. Определите тех лиц, кто должен утверждать требования. Не приступайте к разработке до того момента, пока требования не утверждены. Сделайте это правилом и не отступайте от этого никогда, иначе вы будете постоянно переделывать одну и ту же функциональность и убирать следы сделанных изменений.
В самом простом варианте, я предлагаю следующий формат документа, содержащего утвержденные требования к системе (см. таблицу 1).
Таблица 1.
До момента утверждения я обычно хранил все требования в оригинальном виде: в виде электронных писем, записей в блокноте и т.д. Более подробно о том, как заполнять пункты 4-8 таблицы будет рассмотрено в следующих пунктах.
Направления улучшения данного процесса:
- фиксировать все требования, а не только утвержденные;
- хранить версии требований и историю изменений.
планирование реализации требований
Планировать реализацию требований можно в какой угодно форме, однако, мне кажется, что если требований достаточно для того, чтобы спланировать хотя бы одну итерацию, лучше планировать итерацию. Суть итерации заключается в том, что она вмещает в себя полный цикл всех мероприятий по реализации требований: от проектирования архитектуры до поставки новой версии разрабатываемого ПО. При таком подходе в конце каждой итерации мы получаем работоспособный продукт, хоть и с частично реализованной функциональностью. Это позволяет уже через очень короткое время получить первый отзыв заказчика о продукте, подтвердить правильность выбранной реализации, контролировать сроки разработки и, возможно, даже предоставить заказчику для использования наиболее важную функциональность. Для более подробного изучения итеративного процесса разработки я предлагаю обратиться к соответствующей литературе, здесь я постараюсь перечислить некоторые конкретные рекомендации по планированию итераций.
1. Определите размер итерации. Я всегда планировал двухнедельные итерации и, по моему мнению, это достаточно подходящий размер, потому что за две недели можно сделать не так уж мало, и, в то же время, можно достаточно часто получать результаты и своевременно корректировать ход разработки.
2. Определите объем занятости в человеко-часах на каждую итерацию. Только не пытайтесь спланировать все рабочее время на проектную деятельность. По моим наблюдениям, даже в компании-разработчике ПО у программистов средняя проектная занятость достигает максимум 6 часов в день. Остальное время уходит на организацию работы, деловую переписку, сборку версий, поиск информации в Интернете, установку обновлений, новых версий программ и просто общение. В случае совмещения нескольких обязанностей, я бы не рискнул планировать более половины времени на разработку. Таким образом, приблизительная оценка может быть такой:
4 часа в день * 2 недели * 5 дней * 2 разработчика = 80 человеко-часов на итерацию
Поспешу заверить, что это не так уж мало, как может показаться.
3. Планируйте время на выполнение каждого требования. Такие оценки следует доверить разработчику - он лучше всех представляет, сколько времени может потребоваться на реализацию каждого требования. Не спланировав время на выполнение требований, невозможно спланировать итерацию.
4. Фиксируйте время, на самом деле потраченное на реализацию каждого из требований. Это необходимо для того, чтобы анализировать, насколько точны оценки, даваемые разработчиком, для того, чтобы оценивать, сколько может потребоваться времени на реализацию похожей функциональности, а главное, это показатель, который фиксирует актуальный объем занятости группы разработки на итерацию на вашем предприятии. Это основная цифра, из которой надо исходить, планируя следующую итерацию.
5. Определите порядок определения требований, реализуемых в рамках итерации и действующих лиц. Будет полезно составить технологическую инструкцию, описывающую технологию разработки ПО на стадии планирования конкретно на вашем предприятии.
Основными пунктами такой инструкции могут быть:
- список лиц, утверждающих и согласовывающих документ;
- общее описание документа и его предназначения;
- описание ролей участников процесса (заказчик, разработчик). Стоит описать, какие решения принимает каждый из участников и общий характер взаимодействия участников;
- пошаговый порядок взаимодействия участников процесса;
- перечень разрабатываемых артефактов.
Как и до этого, я рекомендую на начальном этапе включать в такую инструкцию только основные, совершенно необходимые шаги. Ключевым критерием должна быть уверенность, что вы сможете добиться исполнения перечисленных шагов.
Результатом процесса должны стать утвержденные требования к системе, с указанием планируемых трудозатрат, с расставленными приоритетами и распределенные по итерациям.
6. Определите список заинтересованных лиц для каждого проекта. Важно как можно раньше выяснить, кем представлен каждый из классов пользователей при сборе требований, кто назначает приоритеты требованиям и т.д. Очень важно выяснить, кто должен быть оповещен при выпуске версий! Если версии не доходят до заинтересованных лиц, нет смысла в их частом выпуске.
7. Добейтесь участия в процессе всех заинтересованных лиц. Как показывает практика, бывает так, что люди, заинтересованные в продукте, узнают о его разработке только после окончания последней. В этот момент выясняется, что их требования не учтены. Будьте уверены - вам придется реализовать и эти требования, но на поздних этапах работы над проектом, что станет причиной существенных сложностей.
Убедите всех участников обсуждения в том, что их пожелания важны и будут рассмотрены. Только спустя некоторое время работы над проектом, я стал понимать, что некоторые из участников обсуждений не представляли, насколько значимы их предложения для остальных. Как следствие, многие пожелания не высказывались по причине того, что людям казалось, что их пожелания не будут рассмотрены.
8. Приоритетами должен управлять 1 человек, и этот процесс должен быть максимально формализован! По опыту общения с людьми, заинтересованными в проекте, я могу сказать, что у каждого из них, скорее всего, будет свое видение важности реализации каждого из требований. Часто эти люди не могут договориться между собой. Не берите на себя ответственность за то, чтобы решать, чье мнение важнее: это не ваша забота. Пусть руководитель определит, что наиболее приоритетно в его бизнесе.
9. Планируйте изменения в итерации. В вышеуказанной инструкции опишите, что должно выполняться в следующих случаях:
- сокращено время проектной занятости группы разработки на текущую итерацию;
- заказчик изменяет приоритет требований;
- заказчик изменяет состав требований.
Так как заказчик, скорее всего, внутренний, вы должны быть готовы в любом из этих случаев идти ему навстречу. Предусмотрите то, как вы будете перераспределять задачи и относитесь к этому с легкостью. Единственное, чего не рекомендую делать - это сдвигать сроки завершения итераций - иначе они поплывут, и планирование в какой-то момент прекратится.
10. Старайтесь больше общаться с заказчиком. Даже если вы спланировали завершить итерацию через две недели, поставьте промежуточную версию уже через неделю. Предупредите, что версия может содержать ошибки и не должна использоваться в реальных задачах. Не настаивайте на том, чтобы заказчик смотрел эту версию в работе. Однако если заказчик заинтересован в продукте и у него найдется время, он сможет вам что-то подсказать или найти ошибку до того, как вы найдете ее сами (если найдете). Таким образом, вы сможете ненавязчиво привлечь заказчика к тестированию.
11. Храните документ с требованиями в общедоступном месте. Приучите заказчика и себя к тому, что он (заказчик) может в любой момент ознакомиться с ходом работы и еще раз оценить зафиксированные результаты планирования.
Направления улучшения данного процесса:
- ввести более или менее формальную процедуру оценивания заказчиком продукта;
- фиксировать отзывы заказчика о продукте;
- определить, как будет учитываться время на организацию работы, выяснение деталей реализации, совещания и т.д.
управление запросами на поддержку
Процесс разработки и планирования реализации требований, описанный выше, более подходит при разработке нового ПО или существенных доработках существующего, когда требований достаточно много, они взаимосвязаны и относительно невелики по объему. В случае возникновения запросов на поддержку существующего ПО, часто приходится иметь дело с единичными, не связанными друг с другом и достаточно крупными изменениями. Примером такого запроса может служить, например, запрос на модификацию существующих в системе отчетов или запрос на изменение способа обмена данными со сторонней организацией.
Рекомендации тут следующие:
1. Создайте шаблон документа для того, чтобы фиксировать запросы на поддержку. Рекомендуемое содержание данного документа:
- описание того, как в настоящий момент функционирует система. Здесь следует указать, что в данной реализации работает неправильно; - суть изменений, которые следует реализовать в системе;
- возможные преимущества после исправления недостатков. Этот пункт должен заполнить заказчик;
- предложения по технической реализации. Если у решения несколько вариантов, здесь должны быть изложены все;
- предварительная оценка трудозатрат;
- детали технической реализации. Этот пункт описывает, как конкретно были реализованы изменения;
- реальные трудозатраты.
Даже если с текущей документацией на проект у вас не все в порядке, фиксация запросов на поддержку в таком виде позволит вам в некоторой степени восполнить этот пробел. Если вам необходимо определить, какая документация должна создаваться в первую очередь - вы можете смело приступить именно к фиксации вышеуказанных пунктов.
2. Отслеживайте состояние всех запросов на поддержку. Хороший вариант - создать документ приблизительно следующего содержания (см. таблицу 2).
Таблица 2.
Упомянутых статусов ("На рассмотрении", "Выполнено", "На исполнение", "Отменено") может быть вполне достаточно, чтобы контролировать ход работ. Точное время для выполнения запроса назначать не обязательно, достаточно указать дату, когда запрос должен быть выполнен. Полезным наверняка окажется учет фактической даты окончания работ над запросом.
3. Определите порядок обработки запросов на поддержку и действующих лиц. Тут, как и при планировании итераций, полезной может стать инструкция, описывающая технологию управления запросами на поддержку. Данный документ по структуре будет практически аналогичным инструкции, определяющей технологию разработки ПО на стадии планирования. Что касается содержания, то одно из отличий проявляется в том, что кроме роли разработчика и заказчика, можно выделить отдельную роль руководителя. Если в случае с требованиями подразумевается, что руководитель уже дал согласие на начало работ по проекту, а требования утверждает заказчик в лице человека, ответственного за такие решения, то в случае с запросами на поддержку, решение о принятии запроса на исполнение может и не быть принято в силу различных причин. Возможно, понадобится более четко определять сроки реализации запросов на поддержку.
еще раз о пользе отчетов
При любой технологии производства, отчеты - один из самых полезных видов документации. Сделайте отчеты стандартом в вашей организации, вне зависимости от ее размера и рода деятельности. При этом постарайтесь использовать наиболее простую и удобную для ваших сотрудников форму, для того, чтобы не усложнять им жизнь.
итоги
Подводя итоги, я привожу список возможных документов, разрабатываемых в рамках вышеописанного технологического процесса.
Общая управляющая документация:
1. Технологическая инструкция "Технология разработки ПО на стадии планирования".
2. Технологическая инструкция "Технология управления запросами на поддержку".
Управляющая проектная документация:
3. Документ "Образ и границы проекта".
4. Документ "Требования к системе".
Другая управляющая документация:
5. Документ "Запрос на поддержку".
6. Документ "Общий список учета запросов на поддержку".
7. Отчеты
Артем Кондратьев
Риск заключается в том, что управление процессом разработки в этом случае может лечь на плечи людей, основная специальность которых не связана напрямую с такой деятельностью - программистов, инженеров других специальностей или менеджеров, не знакомых со спецификой разработки ПО. Это может быть первый опыт такого рода для данной организации. При этом не менее важно обеспечить приемлемый уровень качества процессов, связанных с разработкой.
Эта статья написана на основе опыта, полученного мной за год работы менеджером проекта и разработчиком ПО в небольшой телекоммуникационной компании. В ней рассматриваются основные процессы, связанные с разработкой ПО, которые я смог выделить и формализовать. Я стараюсь дать основные рекомендации, которые могут быть полезны при управлении разработкой ПО в такого рода компаниях.
Чтобы стало более понятно, о чем идет речь, для начала я постараюсь дать общую картину производства в области разработки и сопровождения ПО в компаниях, профиль которых не связан напрямую с разработкой ПО.
1. Большое число задач (более половины) связано с сопровождением, поддержкой и доработкой существующего ПО.
2. Задачи, связанные с сопровождением существующих систем, практически независимы друг от друга, могут быть решены за небольшое время, но возникают часто и требуют оперативного решения.
3. Разработка и сопровождение ведется небольшой группой специалистов, а зачастую и вообще одним человеком.
4. Как следствие, отсутствует явное разделение ролей в процессе: один и тот же человек может совмещать позиции разработчика, аналитика, архитектора, тестера, системного администратора, менеджера проектов и т.д.
5. Проекты чаще всего не выходят за рамки внутреннего использования.
Как следствие, процесс разработки ПО в таких компаниях в силу объективных причин достаточно примитивен. Многие технологические процессы отсутствуют или присутствуют в сильно упрощенном варианте. Тем не менее, и такими процессами необходимо управлять и гарантировать приемлемое качество их выполнения.
общие рекомендации по организации процесса разработки
Прежде чем озаботиться созданием основ технологии, необходимо по максимуму решить все организационные проблемы. В литературе часто
рассматривается вопрос организации рабочей среды в компании-разработчике ПО, однако, для компании, в которой отдел разработки совсем небольшой (1-3 человека), многие из этих рекомендаций покажутся излишними. Тем не менее, таким компаниям рекомендации нужны не меньше. Из своего опыта я могу рекомендовать следующее.
1. Постарайтесь, насколько возможно, разделить территориально разработчиков ПО и других специалистов. При современном подходе к разработке ПО весьма высоко ценится легкость коммуникации. Несомненно, прекрасно, когда разработчик может, сделав два шага, уточнить у непосредственного заказчика способ решения проблемы, входные данные или что-либо еще, но, посадив менеджера по продажам и разработчика за соседние столы, вы самое малое в четверть снизите продуктивность труда последнего.
2. Запретите кому бы то ни было, кроме менеджера проекта, непосредственно давать указания разработчикам. Проект с большой долей вероятности выйдет из-под контроля, если разработчики будут выполнять такие, пусть даже срочные, распоряжения. Требования не будут фиксироваться, тесты не будут производиться, модификации будут осуществляться на ходу, разработчики будут вынуждены под давлением давать слишком оптимистичные оценки трудозатрат и всегда чувствовать себя неуспевающими, так как никто не будет знать, сколько работы они выполнили.
3. Выделите либо человека, либо время на обсуждение задач. Практика показывает, что задачи по сопровождению-разработке ПО возникают постоянно в течение дня, обстоятельства почти всегда требуют немедленного выяснения. Если вы имеете двух разработчиков, пусть они по очереди общаются с представителями заказчика, если у вас есть специально выделенный для этого менеджер - пусть общается он. Проблема здесь в том, что административные функции (выяснение обстоятельств проблем, степени их важности, взаимодействие с заинтересованными лицами) требуют оперативности, в то время как техническая реализация запросов, наоборот, наиболее эффективна при возможности сосредоточиться на проблеме на длительное время. Постоянное отвлечение внимания разработчика, кроме снижения эффективности работы, имеет еще один отрицательный результат: трудность адекватной оценки фактических трудозатрат. Между тем, без фиксирования фактических затрат, разработчик теряет навык делать правильные оценки.
4. Выделите для разработчиков отдельный телефонный номер. Не привлекайте разработчиков к секретарской работе. Разработчики часто ответственные и пунктуальные люди, а у менеджеров, при всем к ним уважении, часто нет времени. Не чувствуя характер труда разработчика они могут, безо всякой задней мысли, скинуть половину звонков на них.
5. И вообще, никогда ни при каких обстоятельствах не привлекайте разработчиков к неквалифицированному труду. Если вы, конечно, не боитесь потерять разработчика. Помните, разработчик чрезвычайно ценит свою квалификацию. Хороший разработчик всегда сможет найти себе новую работу, а вы вряд ли легко найдете нового разработчика. Это в крупных организациях с развитым процессом разработки программиста можно заменить без значительных затрат - а в такой небольшой компании, которая описывается здесь, разработчик может быть единственным носителем знаний о функционирующих программных продуктах, или вообще их единственным автором.
6. Считайте и учитывайте занятость разработчика. В изменяющемся мире бизнеса, например, в телекоммуникационном бизнесе, число задач, связанных с поддержкой существующих систем остается примерно постоянным. Небольшие изменения в существующем ПО требуются регулярно. В процессе разработки нового ПО число систем, которые необходимо сопровождать, растет. Что получается? Суммарное число задач растет со временем. Если разработчик говорит, что он перестает справляться с объемом задач, скорее всего это так. Возьмите еще одного человека, либо закажите разработку и сопровождение части ПО другим организациям.
7. Обеспечьте для разработчиков обучение и обмен опытом. Как руководитель, вы не можете быть в курсе всех последних изменений в мире разработки ПО. Вы можете считать, что человеку, который умеет программировать, учиться больше не надо, вполне достаточно опыта, получаемого в процессе работы. Однако если разработчики не будут в курсе последних технологий, ваше ПО устареет очень быстро.
8. В конце концов, создайте документ, описывающий организационную структуру предприятия. Какой бы небольшой ни была ваша компания, такой документ просто необходим. Как минимум, он необходим разработчику, для того, чтобы знать, с кем контактировать по какому вопросу.
Я не могу утверждать, что данный список является полным, и вполне вероятно, что можно дать еще некоторые рекомендации, например, обеспечить разработчиков всем необходимым аппаратным и программным обеспечением. Однако дело в том, что я даю рекомендации относительно лишь тех пунктов, которые вызывали наибольшие проблемы в период моей работы в компании описываемого уровня.
выделение основных процессов
Когда организационные проблемы решены на достаточном уровне, можно сконцентрироваться на процессе разработки.
Несомненно, вряд ли в этом случае удастся реализовать какой-либо тяжеловесный процесс разработки, и литература по данному вопросу, скорее всего, не сильно поможет, но формализовать существующие процессы и сделать их более эффективными постараться стоит.
Мое мнение состоит в том, что основная рекомендация, которую здесь можно дать, звучит так: "Ничего лишнего". Если вы имеете возможность начать с малого, формализуйте только те процессы, которые можете формализовать и создавайте только те документы, которые будут использоваться. Наиболее вероятно, что вы сможете выделить следующие процессы:
- разработка требований;
- планирование реализации требований (планирование итераций);
- реализация требований;
- планирование и реализация запросов на поддержку существующего ПО;
- тестирование.
На каком-то этапе даже этих процессов будет достаточно. Далее в статье я более подробно разберу процессы, связанные с планированием и управлением проектами и процессом разработки в целом, и попытаюсь дать рекомендации по формализации этих процессов.
разработка требований
По данному вопросу существуют хорошая и гораздо более подробная и глубокая, чем данная статья, литература. Здесь я опишу тот минимум работы, который, по моему мнению, нужно выполнить для того, чтобы в организации появился повторяемый процесс управления требованиями.
1. Определите источники требований. В качестве таких источников могут выступать:
- начальники любого уровня;
- сами разработчики;
- инженеры других отделов;
- сотрудники коммерческого отдела, менеджеры;
- представители сотрудничающей организации;
- отдел клиентской поддержки (customer service);
- конечные клиенты (retail customers).
2. Определите, кто, как и когда может вносить на рассмотрение требования к ПО. При этом не следует ограничивать всех вышеперечисленных действующих лиц какими-либо форматами или средствами. Будьте готовы, что при необходимости требования будут озвучены устно или по телефону, будут отправляться письмом или по ICQ, при чем в том виде, в котором удобно тому, кто данное требование высказывает. В разработке требований будут участвовать самые нетехнические специалисты или даже не специалисты. Главное здесь добиться следующего:
- чтобы разработчик мог работать, не отвлекаясь (см. общие требования по организации процесса разработки);
- дать понять всем участникам процесса, что тот факт, что требование зафиксировано, не означает того, что оно будет выполнено.
3. Участвуйте в разработке требований. Может случиться так, что по разным причинам, вы окажетесь не вовлеченными в процесс обсуждения разрабатываемой системы, и не будете иметь информации о проводимых совещаниях и их результатах. Вместо этого вы будете иметь дело с уже написанными документами. Такое вполне может произойти, если ваша основная позиция - разработчик и считается, что ваша задача - исполнять требования, а не тратить время на их обсуждение. Такое может случиться, если компания имеет несколько территориально удаленных филиалов. В любом случае, постарайтесь убедить руководство в том, что вам, как лицу, осуществляющему планирование и управление процессом разработки, необходимо участвовать в таких обсуждениях.
4. Фиксируйте требования! Насколько этот пункт важен, настолько же часто им и пренебрегают. Еще раз о том, для чего нужно фиксировать требования:
- чтобы формально утверждать;
- чтобы планировать работу;
- чтобы проверять работу;
- чтобы аргументировано спорить с заказчиком;
- чтобы обучать разработчиков и пользователей;
- чтобы иметь возможность проверить правильность работы системы при модификациях;
- чтобы иметь возможность заменить одну часть системы другой.
5. Фиксируйте источники требований. Это касается как высокоуровневых требований, так и конкретных технических деталей. Если требование или пожелание к системе принято в процессе дискуссии, фиксируйте, кто принимал участие в дискуссии. Это позволит при необходимости выяснить детали, причины требований непосредственно с тем, кто данное требование высказал. Кроме того, вы сможете проанализировать, чьи требования учтены, а чьи - нет.
6. Утверждайте требования. Определите тех лиц, кто должен утверждать требования. Не приступайте к разработке до того момента, пока требования не утверждены. Сделайте это правилом и не отступайте от этого никогда, иначе вы будете постоянно переделывать одну и ту же функциональность и убирать следы сделанных изменений.
В самом простом варианте, я предлагаю следующий формат документа, содержащего утвержденные требования к системе (см. таблицу 1).
Таблица 1.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| # | User Story | Comments | Priority (1,2...) | Realize in iteration # | Realize in version # | Man-hours estimated | Man-hours used |
До момента утверждения я обычно хранил все требования в оригинальном виде: в виде электронных писем, записей в блокноте и т.д. Более подробно о том, как заполнять пункты 4-8 таблицы будет рассмотрено в следующих пунктах.
Направления улучшения данного процесса:
- фиксировать все требования, а не только утвержденные;
- хранить версии требований и историю изменений.
планирование реализации требований
Планировать реализацию требований можно в какой угодно форме, однако, мне кажется, что если требований достаточно для того, чтобы спланировать хотя бы одну итерацию, лучше планировать итерацию. Суть итерации заключается в том, что она вмещает в себя полный цикл всех мероприятий по реализации требований: от проектирования архитектуры до поставки новой версии разрабатываемого ПО. При таком подходе в конце каждой итерации мы получаем работоспособный продукт, хоть и с частично реализованной функциональностью. Это позволяет уже через очень короткое время получить первый отзыв заказчика о продукте, подтвердить правильность выбранной реализации, контролировать сроки разработки и, возможно, даже предоставить заказчику для использования наиболее важную функциональность. Для более подробного изучения итеративного процесса разработки я предлагаю обратиться к соответствующей литературе, здесь я постараюсь перечислить некоторые конкретные рекомендации по планированию итераций.
1. Определите размер итерации. Я всегда планировал двухнедельные итерации и, по моему мнению, это достаточно подходящий размер, потому что за две недели можно сделать не так уж мало, и, в то же время, можно достаточно часто получать результаты и своевременно корректировать ход разработки.
2. Определите объем занятости в человеко-часах на каждую итерацию. Только не пытайтесь спланировать все рабочее время на проектную деятельность. По моим наблюдениям, даже в компании-разработчике ПО у программистов средняя проектная занятость достигает максимум 6 часов в день. Остальное время уходит на организацию работы, деловую переписку, сборку версий, поиск информации в Интернете, установку обновлений, новых версий программ и просто общение. В случае совмещения нескольких обязанностей, я бы не рискнул планировать более половины времени на разработку. Таким образом, приблизительная оценка может быть такой:
4 часа в день * 2 недели * 5 дней * 2 разработчика = 80 человеко-часов на итерацию
Поспешу заверить, что это не так уж мало, как может показаться.
3. Планируйте время на выполнение каждого требования. Такие оценки следует доверить разработчику - он лучше всех представляет, сколько времени может потребоваться на реализацию каждого требования. Не спланировав время на выполнение требований, невозможно спланировать итерацию.
4. Фиксируйте время, на самом деле потраченное на реализацию каждого из требований. Это необходимо для того, чтобы анализировать, насколько точны оценки, даваемые разработчиком, для того, чтобы оценивать, сколько может потребоваться времени на реализацию похожей функциональности, а главное, это показатель, который фиксирует актуальный объем занятости группы разработки на итерацию на вашем предприятии. Это основная цифра, из которой надо исходить, планируя следующую итерацию.
5. Определите порядок определения требований, реализуемых в рамках итерации и действующих лиц. Будет полезно составить технологическую инструкцию, описывающую технологию разработки ПО на стадии планирования конкретно на вашем предприятии.
Основными пунктами такой инструкции могут быть:
- список лиц, утверждающих и согласовывающих документ;
- общее описание документа и его предназначения;
- описание ролей участников процесса (заказчик, разработчик). Стоит описать, какие решения принимает каждый из участников и общий характер взаимодействия участников;
- пошаговый порядок взаимодействия участников процесса;
- перечень разрабатываемых артефактов.
Как и до этого, я рекомендую на начальном этапе включать в такую инструкцию только основные, совершенно необходимые шаги. Ключевым критерием должна быть уверенность, что вы сможете добиться исполнения перечисленных шагов.
Результатом процесса должны стать утвержденные требования к системе, с указанием планируемых трудозатрат, с расставленными приоритетами и распределенные по итерациям.
6. Определите список заинтересованных лиц для каждого проекта. Важно как можно раньше выяснить, кем представлен каждый из классов пользователей при сборе требований, кто назначает приоритеты требованиям и т.д. Очень важно выяснить, кто должен быть оповещен при выпуске версий! Если версии не доходят до заинтересованных лиц, нет смысла в их частом выпуске.
7. Добейтесь участия в процессе всех заинтересованных лиц. Как показывает практика, бывает так, что люди, заинтересованные в продукте, узнают о его разработке только после окончания последней. В этот момент выясняется, что их требования не учтены. Будьте уверены - вам придется реализовать и эти требования, но на поздних этапах работы над проектом, что станет причиной существенных сложностей.
Убедите всех участников обсуждения в том, что их пожелания важны и будут рассмотрены. Только спустя некоторое время работы над проектом, я стал понимать, что некоторые из участников обсуждений не представляли, насколько значимы их предложения для остальных. Как следствие, многие пожелания не высказывались по причине того, что людям казалось, что их пожелания не будут рассмотрены.
8. Приоритетами должен управлять 1 человек, и этот процесс должен быть максимально формализован! По опыту общения с людьми, заинтересованными в проекте, я могу сказать, что у каждого из них, скорее всего, будет свое видение важности реализации каждого из требований. Часто эти люди не могут договориться между собой. Не берите на себя ответственность за то, чтобы решать, чье мнение важнее: это не ваша забота. Пусть руководитель определит, что наиболее приоритетно в его бизнесе.
9. Планируйте изменения в итерации. В вышеуказанной инструкции опишите, что должно выполняться в следующих случаях:
- сокращено время проектной занятости группы разработки на текущую итерацию;
- заказчик изменяет приоритет требований;
- заказчик изменяет состав требований.
Так как заказчик, скорее всего, внутренний, вы должны быть готовы в любом из этих случаев идти ему навстречу. Предусмотрите то, как вы будете перераспределять задачи и относитесь к этому с легкостью. Единственное, чего не рекомендую делать - это сдвигать сроки завершения итераций - иначе они поплывут, и планирование в какой-то момент прекратится.
10. Старайтесь больше общаться с заказчиком. Даже если вы спланировали завершить итерацию через две недели, поставьте промежуточную версию уже через неделю. Предупредите, что версия может содержать ошибки и не должна использоваться в реальных задачах. Не настаивайте на том, чтобы заказчик смотрел эту версию в работе. Однако если заказчик заинтересован в продукте и у него найдется время, он сможет вам что-то подсказать или найти ошибку до того, как вы найдете ее сами (если найдете). Таким образом, вы сможете ненавязчиво привлечь заказчика к тестированию.
11. Храните документ с требованиями в общедоступном месте. Приучите заказчика и себя к тому, что он (заказчик) может в любой момент ознакомиться с ходом работы и еще раз оценить зафиксированные результаты планирования.
Направления улучшения данного процесса:
- ввести более или менее формальную процедуру оценивания заказчиком продукта;
- фиксировать отзывы заказчика о продукте;
- определить, как будет учитываться время на организацию работы, выяснение деталей реализации, совещания и т.д.
управление запросами на поддержку
Процесс разработки и планирования реализации требований, описанный выше, более подходит при разработке нового ПО или существенных доработках существующего, когда требований достаточно много, они взаимосвязаны и относительно невелики по объему. В случае возникновения запросов на поддержку существующего ПО, часто приходится иметь дело с единичными, не связанными друг с другом и достаточно крупными изменениями. Примером такого запроса может служить, например, запрос на модификацию существующих в системе отчетов или запрос на изменение способа обмена данными со сторонней организацией.
Рекомендации тут следующие:
1. Создайте шаблон документа для того, чтобы фиксировать запросы на поддержку. Рекомендуемое содержание данного документа:
- описание того, как в настоящий момент функционирует система. Здесь следует указать, что в данной реализации работает неправильно; - суть изменений, которые следует реализовать в системе;
- возможные преимущества после исправления недостатков. Этот пункт должен заполнить заказчик;
- предложения по технической реализации. Если у решения несколько вариантов, здесь должны быть изложены все;
- предварительная оценка трудозатрат;
- детали технической реализации. Этот пункт описывает, как конкретно были реализованы изменения;
- реальные трудозатраты.
Даже если с текущей документацией на проект у вас не все в порядке, фиксация запросов на поддержку в таком виде позволит вам в некоторой степени восполнить этот пробел. Если вам необходимо определить, какая документация должна создаваться в первую очередь - вы можете смело приступить именно к фиксации вышеуказанных пунктов.
2. Отслеживайте состояние всех запросов на поддержку. Хороший вариант - создать документ приблизительно следующего содержания (см. таблицу 2).
Таблица 2.
| 1 | 2 | 3 | 4 | ||||||||||||||||
| Status | To be executed before | Finish date | On consideration | Resolved | On schedule | Rejected | |
Упомянутых статусов ("На рассмотрении", "Выполнено", "На исполнение", "Отменено") может быть вполне достаточно, чтобы контролировать ход работ. Точное время для выполнения запроса назначать не обязательно, достаточно указать дату, когда запрос должен быть выполнен. Полезным наверняка окажется учет фактической даты окончания работ над запросом.
3. Определите порядок обработки запросов на поддержку и действующих лиц. Тут, как и при планировании итераций, полезной может стать инструкция, описывающая технологию управления запросами на поддержку. Данный документ по структуре будет практически аналогичным инструкции, определяющей технологию разработки ПО на стадии планирования. Что касается содержания, то одно из отличий проявляется в том, что кроме роли разработчика и заказчика, можно выделить отдельную роль руководителя. Если в случае с требованиями подразумевается, что руководитель уже дал согласие на начало работ по проекту, а требования утверждает заказчик в лице человека, ответственного за такие решения, то в случае с запросами на поддержку, решение о принятии запроса на исполнение может и не быть принято в силу различных причин. Возможно, понадобится более четко определять сроки реализации запросов на поддержку.
еще раз о пользе отчетов
При любой технологии производства, отчеты - один из самых полезных видов документации. Сделайте отчеты стандартом в вашей организации, вне зависимости от ее размера и рода деятельности. При этом постарайтесь использовать наиболее простую и удобную для ваших сотрудников форму, для того, чтобы не усложнять им жизнь.
итоги
Подводя итоги, я привожу список возможных документов, разрабатываемых в рамках вышеописанного технологического процесса.
Общая управляющая документация:
1. Технологическая инструкция "Технология разработки ПО на стадии планирования".
2. Технологическая инструкция "Технология управления запросами на поддержку".
Управляющая проектная документация:
3. Документ "Образ и границы проекта".
4. Документ "Требования к системе".
Другая управляющая документация:
5. Документ "Запрос на поддержку".
6. Документ "Общий список учета запросов на поддержку".
7. Отчеты
Артем Кондратьев
Сетевые решения. Статья была опубликована в номере 04 за 2006 год в рубрике программирование
