Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Документирование и распределённый мозг команды разработчиков

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

Ответом на это стало появление динамических методологий, основная масса которых относится к документированию приблизительно следующим образом: "Документирования нужно ровно столько, сколько решит команда и спонсор для данного конкретного проекта" [1].

Второе открытие динамических методологий заключается в том, что документирование может быть выражено в различных формах. Наследие инженерных дисциплин сводило документирование к узкому классу инженерных артифактов, а именно "инструкция (алгоритм)" и "чертёж (диаграмма)". Большинство же гибких методологий, протестуя против инженерной сути софтверной разработки, предлагает более вольное трактование понятия "проектная документация" и включают в него все возможные артифакты, способные служить метками, по которым можно восстановить суть ценной для проекта информации, начиная c салфеток с набросками пользовательского интерфейса и заканчивая фотографиями доски или даже видеозаписями митингов или дискуссий [2].

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

Из этой модели следуют и очевидные рамки её применимости:

 - Чем хуже коммуникации, тем больше нужно маркеров, например для эффективной работы удалённой команды этих маркеров нужно больше всего.

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

 - Чем выше риск потери части "распределённого знания" (уход или долгое отсутствие сотрудников), тем выше должно быть дублирование этих знаний и тем больше маркеров приходится задействовать. 

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

 

Источники

1. Alistair Cockburn 'How many work products are needed in software development?'

2. Alistair Cockburn 'The end of software engineering and the start of economic-cooperative gaming'


Posted by Vitalii Tsybulnyk on Sunday, September 13, 2009 7:13 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Add comment




  Country flag

b i u quote
Loading