Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
Например, является ли "командной разработкой" всего лишь "совместная работа трёх и более человек"? Мне кажется, не любую работу "трёх и более" человек можно назвать "командной"
Может быть, "командная" — это такая работа, при которой несколько человек вместе работают эффективнее, чем по отдельности? Но и здесь не ясно — в компании из трёх сотрудников (директора, бухгалтера и программиста) получается тоже "командная" разработка? На мой взгляд, это определение похоже на правду, но сомневаюсь, что требования в вакансиях подразумевают именно такой вид "командной работы"
Или же "командная работа" — это "организованный по одной из [описанных в соответствующей литературе] методик процесс производства"? В таком случае, как я понимаю, в "команде" может быть лишь один программист (вкупе с проектировщиком, тестировщиком, аналитиком и прочими). Но опять же: а этого ли ждут при приёме на работу?
Например я для себя определяю "командность" работы как непрерывные коммуникации (даже "постоянное общенгие") между сотрудниками относительно путей решения существующих задач, обсуждения применяемых технологий, обмена опытом и знаниями. Но, получается, что командной разработкой могут заниматься и два формально не организованных человека, находящихся на разных континентах и общающихся между собой через интернет…
Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
а) наличие системы контроля версий и более менее "общего" кода
б) использование терминологии паттернов проектирования в качестве внутреннего языка общения вместо "а я вот такую фигню сделал, она одной хрень вот сюда тырится, а вот этими тремя коннектиться туда, сюда и на сервис на соседней тачке"
в) взаимное тестирование, ну и в идеале, взаимный код ревью
Здравствуйте, ___Avatar___, Вы писали:
___>Здравствуйте, _FRED_, Вы писали:
_FR>>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
___>а) наличие системы контроля версий и более менее "общего" кода ___>б) использование терминологии паттернов проектирования в качестве внутреннего языка общения вместо "а я вот такую фигню сделал, она одной хрень вот сюда тырится, а вот этими тремя коннектиться туда, сюда и на сервис на соседней тачке" ___>в) взаимное тестирование, ну и в идеале, взаимный код ревью
г) еще бактрекер и общую регулярно обновляемую документацию можно добавить в список
Здравствуйте, _FRED_, Вы писали:
_FR>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
Teamwork is a joint action by two or more people, in which each person contributes with different skills and express his or her individual interests and opinions to the unity and efficiency of the group in order to achieve common goals. This does not mean that the individual is no longer important; however, it does mean that effective and efficient teamwork goes beyond individual accomplishments. The most effective teamwork is produced when all the individuals involved harmonize their contributions and work towards a common goal.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, _FRED_, Вы писали:
_FR>>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
L>
L>Teamwork is a joint action by two or more people, in which each person contributes with different skills and express his or her individual interests and opinions to the unity and efficiency of the group in order to achieve common goals. This does not mean that the individual is no longer important; however, it does mean that effective and efficient teamwork goes beyond individual accomplishments. The most effective teamwork is produced when all the individuals involved harmonize their contributions and work towards a common goal.
L>По-моему, неплохо "расписано".
на практике обычно имеется в виду все таки то, что перечислил я
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, ___Avatar___, Вы писали:
L>>>По-моему, неплохо "расписано".
___>>на практике обычно имеется в виду все таки то, что перечислил я
L>Я так не считаю.
вы можете так не считать наблюдая и управляя рабочим процессом
но в ситуации, когда надо отвечать на этот вопрос на интервью, обычно имеется в виду все таки мой вариант
конечно возможна командная работа без всего описанного мною, но на интервью о такой работе говорить лучше не надо
Здравствуйте, Lloyd, Вы писали:
_FR>>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
L>Teamwork is a joint action by two or more people, in which each person contributes with different skills and express his or her individual interests and opinions to the unity and efficiency of the group in order to achieve common goals. This does not mean that the individual is no longer important; however, it does mean that effective and efficient teamwork goes beyond individual accomplishments. The most effective teamwork is produced when all the individuals involved harmonize their contributions and work towards a common goal.
L>По-моему, неплохо "расписано".
Да, хорошо; но на сколько я понимаю данную формулировку, она означает, что конкретная организация работы (производства) в каждом случае (для каждой команды) должна (или может) быть разной, в зависимости от индивидуальных особенностей участников команды. Важна лишь цель организации труда — получение максимальной эффективности от каждого сотрудника, а то, как именно должны быть построены взаимоотношения в команде не важно.
Я прав в своей оценке?
Help will always be given at Hogwarts to those who ask for it.
L>>Teamwork is a joint action by two or more people, in which each person contributes with different skills and express his or her individual interests and opinions to the unity and efficiency of the group in order to achieve common goals. This does not mean that the individual is no longer important; however, it does mean that effective and efficient teamwork goes beyond individual accomplishments. The most effective teamwork is produced when all the individuals involved harmonize their contributions and work towards a common goal.
L>>По-моему, неплохо "расписано".
_FR>Да, хорошо; но на сколько я понимаю данную формулировку, она означает, что конкретная организация работы (производства) в каждом случае (для каждой команды) должна (или может) быть разной, в зависимости от индивидуальных особенностей участников команды. Важна лишь цель организации труда — получение максимальной эффективности от каждого сотрудника,
Только не "от каждого сотрудника", а "от команды".
_FR>а то, как именно должны быть построены взаимоотношения в команде не важно.
Не всегда можно эти взаимоотношения построить, от людей сильно зависит, являются ли они командными игроками или нет.
_FR>Я прав в своей оценке?
Здравствуйте, Lloyd, Вы писали:
_FR>>Да, хорошо; но на сколько я понимаю данную формулировку, она означает, что конкретная организация работы (производства) в каждом случае (для каждой команды) должна (или может) быть разной, в зависимости от индивидуальных особенностей участников команды. Важна лишь цель организации труда — получение максимальной эффективности от каждого сотрудника, L>Только не "от каждого сотрудника", а "от команды".
Да, так точнее.
_FR>>а то, как именно должны быть построены взаимоотношения в команде не важно.
L>Не всегда можно эти взаимоотношения построить, от людей сильно зависит, являются ли они командными игроками или нет.
Это понятно.
Просто при таком определении "командности" получается, что в команде должен быть один человек — дерижёр или тренер (раз уж в самой википедии сослались на Бейба) и результат работы команды зависит именно от него. И не зависит от члена команды. Простой участник может или "вписаться" или нет (что решает [должен решать] тим-лид) но не может отвечать за результат работы команды в целом и даже за собственный, потому что собственный результат часто может зависеть от работы других участников команды, которая так же регулируется тим-лидом. Правильно я рассуждаю?
А веду я к тому, что при твоём определении "командной работы" (вернее, определении из вики) на собеседовании простого разработчика не должен быть важен опыт "командности" поскольку успешность данного опыта целиком и полностью определяется руководителем.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>>>а то, как именно должны быть построены взаимоотношения в команде не важно.
L>>Не всегда можно эти взаимоотношения построить, от людей сильно зависит, являются ли они командными игроками или нет.
_FR>Это понятно.
_FR>Просто при таком определении "командности" получается, что в команде должен быть один человек — дерижёр или тренер (раз уж в самой википедии сослались на Бейба) и результат работы команды зависит именно от него. И не зависит от члена команды. Простой участник может или "вписаться" или нет (что решает [должен решать] тим-лид) но не может отвечать за результат работы команды в целом и даже за собственный, потому что собственный результат часто может зависеть от работы других участников команды, которая так же регулируется тим-лидом. Правильно я рассуждаю?
Ты в детстве в футбол что-ли ни разу не играл? Вот тебе пример командной работы, когда никакого тим-лида нет.
_FR>А веду я к тому, что при твоём определении "командной работы" (вернее, определении из вики) на собеседовании простого разработчика не должен быть важен опыт "командности" поскольку успешность данного опыта целиком и полностью определяется руководителем.
С "целиком и полностью" — не согласен. Если человек не хочет работать в комманде, то никакой самый расчудесный руководитель не спасет.
> Часто при приёме на работу спрашивают об опыте "командной разработки". > Мне вот очень интересно: что под этим понимается? Хотелось бы узнать > короткое, ёмкое, но точное и максимально полное определение. > > Например, является ли "командной разработкой" всего лишь "совместная > работа трёх и более человек"? Мне кажется, не любую работу "трёх и > более" человек можно назвать "командной" > > Может быть, "командная" — это такая работа, при которой несколько > человек вместе работают эффективнее, чем по отдельности? Но и здесь не > ясно — в компании из трёх сотрудников (директора, бухгалтера и > программиста) получается тоже "командная" разработка? На мой взгляд, это > определение похоже на правду, но сомневаюсь, что требования в вакансиях > подразумевают именно такой вид "командной работы" > > Или же "командная работа" — это "организованный по одной из [описанных в > соответствующей литературе] методик процесс производства"? В таком > случае, как я понимаю, в "команде" может быть лишь один программист > (вкупе с проектировщиком, тестировщиком, аналитиком и прочими). Но опять > же: а этого ли ждут при приёме на работу? > > Например я для себя определяю "командность" работы как непрерывные > коммуникации (даже "постоянное общенгие") между сотрудниками > относительно путей решения существующих задач, обсуждения применяемых > технологий, обмена опытом и знаниями. Но, получается, что командной > разработкой могут заниматься и два формально не организованных человека, > находящихся на разных континентах и общающихся между собой через интернет… > > Отсюда и любопытство: что вы называете "командной работой"? С "наукой" > по данному вопросу я не знаком, потому буду особенно благодарен и за > ссылки на авторитетные источники по данному вопросу. > Что делает одежда с человеком! Просто чудеса какие-то творит. Никто, > ничто и звать никак, а шляпу надел и личность.
Это пустой трёп в описаниях вакансий. Как таковой опыт коммандной работы
не добавляет абсолютно никакого скила. (Конечно помимо систем контроля
версий, багтрекинга, формализации требований).
Задача интегрирования нового разработчика в комманду — на 100% задача
руководства комманды. А опыт коммандной работы — это вообще ни о чем.
Здравствуйте, ___Avatar___, Вы писали:
___>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, ___Avatar___, Вы писали:
L>>>>По-моему, неплохо "расписано".
___>>>на практике обычно имеется в виду все таки то, что перечислил я
L>>Я так не считаю.
___>вы можете так не считать наблюдая и управляя рабочим процессом ___>но в ситуации, когда надо отвечать на этот вопрос на интервью, обычно имеется в виду все таки мой вариант
___>конечно возможна командная работа без всего описанного мною, но на интервью о такой работе говорить лучше не надо
Простите, конечно, но я бы сказал что переисленные Вами пункты вообще сложно назвать определением.
Прежде всего (судя по Вашему же реплаю на свое сообщение) Ваш список не законченный и туда всегда можно что-то добавлять.
Пункт б) надо заменить на "Clear communication". Шаблоны тут не обязательны.
Ну а термин из в) о "взаимном тестировании" — вообще песня
OS>Это пустой трёп в описаниях вакансий. Как таковой опыт коммандной работы OS>не добавляет абсолютно никакого скила. (Конечно помимо систем контроля OS>версий, багтрекинга, формализации требований).
OS>Задача интегрирования нового разработчика в комманду — на 100% задача OS>руководства комманды. А опыт коммандной работы — это вообще ни о чем.
этот вопрос — способ отсева "начинающих звезд" в команду со средненьким менеджером, где нужны середнячки программисты
"начинающие звезды" начинают на нем либо нервничать, либо понимают, что им там нечего делатьи уходят, либо же дают такое развернутое описание методологий и особенностей командной работы, что нервничать начинает работодатель и в итоге также их отсеивает
Здравствуйте, Sanik, Вы писали:
S>Простите, конечно, но я бы сказал что переисленные Вами пункты вообще сложно назвать определением. S>Прежде всего (судя по Вашему же реплаю на свое сообщение) Ваш список не законченный и туда всегда можно что-то добавлять. S>Пункт б) надо заменить на "Clear communication". Шаблоны тут не обязательны. S>Ну а термин из в) о "взаимном тестировании" — вообще песня
S>Тут достаточно развернутое определение и немножко информации
есть идейное определение, аесть практическая реализация этого определения
в профессии программиста практической реализацией является именно то, что я описал
то что дали вы и ллойд — это идейные общие определения, подходящие для ЛЮБОЙ профессии
Здравствуйте, ___Avatar___, Вы писали:
___>Здравствуйте, Sanik, Вы писали:
S>>Простите, конечно, но я бы сказал что переисленные Вами пункты вообще сложно назвать определением. S>>Прежде всего (судя по Вашему же реплаю на свое сообщение) Ваш список не законченный и туда всегда можно что-то добавлять. S>>Пункт б) надо заменить на "Clear communication". Шаблоны тут не обязательны. S>>Ну а термин из в) о "взаимном тестировании" — вообще песня
S>>Тут достаточно развернутое определение и немножко информации
___>есть идейное определение, аесть практическая реализация этого определения ___>в профессии программиста практической реализацией является именно то, что я описал ___>то что дали вы и ллойд — это идейные общие определения, подходящие для ЛЮБОЙ профессии
Ну что Вы. Это чисто практическое.
Ваши "паттерны проектирования" были адаптированны из строительной индустрии. Не сужайте свой кругозор.
Ибо за березой Вы можете не увидеть лес.
> OS>Это пустой трёп в описаниях вакансий. Как таковой опыт коммандной работы > OS>не добавляет абсолютно никакого скила. (Конечно помимо систем контроля > OS>версий, багтрекинга, формализации требований). > > OS>Задача интегрирования нового разработчика в комманду — на 100% задача > OS>руководства комманды. А опыт коммандной работы — это вообще ни о чем. > > этот вопрос — способ отсева "начинающих звезд" в команду со средненьким > менеджером, где нужны середнячки программисты > > "начинающие звезды" начинают на нем либо нервничать, либо понимают, что > им там нечего делатьи уходят, либо же дают такое развернутое описание > методологий и особенностей командной работы, что нервничать начинает > работодатель и в итоге также их отсеивает
Какой смысл отсеивать тех, кто не имеет опыта коммандной работы?
Я на своей первой работе научился пользоваться VSS-ом к концу второго
дня. А первый мой код, который попал в VSS появился не раньше, чем через
неделю (а может быть и через 2). До этого, я вообще не знал, что такое
система контроля версий.
OS>>Это пустой трёп в описаниях вакансий. Как таковой опыт коммандной работы OS>>не добавляет абсолютно никакого скила. (Конечно помимо систем контроля OS>>версий, багтрекинга, формализации требований).
OS>>Задача интегрирования нового разработчика в комманду — на 100% задача OS>>руководства комманды. А опыт коммандной работы — это вообще ни о чем.
___>этот вопрос — способ отсева "начинающих звезд" в команду со средненьким менеджером, где нужны середнячки программисты
___>"начинающие звезды" начинают на нем либо нервничать, либо понимают, что им там нечего делатьи уходят, либо же дают такое развернутое описание методологий и особенностей командной работы, что нервничать начинает работодатель и в итоге также их отсеивает
Послушайте, вы уже столько раз акцентировали на себе внимание, что имеено ваши определния верны, что начинает казаться что вы и есть "начинающая звезда"
Здравствуйте, ___Avatar___, Вы писали:
___>Здравствуйте, Sanik, Вы писали:
S>>Простите, конечно, но я бы сказал что переисленные Вами пункты вообще сложно назвать определением. S>>Прежде всего (судя по Вашему же реплаю на свое сообщение) Ваш список не законченный и туда всегда можно что-то добавлять. S>>Пункт б) надо заменить на "Clear communication". Шаблоны тут не обязательны. S>>Ну а термин из в) о "взаимном тестировании" — вообще песня
S>>Тут достаточно развернутое определение и немножко информации
___>есть идейное определение, аесть практическая реализация этого определения ___>в профессии программиста практической реализацией является именно то, что я описал ___>то что дали вы и ллойд — это идейные общие определения, подходящие для ЛЮБОЙ профессии
Я хотел бы предложить другую версию. Перечисленное ___Avatar___ — это не практическая
реализация, а набор инструментов/методологий обычно сопутствующих успешной командной работе.
Очень часто номинально команда есть, а работает вяло. Что за этим скрыто? Не вдаваясь в
долгие рассуждения, причины примерно такие:
Бестолковое управление ресурсами.
Например, начали проект без QA,
— Нафиг программистам багтрекер? Они прекрасно друг другу словами всё расскажут. И так
сойдет!
Позже решают нанять QA, и начинается креативная свистопляска по созданию велосипедов
для управления дефектами:
— Ты пошли мне письмо, когда закончишь. Тест-кейз приаттачить не забудь. И тут вот еще
в экселе добавь строчку с описанием. Ну и в аську стукнись, что письмо послал.
Такая рутина быстро начинает злить. Изменить же устоявшееся положение
дел, начав использовать инструменты, трудно как минимум по двум причинам:
1) уже образовалась привычка, 2) нехватка времени.
Другой пример, о разделении зон ответственности:
— Зачем нам разных людей на server-side и GUI? И там и там джава (заменить по вкусу).
Очевидно, что они одинаково программируются. Бестолковое управление процессами.
Примеры:
1) Code review вживую, на специально организованном митинге; пусть автор помучается,
запоминая все комментарии; зато начальнику нравится — можно ведь на час притворится
занятым, посидев на этом митинге с умным лицом и ценными замечаниями;
2) На старте большого проекта:
— Для чего вам при интеграции с системой X архитектор-то? Как начнете с ними
интегрироваться, так и разберётесь что к чему. Всегда так делали.
Где-то в середине:
— Елки, опять у X некому клиентское API обновить. Придётся самим писать, хотя
и не планировали. А это чего за новые теги в XML ответа??? Они что там, в X, с ума посходили?!
3)
— Мы уделяем значительную часть времени написанию юнит-тестов! Забота о качестве
продукта — наша гордость!
— Но ведь у нас нет continuous integration?!
— Ничего. Люди прекрасно помнят, что нужно выполнять юнит-тесты вручную. Лень, как следствие первых двух
— Тебе чего, делать больше нечего, subversion на нас троих поднимать? Прекрасно все
на шаре сохранится. Вон, никто ж больше не напрягается. Да и начальнику пофиг.
Или так:
— Да зачем нам компонентная архитектура? Все прекрасно в один класс умещается. Потом
перепишем. Юнит-тесты? Да ну их, только время тратить — всё ж работает.
Список, конечно же, неполный, но вырисовывается одна мысль — командная работа возникает
тогда, когда для достижения общей цели каждый участник команды, включая менеджера,
стремится эффективно выполнять свою часть так, чтобы увеличить эффективность остальных.
Эффективность — многокритериальна. Тут и затраченное время, и сложность понимания реализации,
и количество дефектов, отловленных тестами, и возможность переиспользования кода и много
чего еще. Правильно подобранные инструменты же помогают достичь максимального количества
критериев с минимальными затратами.
Здравствуйте, Lloyd, Вы писали:
L>Ты в детстве в футбол что-ли ни разу не играл? Вот тебе пример командной работы, когда никакого тим-лида нет.
Аспекты организации "дворовых" команд меня не интересуют.
_FR>>А веду я к тому, что при твоём определении "командной работы" (вернее, определении из вики) на собеседовании простого разработчика не должен быть важен опыт "командности" поскольку успешность данного опыта целиком и полностью определяется руководителем.
L>С "целиком и полностью" — не согласен. Если человек не хочет работать в комманде, то никакой самый расчудесный руководитель не спасет.
А если хочет? Я говорю о "хорошей" ситуации, когда руководитель имеет команду людей, которыми доволен и которые довольны руководителем и хотят работать в команде. Если кто-то не хочет — это уже не совсем команда.
Help will always be given at Hogwarts to those who ask for it.
