Здравствуйте, Dirichlet, Вы писали:
D>Здравствуйте, Gaperton, Вы писали:
G>>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
D>Вот не очень понимаю, что мешает побить большой проект на несколько команд, а потом в одной/нескольких/всех использовать XP?
Ну да. Что мешает просто все взять, и поделить, что они там как дети с этим Каутским. Понимаете — в этом основная проблема и состоит, что только на бумаге можно просто все взять, и поделить. Что я могу сказать — валяйте, попробуйте. Увидите, что будет.
D>Отдельный компонент большой системы — это, фактически, отдельный проект со своим заказчиком, требованиями, дизайном, пользователями, версиями, и т.д. Его можно разрабатывать как хочется, при условии, что взаимодействие с остальными командами налажено.
Ни разу не отдельный проект, он должен тестироваться в составе крупной системы, и сильно с ней связан. Его еще надо выделить из общей кучи, этот проект, сформулировать к нему требования, и наладить межгрупповое взаимодействие. Кто это все будет делать по вашему, интересно? Бог из машины, в лице всезнающего архитектора или менеджера? Само собой это должно произойти?
Здравствуйте, b_manvelyan, Вы писали:
_> а где можно узнать побольше о таких "тестовых режимах"? правильно ли я понимаю, что при включенном таком режиме одновременно может работать и старых код (до рефакторинга) некой подсистемы и новый код (полученный после рефакторинга). Можно об этом рассказать подробнее?
Это не является стандартной техникой, это часть креативного подхода к тестированию. В данном случае речь идет о regression tests (тесты, доказывающие что вы ничего в старой системе не изменили), которые делаются достаточно халявным образом — старый код не вырезается, а ставится под флаг компиляции, таким образом, что в тестовом режиме работает одновременно старый и новый код, сравнивается их вывод, и любое несовпадение пишется в лог. Так мы, например, делали в CQG, проверяя корректность построения временных рядов новой версии. Удобно — вы пользуетесь системой, а она сама пишет в лог о вероятных ошибках.
Также в тестовом режиме можно проверять инварианты и также писать об их невыполнении в лог. Мы так тоже делали. Удобно — стоит сервер месяцами, обрабатывает себе тихонько котировки, а ты раз в неделю ищешь баги в файле errors.log
Плюсы тестовых режимов — вам не нужно делать окружения для тестов — роль окружения играет сама ваша система. И делает она это великолепно.
Вообще — тестовые режимы делать не обязательно. Regression test можно организовать и исключительно сверкой логов. Скажем, вы логгируете промежуточные результаты в набор файлов с системы до модификаций. Получаете что-то вроде трейса выполнения программы. После чего — берете diff с логами новой версии, и объясняете различия (не все типы различий будут ошибками в новой версии).
Другой подход к regression-тестированию — сверка состояний. Вы пишете в лог состояние системы в контрольных точках, для старой и новой систем, и так же берете diff. Там мы, например, отлаживали модель процессора MIPS — сравнивали состояние памяти после выполнения тестовой программы, в качестве эталона брали состояние памяти обычной настольной машины.
Короче, если как следует подумать о тестировании, можно съэкономить массу времени при разаботке. Вот еще пример — как отлаживать конечные автоматы. Пишем в лог одну запись на переключение состояния. Лог имеет форму таблицы с разделителями-табуляциями. После чего даем системе поработать, подцепляем лог-файл как таблицу MS Access, и одним SQL-запросом строим из нее матрицу смежности конечного автомата, для сравнения со спецификацией. Удобно? А то . Я так сам делал.
Основной плюс всех перечисленных методов — вам эти unit-tests достаются вам как бы бесплатно, вы их автоматически из общесистемных получаете.
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов: К>1. Необходима большая вовлечённость пользователя в процесс разработки
Пользователь = человек со стороны заказчика, или так называемый Product Owner. Действительно, требуется его сильная вовлеченность в процесс разработки. Но именно благодаря этой вовлеченности нам и удается создать продукт, который больше всего подходит заказчику. К>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов)
Exigen сейчас разрабатывает технологию по продаже Agile-проектов как fixed-price. В мире нет ничего невозможного К>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее)
Точно. А в чем минус? К>4. Тестирование задейстовано в течение всего процесса разработки.
Опять же: это позволяет добиться того, что разрабатываемый апликейшн уже с самого начала – работоспособен и может начать приносить заказчику прибыли (снижать издержки/риски) уже после первого спринта. Плюс найденные быги легче пофиксать в тот момент, когда ты их посадил, а не потом, через пару месяцев, вспоминать – что же ты тут такое понаписал?
Так в чем минус? К>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными
Частые поставки дают 2 огромных плюса:
• Новый функционал у заказчика появляется не в конце разработки всего продукта (через год-два), а после каждого спринта. А так как этот новый функционал как раз тот, который наиболее нужен заказчику на данный момент, то заказчик сразу же после начала его использования начинает получать больше прибыли (снижает свои риски/уменьшает издержки)
• Заказчик сразу же видит, где функционал не соответствует его ожиданиям и где его нужно изменить. И получает измененный функционал в конце следующего спринта. Опять-же: доволен пользователь (быстрая реакция на его запросы) => доволен руковолитель пользователя => довольны мы. Плюс Scrum-team видит, что продукт, который она разрабатывает – используется в жизни (чего не хватает при разработке больших проектов по системе waterfall), что только мотивирует команду и повышает ее мораль. К>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")
100% реализация фич за итерацию – неправда. Некоторые фичи переезжают из спринта в спринт просто потому что они оказались длиннее чем сам спринт или просто мы их начали в конце спринта. В этом ничего нет страшного.
Если под 100% реализацией фич подразумевается наличие работающего билда в конце каждой итерации – то да. Это один из определяющих факторов успешности спринта. Но, почитав пункт 5 мы в реале видим, что команда не только от этого не расстраивается, но и мотивируется, видя, что ее продукт и новые фичи сразу же идут в продакшен. А intense – это больше вопрос правильных эстимейтов и отношений с заказчиком если что-то было плохо проэстимейчено.
Здравствуйте, Ананий., Вы писали:
А>Здравствуйте, Курилка, Вы писали:
К>>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов: А>По-моему агил — это формализация реального положения дел во многих проектах. Кавардак одним словом. И этому кавардаку пытаются придать великий смысл, и заставить разработчиков вкалывать еще сильнее. Ответственность размытая, оттого может получится так, что наиболее ответственные будут на себе тянуть других. По-моему эта модель хорошо подойдет для студентов. Им прикольно потуситься, и они хорошо управляемые.
Не совсем так. Посылка agile на самом деле очень проста. Иногда бывают такие проекты, в которых следование организованному циклу разработки, будь то RUP или ватерфол — сопряжено со сложностями, в силу того, что возможности по формулированию и выяснению требований сильно ограничены. То же самое имеет место быть в проектах, которые находятся на грани технологии. И те и другие, по сути своей, представляют собой в ГОСТ-овской терминологии скорее поисковые НИР, и требуют особых методов управления. А именно — трудозатраты особо не планируются — потому что мы не знаем заранее, что и как мы будем делать, вместо этого работа ведется итерациями с фиксированными заранее определенными сроками.
В таких проектах по мере продвижения вперед и наблюдения за результатом, мы получаем новые знания, которые сильно меняют ТЗ. Agile исходит из предпосылки отказа от попыток сбора требований и глубокого проектирования, заменяя это продвижением к конечному продукту через серию коротких прототипов с фиксированными датами выпуска, и постоянной корректировкой планов. То есть, agile борется с хаосом ускорением получения обратной связи, и ускорением первых коррекций. Для проектов заказной разработки с высокой неопределенностью, небольшим бюджетом и объемом работ такой подход в целом обходится дешевле, чем классика, его отрицательные стороны просто не успевают сработать. Для продуктовой разработки методом agile хорошо писать ГУЙ, у которого высокие требования к юзабилити.
Разумеется, agile имеет сильные ограничения по применимости, и не является заменой обычным методам. Я сочувствую тем организациям и менеджерам, которые применяют в своей практике ТОЛЬКО agile. Глупо строить всю методологию вокруг одного приема планирования из многих, на самом деле. Разводилово это.
Здравствуйте, dangler, Вы писали:
К>>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее) D>Точно. А в чем минус?
минус — рефакторинг стоит дороже (намного! дороже), чем детально спроектированное решение. Это неоспоримый факт! Чем ближе к релизу и чем больше "rollback", тем дороже это стоит.
К>>4. Тестирование задейстовано в течение всего процесса разработки. D>Опять же: это позволяет добиться того, что разрабатываемый апликейшн уже с самого начала – работоспособен и может начать приносить заказчику прибыли (снижать издержки/риски) уже после первого спринта. Плюс найденные быги легче пофиксать в тот момент, когда ты их посадил, а не потом, через пару месяцев, вспоминать – что же ты тут такое понаписал? D>Так в чем минус?
минусов больших не вижу, небольшой недостаток — кпд QA от тестирования намного ниже из-за траты времени на верификацию и декларирование времменых багов и связанных с побочными эффектами рефакторинга (которые известны девелоперам, и с или без участия QA будут исправленны к релизу). Но этот недостаток стоит фирме денег и бесполезного использования человеко-ресурсов (как тестировщиков, так и более ценное время разработчиков).
К>>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными D>Частые поставки дают 2 огромных плюса: D>• Новый функционал у заказчика появляется не в конце разработки всего продукта (через год-два), а после каждого спринта. А так как этот новый функционал как раз тот, который наиболее нужен заказчику на данный момент, то заказчик сразу же после начала его использования начинает получать больше прибыли (снижает свои риски/уменьшает издержки)
использование "в продукции" в сравнении с тестированием бета/спринт итерации на тест серверах на вымышленных данных совсем разные вещи и уж точно не приносят никакой прибыли, а иногда и спринт версия с кучей багов создает отрицательное впечатление и нервозность для заказчика.
D>• Заказчик сразу же видит, где функционал не соответствует его ожиданиям и где его нужно изменить. И получает измененный функционал в конце следующего спринта. Опять-же: доволен пользователь (быстрая реакция на его запросы) => доволен руковолитель пользователя => довольны мы. Плюс Scrum-team видит, что продукт, который она разрабатывает – используется в жизни (чего не хватает при разработке больших проектов по системе waterfall), что только мотивирует команду и повышает ее мораль.
Пользователь может быть недоволен, подсчитывая допольнытельные денежные затраты на изменения, подсознательно и субьективно ощущая, что не все "идет по плану".
P.S. "используется в жизни.." — не используется. Когда дело доходит до дела — к релизу, заведению в продакшн, реальным данным и юзерам, только тогда начинается реальная работа над ошибками, патчи, потная тех-поддержка и нервно курящие тестировщики. Спринты и скрам — мертвому примочка.
К>>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток") D>100% реализация фич за итерацию – неправда. Некоторые фичи переезжают из спринта в спринт просто потому что они оказались длиннее чем сам спринт или просто мы их начали в конце спринта. В этом ничего нет страшного.
Даже осознавая что не все фичи можно "распихать по коробкам" — спринтам, и часть переходит в следущий, это все равно откладывает негативный отпечаток на чуствительных разработчиков
D>Если под 100% реализацией фич подразумевается наличие работающего билда в конце каждой итерации – то да. Это один из определяющих факторов успешности спринта. Но, почитав пункт 5 мы в реале видим, что команда не только от этого не расстраивается, но и мотивируется, видя, что ее продукт и новые фичи сразу же идут в продакшен. А intense – это больше вопрос правильных эстимейтов и отношений с заказчиком если что-то было плохо проэстимейчено.
За годы участия в разработке и внедрении, не при какой технологи НЕ ВИДЕЛ, ЧТОБЫ итерации (не говоря даже о сырых бета версиях), а при агиле еще и потенциально подверженных рефакторингу, ШЛИ СРАЗУ В ПРОДАКШН!!!
Вот, примерно так звучит отзыв об agile опытного инженера, который делал коробочный продукт, а не только наколенные поделки для внутреннего использования и сайты на PHP, и вообще нюхал пороху в командной разработке. Сразу видно по суждениям. Правильно. Не дадим заscrew-upить разработку разными там fuck-up meetingами!
SD>минус — рефакторинг стоит дороже (намного! дороже), чем детально спроектированное решение. Это неоспоримый факт! Чем ближе к релизу и чем больше "rollback", тем дороже это стоит.
Согласен про рефакторинги. Тут как раз идет сравнение времени, которое тратиться на разработку детального SRS а потом архитектуры со временем, которое мы может потратим (а может и нет) на последующие рефакторинги. Причем TDD во многом удешевит стоимость рефакторингов и последующего перетестирования.
SD>минусов больших не вижу, небольшой недостаток — кпд QA от тестирования намного ниже из-за траты времени на верификацию и декларирование времменых багов и связанных с побочными эффектами рефакторинга (которые известны девелоперам, и с или без участия QA будут исправленны к релизу). Но этот недостаток стоит фирме денег и бесполезного использования человеко-ресурсов (как тестировщиков, так и более ценное время разработчиков).
Это что за баги такие, которые «известны девелоперам», но еще не пофиксаны?
Фикс багов, как я писал выше, идет быстрее за счет быстрого реагирования. Плюс тесное общение людей внутри команды позволяет фиксать багги не регистрируя их в баг-треккинг системе, что еще больше снижает время их фикса.
SD>использование "в продукции" в сравнении с тестированием бета/спринт итерации на тест серверах на вымышленных данных совсем разные вещи и уж точно не приносят никакой прибыли, а иногда и спринт версия с кучей багов создает отрицательное впечатление и нервозность для заказчика.
Все зависит от уровня команды по умению эстимейтить и от умения скрам-мастера объяснить заказчику откуда баги и что с ними будет сделано в ближайшее время . А если команда умеет правильно эстимейтить – то билды после каждой итерации выглядят очень симпатично, и заказчик от этого только становится более счастливым. Это я говорю исключительно на примере моего текущего проекта: у нас бежит уже 12ый спринт, и команда вышла на такой уровень, что без всякого аврала в конце спринта мы показываем заказчику полностью работающую ф-ть, которую мы и планировали в начале спринта. Очень приятно.
SD>Пользователь может быть недоволен, подсчитывая допольнытельные денежные затраты на изменения, подсознательно и субьективно ощущая, что не все "идет по плану". SD>P.S. "используется в жизни.." — не используется. Когда дело доходит до дела — к релизу, заведению в продакшн, реальным данным и юзерам, только тогда начинается реальная работа над ошибками, патчи, потная тех-поддержка и нервно курящие тестировщики. Спринты и скрам — мертвому примочка.
Вид оплаты Time & Material всегда для заказчиков был менее интересен, чем Fixed Price. Поэтому наша компания сейчас разрабатывает подход, при котором мы сможем продавать Scrum-разработку за Fixed Price.
А по второму пункту – вот у нас сейчас пойдет в продакшен функциональность, которая была разработана за последние 4 спринта (2 месяца). Причем с этой функциональностью знаком уже и конечные пользователи за счет того, что мы ее им презентовали уже 3 раза (в конце каждого спринта). И не ожидается никакого «потная тех-поддержка и нервно курящие тестировщики».
Все зависит от того насколько правильно поставлен процесс
SD>Даже осознавая что не все фичи можно "распихать по коробкам" — спринтам, и часть переходит в следущий, это все равно откладывает негативный отпечаток на чуствительных разработчиков
Такого фид-бека не получал ни от одного из участников своих скрам-проектов… Может у меня просто не было чувствительных разработчиков?
SD>За годы участия в разработке и внедрении, не при какой технологи НЕ ВИДЕЛ, ЧТОБЫ итерации (не говоря даже о сырых бета версиях), а при агиле еще и потенциально подверженных рефакторингу, ШЛИ СРАЗУ В ПРОДАКШН!!!
Да, после каждого спринта в продакшен выходят очень редкие продукты (в конце спринта должен быть “Potentially shippable” билд, а вовсе необязательно продакшен), но все-равно продакшен случается намного чаще, чем при Waterfall и других моделях/методологиях разработки.
SD>минус — рефакторинг стоит дороже (намного! дороже), чем детально спроектированное решение. Это неоспоримый факт! Чем ближе к релизу и чем больше "rollback", тем дороже это стоит.
В теории мега-верно. Не придерёшься. В теории.
На практике фиксация проекта — риск. Дорогой риск.
Рефакторинги дороже, только когда применяются излишне плотно. Иначе — выигрыш из-за отсутствия тяжеловесных перестраховочных конструкций (если Вы фиксируете проект, его утяжеление — это чисто инстинктивный способ разработчика предупредить возможный риск изменений).
Здравствуйте, dangler, Вы писали:
D>Согласен про рефакторинги. Тут как раз идет сравнение времени, которое тратиться на разработку детального SRS а потом архитектуры со временем, которое мы может потратим (а может и нет) на последующие рефакторинги. Причем TDD во многом удешевит стоимость рефакторингов и последующего перетестирования.
Возможно, ..но в классике юниттесты никто не запрещает.
D>Это что за баги такие, которые «известны девелоперам», но еще не пофиксаны?
не буду углубляться в детали различных недоделок которые имеют место в незаконнченном продукте. Коротко пример: Новый функционал затрагивает рефакторинг старого кода, в котором временно ставятся "заглушки" (известные девелоперам ). Тут заканчивается спринт и тестировщики начинают писать баг репорты если заглушка оказыватся в поле их тестов по данному спринту. Что тут удивительного?
D>Все зависит от уровня команды по умению эстимейтить и от умения скрам-мастера объяснить заказчику откуда баги и что с ними будет сделано в ближайшее время . А если команда умеет правильно эстимейтить – то билды после каждой итерации выглядят очень симпатично, и заказчик от этого только становится более счастливым. Это я говорю исключительно на примере моего текущего проекта: у нас бежит уже 12ый спринт, и команда вышла на такой уровень, что без всякого аврала в конце спринта мы показываем заказчику полностью работающую ф-ть, которую мы и планировали в начале спринта. Очень приятно.
Похоже что у вас сферическая команда в вакууме
D>А по второму пункту – вот у нас сейчас пойдет в продакшен функциональность, которая была разработана за последние 4 спринта (2 месяца). Причем с этой функциональностью знаком уже и конечные пользователи за счет того, что мы ее им презентовали уже 3 раза (в конце каждого спринта). И не ожидается никакого «потная тех-поддержка и нервно курящие тестировщики».
D>Все зависит от того насколько правильно поставлен процесс
D>Да, после каждого спринта в продакшен выходят очень редкие продукты (в конце спринта должен быть “Potentially shippable” билд, а вовсе необязательно продакшен), но все-равно продакшен случается намного чаще, чем при Waterfall и других моделях/методологиях разработки.
Повторяю — показать из далека или отдать на реальное пользование — разные вещи.
И вообще, наверное мы говорим о разных вещах. Я о коробочном продукте для больших контор, которые физически не могут (и если и могут то им там по правилам не положено) делать апдейты в продакшн чаще чем раз в полгода, а после оффициального релиза продукт еще и тестируется в течении пары месяцев самыми консервативными заказчиками.
Здравствуйте, mr_kern, Вы писали: _>Здравствуйте, Курилка, Вы писали:
[skipped]
К>>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток") _>и тут тоже ощутимо...
Поясните плз этот пункт...Что-то не понял в чём тут проблема(что сложно)? Нельзя разве запланировать фичу на 2 итерации и интегрировать в проект уже ближе к концу второй итерации?
А "неукоснительность итераций" — стоит понимать как "надо постоянно работать"?
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
Основной недостаток в том, что фокусируемся на "что сделать", а не "как сделать". Идет планирование и анализ отт "user story", т.е. некой неформализованной сущьности. Как результат получается делитанское планирование, где главное сделать "что хочет заказчик" без должного внимания техническим деталям, которых заказчик даже и не знает. Понятно, что заказчик-пользователь внятно не может понять и представить "начинку" сложно системы. Все ограничивается "рожей": диалоги, орнаменты и пр.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, Курилка, Вы писали:
S>Основной недостаток в том, что фокусируемся на "что сделать", а не "как сделать". Идет планирование и анализ отт "user story", т.е. некой неформализованной сущьности. Как результат получается делитанское планирование, где главное сделать "что хочет заказчик" без должного внимания техническим деталям, которых заказчик даже и не знает. Понятно, что заказчик-пользователь внятно не может понять и представить "начинку" сложно системы. Все ограничивается "рожей": диалоги, орнаменты и пр.
S>>Основной недостаток в том, что фокусируемся на "что сделать", а не "как сделать". Идет планирование и анализ отт "user story", т.е. некой неформализованной сущьности. Как результат получается делитанское планирование, где главное сделать "что хочет заказчик" без должного внимания техническим деталям, которых заказчик даже и не знает. Понятно, что заказчик-пользователь внятно не может понять и представить "начинку" сложно системы. Все ограничивается "рожей": диалоги, орнаменты и пр.
G>Все правильно. Обратите внимание, что FDD лишен этого недостатка. Там — нет планирования от user story. G>http://en.wikipedia.org/wiki/Feature_Driven_Development#Develop_Overall_Model
Вот в общем и разобрались .
Подход новых процессов — не от кодирования и делания программы, а от управления требованиями и рисками.
Старые методологии (в том числе и MSF) конечно тоже решают эти вопросы, но не ставят их во главу угла. Для них главное — код. План по валу.
Вы считаете недостатком то, что апологеты новых процессов считают их основным достоинством.
При этом технические вопросы на самом деле никуда не исчезают и не задвигаются. Просто перестают быть приоритетом отчасти потому, что они являются более низкоуровневыми что ли относительно всего процесса и просто подразумеваются, не теряя при этом своей фактической значимости.
В этом отношении FDD — имхо просто кадавр какой-то
VGn>При этом технические вопросы на самом деле никуда не исчезают и не задвигаются. Просто перестают быть приоритетом отчасти потому, что они являются более низкоуровневыми что ли относительно всего процесса и просто подразумеваются, не теряя при этом своей фактической значимости.
Если что-то перестает быть приоритетом, то это и значит, что это задвигается. По крайней мере, я так это понимаю =)
Вообще, мне кажется, что многое зависит от области приложения усилий — одно дело, штамповать N-й по счету веб-сайт, когда действительно надо собрать требования и просто перенести их в готовый фреймворк, и совсем другое дело, когда пишется коробочный продукт, где надо приложить массу усилий, чтобы обогнать конкурентов и технические вопросы играют большую роль.
S>Основной недостаток в том, что фокусируемся на "что сделать", а не "как сделать". Идет планирование и анализ отт "user story", т.е. некой неформализованной сущьности. Как результат получается делитанское планирование, где главное сделать "что хочет заказчик" без должного внимания техническим деталям, которых заказчик даже и не знает.
Это ваше решение. Хотите — делаете "на тяп-ляп", лишь бы заказчику понравилось.
А можно делать по-человечески, оставаясь в рамках agile. Да и черт с ними, с этими рамками, в конце концов!
К примеру, у нас в итерации вполне могут встречаться такие задачи как "спроектировать нечто" или "исследовать возможность применения нечта" или "попробовать на маленьком кусочке применить нечто в объеме достаточном для того, чтобы можно было на следующей итерации оценить трудоемкость применения этого нечта в полный рост".
Ну и попробуй докажи мне, что это не agile Не будьте догматиками!
COF>Если что-то перестает быть приоритетом, то это и значит, что это задвигается. По крайней мере, я так это понимаю =)
Прочти ещё раз. Каким боком сущности на разных уровнях можно рассматривать конкурентно?
COF>Вообще, мне кажется, что многое зависит от области приложения усилий — одно дело, штамповать N-й по счету веб-сайт, когда действительно надо собрать требования и просто перенести их в готовый фреймворк, и совсем другое дело, когда пишется коробочный продукт, где надо приложить массу усилий, чтобы обогнать конкурентов и технические вопросы играют большую роль.
Ты меня не понял. Технические вопросы всегда играют роль. Только заказчик почти никогда не покупает технические вопросы и конкуренты редко конкурируют именно по техническим вопросам.
Здравствуйте, Gaperton, Вы писали:
G>А вообще — блин, какие ссылки — всегда есть требования, дизайн, кодирование, отладка. Однажды я спросил одного из директора R&D CQG, только что заступившего в должность, какой цикл разработки он собирается применять и вообще — какую методологию? Может быть, RUP? Или, все-таки, XP? Ян МакФэйден, который перед этим возглавлял отдел разработки крупнейшего американского банка (Wells Fargo, кажется), засмеялся, и сказал что-то вроде этого: I don't really care. It's always something like requirements, design, coding, and testing.
Right
G>Далее — в течени полугода Ян МакФэйден быстро, четко, без истерик и лишних движений, комплексом мер эффективно решил проблемы с качеством клиента CQG — проблема тогда была, что темп появления дефектов превышал темп их исправления, и никто не знал, что делать.
Выделенное глубоко верно, но это и так все знают.
Более интересно, какими именно мерами он "эффективно решил проблемы с качеством клиента CQG" ?
Кстати, я за этим чудо продуктом трейдил еще 9 лет назад и до сих пор этот ужас не забыл.
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Понимаете — в этом основная проблема и состоит, что только на бумаге можно просто все взять, и поделить. Что я могу сказать — валяйте, попробуйте. Увидите, что будет.
