Здравствуйте, AntoxaM, Вы писали:
AM>Здравствуйте, dkon, Вы писали:
D>>в проекте из трех человек достаточно личного общения, документация будет только лишней обузой.
AM>А как проект поддерживать без документации? AM>А если в будующем проект будет расширяться? AM>Или кто-то решит уйти из проекта?
исходники -- самая что ни на есть правильная, понятная, полностью соответствующая текущему положению, документация.
поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.
Здравствуйте, slskor, Вы писали:
S>Здравствуйте, sergei74ap, Вы писали:
S>>1-й программист делает пользовательский интерфейс на Delphi. S>>2-й — пишет ядро системы (разнообразные вычисления, всякие навороченные алгоритмы, работа с БД) на C++ Builder'е. Ядро представляет собой набор DLL-библиотек, экспортирующих кучу функций (возможно, впоследствии все это будет переделано на COM-серверы). S>>3-й — пишет на MSVC++ набор DLL-библиотек, управляющих разнообразными железяками.
S> На кой вам каша из такого количества разнокалиберных технологий? Типа, каждый пишет на чем умеет? S>Сдается мне, это будет не самый простой, надежный и гибкий проект.
особенно тяжело придется третьему, управлять железом из длл-ки
S>>Вопрос: что посоветуете для ведения проектной документации — какие виды диаграмм, блок-схем? На данном этапе нам не требуется автоматической генерации кода по диаграммам. Пока нужны только средства, которые позволили бы описать интерфейсы компонентов системы и протоколы взаимодействия между ними. Что-то типа диаграмм UML, но с учетом того, что система не является полностью объектно-ориентированной (некоторые ее части представляют собой просто наборы функций).
в проекте из трех человек достаточно личного общения, документация будет только лишней обузой.
Советую сперва прочитать хотя бы пару книг про управление требованиями, опробовать разные методики на практике, а уже потом столь категорично отвергать необходимость такой практики в ИТ проектах, пусть даже маленьких.
А>>Мин.необходимый документ в проектн.док-ции — "Требования".
D>кстати, проект тот загнулся после трех лет разработки (я пришел туда уже к агонии) из-за того, что требования менялись постоянно. а сказать заказчику, что он уже достал, никто не решался, потому что тот бабки платит.
Что всего лишь свидетельствует о плохо налаженном управлении требованиями и/или плохом технологическом процессе разработки, но никак не о бессмысленности самой практики управления требованиями.
Вероятно, в том проекте:
— небыло профессиональных разработчиков, которые умеют писать сложный софт (например, была толпа рядовых программистов без менеджера проекта, архитектора, тестировщиков адекватной проекту квалификации);
— заказчики проекта постоянно менялись и опять же разработчики не справились с управлением требованиями и выбором архитектуры;
— заказчик проекта вообще не хотел, чтобы проект завершился (участвовал я как-то в таком проекте ). Иногда важен сам факт наличия проекта по автоматизации, к примеру, а не его завершение. Некоторые инвесторы/акционеры могут скушать лапшу о том, что мы работаем над автоматизацией и вскоре наступит светлое будущее. Соответственно, они могут под это дело кому-нибудь из руководства зарплату повысит ;
— еще уйма разных причин, которые могли привести к неудаче.
Здравствуйте, dkon, Вы писали:
D>Здравствуйте, AntoxaM, Вы писали:
AM>>Здравствуйте, dkon, Вы писали:
D>>>в проекте из трех человек достаточно личного общения, документация будет только лишней обузой.
AM>>А как проект поддерживать без документации? AM>>А если в будующем проект будет расширяться? AM>>Или кто-то решит уйти из проекта?
D>исходники -- самая что ни на есть правильная, понятная, полностью соответствующая текущему положению, документация.
D>поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.
Помогала и не раз. Ещё мне "повезло" поучаствовать в проекте, на который не было никакой документации. Один программер налабал прогу, и через некоторое время уволился. Человек, с чьих слов её рисовали тоже ушёл. В итоге никто не знает, что и как прога должна делать. Не забываемые впечатления.
D>поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.
делюсь. Помогала. Очень. Видимо, эти 6 лет ты работал в "не очень крупных" проектах. У нас в конторе такие вещи называют "программирование на коленке".
Мин.необходимый документ в проектн.док-ции — "Требования".
Здравствуйте, dkon, Вы писали:
D>и сколько гхм... гхе.. высокооплачиваемых специалистов не смогли разобраться в "проге", написанной одним человеком? у вас людей после увольнения убивают, поэтому у них никак спросить нельзя?
Да разобраться, то разобрались. Только времени на это ушло гораздо больше чем требовалось. Вместо того чтобы почитать доку и начать пилить новый функционал, пришлось разбираться в уже написаном, писать доку и только потом продолжать.
Спросить то можно, но кто через месяц помнит, что он там раньше понаписал?
Фактически вместо зарабатывания денег занимались всякой $#@нёй.
И ирония здесь совершенно не уместна.
Здравствуйте, sergei74ap, Вы писали:
S>1-й программист делает пользовательский интерфейс на Delphi. S>2-й — пишет ядро системы (разнообразные вычисления, всякие навороченные алгоритмы, работа с БД) на C++ Builder'е. Ядро представляет собой набор DLL-библиотек, экспортирующих кучу функций (возможно, впоследствии все это будет переделано на COM-серверы). S>3-й — пишет на MSVC++ набор DLL-библиотек, управляющих разнообразными железяками.
На кой вам каша из такого количества разнокалиберных технологий? Типа, каждый пишет на чем умеет?
Сдается мне, это будет не самый простой, надежный и гибкий проект.
S>Вопрос: что посоветуете для ведения проектной документации — какие виды диаграмм, блок-схем? На данном этапе нам не требуется автоматической генерации кода по диаграммам. Пока нужны только средства, которые позволили бы описать интерфейсы компонентов системы и протоколы взаимодействия между ними. Что-то типа диаграмм UML, но с учетом того, что система не является полностью объектно-ориентированной (некоторые ее части представляют собой просто наборы функций).
Диаграммы компонент, диаграммы активности, по-большому счету на ООП не завязаны, можно их использовать. Описание протоколов взаимодействия можно через диаграммы последовательности нарисовать, плевать что у вас не объекты, либо изложить все в Word-овском документе.
S>Существует ли такой стандарт документирования, который целесообразно применять в небольшой группе программистов и на внедрение которого уйдет не слишком много сил и времени?
Мой скрымный опыт подсказывает, что лучший стандарт, это тот, который вы придумаете сами. Никто не запрещает использовать UML не совсем так как оно задумано. Например, я как-то через диаграмму состояний сайт спроектировал, и
остался очень доволен результатом.
D>сдал два проекта ведущим, третий на подходе. чтобы стать манагером, надо только сказать, что согласен. но тут появляется нечто и начинает меня жизни учить. обожаю интернет.
товарищ, горбатого могила исправит, знаешь. оценил твои посты, напоминают рассуждения наших студентов последних курсов, услугами которых мы иногда пользуемся. Как сдают проекты — не нужно мне рассказывать, в индустрии уже 15 лет и не таких, как ты, насмотрелся. Если опыта не хватает (т.к. после работы хоть в одной солидной конторе хоть на одном солидном проекте такие рассуждения как у тебя сами отпадают), открой хоть книгу, что ли. По RUP, XP, MSF. Учись, студент.
D>по-моему, ты мой пример неудавшегося из-за постоянных изменений требований проекта принял за мое неприятие спецификации требований. но это ж бред, никто не будет делать не знамо что. другое дело, что внутри небольшого проекта вполне можно обойтись личным общением, без рисования кучи диаграмм, которые потом некому будет поддерживать в живом состоянии.
Как-то я участвовал в проекте из трех человек, где каждый самостоятельно проектировал и программировал свою подсистему, а руководящий менеджер ограничился функциями трекера. После первой итерации я посмотрел, что получилось, и пришел в ужас. Срочно пришлось наколбасить кучу спецификаций, кому как и что делать, Ряд архитектурных изъянов устранить во второй итерации исправить так и не удалось, это было слишком дорого.
В общем, мне как-бы не надо говорить, нужна ли проектная документация для группы из трех человек.
А вот два человека вполне без документации обходятся. Достаточно эскизного UML-моделирования, чтобы архитектуру проработать.
Уважаемые коллеги, прошу высказаться по теме. Приветствуются любые советы и предложения.
Ситуация такова: команда из трех человек пишет набор приложений, работающих с БД, графикой, железом.
1-й программист делает пользовательский интерфейс на Delphi.
2-й — пишет ядро системы (разнообразные вычисления, всякие навороченные алгоритмы, работа с БД) на C++ Builder'е. Ядро представляет собой набор DLL-библиотек, экспортирующих кучу функций (возможно, впоследствии все это будет переделано на COM-серверы).
3-й — пишет на MSVC++ набор DLL-библиотек, управляющих разнообразными железяками.
Вопрос: что посоветуете для ведения проектной документации — какие виды диаграмм, блок-схем? На данном этапе нам не требуется автоматической генерации кода по диаграммам. Пока нужны только средства, которые позволили бы описать интерфейсы компонентов системы и протоколы взаимодействия между ними. Что-то типа диаграмм UML, но с учетом того, что система не является полностью объектно-ориентированной (некоторые ее части представляют собой просто наборы функций).
Существует ли такой стандарт документирования, который целесообразно применять в небольшой группе программистов и на внедрение которого уйдет не слишком много сил и времени?
Спасибо.
Здравствуйте, AntoxaM, Вы писали:
AM>>>А как проект поддерживать без документации? AM>>>А если в будующем проект будет расширяться? AM>>>Или кто-то решит уйти из проекта?
D>>исходники -- самая что ни на есть правильная, понятная, полностью соответствующая текущему положению, документация.
D>>поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.
AM>Помогала и не раз. Ещё мне "повезло" поучаствовать в проекте, на который не было никакой документации. Один программер налабал прогу, и через некоторое время уволился. Человек, с чьих слов её рисовали тоже ушёл. В итоге никто не знает, что и как прога должна делать. Не забываемые впечатления.
и сколько гхм... гхе.. высокооплачиваемых специалистов не смогли разобраться в "проге", написанной одним человеком? у вас людей после увольнения убивают, поэтому у них никак спросить нельзя?
Здравствуйте, Аноним, Вы писали:
D>>с такими аргументами -- в сад.
А>Открой хоть книгу какую, почитай что-ли. А то так и останешься кодером на всю жизнь.
сдал два проекта ведущим, третий на подходе. чтобы стать манагером, надо только сказать, что согласен. но тут появляется нечто и начинает меня жизни учить. обожаю интернет.
Здравствуйте, dkon, Вы писали:
D>по-моему, ты мой пример неудавшегося из-за постоянных изменений требований проекта принял за мое неприятие спецификации требований.
Точно. И, похоже, не только я.
D>но это ж бред, никто не будет делать не знамо что. другое дело, что внутри небольшого проекта вполне можно обойтись личным общением, без рисования кучи диаграмм, которые потом некому будет поддерживать в живом состоянии.
Необходимость документации существенно зависит не только от размеров проекта, но и от времени жизни разрабатываемой программы. Если год-два — то да. А если больше — то нет. Даже для самой простой программы нужно описывать, что собственно она должна делать. Иначе потом будут проблемы с ее поддержкой и развитием.
M>>Опять же в XP проект ведется не как на душу положал, а через упорядочивание User Stories и их группировку в релизы системы. Собственно, упрощенный подход к управлению требованиями. D>в изначальном постинге об управлении требованиями ничего не было.
Управление требованиями — составная часть ведения проектной документации. Соответственно, отвергая необходимость проектной документации ты отвергал необходимость управления требованиями. Ведь ты же не станешь утверждать, что можно управлять требованиями, которые нигде не записаны???
M>>Так что получается, что ты всем мозги пудришь насчет успешных проектов полностью без проектной документации (включая спецификацию функциональных требований). M>> D>я пудрю? да боже упаси
А вот такое впечатление все же складывается...
Здравствуйте, dkon, Вы писали:
D>XP обожаю. в полном объеме использовать пока не получается, к сожалению. утверждение, что исходники -- это лучшая документация, как раз из XP. а ты не знал?
Совсем недавно читал Бека. Что-то не помню там такого утверждения.
Здравствуйте, dkon, Вы писали:
D>Здравствуйте, AntoxaM, Вы писали:
D>и сколько гхм... гхе.. высокооплачиваемых специалистов не смогли разобраться в "проге", написанной одним человеком? у вас людей после увольнения убивают, поэтому у них никак спросить нельзя?
Была такая же история и прога была довольно небольшая. Уволившийся программист с удовольствием предложил свою "помощь". Порядка 200$ в час. Естественно пришлось самому разбираться..
Здравствуйте, Аноним, Вы писали:
D>>поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.
А>делюсь. Помогала. Очень. Видимо, эти 6 лет ты работал в "не очень крупных" проектах. У нас в конторе такие вещи называют "программирование на коленке".
я учавствовал в "сделанном на коленке" проекте для нефтегазовой промышленности, продаваемом за сотни килобаксов и делавшимся по науке кучей народа для недопартнера мелкомягких, спущенном в унитаз. мне, конечно, очень интересно как называют такие вещи у тебя в конторе, только что это доказывает?
А>Мин.необходимый документ в проектн.док-ции — "Требования".
кстати, проект тот загнулся после трех лет разработки (я пришел туда уже к агонии) из-за того, что требования менялись постоянно. а сказать заказчику, что он уже достал, никто не решался, потому что тот бабки платит.
Re[7]: Как вести проектную документацию?
От:
Аноним
Дата:
15.07.03 10:48
Оценка:
D>я учавствовал в "сделанном на коленке" проекте для нефтегазовой промышленности, продаваемом за сотни килобаксов и делавшимся по науке кучей народа для недопартнера мелкомягких, спущенном в унитаз. мне, конечно, очень интересно как называют такие вещи у тебя в конторе, только что это доказывает?
хм.. ты считаешь, это звучит гордо? я даже могу предположить пару контор, о которых может идти речь.. проект без документации — это несерьезно..
D>>я учавствовал в "сделанном на коленке" проекте для нефтегазовой промышленности, продаваемом за сотни килобаксов и делавшимся по науке кучей народа для недопартнера мелкомягких, спущенном в унитаз. мне, конечно, очень интересно как называют такие вещи у тебя в конторе, только что это доказывает?
А>хм.. ты считаешь, это звучит гордо?
пример личного опыта, с удовольствием выслушаю твою success story.
А>я даже могу предположить пару контор, о которых может идти речь..
давай, давай
А>проект без документации — это несерьезно..
Здравствуйте, dkon, Вы писали:
D>сдал два проекта ведущим, третий на подходе. чтобы стать манагером, надо только сказать, что согласен. но тут появляется нечто и начинает меня жизни учить. обожаю интернет.
Везению можно позавидовать
Если у тебя есть практический опыт руководства проектом, то приведи свои аргументы в пользу твоего же утверждения о невостребованности документации и, в частности, спецификации требований.
Как ты проверял, что пректы действительно сделаны?
Какие действия ты предпринимал в ситуациях, когда разные заинтересованные в проекте лица настаивают на принципиально различной реализации некоторой функциональности?
Так же прошу уточнить размеры проектов (количество строк/трудозатраты/данные по другим метрикам).
Здравствуйте, Аноним, Вы писали:
А>товарищ, горбатого могила исправит, знаешь. оценил твои посты, напоминают рассуждения наших студентов последних курсов, услугами которых мы иногда пользуемся. Как сдают проекты — не нужно мне рассказывать, в индустрии уже 15 лет и не таких, как ты, насмотрелся. Если опыта не хватает (т.к. после работы хоть в одной солидной конторе хоть на одном солидном проекте такие рассуждения как у тебя сами отпадают), открой хоть книгу, что ли. По RUP, XP, MSF. Учись, студент.
XP обожаю. в полном объеме использовать пока не получается, к сожалению. утверждение, что исходники -- это лучшая документация, как раз из XP. а ты не знал?
А>P.S. это кто из нас еще "нечто", хам.
прошу прощения, если обидел, просто реакция на твой тон и "аргументы".
Здравствуйте, dkon, Вы писали:
D>Здравствуйте, Аноним, Вы писали:
А>>товарищ, горбатого могила исправит, знаешь. оценил твои посты, напоминают рассуждения наших студентов последних курсов, услугами которых мы иногда пользуемся. Как сдают проекты — не нужно мне рассказывать, в индустрии уже 15 лет и не таких, как ты, насмотрелся. Если опыта не хватает (т.к. после работы хоть в одной солидной конторе хоть на одном солидном проекте такие рассуждения как у тебя сами отпадают), открой хоть книгу, что ли. По RUP, XP, MSF. Учись, студент.
D>XP обожаю. в полном объеме использовать пока не получается, к сожалению. утверждение, что исходники -- это лучшая документация, как раз из XP. а ты не знал?
А как же User Stories??? — спицифический подход к спецификации требований, но ведь подход же (почему-то у меня несколькими постами раньше появлось убеждение, что речь не о ламерстве, а о недопонимании концепции eXtreme Programming — рад, что угадал)!
Опять же в XP проект ведется не как на душу положал, а через упорядочивание User Stories и их группировку в релизы системы. Собственно, упрощенный подход к управлению требованиями.
Так что получается, что ты всем мозги пудришь насчет успешных проектов полностью без проектной документации (включая спецификацию функциональных требований).
Здравствуйте, mikkri, Вы писали:
M>Здравствуйте, dkon, Вы писали:
D>>Здравствуйте, Аноним, Вы писали:
А>>>товарищ, горбатого могила исправит, знаешь. оценил твои посты, напоминают рассуждения наших студентов последних курсов, услугами которых мы иногда пользуемся. Как сдают проекты — не нужно мне рассказывать, в индустрии уже 15 лет и не таких, как ты, насмотрелся. Если опыта не хватает (т.к. после работы хоть в одной солидной конторе хоть на одном солидном проекте такие рассуждения как у тебя сами отпадают), открой хоть книгу, что ли. По RUP, XP, MSF. Учись, студент.
D>>XP обожаю. в полном объеме использовать пока не получается, к сожалению. утверждение, что исходники -- это лучшая документация, как раз из XP. а ты не знал?
M>А как же User Stories??? — спицифический подход к спецификации требований, но ведь подход же (почему-то у меня несколькими постами раньше появлось убеждение, что речь не о ламерстве, а о недопонимании концепции eXtreme Programming — рад, что угадал)!
по-моему, ты мой пример неудавшегося из-за постоянных изменений требований проекта принял за мое неприятие спецификации требований. но это ж бред, никто не будет делать не знамо что. другое дело, что внутри небольшого проекта вполне можно обойтись личным общением, без рисования кучи диаграмм, которые потом некому будет поддерживать в живом состоянии.
M>Опять же в XP проект ведется не как на душу положал, а через упорядочивание User Stories и их группировку в релизы системы. Собственно, упрощенный подход к управлению требованиями.
в изначальном постинге об управлении требованиями ничего не было.
M>Так что получается, что ты всем мозги пудришь насчет успешных проектов полностью без проектной документации (включая спецификацию функциональных требований). M>
Здравствуйте, S-SH, Вы писали:
>> Совсем недавно читал Бека. Что-то не помню там такого утверждения.
SS>Пора перечитать
Даже если там это и написано. Что с того?
К мнению любого авторитета лучше по возможности относиться с долей скепсиса.
Если уж чему-то следовать, то осознанно.
Иначе сами же сторонники хорошей идеи доведут ее до абсурда.
Кстати, с XP именно это и может приключиться.
У меня сложилось такое впечатление, что горячие сторонники некой идеи больше всего ей и вредят
"bkat" <forum@rsdn.ru> сообщил/сообщила в новостях следующее: news:326360@news.rsdn.ru... > Здравствуйте, S-SH, Вы писали: > > >> Совсем недавно читал Бека. Что-то не помню там такого утверждения. > > SS>Пора перечитать > > Даже если там это и написано. Что с того? > К мнению любого авторитета лучше по возможности относиться с долей скепсиса. > Если уж чему-то следовать, то осознанно. > Иначе сами же сторонники хорошей идеи доведут ее до абсурда. > Кстати, с XP именно это и может приключиться. > У меня сложилось такое впечатление, что горячие сторонники некой идеи больше
всего ей и вредят
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, S-SH, Вы писали:
>>> Совсем недавно читал Бека. Что-то не помню там такого утверждения.
SS>>Пора перечитать
B>Даже если там это и написано. Что с того? B>К мнению любого авторитета лучше по возможности относиться с долей скепсиса. B>Если уж чему-то следовать, то осознанно. B>Иначе сами же сторонники хорошей идеи доведут ее до абсурда. B>Кстати, с XP именно это и может приключиться. B>У меня сложилось такое впечатление, что горячие сторонники некой идеи больше всего ей и вредят
Точно!
Сперва в XP действительно был такой постулат, что исходники — лучшая документация. Но после того, как XP столкнулся с проблемой масштабирования на большие коллективы/большие проекты, данный постулат замяли, начав трактовать как излишек документации лучше заменить хорошими исходниками. Т.е. собственно документация быть должна, но только в минимально необходимых для проекта размерах.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, S-SH, Вы писали:
SS>>Извините, это наезд или риторический вопрос?
B>Только не наезд! B>Извини, если возникло такое впечатление
Нет, такое не возникло. Возникло впечатление, что на смайлики не обращается внимание. А то, что меня в сторонники XP записали, ну ошибся человек, с кем не бывает. Просто книгу Бека я тоже читал, и вроде там этот постулат в самом начале обсасывается. Тоже, кстати, могу ощибиться — книги под рукой нет.
Вот вам фраза на закуску:
"Можно даже сказать, что популярность ХР стала в некотором роде проблемой, так как эта методология практически вытеснила все остальные, а вместе с ними и те ценные идеи, которые они несут."
(С) Мартин Фаулер, Новые методологии программирования
Здравствуйте, S-SH, Вы писали:
SS>Здравствуйте, bkat, Вы писали:
B>>Здравствуйте, S-SH, Вы писали:
SS>>>Извините, это наезд или риторический вопрос?
B>>Только не наезд! B>>Извини, если возникло такое впечатление
SS>Нет, такое не возникло. Возникло впечатление, что на смайлики не обращается внимание.
Да, каюсь, смайлики далеко не всегда воспринимаю как задумывал автор...
Ну это уже в чистом виде потеря информации при передачи ее через интернет
D>я учавствовал в "сделанном на коленке" проекте для нефтегазовой промышленности, продаваемом за сотни килобаксов и делавшимся по науке кучей народа для недопартнера мелкомягких, спущенном в унитаз. мне, конечно, очень интересно как называют такие вещи у тебя в конторе, только что это доказывает?
А>>Мин.необходимый документ в проектн.док-ции — "Требования".
D>кстати, проект тот загнулся после трех лет разработки (я пришел туда уже к агонии) из-за того, что требования менялись постоянно. а сказать заказчику, что он уже достал, никто не решался, потому что тот бабки платит.
1. Требования меняются всегда ...
2. Странно, что за 3 года команда не смогла выработать архитектуру и методику, адаптации к изменяющимся требованиям.
3. Требования требованиям рознь. Создавать приложения при изменяющихся бизнес-процессах -- очень сложно ...
D>сдал два проекта ведущим, третий на подходе. чтобы стать манагером, надо только сказать, что согласен. но тут появляется нечто и начинает меня жизни учить. обожаю интернет.
... только 2 проекта?? ... вот так и появляются плохие менеджеры и безнадежные проекты ))... управлять проектом, это не архитектуру проектировать и тем более не кодить ...
Вспомним, что речь как-раз и шла о мелком проекте из 3-4-х человек.
А>Открой хоть книгу какую, почитай что-ли.
В какой-то из книг Кента Бэка написано, что существуют проекты, которым документация во всей ее красе не нужна. Это не означает, что ее не ведут вообще, а только то, что ее ведут в минимальном необходимом объеме (который может вызвать шевеление волос на голове управленца из большой корпорации с поставленной бюрократией). К таким проектам, к примеру, относятся проекты с:
* малалым количеством совместно работающих интенсивно общающихся разработчиков
* низкой (нулевой) текучестью кадров
Такие проекты существуют, динамично развиваются, часто успешно сдаются.
Такие книги также существуют
А>А то так и останешься кодером на всю жизнь.
PS: Я, конечно, поддерживаю ту мысль, что чтение правильной литературы — путь к познанию, но форма выражения ...
). Иногда важен сам факт наличия проекта по автоматизации, к примеру, а не его завершение. Некоторые инвесторы/акционеры могут скушать лапшу о том, что мы работаем над автоматизацией и вскоре наступит светлое будущее. Соответственно, они могут под это дело кому-нибудь из руководства зарплату повысит 
;
— рад, что угадал)!
))... управлять проектом, это не архитектуру проектировать и тем более не кодить ...
