Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Gaperton, Вы писали:
G>>Это круто, но это на самом деле маленько не то — то ЕСКД (единая система конструкторской документации) и ЕСПД (программной документации). G>>А по процессам разработки надо немного другое — "порядок выполнения опытно-конструкторских работ". У меня есть военный ГОСТ РВ 15.203-2001 со штампом и в печатном виде.
AL>По приведенной ссылке надо смотреть надо ЕСС АСУ. В частности по стадиям -- ГОСТ 34.601-90. Гражданские фирмы, занимающиеся автоматизированными системами, обычно следуют этим стандартам.
Круто. Ты бы дал какой-нибудь глоссарий по этим стандартам — чтобы проще орентироваться было.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, A.Lokotkov, Вы писали:
AL>>Здравствуйте, Gaperton, Вы писали:
G>>>Это круто, но это на самом деле маленько не то — то ЕСКД (единая система конструкторской документации) и ЕСПД (программной документации). G>>>А по процессам разработки надо немного другое — "порядок выполнения опытно-конструкторских работ". У меня есть военный ГОСТ РВ 15.203-2001 со штампом и в печатном виде.
AL>>По приведенной ссылке надо смотреть надо ЕСС АСУ. В частности по стадиям -- ГОСТ 34.601-90. Гражданские фирмы, занимающиеся автоматизированными системами, обычно следуют этим стандартам.
Допускается исключить стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.
Ай-ай. Ай да ватерфор . Надо-ж — допускается выполнять отдельные этапы работ до заверения предшествующих стадий . Это ж РУП какой-то получается .
Короче говоря. Под ватерфолом общественностью понимается наличие предварительного проектирования, плюс ранняя работа нед требованиями. Т.е., как в RUP:
1) Определяемся, что мы делаем.
2) Решаем, как мы делаем.
3) Делаем первую полнофункциональную версию, доступную тестерам
4) Доводим ее до рабочего состояния.
Вопрос — чем цикл разработки RUP отличается от waterfall? Ну не тем же, что при waterfall "на фазе дизайна кодировать запрещено" — как мы выясняем, очень даже можно. Просто это в результаты этапа дизайна не войдет, как и в RUP.
Здравствуйте, Gaperton, Вы писали:
G>Ай-ай. Ай да ватерфор . Надо-ж — допускается выполнять отдельные этапы работ до заверения предшествующих стадий . Это ж РУП какой-то получается .
Глоссарий по ЕСПД. Стадии разработки -- по ГОСТ 19.102-77.
Waterfall -- это жупел, которым пугают детей... вернее, потенциальных пользователей новомодных agile-течений, никогда не работавших в "стандартном" процессе. Как видно из наших ГОСТ-ов и стандартов IEEE серии Software Engineering, которые, насколько я могу судить, и считаются воплощением водопадного процесса, они изначально предполагали и предполагают итеративность разработки, когда в конце каждой итерации появляется все более близкая к цели модель того, что хотелось сделать в начале. Проблема, я думаю, в том, что зачастую при следовании стандартам конечная цель проектирования подменяется некачественными артефактами промежуточных стадий и этапов (обычно тонны никчемной бумаги, которую кроме непосредственных авторов никто не читал). Это в первую очередь относится к большим инновационным проектам и к ситуациям, когда на стадии предварительного дизайна предпринимаются попытки построить всю систему на бумаге. С другой стороны, суровая правда жизни заключается в том, что пресловутый "ватерфол" применительно к сложным проектам (сложность размера и сложность кол-ва взаимосвязей) все-таки позволяет достичь результата. При условии, что в процессе имеются люди, которым не требуется задавать вопрос в интернете "А нет ли у кого образца ТЗ (SRS), ПЗ (SDD) ..?".
Здравствуйте, A.Lokotkov, Вы писали:
G>>Ай-ай. Ай да ватерфор . Надо-ж — допускается выполнять отдельные этапы работ до заверения предшествующих стадий . Это ж РУП какой-то получается .
AL>Глоссарий по ЕСПД. Стадии разработки -- по ГОСТ 19.102-77. AL>Waterfall -- это жупел, которым пугают детей... вернее, потенциальных пользователей новомодных agile-течений, никогда не работавших в "стандартном" процессе. Как видно из наших ГОСТ-ов и стандартов IEEE серии Software Engineering, которые, насколько я могу судить, и считаются воплощением водопадного процесса, они изначально предполагали и предполагают итеративность разработки, когда в конце каждой итерации появляется все более близкая к цели модель того, что хотелось сделать в начале.
Хорошо, что мне не одному это кажется . Я уж почти начал думать, что я с ума сошел, или всю жизнь тупой был .
AL>Проблема, я думаю, в том, что зачастую при следовании стандартам конечная цель проектирования подменяется некачественными артефактами промежуточных стадий и этапов (обычно тонны никчемной бумаги, которую кроме непосредственных авторов никто не читал). Это в первую очередь относится к большим инновационным проектам и к ситуациям, когда на стадии предварительного дизайна предпринимаются попытки построить всю систему на бумаге.
Эта проблема известна — "сдвиг акцента с разработки продукта на разработку документации". Еще демарко в пиплваре про нее писал. Ну, и многие, я думаю, наблюдали это на практике.
...
В том то и дело, что ОКР в разработке ПО отличается от обычной ОКР, тем что Вы заранее не знаете полных требований. Именно для выяснения этих требований, а также основанной на ней архитектуры и нужна итеративная разработка.
Да. Можно сначала провести кропотливую работу по выяснению, подтверждению и обоснованию требований, а потом основываясь на них начать разработку (водопад).
Но во первых, это не так эффективно, как эволюция прототипов. И больше сроки. И больше бумаги.
Во вторых, я ещё не видел проектов, где бы не было ошибок в требованиях.
В третьих, заказчик часто изменяет свои требования, имея уже частично работающий продукт (не всё можно оценить на прототипах). Особенно, когда связь между потребителем и разработчиком слишком длинна.
В четвёртых, тестирование во время разработки позволяет уменьшить общую пиковую нагрузку тестировщиков и повысить их эффективность (если это конечно не обезьянки с клавиатурами). Это касается также итеративной работы архитекторов, аналитиков и самих разработчиков.
В пятых, это уже проверено Хотя не скажу, что всё так просто. Как я уже убедился, нормальный итеративный процесс разработки требует более высокой квалификации абсолютно всех участников. Кому-то это минус
При всём при этом я допускаю, что в некоторых проектах водопад может быть применен (требования бывают разные).
Врядли в той же космической промышленности заказчик не знает, что ему надо.
Хотя и тут применяют скорее не водопад, а циклическую разработку, которая не эффективней итеративной, потому что увеличивает объём работы при том же качестве.
Заодно кину камень в огород XP, которое мне представляется не более чем играми в песочнице.
Здравствуйте, VGn, Вы писали:
VGn>... VGn>В том то и дело, что ОКР в разработке ПО отличается от обычной ОКР, тем что Вы заранее не знаете полных требований. Именно для выяснения этих требований, а также основанной на ней архитектуры и нужна итеративная разработка.
Есть два вида разработки ПО — разработка (коробочного) продукта, и разработка на заказ под нужды внешнего заказчика.
При первом виде разработки требования составляете вы, и никто другой. У вас есть все возможности выяснить требования. При втором виде разработки целесообразно провести анализ требований, заслав к заказчику аналитика. Я выполнял эту работу — при анализе бизнес-процессов на сбор информации тратится примерно 2 часа на одного исполнителя. Кроме этого, вам нужна информация об оргструктуре предприятия и заполненные реальными данными печатные формы всех документов. После чего, в течении дня-двух (примерно 20% времени от сбора данных — у нас были короткие заказы) тратится на построение модели бизнес-процессов организации и грубое предварительное проектирование — разбивку на модули.
Здесь ситуация простая — либо вы умеете собирать требования, либо нет. Если да — вам дешевле их собрать и проанализировать, иначе итерациям конца и края не будет, и ваш заказчик рискует вылететь за бюджет на автоматизацию так и не получив нужный ему результат. В этом случае вы не просто потеряете заказчика, но еще и получите негативный отзыв.
Насчет итеративной разработки — ее никто не мешает применять при так называемом "водопаде" (которого на практике не существует, но об этом позже) — вы бьете всю функицональность на модули и делаете по одному модулю с законченной функциональностью за итерацию. Это простой здравый смысл — чем чаще вы получаете деньги, тем меньше ваши финансовые риски. Для заказчика также психологически проще проводить приемку законченными работающими модулями.
VGn>Да. Можно сначала провести кропотливую работу по выяснению, подтверждению и обоснованию требований, а потом основываясь на них начать разработку (водопад).
Вам никто не мешает во время сбора требований делать прототипы системы и показывать их клиенту. "Водопад" это не запрещает. Вы можете начинать активности по разработке до завершения предыдущих стадий, если это необходимо.
VGn>Но во первых, это не так эффективно, как эволюция прототипов. И больше сроки. И больше бумаги.
Это как раз более эффективно, чем эволюция прототипов, и сроки меньше. Потому, что переделывать меньше надо. А если вы требования на бумаге не зафиксируете, и акты приемки подписывать не будете, то вас на котракте fixed cost клиенты разведут как лоха, залезете в минус, и еще с ним поругаетесь. На бумаге надо фиксировать бизнес-процессы (в виде сценариев/use case — обязательно) и архитектуру — так дешевле. Без бумаги вы в них элементарно запутаетесь, и разработчики ошибок наляпают из-за разного понимания бизнес-процессов. Более того, непонятно как вы тесты собрались разрабатывать без описания сценариев на бумаге. Из головы их будете брать? Вот и пойдут у вас проблемы на приемке, как тут не так давно описывал человек, который правильно работает по scrum. Потому что требованиями надо управлять, и выполнять их трассировку, чтобы не иметь проблем на приемке.
Что до описания архитектуры — то для бизнес-приложений при готовых сценариев, описании ролей, и наличии заполненных форм документов и отчетов (собирается при анализе) это совершенно тривиальная задача — там практически нечего проектировать, все предельно быстро и просто. Не выполнять предварительного проектирования в этом случае — глупо, оно слишком простое.
VGn>Во вторых, я ещё не видел проектов, где бы не было ошибок в требованиях.
В моих проектах не было крупных ошибок в требованиях (приводящих к коррекции архитектуры и дизайна) начиная примерно с 2000 года — только косметика и мелочь. После того, как я несколько раз крупно лажанулся с требованиями, и сделал выводы. Требования надо уметь собирать, чтобы в них ошибок не было, это умение, которому надо учиться. Можно, конечно, вместо тренировки в анализе требований, плюнуть и применять agile. Это несколько снизит вред от отсутствия управления требованиями, но проблемы останутся. И серьезные проблемы — сыграют очень больно и неожиданно.
Кроме этого — при анализе требований я могу во многих случаях позволить себе брать с клиента fixed cost, и дать ему подробную раскладку за что он конкретно платит — это для него более понятный и психологически выгодный контракт,чем оплата непонятной "работы" с "итерациями". В моем случае он платит за результат, который нагляден и понятен. Это я к тому, что при прочих равных я выиграю тендер у вас.
VGn>В третьих, заказчик часто изменяет свои требования, имея уже частично работающий продукт (не всё можно оценить на прототипах). Особенно, когда связь между потребителем и разработчиком слишком длинна.
Для этого проводят анализ бизнес-процессов — чтобы собрать реальную информацию о фактических бизнес-процессах (от исполнителей, а не со слов менеджмента, нихрена в том ни пендрящем). Имея точный анализ, вы никогда не столкнетесь с пожеланием, радикально расходящимся с вашей картиной — это просто невозможно. Для этого согласут и подписывают ТЗ, изменения к которому идут за отдельную плату. Для этого клиенту в тяжелых случаях на раннем этапе показывают прототипы гуя (хотя при задачах автоматизации при наличии проведенного анализа это делать скорее вредно, чем полезно). Для этого планируют этап "внедрение", на котором выполняются доработки по ходу эксплуатации.
VGn>В четвёртых, тестирование во время разработки позволяет уменьшить общую пиковую нагрузку тестировщиков и повысить их эффективность (если это конечно не обезьянки с клавиатурами). Это касается также итеративной работы архитекторов, аналитиков и самих разработчиков.
Тестирование во время разработки не есть изобретение agile. Прекрасно и давным давно применяется при т.н. "водопаде". Тестирование вообще-то необходимо чтобы задачу разработчику закрыть, а задачи желательно делать короткими — не более недели. Так делается в самом водопадном из водопадов — PSP/TSP.
VGn>В пятых, это уже проверено Хотя не скажу, что всё так просто. Как я уже убедился, нормальный итеративный процесс разработки требует более высокой квалификации абсолютно всех участников. Кому-то это минус
Конечно минус. У меня высокая квалификация, которая позволяет писать навернутые штуки на сложном С++. Однако, я ценю свое время, и предпочту Erlang, который позволяет мне тратить свое время более продуктивно, не думая о целой куче всякой ерунды. Так же и с процессом — я не понимаю, зачем нужен процесс разработки, требующий высокой квалификации (т.е. постоянного напряжения от инженеров для достижения адекватного результата). Это означает, что он не помогает работать, а мешает. Хороший процесс должен упрощать жизнь, снимая проблемы коммуникации, позволяя людям заниматься существенными вещами, трятя свой креатив на инженерную работу.
VGn>При всём при этом я допускаю, что в некоторых проектах водопад может быть применен (требования бывают разные). VGn>Врядли в той же космической промышленности заказчик не знает, что ему надо. VGn>Хотя и тут применяют скорее не водопад, а циклическую разработку, которая не эффективней итеративной, потому что увеличивает объём работы при том же качестве.
Все проще. Никакого waterfall-а, которым пугают людей, в природе несуществует. Сейчас сами поймете, если вдумчиво ответите на вопрос. Чем водопад отличается от RUP? Вот фазы RUP — упрощенно, по книге Murray Cantor "Project management with UML", которая лежит на столе.
1) Определяемся, что мы делаем.
2) Решаем, как мы делаем.
3) Делаем первую полнофункциональную версию, доступную тестерам
4) Доводим ее до рабочего состояния.
Вопрос — в чем отличие от ватерфол? Подумайте как следует, применима ли ваша критика к RUP? Подумайте, понимаете ли вы на самом деле разницу между RUP и этим, как его, ватерфол? Правильный ответ вас удивит — "да, ваша критика относится и к RUP тоже в полном объеме" — так как вы считаете критерием ватерфола наличие предварительной работы с требованиями и предварительного дизайна. Вот они, в критериях завершения двух первых фаз в цикле разработки RUP. Вы, очевидно, этого не хотели, потому, что RUP — "это хорошо", а ватерфол, "это плохо и страшно". Попробуйте обяснить этот казус — как так вышло, что вы жостко аргументируете в том числе и против RUP, который считаете хорошим. Я намеренно не стал приводить идиотские названия фаз RUP, которые выдуманы с целью показать, что тут якобы что-то новое есть. Нихрена нового нет в их цикле разработки на самом деле, кроме несколько более общей чем в классике формулировки критериев завершения фаз (за что им спасибо).
Ларман указывает на то, что Ройс описывал итеративный процесс, но его не поняли и упростили его модель до однопроходной. И в таком виде она попала в DOD-STD-2167, откуда разнеслась по всему миру.
It is no small irony that 2167 was then used as input to other standards, both within the United States and internationally. For example, the British JSP-188, German V-Model (also the basis of the Austrian and Swiss standards), and the French GAM-T-17 were influenced by 2167, with an emphasis on single-pass waterfall phases, and early large, signed-off specifications before construction.
Вообще если посмотреть на любые подходы, то можно выделить их ограниченность
Какой ожидается результат от разработки По?
Для вотерфольных моделей, и многих итерационных цели две: 1) создать программу 2) написать документацию
Получается вместо одного продукта делается ДВА!
В гибких методологиях, особенно SCRUM та же ерунда. Только пункт второй вычёркивается и добавляется ещё один 1) создать программу
2) (ВЫЧЕРКНУТЬ) написать документацию 3) создать самоорганизующуюся Команду
То есть тоже 2 продукта! Фактически. когда заказчик взращивает команду -- он для себя создаёт новый продукт. А Agile всего лишь помогает ему это делать.
Понятно. Первая статья про организованную разработку, судя по тексту. Это не методология. Это простое замечание, что иногда разработчики проектируют перед тем как кодировать, и то в принципе хорошо. Но иногда они ошибаются, и тогда опять проектируют. Это научно-популярная статья про то, как работает програмист. Никакая это не модель жизненного цикла. Просто симпатичная статья, для своего времени так вообще блеск.
F> wikipedia: Waterfall model F> C.Larman, Agile and Iterative Development: A Manager's Guide. (Topic: The Historical Accident of Waterfall Validity?)
F>Ларман указывает на то, что Ройс описывал итеративный процесс, но его не поняли и упростили его модель до однопроходной.
Разумеется он описал итеративный процесс. У него в там циклически чередуются каждые две соседних активности.
И в таком виде она попала в DOD-STD-2167, откуда разнеслась по всему миру.
Ага. Ранний американский военный стандат. Видимо тоже, первый.
F>
F>It is no small irony that 2167 was then used as input to other standards, both within the United States and internationally. For example, the British JSP-188, German V-Model (also the basis of the Austrian and Swiss standards), and the French GAM-T-17 were influenced by 2167, with an emphasis on single-pass waterfall phases, and early large, signed-off specifications before construction.
Ну теперь понятно, один в нормальный человек в первый раз более-менее формально описал процесс разработки, и тысяча долбоящеров-менеджеров нихрена не разобравшись подхватили это как попугаи и начали повторять (что характерно, никто по большому счету по этому стандату DOD не работал, потому что работать по нему невозможно). Потом этот bullshit с названием waterfall попал в авторитетные толстые книги, и теперь уже инженеры, видя этот страшный "жупел" в авторитетных толстых книгах, пугаются, и внимают очередным пропагандистам "новых, совсем не таких как старых" методологий.
Остается посочуствовать автору "ватерфола". Его же теперь автором этого угребища из толстых книг считают почем зря.
Здравствуйте, denis miller, Вы писали:
DM>Вообще если посмотреть на любые подходы, то можно выделить их ограниченность
DM>Какой ожидается результат от разработки По?
От разработки ПО ожидается (сюрприз) ПО, работающее именно так, как требуется, причем не просто так, а сделанное именно за те деньги и к тому сроку, которые планировались. Как вы это сделаете — по большому счету неважно. У вас то либо получается, какой бы подхо вы не применяли, либо нет.
DM>Вот так всё просто
DM>>Какой ожидается результат от разработки По? G>От разработки ПО ожидается (сюрприз) ПО, работающее именно так, как требуется, причем не просто так, а сделанное именно за те деньги и к тому сроку, которые планировались. Как вы это сделаете — по большому счету неважно. У вас то либо получается, какой бы подхо вы не применяли, либо нет. DM>>Вот так всё просто G>Ага .
Ну стандартное предположение — а если требования меняются?
Здравствуйте, denis miller, Вы писали:
DM>>>Какой ожидается результат от разработки По? G>>От разработки ПО ожидается (сюрприз) ПО, работающее именно так, как требуется, причем не просто так, а сделанное именно за те деньги и к тому сроку, которые планировались. Как вы это сделаете — по большому счету неважно. У вас то либо получается, какой бы подхо вы не применяли, либо нет. DM>>>Вот так всё просто G>>Ага .
DM>Ну стандартное предположение — а если требования меняются?
Слово "меняются" предполагает, что они как-то меняются сами по себе. Это слово предполагает, что вы над требованиями невластны. Но на самом деле они не "меняются" сами — их всегда кто-то меняет. Обыкновенно, их меняет тот, кто их составляет. И на самом деле, требованиями вы можете и должны управлять. Если они меняются сами, и живут собственной жизнью — это означает, что вы ими никак не управляете, и вам надо обратить на это внимание, и принять корректирующие мероприятия для ликвидации крня проблемы.
Если кто-то изменил требования слишком сильно и слишком поздно — вы вылетаете за бюджет и ваш проект становится убыточен, никакой процесс разработки вам не поможет. Не сделаете вы электронную таблицу из текстового процессора — никакие методы рефакторинга не помогут. Если вы разрабатываете собственный продукт, вы сами источник требований и у вас они сами меняются — у вас великолепные шансы угробить вашу компанию. Применение разных agile в данном случае не лечит причину, это неэффективное симптоматическое лечение. Которое может на деле привести к усугублению проблемы.
Gaperton,
G>Угу, обычное дело, все сравнивают все это с мистическим ватерфолом. Раньше я как-то это обычно воспринимал, как все, начиная трепетать при страшном слове ватерфол. Однако, сейчас ловлю себя на том, что на самом деле я не понимаю что такое ватерфол и ни разу за свою жизнь не видел его в работе. Я всегда верил книгам, которые про него, великий и ужасный пишут как про ад кромешный.
DM>>Ну стандартное предположение — а если требования меняются? G>Если кто-то изменил требования слишком сильно и слишком поздно — вы вылетаете за бюджет и ваш проект становится убыточен,
А что мешает быть ближе к заказчику? На пьянки ходить вместе, жить жизнью заказчика...
Не только программировать их бизнес, но знать и быть в их бизнесе?
Здравствуйте, denis miller, Вы писали:
DM>Вообще если посмотреть на любые подходы, то можно выделить их ограниченность
DM>Какой ожидается результат от разработки По?
DM>Для вотерфольных моделей, и многих итерационных цели две: DM>1) создать программу DM>2) написать документацию DM>Получается вместо одного продукта делается ДВА!
О боже. Как Вы собираетесь поддерживать проект, не имея документации? Или у SCRUM-мастеров так принято — наследил и убежал, а после меня хоть трава не расти?
DM>В гибких методологиях, особенно SCRUM та же ерунда. Только пункт второй вычёркивается и добавляется ещё один DM>1) создать программу DM>2) (ВЫЧЕРКНУТЬ) написать документацию DM>3) создать самоорганизующуюся Команду
Товарищ, я Вас не вполне понимаю. Вы предлагаете на каждый проект заново команду создавать?
Здравствуйте, Gaperton, Вы писали:
G>Вопрос — в чем отличие от ватерфол? Подумайте как следует, применима ли ваша критика к RUP? Подумайте, понимаете ли вы на самом деле разницу между RUP и этим, как его, ватерфол? Правильный ответ вас удивит — "да, ваша критика относится и к RUP тоже в полном объеме" — так как вы считаете критерием ватерфола наличие предварительной работы с требованиями и предварительного дизайна. Вот они, в критериях завершения двух первых фаз в цикле разработки RUP. Вы, очевидно, этого не хотели, потому, что RUP — "это хорошо", а ватерфол, "это плохо и страшно". Попробуйте обяснить этот казус — как так вышло, что вы жостко аргументируете в том числе и против RUP, который считаете хорошим.
In the previous section we stated that the best process for a project is the smallest process that project could afford.
<...>
We discussed a minimal implementation of RUP which we called dX . The principles and practices of dX were identified several years ago by Ward Cunningham, Kent Beck, Ron Jeffries, and a host of other developers and methodologists. They have used this process on several projects with significant success. Because of that success, they have gathered quite a following. They call the process Extreme Programming; or for short: XP .
Здравствуйте, denis miller, Вы писали:
DM>>>Ну стандартное предположение — а если требования меняются? G>>Если кто-то изменил требования слишком сильно и слишком поздно — вы вылетаете за бюджет и ваш проект становится убыточен,
DM>А что мешает быть ближе к заказчику? На пьянки ходить вместе, жить жизнью заказчика...
Вот, как говорится, что бы ни делать, лишь бы не работать.
1. Ходить на пьянки с заказчиком не лучший способ управления требованиями.
2. "Близость к заказчику" тоже вам ничего не гарантирует. "Наши студенты становятся ближе к знаниям — ведь здание общежития находится всего в 50 метраж от университетской библиотеки".
3. У заказчика своя жизнь, у вас своя. Я предпочитаю жить своей жизнью, и управлять требованиями.
DM>Не только программировать их бизнес, но знать и быть в их бизнесе?
Знание и понимание их бизнеса — слишком широко берете. Вам заказчики платят не за это. Они платят вам за то, что вы делаете ровно то, что им нужно — даже если они сами не могут это сформулировать, а не за совместные пьянки, и на за разговоры по душам. Более того, они были бы благодарны вам за то, что вы не заставляете их это формулировать. Именно поэтому вам и платят — потому что у заказчика в частности нет специалистов по составлению ТЗ и анализу требований.
Здравствуйте, Павел Кузнецов, Вы писали:
G>>Вопрос — в чем отличие от ватерфол? Подумайте как следует, применима ли ваша критика к RUP? Подумайте, понимаете ли вы на самом деле разницу между RUP и этим, как его, ватерфол? Правильный ответ вас удивит — "да, ваша критика относится и к RUP тоже в полном объеме" — так как вы считаете критерием ватерфола наличие предварительной работы с требованиями и предварительного дизайна. Вот они, в критериях завершения двух первых фаз в цикле разработки RUP. Вы, очевидно, этого не хотели, потому, что RUP — "это хорошо", а ватерфол, "это плохо и страшно". Попробуйте обяснить этот казус — как так вышло, что вы жостко аргументируете в том числе и против RUP, который считаете хорошим.
ПК>
ПК>In the previous section we stated that the best process for a project is the smallest process that project could afford.
ПК><...>
В этом с ними не согласен. Многие проекты можно довести до конца вообще не следуя никаким процессам, и даже уложиться в бюджеты. И многие именно так и работают. И ничего. И что это означает? Процесс — это не есть неотвратимое зло, которое надо минимизировать (их исходная посылка — однобокий взгляд на вещи, типичный девелоперский — разработчиков прошу не обижаться, ведь процессы разработки решают в основном не ваши проблемы, на самом деле), процесс направлен на достижение вполне конкретных целей, которые диктуются бизнесом, и к слову, могут отличаться от одной организации к другой.
Цели эти должны рассматриваться с точки зрения проектного управления, в контексте задач, стоящих перед организацией. И цели эти очень просты — как оптимальным образом организовать групповую работу, чтобы достичь нужного результата (именно требуемого, других достигать не надо!) с требуемым качеством (именно с требуемым — не меньше не больше) в условиях ограниченного бюджета и сроков.
Что они там пишут? We stated that the best process for a project is the smallest process that project could afford?
Лучший процесс для проекта такой, который позволет не просто достичь поставленных целей, о которых у них вообще ни слова, но сделать это оптимальным способом. Т.е. дешевле и эффективнее. И не только локальных целей (сдать проект любой ценой), но и долговременных стратегических, затрагивая весь жизненный цикл продукта, и не только одного продукта здесь и сейчас — а в контексте общей продуктовой стратегии компании. Я, собственно, говорю о трассировке требований, вопросах поддержки и развития интеллектуальной собственности, а также аспектах ее повторного использования, планирования, и управлении приориетами.
ПК>We discussed a minimal implementation of RUP which we called dX . The principles and practices of dX were identified several years ago by Ward Cunningham, Kent Beck, Ron Jeffries, and a host of other developers and methodologists. They have used this process on several projects with significant success. Because of that success, they have gathered quite a following. They call the process Extreme Programming; or for short: XP .
Давно слышал что хр типа укоцанный РУП, и поэтому это очень круто. Видите-ли в чем тут фокус — на самом деле этот тезис ничего не означает. Жизненный цикл, на котором основан РУП — это general problem solving process. Вы любую активность на него натянуть можете без проблем, вообще. Включая процесс заваривания чая и хождения покакать. Цикл РУП — это не искуственные правила, а закон природы, который нарушить нельзя — у вас любой процесс решения пробем является "частным случаем РУП."
. Надо-ж — допускается выполнять отдельные этапы работ до заверения предшествующих стадий 
