?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Полностью распределенная разработка - что в основе

Posted on 2010.02.12 at 02:05
Tags: ,

Я не успел подробно расспросить 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)

А еще удивительно то, что эта статья не лежит в открытом доступе :). Потрясающе.

Но его описание вы можете найти в мифическом человекомесяце Брукса. Брукс, зачем-то тихо поменял название этому замечательному методу, дав ему настолько дурацкое “хирургическое” название, что вряд-ли кому пришло в голову метод попробовать. Интересно, сослался при этом на Миллза с Бейкером, или нет. Не помню.

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


Comments:


nuald at 2010-02-12 03:27 (UTC) (Link)

Небольшое уточнение

Раз уж вы приводите в пример нашу компанию, то внесу пару уточнений:
- Chief Programmer - это обычно наш Project Manager (только он не всегда пишет код). Да, это не особо удачно и не особо эффективно, поэтому мы активно работаем над оптимизацией внутренней логистики, чтобы снизить на PM-а нагрузку. И из этого следствие - PM-ами у нас становятся только бывшие разработчики, которые хорошо разбираются в теме.
- Вместо доски с маркерами мы активно используем вики. Стараемся все по максимуму документировать, чтобы инфа была не в головах, а была известна всем заинтересованным сторонам.
kpy3 at 2010-02-12 05:33 (UTC) (Link)

Re: Небольшое уточнение

Доска + мыльница-из-телефона + wiki тоже хороший вариант. Дружно нарисовали, обсудили, сфоткали, картинку вставили в wiki, добавили комментариев.
shalayev
shalayev at 2010-02-12 07:31 (UTC) (Link)

Re: Небольшое уточнение

Доска и мыльница легко заменяются whiteboardmeeting (приблуда такая к скайпу)
kpy3 at 2010-02-12 07:37 (UTC) (Link)

Re: Небольшое уточнение

О! Спасибо за наводку. =)
nuald at 2010-02-12 08:40 (UTC) (Link)

Re: Небольшое уточнение

К сожалению, работает только под Windows. Нормального кроссплатформенного аналога я так и не нашел, в основном какие-то глючные поделки. Но может не там искал :)
Gaperton
gaperton at 2010-02-12 14:03 (UTC) (Link)

Re: Небольшое уточнение

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

В CQG мы каким-то онлайн-сервисом пользовались для этого - он и конференции тянул большие, и презентации, и стол расшаривать позволял. Забыл тока, черт, как эта штука называлась. Но их полно быть должно.
saveug at 2010-02-12 08:27 (UTC) (Link)

Re: Небольшое уточнение

Интересно, а кроме wiki еще какими-то инструментами по обеспечению процесса разработки вы пользуетесь? Ну, в первую очередь, интересует совместное планирование и постановка задач/целей?
nuald at 2010-02-12 08:37 (UTC) (Link)

Re: Небольшое уточнение

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

Если говорить про планирование, то в Trac-e есть Roadmap, который мы заполняем, плюс первоначальные задачи ставятся через тикеты. Хотелось бы отметить, что всяческие диаграммы Ганта не прижились, т.к. слишком много времени требуется для их поддержания в актуальном состоянии. Мы живем в реальном мире, и он диктует свои условия. Это только в мечтах, или в очень формализованных методиках разработки можно все заранее распланировать. Плюс сказывается то, что у нас в основном идет упор на Research, и здесь предугадать сроки очень тяжело. В основном мы планируем на уровне функциональных checkpoint-ов - как раз то, что многоуважаемый господин Балин читал нам на семинаре.
Gaperton
gaperton at 2010-02-12 14:18 (UTC) (Link)

Re: Небольшое уточнение

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

На это есть фундаментальные причины. Диаграммы Ганта были изначально изобретены Гантом для описания производственных процессов. Производственная метафора плохо подходит для проектной деятельности, приводя к смещению акцента в управлении с результата на процессы, отчетность, и показатели. А в случае софта и R&D - она катастрофически плохо работает.

Я примерно половину тренинга посвятил объяснению, почему именно "производственная метафора" не работает, показывая, как глубоко она запустила корни в разные аспекты "традиционного" управления проектами :). И в частности, в чем проблема сетевого графика (это тот же гант по сути - только в профиль).
Gaperton
gaperton at 2010-02-12 13:58 (UTC) (Link)

Re: Небольшое уточнение

"- Chief Programmer - это обычно наш Project Manager (только он не всегда пишет код). Да, это не особо удачно и не особо эффективно, поэтому мы активно работаем над оптимизацией внутренней логистики, чтобы снизить на PM-а нагрузку."

Это существенное отступление от CPT которое должно повысить "трение". Наличие двух программеров, которые пишут код - важно в этой схеме. Менеджер в CPT также присутствует (третьим), его отличие от Chief Programmer в том, что он не полностью погружен в тему, и вообще говоря, координирует работу нескольких команд. Есть также вариант, когда менеджер работает по запросам Chief Programmer-a, ассистируя ему и беря на себя только организационные вопросы. Менеджер занят вопросами выделения ресурсов. И, возможно, управлением требованиями - хорошее сочетание, не приводящее к конфликту приоритетов.

Chief Progrаmmer ближе всего к современной должности Team Lead, или Lead Programmer, который является полупрограммистом-полуруководителем в группе размером 5-6 человек. В американской армии есть прямой эквивалент этой должности - сержант.
Gaperton
gaperton at 2010-02-12 14:00 (UTC) (Link)

Re: Небольшое уточнение

Как вы диаграммы в вики кладете, кстати?
nuald at 2010-02-12 14:24 (UTC) (Link)

Re: Небольшое уточнение

Обычно рисуются в чем-то типа Visio, хотя есть и более продвинутая методика - используется GraphViz плагин, который рисует все автоматом из dot-формата (текстовой формат для описания диаграмм).

Потом это либо аттачится (если это рисунок), либо просто меняется текст (при использовании dot-формата) и плагин уже рисует диаграмму на основе этого текста.
NaN
guamoka at 2010-02-12 09:41 (UTC) (Link)
Вообще удивительно, до чего много таких разработчиков, стоящих на ключевых позициях в проекте, у которых напрочь осутствует чутье на "узловые точки", иерархию и координацию. В результате на каждого члена команды сваливается задача с кучей открытых горизонтальных и- того хуже- вертикальных связей. На одной из работ все же довелось наблюдать разработку по принципу "команда главного хирурга", правда всего лишь в масштабе подсистемы. Но разницу можно было почувствовать сразу, когда один ключевой разработчик занимался формулированием требований, делегированием обязанностей и интеграцией полученных компонент. Чаще же работа вырождается в то, что для разработки прикуривателя или, там, бардочка, каждый разработчик должен иметь и поддерживать целый автомобиль. Уныло.
nuald at 2010-02-12 14:35 (UTC) (Link)
Когда ключевой разработчик занимается всем сразу, это, конечно, плохо, и вообще это нонсенс - при любом косяке (например, этот разработчик заболевает) проект скатывается в бездну. Ну может кто-то так и делает, могу только посочувствовать.

А вот насчет того, что каждый разработчик не "должен иметь и поддерживать целый автомобиль" я все-таки буду немного несогласен. Я не особо люблю очень узкопрофильных специалистов, т.к. они:
- бесполезны вне своего профиля (как дотнетчики, которые теряются когда им нужно через interop прикрутить какую-нить dll-ку, хотя по идее это их обязанность);
- при каких-то форсмажорных обстоятельствах (опять-таки кто-то заболел) не смогут никого заменить.

Специализацию конечно, хорошо иметь, и развиваться в данном направлении, но не стоит забывать и про другие векторы развития - жизнь не стоит на месте, и надо постоянно учиться, особенно в нашей динамично изменяющейся отрасли.
Gaperton
gaperton at 2010-02-12 14:48 (UTC) (Link)
+1 везде.

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

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

Гораздо лучше "функциональная" специализация - по предметной области. Она рулит.
NaN
guamoka at 2010-02-13 18:16 (UTC) (Link)
В общем-то, я имел в виду не совсем то.


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


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


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


Во-вторых, речь не идет об узкой специализации. Существует определенный стек знаний, которым должен обладать разработчик, скажем, разработчик JEE приложенией, и этот набор знаний не ограничевается Java, либо какой-то частью JEE спецификации, а влючает в себя и базы данных, и интернет технологий, и администрирования App серверов, причем от различных вендоров, и проч. Речь шла о грамотном распределении обязанностей в команде на проекте и зон отвественности. На практике же, очень часто встреченной мной, получается так, что отсутствие менеджмента на этом уровне выливается в разработку "Фигаро здесь, Фигаро там, Фигаро опять здесь, Фигаро и здесь и там, пока другой Фигаро занят еще более срочным делом". И все это- отсутствие грамотного управления разработкой- оправдывается тем, что якобы разработчи а) не желают учиться б) не хотят работать.
i_love_python
i_love_python at 2010-02-12 13:41 (UTC) (Link)
В комментариях к предыдущей статье я пытался приводить примеры на основе команд в Canonical, с которыми я немного знаком. В целом так, как вы пишете, там и работают.
Gaperton
gaperton at 2010-02-12 13:44 (UTC) (Link)
Это радует. Это подтверждает, что истина где-то рядом.
Previous Entry  Next Entry