Модели команды разработчиков

2.1. Коллективный характер разработки

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

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

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

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

Команда проекта – группа людей, как правило, сотрудников одной программирующейорганизации, осуществляющая процесс разработки программного обеспечения в рамкаходного проекта.

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

2.1.1. Оптимальный размер команды.

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

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

Замечание. Регулярное общение означает разговор с кем-либо в течение примерно двух часов в неделю.

В принципе программист-разработчик может работать почти без регулярного индивидуального общения с кем бы то ни было. Однако такая изоляция обычно приводит к непониманию разработчиком предъявляемых к нему требований и, как следствие, к относительно низкому уровню эффективности. С другой стороны, если участник проекта работает в слишком большой команде, то из-за постоянного общения с каждым из коллег у негоне останется времени на выполнение своих основных обязанностей по проекту. Это сноваприводит к относительно низкому уровню эффективности. Например, если сотрудник регулярно общается с десятью своими коллегами, то половина его рабочего времени (20 из40 часов в неделю) проходит в разговорах. Менеджеры проектов, планирующие проекты сбольшими командами, должны это учитывать.

2.1.2. Подчиненность участников проекта.

В современных условиях используются три основных вида организации подчиненности(субординации):

- линейно-функциональная;

- проектно-ориентированная;

- матричная.

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

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

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

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

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

2.1.3. Развитие команды и развитие персонала.

Каждыйпроект, кромедостиженияосновнойсвоейцели, должениспользоватьсяруководителемпроектадляразвитиякоманды. Аименно, впроцессевыполненияпроекта:

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

- вырабатываютсяиукрепляютсянавыкикоманднойработы,

- приобретаетсяопытвыполненияпроектоввсоответствииспринятойвкомпаниисхемойорганизациипроцессаразработкипрограммногообеспечения.

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

2.1.4. Специализация, кооперация и взаимодействие.

Программированиеотнюдьнеоднородно. Вмоделипроцессамывыделилинесколькофаз. Успешноевыполнениекаждаяизфазтребуетналичияопределенныхнавыковуработников. Частичноэтинавыкидляразныхфазсовпадают, ноестьиспециальныенавыки, которыеспецифичныдлянекоторойфазы. Например, есливпроектеприменяютсяформальныеметоды, тонафазаханализаипроектированияможетпотребоватьсявладениематематическимаппаратомвтакихобъемах, которыенепредусматриваютсяпрограммамиучебныхзаведений, готовящихпрограммистов.Другойпример: нафазевнедрениятребуетсянаписатьпользовательскуюдокументацию. Ксожалению, практикапоказывает,чтобольшинствопрограммистовпростоневсостояниинаписатьхорошееруководстводляпользователя–нетнавыка, нетопыта. Поэтомуспециализация«техническийписатель»являетсясейчасдажеболеедефицитной, чем«системныйархитектор». Таким образом, люди (втомчислеипрограммисты) разные. Хорошийруководительпроектастараетсятакраспределитьработу, чтокаждыйработникделалто, вчемонсиленинеделалтого, вчемонслаб. Этоназывается специализацией.

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

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

2.2. Иерархическая модель команды.

Иерархическая модель (илимодель дерева субординации, рисунок 7.4) являетсясамойраспространеннойиизвестноймоделью. Этамодельобладаетцелымрядомдостоинств.

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

Иерархическаямодельпривычнаиизвестнаабсолютновсем. Ееиспользованиенетребуетдополнительныхмероприятийповнедрениюиобучениюперсонала.

Иерархическаямодельобладаетвысокойстепеньюмасштабируемости. Онасуспехомприменяетсявмасштабахотдесятковдодесятковмиллионовисполнителей.

Рисунок 7.4. Иерархическая модель команды.

 

В тожевремяиерархическоймоделиприсущинекоторыепринципиальныенедостатки.

Иерархическаямодельэкстенсивна. Наращиваниефункциональностиобеспечиваетсяувеличениемсостава.

Иерархическаямодельжесткая, т.е. практическинедопускаетперестройки«находу» (впроцессе). Онаориентировананавыполнениестрогоопределенныхфункций. Изменениефункцийтребуетболезненнойперестройкидеревасубординации.

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

Иерархическаямодельнеустойчивапоотношениюкличнымкачествамруководителей.

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

2.3. Метод хирургической бригады.

Модель главного программиста появиласьвовремяпервойтехнологическойреволюциивпрограммированиинарубеже 60–70-хгодов. Долгоевремямодельглавногопрограммиста(или метод хирургической бригады, или модель звезды, рисунок 7.5) являласьдоминирующеймодельюприразработкепрограммногообеспечения.

Рисунок 7.5. Модель бригады главного программиста (звезда).

 

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

Модельглавногопрограммистаимеетследующиедостоинства.

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

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

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

Бригадаглавногопрограммистанаследуетвседостоинствапринципаединоначалия (посколькуглавныйпрограммистединоличнопринимаетвсепринципиальныерешенияпопроекту).

Методбригадыглавногопрограммистадопускаетразличныемодификацииприсохранениисвоейсути.

Перваямодификация: изменениеколичестваикачествалучейвзвезде. Вклассическоймодели, описаннойвкнигеБрукса, взвездеещеприсутствоваливторойСекретарьиЯзыковед. Впрактическихслучаяхколичестволучейсокращают, например, объединяяСекретаря, РедактораиАрхивариуса. ХарактеристическимиролямивбригадеявляютсяГлавныйпрограммист, ВторойпилотиАдминистратор, остальныеролименяютсяпомереразвитиятехнологийпрограммирования.

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

Третьямодификация: «сдвоенныйцентр» (рисунок 7.6). Этамодификацияпозволяетхотябывнекоторыхпределахмасштабироватьбригаду. ИмеютсядваГлавныхпрограммиста, которыеделятпроектпополам, всерешенияпринимаютконсенсусомиявляютсявторымипилотамидругдлядруга.

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

 

Рисунок 7.6. Модификация модели бригады главного программиста

(сдвоенный центр).

 

Модельбригадыглавногопрограммистаимеетопределенныенедостатки.

Бригадаглавногопрограммистанеявляетсямасштабируемымрешением.Онаотличноработаетнапроектахобъема 6-8 человек× 1-2 года. Еслипроекттребуетболеекороткихсроковилисущественнобольшихобъемов, тоиспользованиебригадыглавногопрограммистазатруднено.

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

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

Бригадаглавногопрограммистаимеетуязвимоецентральноезвено. Оченьвеликуправленческийрискмгновеннойаннигиляциибригады, есличто-тослучаетсясглавнымпрограммистом.

Замечание. Второйпилотвбригадеглавногопрограммистадолжентщательноотслеживатьвседействияглавногопрограммиста. Этонесколькоснижаетрисканнигиляции.

2.4. Модель команды равных.

Моделькомандыравныхявляетсясоставнойчастью Microsoft Solutions Framework (MSF) – методологииразработкипрограммныхпроектовфирмы Microsoft. Этонаиболеедемократичнаямодель, посколькувнейнетявновыделенногоцентра. Моделькоманды MSF – этокомандаравных. Схематическиеепринятоизображатьввидецикла (рисунок 7.7), гдевсеролиравноправныисвязаныдругсдругом.

 

 

Рисунок 7.7. Модель команды равных.

 

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

Преимуществамоделикомандыравных.

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

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

Сильнаяположительнаямотивациятрудаиравновысокаязаинтересованностьвсехучастниковвконечномуспехе.

Основныенедостаткимодели MSF являютсяпродолжениемеедостоинств.

Дляформированиякоманды MSF нужныравные (равноквалифицированныеиравнозаинтересованные) участники.

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

Демократичнаямоделькоманды MSF плохосопрягаетсясжесткойиерархическоймодельюподразделения (предприятия).