Здравствуйте, mikkri, Вы писали:
M>Здравствуйте, dkon, Вы писали:
D>>Здравствуйте, Аноним, Вы писали:
А>>>товарищ, горбатого могила исправит, знаешь. оценил твои посты, напоминают рассуждения наших студентов последних курсов, услугами которых мы иногда пользуемся. Как сдают проекты — не нужно мне рассказывать, в индустрии уже 15 лет и не таких, как ты, насмотрелся. Если опыта не хватает (т.к. после работы хоть в одной солидной конторе хоть на одном солидном проекте такие рассуждения как у тебя сами отпадают), открой хоть книгу, что ли. По RUP, XP, MSF. Учись, студент.
D>>XP обожаю. в полном объеме использовать пока не получается, к сожалению. утверждение, что исходники -- это лучшая документация, как раз из XP. а ты не знал?
M>А как же User Stories??? — спицифический подход к спецификации требований, но ведь подход же (почему-то у меня несколькими постами раньше появлось убеждение, что речь не о ламерстве, а о недопонимании концепции eXtreme Programming — рад, что угадал)!
по-моему, ты мой пример неудавшегося из-за постоянных изменений требований проекта принял за мое неприятие спецификации требований. но это ж бред, никто не будет делать не знамо что. другое дело, что внутри небольшого проекта вполне можно обойтись личным общением, без рисования кучи диаграмм, которые потом некому будет поддерживать в живом состоянии.
M>Опять же в XP проект ведется не как на душу положал, а через упорядочивание User Stories и их группировку в релизы системы. Собственно, упрощенный подход к управлению требованиями.
в изначальном постинге об управлении требованиями ничего не было.
M>Так что получается, что ты всем мозги пудришь насчет успешных проектов полностью без проектной документации (включая спецификацию функциональных требований). M>
Здравствуйте, dkon, Вы писали:
D>по-моему, ты мой пример неудавшегося из-за постоянных изменений требований проекта принял за мое неприятие спецификации требований.
Точно. И, похоже, не только я.
D>но это ж бред, никто не будет делать не знамо что. другое дело, что внутри небольшого проекта вполне можно обойтись личным общением, без рисования кучи диаграмм, которые потом некому будет поддерживать в живом состоянии.
Необходимость документации существенно зависит не только от размеров проекта, но и от времени жизни разрабатываемой программы. Если год-два — то да. А если больше — то нет. Даже для самой простой программы нужно описывать, что собственно она должна делать. Иначе потом будут проблемы с ее поддержкой и развитием.
M>>Опять же в XP проект ведется не как на душу положал, а через упорядочивание User Stories и их группировку в релизы системы. Собственно, упрощенный подход к управлению требованиями. D>в изначальном постинге об управлении требованиями ничего не было.
Управление требованиями — составная часть ведения проектной документации. Соответственно, отвергая необходимость проектной документации ты отвергал необходимость управления требованиями. Ведь ты же не станешь утверждать, что можно управлять требованиями, которые нигде не записаны???
M>>Так что получается, что ты всем мозги пудришь насчет успешных проектов полностью без проектной документации (включая спецификацию функциональных требований). M>> D>я пудрю? да боже упаси
А вот такое впечатление все же складывается...
Здравствуйте, dkon, Вы писали:
D>XP обожаю. в полном объеме использовать пока не получается, к сожалению. утверждение, что исходники -- это лучшая документация, как раз из XP. а ты не знал?
Совсем недавно читал Бека. Что-то не помню там такого утверждения.
D>по-моему, ты мой пример неудавшегося из-за постоянных изменений требований проекта принял за мое неприятие спецификации требований. но это ж бред, никто не будет делать не знамо что. другое дело, что внутри небольшого проекта вполне можно обойтись личным общением, без рисования кучи диаграмм, которые потом некому будет поддерживать в живом состоянии.
Как-то я участвовал в проекте из трех человек, где каждый самостоятельно проектировал и программировал свою подсистему, а руководящий менеджер ограничился функциями трекера. После первой итерации я посмотрел, что получилось, и пришел в ужас. Срочно пришлось наколбасить кучу спецификаций, кому как и что делать, Ряд архитектурных изъянов устранить во второй итерации исправить так и не удалось, это было слишком дорого.
В общем, мне как-бы не надо говорить, нужна ли проектная документация для группы из трех человек.
А вот два человека вполне без документации обходятся. Достаточно эскизного UML-моделирования, чтобы архитектуру проработать.
Здравствуйте, 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 проекта?? ... вот так и появляются плохие менеджеры и безнадежные проекты ))... управлять проектом, это не архитектуру проектировать и тем более не кодить ...
Здравствуйте, dkon, Вы писали:
D>Здравствуйте, AntoxaM, Вы писали:
D>и сколько гхм... гхе.. высокооплачиваемых специалистов не смогли разобраться в "проге", написанной одним человеком? у вас людей после увольнения убивают, поэтому у них никак спросить нельзя?
Была такая же история и прога была довольно небольшая. Уволившийся программист с удовольствием предложил свою "помощь". Порядка 200$ в час. Естественно пришлось самому разбираться..
Вспомним, что речь как-раз и шла о мелком проекте из 3-4-х человек.
А>Открой хоть книгу какую, почитай что-ли.
В какой-то из книг Кента Бэка написано, что существуют проекты, которым документация во всей ее красе не нужна. Это не означает, что ее не ведут вообще, а только то, что ее ведут в минимальном необходимом объеме (который может вызвать шевеление волос на голове управленца из большой корпорации с поставленной бюрократией). К таким проектам, к примеру, относятся проекты с:
* малалым количеством совместно работающих интенсивно общающихся разработчиков
* низкой (нулевой) текучестью кадров
Такие проекты существуют, динамично развиваются, часто успешно сдаются.
Такие книги также существуют
А>А то так и останешься кодером на всю жизнь.
PS: Я, конечно, поддерживаю ту мысль, что чтение правильной литературы — путь к познанию, но форма выражения ...
— рад, что угадал)!
))... управлять проектом, это не архитектуру проектировать и тем более не кодить ...
