Аннотация:
Использование методологии Adaptive Software Development (ASD) поможет вам выполнять работу в условиях частых и срочных изменений в проекте.
"Не верьте тому, что вам втолковывали на протяжении всей жизни: форма основывается не на функциональности. Форма основывается на ошибках.
"Форма созданных человеком вещей меняется всякий раз, когда он обнаруживает в них уже существующие или потенциальные недостатки" – пишет Генри Петроски (Henry Petroski), профессор, преподающий гражданское строительство, и автор книги "The Evolution of Useful Things" ("Эволюция полезных вещей"). "Этот принцип справедлив для всех изобретений, инноваций и нововведений. Именно он заставляет работать творческую мысль изобретателей и инженеров". В том же ключе пишет и другой автор, Стюарт Брэнд (Stuart Brand). Он тоже полагает, что постулат "форма проистекает из функциональности" – не более чем иллюзия. В его книге "How Buildings Learn" ("Чему учит строительство") мы читаем: "Луи Салливан (Louis Sullivan) провозгласил, что форма следует за функциональностью, в результате чего большинство архитекторов более ста лет свято верило в то, что могут предвидеть все нюансы функционирования своих творений".
Здравствуйте, Аноним, Вы писали:
А>Использование методологии Adaptive Software Development (ASD) поможет вам выполнять работу в условиях частых и срочных изменений в проекте.
А хэдэндшолдерс — от перхоти.
Несерьёзно всё это. Ну, очередная методика, которых сотни. Как и все остальные, в одних случаях применима, а в других — нет.
Почему бы авторам подобных лекарств от всех болезней не перенять шаблон изложения, принятый в аптекарских аннотациях:
— Фармакотерапевтическая группа
— Фармакологические свойства
— Показания
— Противопоказания
— Способ применения и дозировка
— Побочные действия
Здравствуйте, Аноним, Вы писали:
А>Отстойная статья. Часто в последнее время появляются "умники" из никому не известных фирм и начинают учить других, как надо работать. ....
Сколько я читал Трёх амигос, Бека, Коуберна и других авторов/идеологов методологий-подходов — они никого не учат работать, а свои утверждения аргументируют и часто поясняют на примарах. Неблагодарное это дело "учить" целые поколения разработчиков, невежественных в плане организации производственного процесса, что они работают хуже, чем могли бы. Так почти 30 лет и "учили", что каскадный подход это плохо... Поэтому не стоит называть "умниками" тех, кто продвигает ИТ-науку вперёд пусть даже путём обобщения и некой формализации подходов, полученных эволюционным путём и известных всем. Потом организация процессов — это задача менеджеров/инженеров БП, но только когда им эта задача поставлена руководством компании, а их вознаграждение зависит от эффективности работы, качества продукта и т.п. Это же относится и к разработчикам — они заинтересованы в методологии, когда у них есть стимул. В противном случае у них возникает естественное негативное отношение к любым нововведениям, к-рые выливаются для них в изучение и применение нового за те же зарплаты
А>.. Начиная с XP и заканчивая ASD. Вот когда кто-то из уважаемой фирмы — например MS, или Adobe, или Valve с
Id Software скажет, что они использовали эту технологию в каком-то конкретном успешном проекте, я к ним прислушаюсь.
Если люди в MS, или Adobe, или Valve с Id Software начнут биться головой об стенку и говорить, что это здорово, вы поверите и тоже начнёте? Своя голова ведь тоже на что-то дана. К вашему сведению в MS и нек-рыми ее партнёрами используется методология MSF (Microsoft Solutions Framework)
А>.. А пока этого не произошло, все эти "учения" — треп на пустом месте.
Извините за резкость, но трёп на пустом месте — это ваш постинг.
Re[2]: Пора расставить все точки над "i". Без эмоций...
Здравствуйте, Voblin, Вы писали:
V>Несерьёзно всё это. Ну, очередная методика, которых сотни. Как и все остальные, в одних случаях применима, а в других — нет.
Также как и лекарства — универсальных не бывает. Кроме топора в голове и dont worry, be happy
V>Почему бы авторам подобных лекарств от всех болезней не перенять шаблон изложения, принятый в аптекарских аннотациях: ....
Просто методология в плане применения гораздо сложнее, чем лекарство из аптеки. Поэтому инструкцией к применению является документация по этой методологии или хорошая книга как, например, "eXtreme Programming Explained" для XP — там все аспекты подробно рассмотрены, включая случаи, когда использование методологии может быть осложнено или она не применима вообще. Так что никакого "гербалайфа"
А>Про линух — согласен. Но OpenSource — это же не только линух.
Еще добавлю: ИМХО OpenSource продукты активно используют закон Парето, а именно реализуют 80% функциональности на которую уходит 20% времени. Коммерческая фирма себе такого позволить не может, т.к. пользователь который денег заплатил куда как въедливей. особенно если он этим софтом деньги зарабатывает.
А с линухом и пр. все просто:
1. не нравится — не ешь.
2. так оно ж бесплатное
Отсюда и создается впечатление что OpenSource продукты быстрее, больше, круче, лучше работают и т.п.
PS: это отнюдь не умоляет достоинств OpenSource продуктов. Они безусловно рулят!
>>>>Про линух — согласен. Но OpenSource — это же не только линух. dmz>Не согласен.
DAN>>>Процитирую вас "Голословно." Примеры, пожалуйста, приведите? DAN>>>Чем крупней проект, тем лучше.
А>>Mozilla, Apache, OpenOffice, Eclipse, весь sourceforge.net dmz>JBoss тоже заслуживает внимания, учитывая его прогресс.
А>>Полноценного аналога не вижу только для SQL Server. dmz>PostgreSQL ?
Постгр даже близко не стоял рядом с SQL Server особенно по скорости выборки из базы.
И скорости транзакция.
А>>При этом практ. все OpenSource поддерживают несколько платформ — значительные доп. трудозатраты.
А>>Несколько сравнений: А>>OpenOffice vs MS Office: оба жирные глючные монстры, примерно равноценны. dmz>В первом поменьше функций — особенно заментно в OO.Calc vs Excel. В вину OO также dmz>ставится то, что он не поддерживает сложных документов Word со скриптами.
только майкрософтский офис не падает на ровном месте, спотыкаясь о свои ноги
А>>Сравните Firefox c IE: последний — просто жирный глючный монстр, при одинаковом функционале. А>>Сравните Subversion c Visual Source Safe: последний — просто жирный глючный монстр, при ничтожном функционале. dmz>Согласен.
Они одинаково показывают хтмлки Это правда. Тока JavaScript машина осла в несколько раз лудше.
А еще можно глянуть на расходы Майкрософта и увидеть презабавеую цифру... Расходы на девелопинг там минемальны
Здравствуйте, Odi$$ey, Вы писали:
OE>Здравствуйте, __SPIRIT__, Вы писали:
__S>>только майкрософтский офис не падает на ровном месте, спотыкаясь о свои ноги
OE>если dll проверки орфографии удалить
Ну не знаю... Автор думает, что он совершил революцию, а все существующие методологии оказывается "смотрят не туда".
Мне кажется, что это более-менее мыльные пузыри вокруг существующих методологий, а все, что в этой статье разумно — при небольшом количестве здравого смысла просто очевидно и уже давно существует.
Изобилие "новых" красивых терминов "взаимодействие", "общение", "развитие" просто поражает — непонятно, а что, до Джима в командах никто друг с другом не "взаимодействовал"? Никто не учился на ошибках? Никто не сопровождал проект после сдачи? Никто не собирал feedback юзеров?
Короче, может я ничего и не понимаю в этой жизни, но Америку мне не открыли... Если я не прав, то наставьте тогда заблудшего на путь истинный!
Кирилл Осенков -> "Re: Устаревшие методологии – на пенсию!" :
КО> Короче, может я ничего и не понимаю в этой жизни, но Америку мне не КО> открыли... Если я не прав, то наставьте тогда заблудшего на путь КО> истинный!
Прав, прав. Но автору тоже же кушать хочеться.
Yury Kopyl aka hrg | http://id.totem.ru | "Сегодня с нами ты не пьешь, а
завтра Родине изменишь!"
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Ну не знаю... Автор думает, что он совершил революцию, а все существующие методологии оказывается "смотрят не туда".
КО>Мне кажется, что это более-менее мыльные пузыри вокруг существующих методологий, а все, что в этой статье разумно — при небольшом количестве здравого смысла просто очевидно и уже давно существует.
КО>Изобилие "новых" красивых терминов "взаимодействие", "общение", "развитие" просто поражает — непонятно, а что, до Джима в командах никто друг с другом не "взаимодействовал"? Никто не учился на ошибках? Никто не сопровождал проект после сдачи? Никто не собирал feedback юзеров?
КО>Короче, может я ничего и не понимаю в этой жизни, но Америку мне не открыли... Если я не прав, то наставьте тогда заблудшего на путь истинный!
Автор смещает акценты на те моменты разработки ПО, которые были, так сказать в тени. Автор абсолютно прав смещая критерии, которыми руководствуются руководители проектов при организации работ.
ICQ#325162271
Re[3]: Устаревшие методологии – на пенсию!
От:
Аноним
Дата:
24.05.04 13:29
Оценка:
Здравствуйте, hrg, Вы писали:
hrg>Кирилл Осенков -> "Re: Устаревшие методологии – на пенсию!" :
КО>> Короче, может я ничего и не понимаю в этой жизни, но Америку мне не КО>> открыли... Если я не прав, то наставьте тогда заблудшего на путь КО>> истинный!
hrg>Прав, прав. Но автору тоже же кушать хочеться.
/*...*/
Отстойная статья. Часто в последнее время появляются "умники" из никому не известных фирм и начинают учить других, как надо работать. Начиная с XP и заканчивая ASD. Вот когда кто-то из уважаемой фирмы — например MS, или Adobe, или Valve с Id Software скажет, что они использовали эту технологию в каком-то конкретном успешном проекте, я к ним прислушаюсь. А пока этого не произошло, все эти "учения" — треп на пустом месте.
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Мне кажется, что это более-менее мыльные пузыри вокруг существующих методологий, а все, что в этой статье разумно — при небольшом количестве здравого смысла просто очевидно и уже давно существует.
Коенчо, очевидно и очень давно существует, но что-то никто это не применяет, не внедряет и часто не понимает, что можно от этого поиметь — это объективнее и гораздо хуже, чем такое "несчастье", как появление очередной статьи, делающей "революцию". Имеются в виду не только руководители компаний или менеджеры, а даже сами разработчики
КО>Изобилие "новых" красивых терминов "взаимодействие", "общение", "развитие" просто поражает — непонятно, а что, до Джима в командах никто друг с другом не "взаимодействовал"? Никто не учился на ошибках? Никто не сопровождал проект после сдачи? Никто не собирал feedback юзеров?
Взаимодействовали, учились, сопровождали! Но только если взять российскую ИТ-индустрию, где гораздо меньше используются методологии и управление качеством (ISO, CMM) и сравнить с индийской или американской (даже не по обороту, а по уровню рентабельности), то сразу становится ясно, где взаимодействуют больше, а главное лучше
КО>Короче, может я ничего и не понимаю в этой жизни, но Америку мне не открыли... Если я не прав, то наставьте тогда заблудшего на путь истинный!
Мне уважаемый Джим тоже ничего нового не открыл, но не согласиться я с ним не могу хотя мы и используем tailored RUP
Re[4]: Устаревшие методологии – на пенсию!
От:
Аноним
Дата:
01.09.05 04:33
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, hrg, Вы писали:
hrg>>Кирилл Осенков -> "Re: Устаревшие методологии – на пенсию!" :
КО>>> Короче, может я ничего и не понимаю в этой жизни, но Америку мне не КО>>> открыли... Если я не прав, то наставьте тогда заблудшего на путь КО>>> истинный!
hrg>>Прав, прав. Но автору тоже же кушать хочеться.
А>/*...*/
А>Вот когда кто-то из уважаемой фирмы — например MS, или Adobe, или Valve с Id Software скажет, что они использовали эту технологию в каком-то конкретном успешном проекте, я к ним прислушаюсь. А пока этого не произошло, все эти "учения" — треп на пустом месте.
А почему надо считать MS эталоном? Позволю себе крамольное утверждение: с точки зрения организации проектов у MS дела очень плохи. Доводы:
1) Ни один их проект не уложился в сроки/бюджет даже близко. Всё выходит с опозданием на годы, в сыром виде и с кучей известных уже на момент релиза багов.
2) В Open Source есть аналоги практ. любому MS продукту близкий по функциональноси/кач-ву и реализация этих проектов обошлась в тысячи (десятки тысяч?) раз дешевле и сделано было в сотни раз быстрее (человеко-часы).
У MS денег много и берут они и берут они голой силой, засаживая тысячи программистов за проект и тратя миллиарды. Считаю, что они скорее чемпионы в неэффективности и обычная фирма при таком КПД труда программистов вылетит в трубу моментально.
А>А почему надо считать MS эталоном? Позволю себе крамольное утверждение: с точки зрения организации проектов у MS дела очень плохи. Доводы: А>1) Ни один их проект не уложился в сроки/бюджет даже близко. Всё выходит с опозданием на годы, в сыром виде и с кучей известных уже на момент релиза багов.
Не правда! некоторые проекты — не уложились, некоторые вполне во время выходят. Windows 95 например вышел в 95-м году
С другой стороны MS был первопроходцем в достаточно многих вещах, а как известно планирование того что до тебя еще никто не делал сложней и менее точно.
А>2) В Open Source есть аналоги практ. любому MS продукту близкий по функциональноси/кач-ву и реализация этих проектов обошлась в тысячи (десятки тысяч?) раз дешевле и сделано было в сотни раз быстрее (человеко-часы).
Сказано сильно, но голосовно.
Вот здесь: http://www.dwheeler.com/sloc/ например приводятся следующие цифры:
RedHat 7.1
It would cost over $1 billion (a Gigabuck) to develop this Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars).
It includes over 30 million physical source lines of code (SLOC).
It would have required about 8,000 person-years of development time, as determined using the widely-used basic COCOMO model.
Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2 (which was released about one year earlier).
и дальше:
Comparitive numbers are hard to find. Gary McGraw (of Cigital) has searched public information to find Windows SLOC size. According to his sources, Windows NT 5.0 (in 2000) was 20M SLOC, Windows 2000 (in 2001) was 35M SLOC, and Windows XP (in 2002) was 40M SLOC. (This information is from his briefing Building Secure Software: How to avoid security problems the right way).
Т.е. редхат до XP не дотягивает. А если посчитать все что напихано в редхат для MS-а (компилер, офис, тулзы и т.п.) перевес думаю как бы не в 2 раза будет. А уж сложность далеко не в 2 раза как вы понимаете возрастет.
По количеству человеко-часов думаю тоже похожая будет картина.
Ну и напоследок (только пожалуйста без флейма) на ваше ИМХО у меня есть свое ИМХО:
1. качество линух продуктов ниже чем качество продуктов от того же MS
2. утверждение что линух качественней — миф, связанный с тем что количетсво пользователей линух и windows систем несопоставимо. Как только возрастет кол-во пользователей — сразу и баги посыпятся. Кстати в прошлом году в линухе было надейно больше уязвимостей чем в Windows
А>У MS денег много и берут они и берут они голой силой, засаживая тысячи программистов за проект и тратя миллиарды. Считаю, что они скорее чемпионы в неэффективности и обычная фирма при таком КПД труда программистов вылетит в трубу моментально.
Программирование это не та отрасль в которой можно взять голой силой.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[6]: Устаревшие методологии – на пенсию!
От:
Аноним
Дата:
01.09.05 08:49
Оценка:
Здравствуйте, savaDAN, Вы писали:
DAN>2. утверждение что линух качественней — миф, связанный с тем что количетсво пользователей линух и windows систем несопоставимо. Как только возрастет кол-во пользователей — сразу и баги посыпятся. Кстати в прошлом году в линухе было надейно больше уязвимостей чем в Windows
Про линух — согласен. Но OpenSource — это же не только линух.
DAN>Программирование это не та отрасль в которой можно взять голой силой.
Голословно. MS берёт.
А>Про линух — согласен. Но OpenSource — это же не только линух.
Процитирую вас "Голословно." Примеры, пожалуйста, приведите? Чем крупней проект, тем лучше.
DAN>>Программирование это не та отрасль в которой можно взять голой силой. А>Голословно. MS берёт.
Все тривиально:
1. Расходы на коммуникации растут с размером проекта
2. Сложность проекта растет с размером проекта.
3. (вывод из 1 и 2) Управление проектом усложняется с ростом размера проекта.
Т.е. чем больше размер проекта тем талантливей должны быть менеджеры, тем строже процесс.
Следовательно ни 1000 ни 10 000 ни 100 000 разработчиков не напишут Windows XP если не будет процесса, менеджеров и т.п. ЧТД.
Или что вы понимете под "голой силой"?
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, Аноним, Вы писали:
V>Несерьёзно всё это. Ну, очередная методика, которых сотни. Как и все остальные, в одних случаях применима, а в других — нет.
... V>А то гербалайф какой-то
Вы саму статью-то читали? Или какую-нибудь из его книг? Или хотя бы review к его книгам?
bloß it hudla
Re[8]: Устаревшие методологии – на пенсию!
От:
Аноним
Дата:
01.09.05 09:59
Оценка:
Здравствуйте, savaDAN, Вы писали:
А>>Про линух — согласен. Но OpenSource — это же не только линух. DAN>Процитирую вас "Голословно." Примеры, пожалуйста, приведите? Чем крупней проект, тем лучше.
Mozilla, Apache, OpenOffice, Eclipse, весь sourceforge.net
Полноценного аналога не вижу только для SQL Server.
При этом практ. все OpenSource поддерживают несколько платформ — значительные доп. трудозатраты.
Несколько сравнений:
OpenOffice vs MS Office: оба жирные глючные монстры, примерно равноценны.
Сравните Firefox c IE: последний — просто жирный глючный монстр, при одинаковом функционале.
Сравните Subversion c Visual Source Safe: последний — просто жирный глючный монстр, при ничтожном функционале.
Как вы думаете, на что угрохали больше денег/человеко-часов — на Subversion или на Visual Source Safe? Хотя это конечно не гигантские проекты.
А в чём интересно MS первопроходец? Он вообще-то всю жизнь покупает чужие разработки и людей с наработанным в других фирмах know-how (кто Win NT делал?, кто .NET-oм командует?).
>>>Про линух — согласен. Но OpenSource — это же не только линух.
Не согласен.
DAN>>Процитирую вас "Голословно." Примеры, пожалуйста, приведите? DAN>>Чем крупней проект, тем лучше.
А>Mozilla, Apache, OpenOffice, Eclipse, весь sourceforge.net
JBoss тоже заслуживает внимания, учитывая его прогресс.
А>Полноценного аналога не вижу только для SQL Server.
PostgreSQL ?
А>При этом практ. все OpenSource поддерживают несколько платформ — значительные доп. трудозатраты.
А>Несколько сравнений: А>OpenOffice vs MS Office: оба жирные глючные монстры, примерно равноценны.
В первом поменьше функций — особенно заментно в OO.Calc vs Excel. В вину OO также
ставится то, что он не поддерживает сложных документов Word со скриптами.
А>Сравните Firefox c IE: последний — просто жирный глючный монстр, при одинаковом функционале. А>Сравните Subversion c Visual Source Safe: последний — просто жирный глючный монстр, при ничтожном функционале.
Согласен.
>>> >>Про линух — согласен. Но OpenSource — это же не только линух. >> Не согласен.
K>FreeBSD ? Кроссплатформенные тулы ? Тот же OpenSSH, который
Ээ, в смысле не согласен с низким качеством. Нормальное качество.
K>хорошие люди на солярке пользуют. Или тот же gcc, который K>используют вообще где не лень.
Да, безусловно, вполне зрелые и хорошие продукты.
>>>> >>Про линух — согласен. Но OpenSource — это же не только линух. >>> Не согласен.
Коллеги, давайте не уходить от темы разговора: Мы пытаемся доказать утверждение что большие OpenSource системы сопоставимого размера с коммерческими продуктами (брался пример Microsoft и Adobe) разрабатываются быстрее (тобишь дешевле), и качественней.
Как я уже показал выше RedHat — этому требованию не удовлетворяет
Есть ли данные по конкретным продуктам с конкретными цифрами?
VSS это не пример т.к. проект относительно небольшой сложности.
FireFox & IE вообще по моему несравнимые приложения.
OpenOffice-у до MS Office-а еще разрабатываться и разрабатываться....
По поводу OpenBSD — есть ли метрики этой системы чтобы можно было ее сравнить с Windows XP например?
Еще раз: речь идет о продуктах большого размера. скажем от 5 млн. строк кода. На маленьких проектах я вполне допускаю что крупные компании будут проигрывать за счет ресурсов которые необходимо тратить чтобы поддерживать ее размер.
Здравствуйте, savaDAN, Вы писали:
DAN>Еще раз: речь идет о продуктах большого размера. скажем от 5 млн. строк кода. На маленьких проектах я вполне допускаю что крупные компании будут проигрывать за счет ресурсов которые необходимо тратить чтобы поддерживать ее размер.
byur wrote: > > Здравствуйте, savaDAN, Вы писали: > > DAN>Еще раз: речь идет о продуктах большого размера. скажем от 5 млн. > строк кода. На маленьких проектах я вполне допускаю что крупные компании > будут проигрывать за счет ресурсов которые необходимо тратить чтобы > поддерживать ее размер. > > Упоминали JBoss ...
Кстати, хороший пример — его можно сравнивать с достижениями
конкурентов. Единственный конкурент, о котором слышал много
хорошего в своей время (orion), разрабатывался в то время
всего двумя разработчиками, а монстры от больших контор
особо не радовали. Сейчас наверно все уже подтянулись, но
у JBoss была хорошая фора.
А>Отстойная статья. Часто в последнее время появляются "умники" из никому не известных фирм и начинают учить других, как надо работать. Начиная с XP и заканчивая ASD. Вот когда кто-то из уважаемой фирмы — например MS, или Adobe, или Valve с Id Software скажет, что они использовали эту технологию в каком-то конкретном успешном проекте, я к ним прислушаюсь. А пока этого не произошло, все эти "учения" — треп на пустом месте.
Насчет ХP это не изобретение никому неизвестных умников Intel например его юзает Да и вообще XP не так и плох.
Имхо суть статьи можно определить просто:
В совр. мире все меньше внимания уделяют анализу и проектированию (может времени нет, но скорее всего нет соотв людей). Поэтому на этапе реализации вылазит все больше проблем. Давайте построим процесс так чтобы вот это — то что повылазило не сильно влияло на разработку.
Затрудняюсь сказать правильно это или нет, но на всех проектах в которых я учавствовал в последнее время, требования изменялись на ходу.
Это правда. Тока JavaScript машина осла в несколько раз лудше.
