Здравствуйте, Valery A. Boronin, Вы писали:
VAB>всем привет!
Тезизы подчерпнутые из имхо толковых книг:
1. Полезность человека на данной позиции определяется тем, насколько часто к нему обращаются.
Соотв. если на архитектора кладут с пробором — ценности от него 0.
2. Лидерство — есть чел. качество, такое что люди асооциируют лидера с возможностью достижения собственных целей.
Соотв. если человек не смог убедительно продемонстрировать команде, что он эффективнее других видит путь достижения проектных целей — такой лидер нелегитимный.
Мое имхо — архитектора или проектировщика нельзя просто так назначить, он обязан заполучить доверие большинства в команде.
On Thu, 13 Apr 2006 12:35:59 +0300, Joker6413 <16101@users.rsdn.ru> wrote:
> Здравствуйте, Valery A. Boronin, Вы писали: > > VAB>всем привет! > > Тезизы подчерпнутые из имхо толковых книг: > > 1. Полезность человека на данной позиции определяется тем, насколько часто к нему обращаются. > > Соотв. если на архитектора кладут с пробором — ценности от него 0. > > 2. Лидерство — есть чел. качество, такое что люди асооциируют лидера с возможностью достижения собственных целей. > > Соотв. если человек не смог убедительно продемонстрировать команде, что он эффективнее других видит путь достижения проектных целей — такой лидер нелегитимный. > > Мое имхо — архитектора или проектировщика нельзя просто так назначить, он обязан заполучить доверие большинства в команде.
согласен.
да вот только узнать ето можно если команда устоявшаяса,
и сотрудники уже хорошо знакомы, а если команда недавно
создана. если ждать пока все подружатса и начнуть адекватно
оценивать друг друга — то можно и проект убить ...
как на меня — роли и ответственость распределить надо сначала,
а по мере утряски можно менять людей местами,
может человек которий хочет "попроектить" не ув'язывает
ето с ответственностю, а если да — то пусть попробует
дать ему испытательный строк. может ему самому перехочетса
J>Мое имхо — архитектора или проектировщика нельзя просто так назначить, он обязан заполучить доверие большинства в команде.
Как сказать. Если его не считают сильным профессионалом — то да.
А если он просто не вписался в тусню — то вот на это и положить можно. Вообще должно быть меньше неформальных тусовок на работе — это в конечном счете всегда вредит.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Такая маленькая мелочь. Чем выше позиция, тем меньше таких людей. Отсюда следствие — далеко не каждый сотрудник растет безгранично. Более того — у каждого сотрудника есть некий потолок, после которого он уже не способен к росту. По достижении этого потолка человек может хоть 10 лет на одном проекте на той же позиции сидеть.
Трудно с этим не согласится, но лично мне например ( и не только мне) больше по душе люди которые развиваются постоянно. Но я категорически не согласен с наличием строго вертикального роста. т.е классный разработчик -- проектный менеджер или системный аналитик. Кстати за вопросы по повышению квалификации команды тоже в ответе ПМ
MSS>Достиг ли данный девелопер этого потолка? Это один вопрос. Сравнительная его позиция в _данной конкретной команде_ — второй. Если он уже де-факто архитектор, то почему бы это не сделать де-юре? а если он умничающий оболтус, который делает немного полезного труда — то другой разговор.
MSS>Согласен. Не будет более опытный человек всерьез прислушиваться к менее опытному. Почти никогда.
Ага и вам как ПМ осталось определить кто в каком вопросе самый опытный. Есть такой тест по работе командой(для менеджеров) дают набор работ из совершенно "левой" предметной области. Нужно их в правильном порядке расставить. два человека делая сие независимо и вместе имеют разыне результаты. Командный результат лучше..
MSS>А вот если менеджер пытается лезть в технику... вот тут-то саботаж и начинается.
Менеджер обязан разибратся в области в которой он работает... Кроме этого конечно же лучше иметь экспертом которымподобные вопросв можно делегировать.
MSS>Абсолютно не согласен. Как представлю себе внесение в MS Project "палочки" о документировании кода — так дурно становится — как можно так неэффективно работать? Код должен всегда пребывать в относительно документированном состоянии, критерий "документированности" — понятность соседу. Особенно это к интерфейсам относится.
Вы абсолютно правы. Документация должна развиватся вместе с разработкой. в реальной жизни дедлайны и все такое... так редко получается. Поэтому приходится корректировать ситуацию.
MSS>При помощи собственных комментариев в первую очередь. Тратить время на юнит-тесты (время, часто сравнимое с написанием самого кода) имеет смысл только в особо ответственных местах, где хотелось бы не допускать появления баги ну почти любой ценой (в пределах ресурсов).
В этом осторожнее. Может ветка в холливарс оказатся. Лично то что видел я — разработка бизнес логики используя TDD получается более быстрой. ( тесты не так медленно пишутся а вот отладка сокращается в разы).
MSS>Некоторые компоненты, такие, как GUI, вообще не поддаются юнит-тестированию.
Я сталкивался с умельцами кто тестировал ГУИ... вынужден согласится — мрачно но TDD штука прикольная
MSS>Цель любой диаграммы — облегчить понимание человеком какой-то сущности. Дело в том, что человеческая психика часто с трудом понимает набор слов, коим является текстовое описание. Вот для облегчения этого понимания и делают диаграммы. Они не могут заменить текст, да и нужны только тогда, когда текста недостаточно для понимания.
Ваше ИМХО
MSS>Это дидактический материал, т.е. материал, цель которого не в создании проекта, а в доведении уже созданного проекта до некоторых (обычно не совсем звездных) голов. Простите, вели ли Вы большие проекты ?
MSS>Вот на что реально стоит тратить время — это на то, чтобы _все верно и одинаково все понимали_. Это основная цель митингов в толковых командах. Это вообще один из важнейших факторов в работе команды, недостаток этого фактора приводит к тяжким последствиям.
Математичекси — верно. В реальной жизни я такого не видел.. но опыта у меня всего года 2. так что не буду спорить.
MSS>Такую цель стоит решать напрямую митингом, а не уповать на доп. инструменты типа диаграмм.
угу. В результате митинга должны появится диаграммы. хоть УМЛ хоть кружочки хоть... в общем митинги в данном топике оффтоп
MSS>Когда время есть — то конечно. А уж кросс-ревизия ради _вычитки явных багов_ — просто благо, особенно в системном софте, где поиск 1 бага часто занимает несколько дней. Кросс-ревизия _ради повышения читаемости_ — тут я более скептически отношусь, тому есть причины.
MSS>Microsoft делал и делает совершенно иначе, и как-то лидирует на рынке ключевые подсистемы Windows написаны в 89-92 годы очень небольшим количеством людей, кое-где в одиночку. За большое время, порядка полутора лет каждая.
то что Вы указали год и есть ключевой момент вашей реплики.
>>людей, которые разберутся в написанном.. и не МЕНЕЕ двух людей способных обьяснить
MSS>То-то у Microsoft есть понятие owner для любого куска кода. который часто один, хотя и меняется во времени.
И правильная политика. На любой работе должен быть 1 ответсвенный. Наверное поэтому и придумали ПМ, ведущих разработчиков архитекторов и тп.
MSS>Нет. Задача менеджера — обеспечить получение того продукта, ради которого трудится команда и тратятся ресурсы. С требуемым качеством и в требуемые сроки.
Хорошая книжная формулировка. Кстати еще менеджеру необходимо научится искать интерационные и компромисные решения да и выдать продукт хреновой командой не удасться..как ни крути. Хотя конечно бывают исключения...
MSS>Налицо совершенно неверное понимание смысла работы руководителя. Приведет оно к весьма распространенному в постсовковом бизнесе явлению — личностные игры с мелкими кадровыми перестановками и прочий "тим-спирит-по-весьегонски" вдруг выходят на первый план, а реальное дело — уходит на второй.
Боже упаси. На самом деле ключевой проблеммой являются как раз люди. С ними сложнее всего. И именно они проект и делают. Смысл руководителя сделать так чтобы люди работали так, чтобы "обеспечить получение того продукта, ради которого трудится команда и тратятся ресурсы. С требуемым качеством и в требуемые сроки"
MSS>Мы имеем — есть очень важный кусок проекта, на нем сидит 1 девелопер, который с заморочками, но в общем справляется, и труднозаменим. Ему предлагается — дать в нагрузку олуха царя небесного, просто из каких-то "менеджерских" соображений.
MSS>Вы можете себе представить, как упадет производительность этого девелопера (и олух-помощник ее совсем не повысит)? как это отразится на проекте в целом?
Олухов надо гнать. А раз не выгнали, то поверте — под нормальным ведущим олух хотябы беды не наделает
MSS>Разумные руководители — не только в IT — спокон веков старались изолировать ключевых людей, реально делающих главнейшие куски работы, от любых дурацких видов активности и всякой месткомовской общественной работы.
Для этого нас ПМов и придумали. для этого придумали и аналитиков. и тестировщиков.. в общем роли для этого и придумали И назначать человека на роль ему соответсвующую.. это и есть та изоляция , о которой вы говорите.
MSS>Тут же предлагается обратное.
>>Пару ему необходимо менять. Перед началом такой практики сотруднику необходимо >>объяснить, что его задача не доказать всем что он самый умный, но попытатся научить >>остальных.
MSS>За-чем??? не, ну правда, ну зачем??? у каждого из остальных — есть свой кусок работы, который тоже надо делать. Зачем отрывать от этого время ради обучения у того, первого девелопера? в ситуации, когда на тебе накопилось 100 issues в source control, человеку уже совсем не до получения знаний о _чужой_ компоненте проекта.
В такой ситуации человека трогать нельзя. Но с другой стороны — если на ВАС 100 реквестов то лично я бы попытался подсоеденить к ВАМ когото еще на помощь а может и нет. это зависит от сроков и наличия ресурсов.
MSS>Налицо еще и неправильное понимание роли архитектора. Архитектура — она не зависит от исполнителей. Неужели это не понятно? Это чисто техническая вещь. Может быть хорошая архитектура при отстойной команде. Может быть наоборот.
Ноу комментс.
MSS>Архитектор софта — это вообще практически не социальная роль. Он с объектами и абстракциями работает, а не с людьми. Это работа "человек — знаковые системы", а не работа "человек — человек".
трудно ему..архитектору этому придется.. ведь кроме того чтобы чтото разработать..нужно еще и доказать гениальность задуманного ... Хотя последнее верно лишь для демократического и авторитарного способа управления
MSS>Какая прелесть. Совок образца Константина Устиныча Черненко. Вы хоть время в MS Project на участие в этих митингах не забыли саллоцировать?
Между прочим есть очень важный фактор. Кажется — вовлеченность в проект. Очень важный мотиватор. Что касается черненко, то я не слышал о таком ПМ
MSS>Ни одна компания не может обеспечить всему персоналу карьерный рост в плане количества подчиненных и наименования позиции. Да это и не есть цель никакой компании.
Цкль компании — прибыль. В основном успех компании зависит от персонала.
MSS>Скажем точнее — не в крупных компаниях, а в бестолковых.
Да ну
Вы ведете проект на 1000000 доларов. Сильно сомневаюсь, что заказчикам не будет интересны Ваши архитектурные решения .
MSS>А вот это очень и очень правильно. И людей надо приучать к _конструктиву_ в конфликтных и прочих гнилых ситуациях.
Я очень рад, что мы с вами в большинстве вопросов сходимся
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>Руководитель не видит для этого возможности, так как: VAB>1 — есть проблемы в общении почти со всеми членами команды, выражающиеся в том, что свое мнение сотрудник всегда считает самым важным, а остальных членов команды не совсем квалифицированными мягко говоря. VAB>2 — есть проблемы с управляемостью, сотрудник не документирует работу, пишет код в котором может разобраться только он, по сути. VAB>3 — саботирует приказы, реагирует только на кнут – в стиле – «не будешь делать, так как я говорю — лишим премии». VAB>4 — если сотрудник выпадет из процесса по какой-либо причине — есть кому разбираться и делать его работу, но около 2х месяцев уйдет на изучение, и через еще месяца 4, возможно, ситуация выправится.
А может он прав? И в команде что-то не так?
1. Задача архитектора выработать доказанное решение в форме понятной сверху (менеджменту и соседним структурам) и снизу (разработчикам). Может он просто плохо выполняет такие требования(что к сожалению часто бывает) и чем вызывает у сотрудника вполне обоснованный протест(типа что тут делает этот лох, когда я лучше)?
2. Задача team-leader не только корректно управлять заданиями и временем работы сотрудников. Его задача знать весь код и все особенности этого кода. Может он не выполняет свои функции если придется новому сотруднику разбираться в недокументированном коде?
VAB>Вопросы: VAB>Можно ли изменить ситуацию?
Не бывает ничего невозможного. Но за все надо платить. VAB>Каким образом?
Сначало ответь на вполне корректные вопросы по принятой системе разработки
GZ>1. Задача архитектора выработать доказанное решение в форме понятной сверху (менеджменту и соседним структурам) и снизу (разработчикам). Может он просто плохо выполняет такие требования(что к сожалению часто бывает) и чем вызывает у сотрудника вполне обоснованный протест(типа что тут делает этот лох, когда я лучше)? GZ>2. Задача team-leader не только корректно управлять заданиями и временем работы сотрудников. Его задача знать весь код и все особенности этого кода. Может он не выполняет свои функции если придется новому сотруднику разбираться в недокументированном коде?
Честно говоря, у меня возникает мнение, что архитектор и тимлид в классическом понимании нужны _только_ тогда, если в компании всего 2 толковых разработчика, а остальные — лохи.
А если толковы _все_ разработчики? нужны ли вообще тогда функции архитектора и тимлида, или тут стоит почерпнуть что-то из XP?
Здравствуйте, malkolinge, Вы писали:
M>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Такая маленькая мелочь. Чем выше позиция, тем меньше таких людей. Отсюда следствие — далеко не каждый сотрудник растет безгранично. Более того — у каждого сотрудника есть некий потолок, после которого он уже не способен к росту. По достижении этого потолка человек может хоть 10 лет на одном проекте на той же позиции сидеть. M>Трудно с этим не согласится, но лично мне например ( и не только мне) больше по душе люди которые развиваются постоянно. Но я категорически не согласен с наличием строго вертикального роста. т.е классный разработчик -- проектный менеджер или системный аналитик. Кстати за вопросы по повышению квалификации команды тоже в ответе ПМ
MSS>>Достиг ли данный девелопер этого потолка? Это один вопрос. Сравнительная его позиция в _данной конкретной команде_ — второй. Если он уже де-факто архитектор, то почему бы это не сделать де-юре? а если он умничающий оболтус, который делает немного полезного труда — то другой разговор.
MSS>>Согласен. Не будет более опытный человек всерьез прислушиваться к менее опытному. Почти никогда. M>Ага и вам как ПМ осталось определить кто в каком вопросе самый опытный. Есть такой тест по работе командой(для менеджеров) дают набор работ из совершенно "левой" предметной области. Нужно их в правильном порядке расставить. два человека делая сие независимо и вместе имеют разыне результаты. Командный результат лучше..
MSS>>А вот если менеджер пытается лезть в технику... вот тут-то саботаж и начинается. M>Менеджер обязан разибратся в области в которой он работает... Кроме этого конечно же лучше иметь экспертом которымподобные вопросв можно делегировать.
MSS>>Абсолютно не согласен. Как представлю себе внесение в MS Project "палочки" о документировании кода — так дурно становится — как можно так неэффективно работать? Код должен всегда пребывать в относительно документированном состоянии, критерий "документированности" — понятность соседу. Особенно это к интерфейсам относится. M>Вы абсолютно правы. Документация должна развиватся вместе с разработкой. в реальной жизни дедлайны и все такое... так редко получается. Поэтому приходится корректировать ситуацию.
MSS>>При помощи собственных комментариев в первую очередь. Тратить время на юнит-тесты (время, часто сравнимое с написанием самого кода) имеет смысл только в особо ответственных местах, где хотелось бы не допускать появления баги ну почти любой ценой (в пределах ресурсов). M>В этом осторожнее. Может ветка в холливарс оказатся. Лично то что видел я — разработка бизнес логики используя TDD получается более быстрой. ( тесты не так медленно пишутся а вот отладка сокращается в разы).
MSS>>Некоторые компоненты, такие, как GUI, вообще не поддаются юнит-тестированию. M>Я сталкивался с умельцами кто тестировал ГУИ... вынужден согласится — мрачно но TDD штука прикольная
MSS>>Цель любой диаграммы — облегчить понимание человеком какой-то сущности. Дело в том, что человеческая психика часто с трудом понимает набор слов, коим является текстовое описание. Вот для облегчения этого понимания и делают диаграммы. Они не могут заменить текст, да и нужны только тогда, когда текста недостаточно для понимания. M>Ваше ИМХО
MSS>>Это дидактический материал, т.е. материал, цель которого не в создании проекта, а в доведении уже созданного проекта до некоторых (обычно не совсем звездных) голов. M> Простите, вели ли Вы большие проекты ?
MSS>>Вот на что реально стоит тратить время — это на то, чтобы _все верно и одинаково все понимали_. Это основная цель митингов в толковых командах. Это вообще один из важнейших факторов в работе команды, недостаток этого фактора приводит к тяжким последствиям. M>Математичекси — верно. В реальной жизни я такого не видел.. но опыта у меня всего года 2. так что не буду спорить.
MSS>>Такую цель стоит решать напрямую митингом, а не уповать на доп. инструменты типа диаграмм. M>угу. В результате митинга должны появится диаграммы. хоть УМЛ хоть кружочки хоть... в общем митинги в данном топике оффтоп
MSS>>Когда время есть — то конечно. А уж кросс-ревизия ради _вычитки явных багов_ — просто благо, особенно в системном софте, где поиск 1 бага часто занимает несколько дней. Кросс-ревизия _ради повышения читаемости_ — тут я более скептически отношусь, тому есть причины.
MSS>>Microsoft делал и делает совершенно иначе, и как-то лидирует на рынке ключевые подсистемы Windows написаны в 89-92 годы очень небольшим количеством людей, кое-где в одиночку. За большое время, порядка полутора лет каждая. M>то что Вы указали год и есть ключевой момент вашей реплики.
>>>людей, которые разберутся в написанном.. и не МЕНЕЕ двух людей способных обьяснить
MSS>>То-то у Microsoft есть понятие owner для любого куска кода. который часто один, хотя и меняется во времени. M>И правильная политика. На любой работе должен быть 1 ответсвенный. Наверное поэтому и придумали ПМ, ведущих разработчиков архитекторов и тп.
MSS>>Нет. Задача менеджера — обеспечить получение того продукта, ради которого трудится команда и тратятся ресурсы. С требуемым качеством и в требуемые сроки. M>Хорошая книжная формулировка. Кстати еще менеджеру необходимо научится искать интерационные и компромисные решения да и выдать продукт хреновой командой не удасться..как ни крути. Хотя конечно бывают исключения...
MSS>>Налицо совершенно неверное понимание смысла работы руководителя. Приведет оно к весьма распространенному в постсовковом бизнесе явлению — личностные игры с мелкими кадровыми перестановками и прочий "тим-спирит-по-весьегонски" вдруг выходят на первый план, а реальное дело — уходит на второй. M>Боже упаси. На самом деле ключевой проблеммой являются как раз люди. С ними сложнее всего. И именно они проект и делают. Смысл руководителя сделать так чтобы люди работали так, чтобы "обеспечить получение того продукта, ради которого трудится команда и тратятся ресурсы. С требуемым качеством и в требуемые сроки"
MSS>>Мы имеем — есть очень важный кусок проекта, на нем сидит 1 девелопер, который с заморочками, но в общем справляется, и труднозаменим. Ему предлагается — дать в нагрузку олуха царя небесного, просто из каких-то "менеджерских" соображений.
MSS>>Вы можете себе представить, как упадет производительность этого девелопера (и олух-помощник ее совсем не повысит)? как это отразится на проекте в целом?
M>Олухов надо гнать. А раз не выгнали, то поверте — под нормальным ведущим олух хотябы беды не наделает
MSS>>Разумные руководители — не только в IT — спокон веков старались изолировать ключевых людей, реально делающих главнейшие куски работы, от любых дурацких видов активности и всякой месткомовской общественной работы. M>Для этого нас ПМов и придумали. для этого придумали и аналитиков. и тестировщиков.. в общем роли для этого и придумали И назначать человека на роль ему соответсвующую.. это и есть та изоляция , о которой вы говорите.
MSS>>Тут же предлагается обратное.
>>>Пару ему необходимо менять. Перед началом такой практики сотруднику необходимо >>>объяснить, что его задача не доказать всем что он самый умный, но попытатся научить >>>остальных.
MSS>>За-чем??? не, ну правда, ну зачем??? у каждого из остальных — есть свой кусок работы, который тоже надо делать. Зачем отрывать от этого время ради обучения у того, первого девелопера? в ситуации, когда на тебе накопилось 100 issues в source control, человеку уже совсем не до получения знаний о _чужой_ компоненте проекта. M>В такой ситуации человека трогать нельзя. Но с другой стороны — если на ВАС 100 реквестов то лично я бы попытался подсоеденить к ВАМ когото еще на помощь а может и нет. это зависит от сроков и наличия ресурсов.
MSS>>Налицо еще и неправильное понимание роли архитектора. Архитектура — она не зависит от исполнителей. Неужели это не понятно? Это чисто техническая вещь. Может быть хорошая архитектура при отстойной команде. Может быть наоборот. M>Ноу комментс.
MSS>>Архитектор софта — это вообще практически не социальная роль. Он с объектами и абстракциями работает, а не с людьми. Это работа "человек — знаковые системы", а не работа "человек — человек". M>трудно ему..архитектору этому придется.. ведь кроме того чтобы чтото разработать..нужно еще и доказать гениальность задуманного ... Хотя последнее верно лишь для демократического и авторитарного способа управления
MSS>>Какая прелесть. Совок образца Константина Устиныча Черненко. Вы хоть время в MS Project на участие в этих митингах не забыли саллоцировать? M>Между прочим есть очень важный фактор. Кажется — вовлеченность в проект. Очень важный мотиватор. Что касается черненко, то я не слышал о таком ПМ
MSS>>Ни одна компания не может обеспечить всему персоналу карьерный рост в плане количества подчиненных и наименования позиции. Да это и не есть цель никакой компании. M>Цкль компании — прибыль. В основном успех компании зависит от персонала.
MSS>>Скажем точнее — не в крупных компаниях, а в бестолковых. M>Да ну M>Вы ведете проект на 1000000 доларов. Сильно сомневаюсь, что заказчикам не будет интересны Ваши архитектурные решения .
MSS>>А вот это очень и очень правильно. И людей надо приучать к _конструктиву_ в конфликтных и прочих гнилых ситуациях.
M>Я очень рад, что мы с вами в большинстве вопросов сходимся
M>Евгений Веселов
Написал длииинный такой ответ, и тут у меня упал IE, в соседнем окне которого был открыт RTFный документ. Увы.
Писать подробно теперь в лом. Скажу только главное — вы слишком большое внимание уделяете личностному фактору в команде, в то время как обычно его наоборот стараются нейтрализовать и удавить.
Например, формализация всего делового общения между сотрудниками — дело а) благое б) азы управления бизнесом, то, с чего начинаются стандарты управления ISO 9000 и прочее.
Это не значит заполнения дебильных форм. Это значит всего лишь принятые схемки общения.
Цель формализации — очевидна. Убрать межличностный элемент.
Что же касается "вовлеченности в проект" как мотиватора — слабенький это мотиватор, хилОй совсем. Это такой же мотиватор, как переходящее красное знамя в 83ем году.
По сравнению с такими вещами, как деньги и как наличие/отсутствие хамства — это просто пустяк.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Честно говоря, у меня возникает мнение, что архитектор и тимлид в классическом понимании нужны _только_ тогда, если в компании всего 2 толковых разработчика, а остальные — лохи.
Нет. Проблема в том, что у простого программера и архитектора(или человека выполняющего его функции) и роль и знания достаточно разные. Оружие архитектора не код, а некоторый документ(не важно в чем но он быть обязан) в котором описывается требования к архитектуре, как будут они выполняться, и т.д. Задача программистов — детализация и реализация. И стоимость ошибки архитектора и разработчика, разные на порядки. Нет ничего страшнее чем хреновый архитектор(разве что только хреновый PM). А не каждый разработчик сможет выполнять роль архитектора без дополнительного обучения.
Что касается Team Leader, то тут вопрос даже другой. Одной из задачей team leader уменьшить риски связанные с уходом того, или иного члена команды. Он должен знать что, где и как все работает. Это его прямая обязанность, ради которой он может даже пожертвовать ролью играющего тренера.
MSS>А если толковы _все_ разработчики? нужны ли вообще тогда функции архитектора и тимлида, или тут стоит почерпнуть что-то из XP?
Вот только не надо половинчатых решений. Слишком много проблем сразу получается. Возьмем даже ту что здесь проявилось. Для XP — чрезвычайно важный момент парное программирование(или хотя бы Code Review), общее обсуждение проекта и закладка на неправильные и недоделанные решения. Как только убираем что-то система падает с грохотом и начинается бардак вплоть до провала проектов. Собственно именно поэтому и возник вопрос, какой здесь принятый процесс.
Самое болезненное (и распроспространенное) это когда вообще не принят ни один процесс разработки. Сколь толковыми разработчики не были, если нет ни одного человека который владел бы всей информации о проекте, риски проекта повышаются.
