Полностью распределенная разработка - что в основе
Я не успел подробно расспросить codedgers о том, как у них все устроено, но так даже интереснее. Когда теперь я знаю, что так можно, - можно попробовать применить “дедуктивный метод”.
Начнем с того, что новых методов контроля выполнения работ они вряд-ли изобрели, и пользуются существующими. Задача сводится к разбору существующих критериев закрытия задач/методов контроля/тестирования. Это раз.
Надо проанализировать все случаи, когда есть сильный выигрышь от быстрой “синхронной” коммуникации даже в офисе, а также - был замечен проигрышь в ее потере, скажем, из-за сдвига часовых поясов. Здесь будет слабое место распределенки, и надо будет уделить этому особое внимание. Это два.
И три. Коммуникация пир-ту-пир всегда эффективнее даже в личном общении. В распределенном - синхронная коммуникация пир-ту-пир заметно проще осуществляется. Вывод - надо учитывать этот факт.
Итак, первое, что мы делаем, учитывая последний факт - объединяем разработчиков в пары для работы над одной темой. Вводим первое правило - группе из пары мы можем поручить группу сильносвязных задач, тройке - уже нет.
Второе. Синхронная коммуникация. Она заметно ускоряет работу, в случае итеративного от природы процесса. Таковым у нас является, например, проектирование. После проектирования возможно выделить сльносвязные, и слабосвязные части, распараллелить работу. Соединяя это с предыдущим, получаем, следующее.
Мы должны поручить проектирование крупного куска паре разработчиков. Одного из них, в таком случае, надо назначить главным. После того, как они выполнят проектирование, они выделят набор изолированных задач, которые можно поручить другим программистам, работая с ними по схеме пир-ту-пир. За формулировку задач и интеграцию будет отвечать эта пара.
Да, им вполне может помогать удаленный спец по автоматической сборке, тестам, и прочему. Полуадмин-полупрограммист. Возможно, тестер. Возможно, полуавтоматический тестер. Здесь надо подумать.
Что у нас с критериями закрытия? Нам известны:
1) Дизайн-ревью. Документ, типо проходит ревью. Легкая форма - беседа группы у доски с маркером. Но мы поручаем крупное проектирование паре людей, так? Значит, наш критерий завершения дизайна
- они двое имеют общее понимание того, как будут делать систему.
- они четко выделили и детально прописали интерфейсы и контракты того, что будет делаться впараллель теми, кому они поручат разработку. Это должен быть таки документ. Один документ - Common Design Principles, который должен пройти стороннее ревью, и в коде, который они напишут - должны быть автогенеренные комменты по каждому классу, с которым столкнутся разработчики, которым поручат работу.
- О да, они должны написать код ядра системы, костяк, хотя бы минимум, и хоть на одном юзкейсе его протестить грубо. Чтобы интерфейсы стабилизировались, можно было поручать задания другим программистам, и можно было _принимать_ их работу.
- и последнее - они должны дать другим “параллельным удаленным” разработчикам какой-либо инструмент отладки. Можно, конечно, заставить удаленного парня писать на свой код юнит-тест. Но при описанном подходе, удаленный разработчик может скачать костяк системы (он будет работать на момент выдачи задания), и тестить свой компонент через него. Вот здесь - есть о чем подумать.
2) Код-ревью. То же с кодом. Есть клевые тулы, позволяющие делать это уделенно без сильных потерь. Ревью начинается с того, что его делает наша мегапара, с постепенным переводом код-ревью на горизонтальный уровень - чтобы параллельные разработчики ревьювили код друг друга.
Код лучше всего рьвьювить малыми порциями, но здесь это затруднительно. Здесь надо подумать.
Кстати, можно попросить удаленных также делать “дизайн”, и проверять его на ревью.
3) Юнит-тесты. Говорят, что помогает. Возможно.
4) Просто автоматические тесты + инварианты в коде. Доктор прописал. Моя любимая техника.
Что, в целом, у нас получилось?
Старый добрый подход Chief Programmer Team, увешанный набором модных современных прибамбасов. Но - все тот же Chief Programmer Team.
Первый подход из придуманных. И подход, имеющий минимальное трение при дорогих коммуникациях и максимальный КПД при полностью распределенной разработке (т.е. чрезвычайно дорогих коммуникациях).
Фигассе. Удивительное рядом, правда?
Seeking to demonstrate increased programmer productivity, a functional organization of specialists led by a chief programmer has combined and applied known techniques into a unified methodology. Combined are a program production library, general-to-detail implementation, and structured programming. The overall methodology has been applied to an information storage and retrieval system. Experimental results suggest significantly increased productivity and decreased system integration difficulties.
by F. T. Baker
IBM Systems Journal, 1972
Volume 11, Number 1, Page 56 (1972)
А еще удивительно то, что эта статья не лежит в открытом доступе :). Потрясающе.
Но его описание вы можете найти в мифическом человекомесяце Брукса. Брукс, зачем-то тихо поменял название этому замечательному методу, дав ему настолько дурацкое “хирургическое” название, что вряд-ли кому пришло в голову метод попробовать. Интересно, сослался при этом на Миллза с Бейкером, или нет. Не помню.
Так вот, за основу, я пожалуй, взял бы именно этот метод, если бы занимался полностью распределенной разработкой. С него бы начал, а далее - по обстоятельствам.