Исправление ilinsky, (текущая версия) :
Ну а я под «командой» понимаю всю цепочку - от разработчика до людей, которые понимают что, когда и почем нужно рынку.
Это может работать только разве что в небольших стартапах. Где разработчики и те кто им платит сидят в одной комнате (условно). Как я уже говорил, в боле менее крупных компаниях, это не работает. В таких компаниях как правило есть некое связующее звено (носитель предметной области), который приходит в отдел разработки (ИТ департамент, etc...) и озвучивает требования и то что хочет бизнес. И тут как раз должна происходить связь о которой я уже упоминал. Команда(ы) должна проанализировать, выработать необходимую для понимания бизнеса информацию (как программисты так и стоящие над ними лиды) и на понятном для всех сторон языке дать развернутый ответ по требованиям и о том как будет осуществляться реализация.
Я думаю мы поняли друг друга. Все эти вещи давно придуманы и обкатаны, но далеко не везде применяются. Об этом можно почитать как у Макконнелла в «Совершенном коде» так и в других книгах, например Эванса или Миллетта. Изобретать ничего не нужно. Все уже изобретено и работает. Вопрос в том, нужен ли бизнесу такой подход - это отдельная тема. Более того, часто случается так что в компаниях пробуют такие подходы, и они не приживаются. И это не значит что подход плох, а скорее что они делают это следуя «по буквам» что конечно не работет, ибо нужно вырабатывать свою индивидуальную концепцию, опираясь на чужой опыт.
Исправление ilinsky, :
Ну а я под «командой» понимаю всю цепочку - от разработчика до людей, которые понимают что, когда и почем нужно рынку.
Это может работать только разве что в небольших стартапах. Где разработчики и те кто им платит сидят в одной комнате (условно). Как я уже говорил, в боле менее крупных компаниях, это не работает. В таких компаниях как правило есть некое связующее звено (носитель предметной области), который приходит в отдел разработки (ИТ департамент, etc...) и озвучивает требования и то что хочет бизнес. И тут как раз должна происходить связь о которой я уже упоминал. Команда(ы) должна проанализировать, выработать необходимую для понимания бизнеса информацию (как программисты так и стоящие над ними лиды) и на понятном языке дать развернутый ответ по требованиям и о том как будет осуществляться реализация.
Я думаю мы поняли друг друга. Все эти вещи давно придуманы и обкатаны, но далеко не везде применяются. Об этом можно почитать как у Макконнелла в «Совершенном коде» так и в других книгах, например Эванса или Миллетта. Изобретать ничего не нужно. Все уже изобретено и работает. Вопрос в том, нужен ли бизнесу такой подход - это отдельная тема. Более того, часто случается так что в компаниях пробуют такие подходы, и они не приживаются. И это не значит что подход плох, а скорее что они делают это следуя «по буквам» что конечно не работет, ибо нужно вырабатывать свою индивидуальную концепцию, опираясь на чужой опыт.
Исходная версия ilinsky, :
Ну а я под «командой» понимаю всю цепочку - от разработчика до людей, которые понимают что, когда и почем нужно рынку.
Это может работать только разве что в небольших стартапах. Как я уже говорил, в боле менее крупных компаниях, это не работает. В таких компаниях как правило есть некое связующее звено (носитель предметной области), который приходит в отдел разработки (ИТ департамент, etc...) и озвучивает требования и то что хочет бизнес. И тут как раз должна происходить связь о которой я уже упоминал. Команда(ы) должна проанализировать, выработать необходимую для понимания бизнеса информацию (как программисты так и стоящие над ними лиды) и на понятном языке дать развернутый ответ по требованиям и о том как будет осуществляться реализация.
Я думаю мы поняли друг друга. Все эти вещи давно придуманы и обкатаны, но далеко не везде применяются. Об этом можно почитать как у Макконнелла в «Совершенном коде» так и в других книгах, например Эванса или Миллетта. Изобретать ничего не нужно. Все уже изобретено и работает. Вопрос в том, нужен ли бизнесу такой подход - это отдельная тема. Более того, часто случается так что в компаниях пробуют такие подходы, и они не прижываются. И это не значит что подход плох, а скорее что они делают это следуя «по буквам» что конечно не работет, ибо нужно вырабатывать свою индивидуальную концепцию, опираясь на чужой опыт.