Большинство имеющихся методологий адаптировано на командную разработку(RUP, XP, TSP и т.д.).
Я являюсь независимым разработчиком и хотела бы упорядочить свой процесс разработки.
Большинство моих проектов — небольшие проекты на 2-3 человеко-месяца (изредка и больше). Все они не стоят на месте, а потихоньку обрастают дополнительными возможностями по требованию заказчика.
Подскажите, какая из методологий больше всего подходит в моем случае?
Здравствуйте, ZORK, Вы писали:
AVK>> Абсолютно.
ZOR>?
Что непонятно? Все методологии заточены прежде всего на повышение эффективности работы команды. В случае работы в одиночку все эти навороты просто не имеют смысла
Здравствуйте, AndrewVK, Вы писали:
AVK>Что непонятно? Все методологии заточены прежде всего на повышение эффективности работы команды. В случае работы в одиночку все эти навороты просто не имеют смысла
Там не только про эффективность команды, но и про эффективность ведения проекта. И то что касается именно эфективности ведения проекта пременимо к работе в одиночку. При чем даже из RUP можно кое что почерпнуть, но при этом прада возникает гора дополнительной работы, и в одиночку проект становится вести не реально .
Но вот из XP точно можно взять тестирование и refactoring, и это сильно помогает, если даже ты один на проекте.
AVK>Что непонятно? Все методологии заточены прежде всего на повышение эффективности работы команды. В случае работы в одиночку все эти навороты просто не имеют смысла
Я прочитала занятную статеечку http://www.interface.ru/fset.asp?Url=/rational/f_process.htm "Разработка программного обеспечения группой в составе одного человека" где описано, как RUP можно применить для одного человека. Никто и не говорил, что нужно брать определенную методику и тупо ей следовать один к одному. Вопрос был в том, какую из методик эффективнее всего заточить для разработки в одиночку.
Но то, что какая-либо методология нужна(хотя бы своя собственная), у меня сомнений не вызывает.
Здравствуйте, Nata1111, Вы писали:
N>...как RUP можно применить для одного человека.
Насколько я понял, там не только про RUP — в списке литературы, в конце статьи, первым идет Extreme Programming Explained . И, увы, в этой статье ней нет ничего про тестирование, refactoring, bugtracking и т.д.. Там только про то как записывать и сортировать свои мысли.
Здравствуйте, ZORK, Вы писали:
ZOR>Насколько я понял, там не только про RUP — в списке литературы, в конце статьи, первым идет Extreme Programming Explained . И, увы, в этой статье ней нет ничего про тестирование, refactoring, bugtracking и т.д.. Там только про то как записывать и сортировать свои мысли.
Вот поэтому вопрос и возник. Попробую для начала поверхностно с XP ознакомится. Мне лично идея рефакторинга очень нравится.
А что там еще помимо pair programming можно исключить? Ведь наверняка куча избыточной документации.
Знаю я этот сайтик. Там если все читать, никакой жизни не хватит
ON>там должно быть о Personal Software Process и вообще много вкусного для менеджеров
О PSP я немного почитала. Вряд ли я смогу точно выполнить его базовый принцип — четкое планирование работы по времени. Никогда не могу точно вычислить, сколько времени займет та или иная работа.
Здравствуйте, Nata1111, Вы писали:
N>Большинство имеющихся методологий адаптировано на командную разработку(RUP, XP, TSP и т.д.). N>Я являюсь независимым разработчиком и хотела бы упорядочить свой процесс разработки.
N>Большинство моих проектов — небольшие проекты на 2-3 человеко-месяца (изредка и больше). Все они не стоят на месте, а потихоньку обрастают дополнительными возможностями по требованию заказчика.
Мне кажется, что нужно просто упорядочить ммм... артефакты в терминологии RUP. Ну то есть — документы с постановками, исходники, сообщения об ошибках и расширениях и пр.
N>Подскажите, какая из методологий больше всего подходит в моем случае?
Та, которая тебе больше всего нравится. Всё равно впоследствии ты её перезаточишь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, ZORK, Вы писали:
ZOR>RUP точно не подходит. А XP то что надо, но при это важно пропустить pair programming, чтоб не пришлось с собой разговаривать
Согласен, к тоому же Nata1111, вы в жизни все эти вещи не один раз делали, просто не "задавались" вопросами "А какая это метода ?".
Поэтому удобный для вам способ будет наверное "компиляцией" из XP и ваших соображений.
Здравствуйте, blandger, Вы писали:
B>Согласен, к тоому же Nata1111, вы в жизни все эти вещи не один раз делали, просто не "задавались" вопросами "А какая это метода ?".
Конечно не задавалась. Ведь главное в разработке — результат. Изучение методологий началось после того, когда я обнаружила, что мне очень часто приходится переделывать уже написанный код. Вот теперь ищу причины. Пока нашла одну причину в виде: "Писать Пробные решения для уменьшения риска". Я частенько делала исследования прямо в проекте. Прдолжаю изыскания
B>Поэтому удобный для вам способ будет наверное "компиляцией" из XP и ваших соображений.
Наверное так и будет, я уже наметила, чего мне не достает. Только пока мучают сомнения, а действительно ли нужны Test Cases для каждого класса. Мне кажется, что их написание съедает уйму времени.
Здравствуйте, Nata1111, Вы писали:
N> Мне кажется, что их написание съедает уйму времени.
Используя готовые решения, типа, JUnit, написание теста занимает не больше чем написание просто дополбнительного кода необходимого для дебага, и более того при написании некоторых классов, код теста можно рассматривать как постановку задачи, то есть время экономится на бумажной работе. Вообщем, вроде как должен быть суммарный выигрышь а не проигрышь.
Что касается общего тестирования проекта — автоматического совместного запуска тестирования всего проекта, то тут действительно съедается ресурс, но это можно отложить, как мне кажетмя, до первого релиза проекта.
Здравствуйте, Nata1111, Вы писали:
N>Конечно не задавалась. Ведь главное в разработке — результат.
Конечно!
N>Изучение методологий началось после того, когда я обнаружила, что мне очень часто приходится переделывать уже написанный код.
Хорошо реализованный рефакторинг — очень полезная вешь.
Вот чего мне не хватает например в VS2003, и других средах — так это такого же качества рефакторинга, как в IDEA IntelliJ (java). Там это сделано очень удобно и по работе время от времени приходиться успешно им пользоваться.
N>Вот теперь ищу причины. Пока нашла одну причину в виде: "Писать Пробные решения для уменьшения риска". Я частенько делала исследования прямо в проекте.
Вот и пример, вы уже это делали без XP.
N>Только пока мучают сомнения, а действительно ли нужны Test Cases для каждого класса. Мне кажется, что их написание съедает уйму времени.
Ищите "середину" для себя. Писать тесты стоит писать для "критичных" классов/компонент, если не хочется писать сразу "для всего".
Например, "воткнулись" раз на то, что надо проверить корректность работы класса/компонента — постарайтесь написать test-case, обычно бывает так, что он пригодиться еще не раз, т.к. если уже раз столкнулись, то потом скорее всего еще раз понадобиться "проверка", вот тут готовый tesе-case и пригодиться.
Потом "по опыту" — писать test-case-ы "проще" писать для "низкоуровневых" компонент, т.к. чем "крупнее" проверяемая сущьность, тем больше логики она содержит, тем больше "тестовых данных" надо "предоставить", тем больше "всяких условий" соблюсти и т.д. В итоге — писать и поддерживать "полное тестрование" такого программного компонента достаточно проблематично, и получается, что "овчинка выделки не стоит".
Хотя иногда "простенький тест" для "крупного" компонента тоже полезен, просто для того, чтобы проверить, что выполнение метода/логики "не валиться с ошибкой", или оно "валиться" и хочется "более точно" найти место ошибки. Начинаем запускать тесты "отдельных компонент в цепочке", если "глазами/в логах" не совсем ясно где это происходит. А вот "корректность" обработанных данных для "крупного компонента", иногда проще "посмотреть глазами" (в результирующих — базе, документах и т.д.), т.к. "вытаскивание" тестового значения может оказаться "проблематично" внутри теста или его значение "не линейно зависимо и не постоянно" для сравнения.
Здравствуйте, ZORK, Вы писали:
ZOR>Используя готовые решения, типа, JUnit, написание теста занимает не больше чем написание просто дополбнительного кода необходимого для дебага,
To Nata111, именно про него мы и говорим. JUnit а его реализаций под разные языки/платформы — множество, всегда можно найти.
ZOR>>Используя готовые решения, типа, JUnit, написание теста занимает не больше чем написание просто дополбнительного кода необходимого для дебага,
B>To Nata111, именно про него мы и говорим. B>JUnit а его реализаций под разные языки/платформы — множество, всегда можно найти.
Так, JUnit я сейчас найду и посмотрю.
А теперь такой вопросец: Где-нибудь можно посмотреть, как эти test cases пишутся? Нужны конкретные примеры, желательно в привязке к C++.
Здравствуйте, Nata1111, Вы писали:
N>Так, JUnit я сейчас найду и посмотрю.
JUnit — это под java.
Знаю NUnit под .NET.
Под С++ не слышал, сталкиваться не приходилось.
N>А теперь такой вопросец: Где-нибудь можно посмотреть, как эти test cases пишутся? Нужны конкретные примеры, желательно в привязке к C++.
Да там же с ним и будут примеры.
В java — расширяется класс TestCase, переопределяются методы "инциализации" и "очистке ресурсов" (если надо), пишутся методы самих test-case.
Чтобы у тебя не вызывало удивления (не знаю как это будет для С++ unit-а) — но для JUnit методы "ининта и очистки" выполняются соответственно "до и после" КАЖДОГО метода test-case.
Удачи.
Сообщение опубликовано обалденной софтиной << RSDN@Home 1.1 beta 1 >>
Здравствуйте, Nata1111, Вы писали:
N>О PSP я немного почитала. Вряд ли я смогу точно выполнить его базовый принцип — четкое планирование работы по времени. Никогда не могу точно вычислить, сколько времени займет та или иная работа.
Хм, ну вообще погрешность в 10% считается очень хорошей. Для того, чтобы научиться правильно прогнозировать затраты времени, нужно просто аккуратно вести метрики (сколько фактически было потрачено на какую задачу), а потом сравнивать с заранее предсказанными результатами. После 4-6 недель такойц практики ты уже будешь достаточно хорошо оценивать время выполнения.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Хм, ну вообще погрешность в 10% считается очень хорошей. Для того, чтобы научиться правильно прогнозировать затраты времени, нужно просто аккуратно вести метрики (сколько фактически было потрачено на какую задачу), а потом сравнивать с заранее предсказанными результатами. После 4-6 недель такойц практики ты уже будешь достаточно хорошо оценивать время выполнения.
У меня точность оценки временных затрат — по Бруксу (т.е в 2-3 раза дольше А есть какой-либо софт, которым ведут эти метрики?
Здравствуйте, blandger, Вы писали:
B>Здравствуйте, Nata1111, Вы писали:
N>>Так, JUnit я сейчас найду и посмотрю. B>JUnit — это под java. B>Знаю NUnit под .NET. B>Под С++ не слышал, сталкиваться не приходилось.
Здравствуйте, Nata1111, Вы писали:
S>>Хм, ну вообще погрешность в 10% считается очень хорошей. Для того, чтобы научиться правильно прогнозировать затраты времени, нужно просто аккуратно вести метрики (сколько фактически было потрачено на какую задачу), а потом сравнивать с заранее предсказанными результатами. После 4-6 недель такойц практики ты уже будешь достаточно хорошо оценивать время выполнения.
N>У меня точность оценки временных затрат — по Бруксу (т.е в 2-3 раза дольше А есть какой-либо софт, которым ведут эти метрики?
Можно попробовать вот это.
Для одиночек видимо будет в самый раз.
Ну может еще "эксель" можно приспособить...
А вообще, лучше поставить цель начать работать в команде.
Ей богу, это куда интереснее и захватывающее
Не, не серьезно.
B>А вообще, лучше поставить цель начать работать в команде. B>Ей богу, это куда интереснее и захватывающее
У меня это пройденный этап. Сколько можно работать на дядю?
Ничего интересного и захватывающего. А последняя работа на дядю меня просто доканала: постоянные неплатежи, дерьмовый монитор, компьютер с PII, на котором VC++6 с большим проектом еле шевелится.
Здравствуйте, Nata1111, Вы писали:
B>> Ну может еще "эксель" можно приспособить...
N>Не, не серьезно.
Ты будешь удивлена, когда узнаешь, что "экселем" не гнушаются
в больших и авторитетных компаниях.
Для сбора метрик он вполне подойтет.
Метрики, если их продумать, можно вообще на листке бумаге собирать.
Нужно просто понимать что, и зачем мерять...
B>>А вообще, лучше поставить цель начать работать в команде. B>>Ей богу, это куда интереснее и захватывающее
N>У меня это пройденный этап. Сколько можно работать на дядю? N>Ничего интересного и захватывающего. А последняя работа на дядю меня просто доканала: постоянные неплатежи, дерьмовый монитор, компьютер с PII, на котором VC++6 с большим проектом еле шевелится.
Сложные и по настоящему интересные проекты все же делаются в команде.
Одиночки лишены возможности выслушивать критическое мнение.
Одиночка может только сам с собой спорить и обсуждать рещения.
Для меня лично — это самый большой минус работы в одиночку.
B>Одиночки лишены возможности выслушивать критическое мнение. B>Одиночка может только сам с собой спорить и обсуждать рещения. B>Для меня лично — это самый большой минус работы в одиночку.
А вот для этого и существуют форумы типа rsdn, ньюсы..., где прекрасно можно обсудить все что угодно. И вероятность нахождения правильного решения выше, поскольку сконцентрировано большое количество умного народа.
Здравствуйте, Nata1111, Вы писали:
B>>Одиночки лишены возможности выслушивать критическое мнение. B>>Одиночка может только сам с собой спорить и обсуждать рещения. B>>Для меня лично — это самый большой минус работы в одиночку.
N>А вот для этого и существуют форумы типа rsdn, ньюсы..., где прекрасно можно обсудить все что угодно. И вероятность нахождения правильного решения выше, поскольку сконцентрировано большое количество умного народа.
РСДН я лично очень люблю, но не все тут можно обсудить.
Тут очень хорошо можно обсудить конкретные технические вопросы
и глобальные философские проблемы (Linux vs. Windows).
Архитектуру системы, к примеру, покрытие тестами, и много еще чего,
тут видимо обсудить не получится.
Как ты, например, организуешь code review на РСДН?
Все свои исходники сюда запостишь?
Впрочем для одиночки code review видимо не имеет никакого смысла.
Свой код он всегда понятен и красив
Про себя лично я могу сказать, что мой самый ценный опыт все же связан
с работой в команде.
Здравствуйте, Nata1111, Вы писали:
N>У меня точность оценки временных затрат — по Бруксу (т.е в 2-3 раза дольше А есть какой-либо софт, которым ведут эти метрики?
Ты знаешь, для метрик на одного человека екселя более чем достаточно. Важна аккуратность. Никакого софта на эту тему не существует. Мы пытались изобрести такой софт, но проблема упирается в то, что он не может понять, что ты делаешь. Нет никакого способа отследить, какой задачей ты занимаешься в данный момент.
Потому достаточно просто каждый день заносить в ексель строчки вида "отладка того-то — 2 часа", "эксперименты над тем-то — 6 часов" и т.д.
Можно сравнивать полученные цифры ежедневной выработки с записями в аудит логе винды — когда был логин/логаут, чтобы убедиться, что все потраченные часы отражены в отчете.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Можно сравнивать полученные цифры ежедневной выработки с записями в аудит логе винды — когда был логин/логаут, чтобы убедиться, что все потраченные часы отражены в отчете.
Как мне кажется, для того чтобы лучше понять что и как, еще очень полезно с утра составлять план на день — что собираешься сделать, а вечером смотреть что получилось. Тогда в будущем легче построить обратную зависимость между: что надо сделать — что для этого надо запланировать
Здравствуйте, ZORK, Вы писали:
ZOR>Здравствуйте, Sinclair, Вы писали:
S>>Можно сравнивать полученные цифры ежедневной выработки с записями в аудит логе винды — когда был логин/логаут, чтобы убедиться, что все потраченные часы отражены в отчете.
ZOR>Как мне кажется, для того чтобы лучше понять что и как, еще очень полезно с утра составлять план на день — что собираешься сделать, а вечером смотреть что получилось. Тогда в будущем легче построить обратную зависимость между: что надо сделать — что для этого надо запланировать
ZOR>-zork
Это общий принцип.
Метрики нужны для того, чтобы сравнивать их с планом.
Только тогда можно будет научится планировать и отслеживать планы...
ZOR>Как мне кажется, для того чтобы лучше понять что и как, еще очень полезно с утра составлять план на день — что собираешься сделать, а вечером смотреть что получилось. Тогда в будущем легче построить обратную зависимость между: что надо сделать — что для этого надо запланировать
Планы составляются, хотя и недостаточно подробные. И даже более-менее выполняются.
B> Можно попробовать вот это. B> Для одиночек видимо будет в самый раз.
Поставила, действительно в самый раз. Немного глючит, но я к бесплатным программам не придираюсь. Не умеет корректно определять, над чем в настоящий момент идет работа, так что интеллектуальную помощь я отключила.
B> РСДН я лично очень люблю, но не все тут можно обсудить. B> Архитектуру системы, к примеру
Зато прекрасно обсуждаются какие-то конкретные части. Вот только что изучала обсуждение: "как хранить настройки приложения и уведомлять объекты, что настройки были изменены". Узнала несколько новых вариантов.
> Изучение методологий началось после того, когда я обнаружила, что мне очень часто приходится переделывать уже написанный код.
Методологии не объяснят вам, как надо писать код. Это больше к правильному
анализу и проектированию относится.
> Вот теперь ищу причины. Пока нашла одну причину в виде: "Писать Пробные решения для уменьшения риска". Я частенько делала исследования прямо в проекте. > Прдолжаю изыскания
Это не причина, а способ минимизации последствий неправильных решений. Еще есть
хороший способ делать прототип системы и показывать его заказчику.
> Наверное так и будет, я уже наметила, чего мне не достает. Только пока мучают сомнения, а действительно ли нужны Test Cases для каждого класса. Мне кажется, что их написание съедает уйму времени.
Стоит делать не для каждого класса, а для каждого _нового_ компонента, который
может быть и классом и совокупностью классов. Классы и компоненты, которые вы
уже отработали в предыдущих проектах, незачем перепроверять без необходимости.
"Накапливайте идиомы. Количество идиом — единственное, что отличает вас и
Шекспира!"
SS>Методологии не объяснят вам, как надо писать код. Это больше к правильному SS>анализу и проектированию относится.
Над этим я тоже работаю, но переделывать приходится не из-за неправильной архитектуры, а из-за невозможности предсказать, какое решение окажется самым эффективным. То есть очень часто бывает так: Все работает, но я случайно вижу, что в конкурирующей программе эта функциональность работает быстрее. И все, я уже не могу успокоится и начинаются поиски наиболее эффективного решения.
SS>Это не причина, а способ минимизации последствий неправильных решений.
Поскольку неправильные решения все равно неизбежны (хотя бы из-за недостатка знаний в определенных областях), то хорошо бы найти все способы минимизации их последствий. Этим и занимаюсь. Если еще знаете таковые — поделитесь!
> Над этим я тоже работаю, но переделывать приходится не из-за неправильной > архитектуры, а из-за невозможности предсказать, какое решение окажется самым > эффективным. То есть очень часто бывает так: Все работает, но я случайно вижу, > что в конкурирующей программе эта функциональность работает быстрее. И все, я > уже не могу успокоится и начинаются поиски наиболее эффективного решения.
Давно в одной книжке по алгоритмам прочитал фразу: "Никогда не думайте, что вы
придумали самый лучший алгоритм — всегда найдется кто-нибудь, кто сможет его
улучшить".
И почти всегда улучшение связано с сознательным нарушением "правильности" работы
алгоритма. Как, например, получение пути ветки из таблицы с древовидной
структурой — вполне распространенный способ и в общем случае звучит так: "Если у
вас проблема производительности при выполнении какой-то работы в вашей
программе, то разбейте эту работу на части и по возможности выполните некоторые
части работы заранее".
> SS>Это не причина, а способ минимизации последствий неправильных решений. > > Поскольку неправильные решения все равно неизбежны (хотя бы из-за недостатка
знаний в определенных областях), то хорошо бы найти все способы минимизации их
последствий. Этим и занимаюсь. Если еще знаете таковые — поделитесь!
Тут важен не конкретный способ, который не всегда может сгодиться, а общий
принцип — последствия надо заранее осознать и постараться предотвратить или хотя
бы смягчить.
Возвратившись к первоначальному вопросу: > Подскажите, какая из методологий больше всего подходит в моем случае?
Методологии в чистом виде вряд ли вам подойдут, лучше выработайте себе свою
собственную.
Для начала попробуйте воспользоваться хотя бы некоторыми из способов:
1. Не пишите сразу готовое приложение, напишите (или нарисуйте) прототип
системы, который можно показать заказчику и убедиться, что и вы и он понимаете
задачу правильно
2. На прототипе определитесь с основной архитектурой приложения
3. Ориентируйтесь на расширяемые решения, т.е. не зависящие от набора и типа
атрибутов, визуального интерфейса и т.п.
4. Накапливайте билиотеку типовых решений ("идиомы") в виде набора абстрактных
классов, интерфейсов и шаблонов кода.
5. Разделяйте ответственность по классам так, чтобы внесение изменений в один
класс не приводило к полной перестройке архитектуры.
Может быть, эти способы помогут вам поменьше переписывать код. Они будут частью
вашей личной методологии, а другие ее части вы выработаете, когда решите
расправиться с очередными узкими местами в вашей работе.
Здравствуйте, Nata1111, Вы писали:
N>Большинство имеющихся методологий адаптировано на командную разработку(RUP, XP, TSP и т.д.). N>Я являюсь независимым разработчиком и хотела бы упорядочить свой процесс разработки. N>Большинство моих проектов — небольшие проекты на 2-3 человеко-месяца (изредка и больше). Все они не стоят на месте, а потихоньку обрастают дополнительными возможностями по требованию заказчика.
N>Подскажите, какая из методологий больше всего подходит в моем случае?
Соглашусь с высказанным мнением, что готовые методологии не подойдут.
Обычно методологии необходимы для постановки сложного процесса разработки ПО.
То, что можно посоветовать это скорее придерживаться набора техник
написания кода и проектирования.
Вообще может и не в тему, но я с трудом представляю заказчика, который ориентируется
на такой способ разработки софта. Если не секрет, в какой области работаете?
F>Вообще может и не в тему, но я с трудом представляю заказчика, который ориентируется F>на такой способ разработки софта. Если не секрет, в какой области работаете?
Заказчики — небольшие фирмы (2-15 человек), которым нужен специализированный софт, и которые не могут обратится в солидную софтверную контору, поскольку там с них сдерут в 5 раз больше.
В основном — системы учета чего-либо, склады, адаптация софта под местные условия (законодательство, язык), плюс в недалеком будущем — Shareware (это мой личный проект).
То что фирмы используют RUP и пр. вовсе не означает, что на выходе получится хороший безглючный продукт. Насмотрелась я уже на разработки крутейших фирм. То то утечки GDI ресурсов, то интерфейс нечитабельный при ACP, отличной от 1251. Я думаю, что качество разработки прежде всего определяется квалификацией разработчиков, а уж во вторую очередь методологиями.
Здравствуйте, Nata1111, Вы писали:
N> И в догонку:
N>То что фирмы используют RUP и пр. вовсе не означает, что на выходе получится хороший безглючный продукт. Насмотрелась я уже на разработки крутейших фирм. То то утечки GDI ресурсов, то интерфейс нечитабельный при ACP, отличной от 1251. Я думаю, что качество разработки прежде всего определяется квалификацией разработчиков, а уж во вторую очередь методологиями.
На больших проектах, кроме разработчиков есть еще куча нужного народу.
Разработчики могут быть сколь угодно квалифицированными, но если скажем маркетинг
сделает ошибку и разработчики очень квалифицированно и красиво сделают ненужную рынку "фичу",
то в итоге все (ну или почти) пойдут на улицу...
Методологии, которые описывают процессы разработки, расматривают команду в целом, а не отдельно
разработчиков. Каждая роль важна и каждый должен делать свою работу квалифицированно.
В теории качества все же принято считать, что хороший процесс разработки дает больше шансов выпустить
качественный продукт, который нужный рынку.
Квалификация разработчиков — это только один из многих факторов, от которых зависит качество.
100% гарантии не дает, и не никогда не даст, ни одна из методологий...
. F>Вообще может и не в тему, но я с трудом представляю заказчика, который ориентируется F>на такой способ разработки софта.
Если я правильно понял, что вы имели в виду, то у меня впечатление, что это обычное дело, когда мелкий заказчик не представляет четко, что ему надо. Сегодня ему надо "белый верх, черный низ", завтра наоборот. И никто заранее не знает, как лучше сделать. Это поиск.
Здравствуйте, Nata1111, Вы писали:
N>Я думаю, что качество разработки прежде всего определяется квалификацией разработчиков, а уж во вторую очередь методологиями.
Полностью согласен !!!
По-моему, в таком случае главная "методика" — работать аккуратно и, если брать помощника — то тоже аккуратно работающего.
Здравствуйте, Dimentiy, Вы писали:
D>Здравствуйте, Nata1111, Вы писали:
N>>Я думаю, что качество разработки прежде всего определяется квалификацией разработчиков, а уж во вторую очередь методологиями.
D>Полностью согласен !!!
D>По-моему, в таком случае главная "методика" — работать аккуратно и, если брать помощника — то тоже аккуратно работающего.
Ага, группа из 100 разработчиков не руководствуюясь ни какой методологией, так, разговаривая друг с другом пишут новую супер ERP систему в надежде утереть нос ораклу с SAp'ом. Или три акуратных разработчика без какой либо медодики, до предела упростив документацию (код, код и только код) пишут систему наведения крылатой ракеты с ядерной боеголовкой. Просто работают акуратно и все.
Все определяестя масштабом проекта, требованиями к надежности и т.д. Если смотреть с этой стороны, тогда не возникают вопросы, а нужна ли документация, процесс и почему такие заморочки с вынесением бизнес логики в промежуточный уровень. Все это вынужденные вещи, а если Вы не понимаете, почему это используется, занчить Вам повезло и вы не столькнулись с ситуацией, когда необходимо это использовать.
PSP/TSP — это действительно вкусно для менеджеров, но для программеров как показывает практика не очень . Внедрена эта шняга у нас на работе. По полной программе, с выпиской специально обученых тренеров из штатов. Уже год с ней работаем. У меня даже сертефикат от Карнеги-Меллонского института есть, что я типа специально обученный PSP программер (никому не пожелаю через это пройти — ужас какой-то
Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне Методологий. Если интересно, могу рассказать подробнее, почему. Как сертифицированный PSP программер.
> Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне
Методологий. Если интересно, могу рассказать подробнее, почему. Как
сертифицированный PSP программер.
Я собираю по форумам, fido, сайтам с исходниками различные функции, классы, паттерны, которые могут в последствии пригодится. Наверное я не одна так поступаю. Сейчас ситуация такова, что я с трудом нахожу в этой горе наработок нужное, даже при том, что тщательно все подписываю.
Вопрос: кто как хранит наработки, чтобы в любой момент времени можно было легко найти нужное?
Здравствуйте, Nata1111, Вы писали:
N>У меня точность оценки временных затрат — по Бруксу (т.е в 2-3 раза дольше А есть какой-либо софт, которым ведут эти метрики?
Тогда Вам должно быть особенно легко прогнозировать время работы. Просто свою оценку умножайте на PI
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Gaperton, Вы писали:
G>Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне Методологий. Если интересно, могу рассказать подробнее, почему. Как сертифицированный PSP программер.
Просим, просим!!!!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, ON, Вы писали:
G>Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне Методологий. Если интересно, могу рассказать подробнее, почему. Как сертифицированный PSP программер.
N>Вопрос: кто как хранит наработки, чтобы в любой момент времени можно было легко найти нужное?
Стараюсь все это иерархично организовывать и храню в виде chm. Всегда можно взять с собой и для того, чтобы просмотреть все это не нужно специфичного софта.
... << RSDN@Home 1.1 alpha 1 >>
Re[3]: Методология для разработки в одиночку.
От:
Аноним
Дата:
22.07.03 12:50
Оценка:
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, Nata1111, Вы писали:
N>>Вопрос: кто как хранит наработки, чтобы в любой момент времени можно было легко найти нужное?
DAS> Стараюсь все это иерархично организовывать и храню в виде chm. Всегда можно взять с собой и для того, чтобы просмотреть все это не нужно специфичного софта.
А я вот все по старинке. Пытаюсь все в голове удержать.
Тоже можно всегда с собой взять и вообще никакого софта не нужно
Здравствуйте, <Аноним>, Вы писали:
А>А я вот все по старинке. Пытаюсь все в голове удержать. А>Тоже можно всегда с собой взять и вообще никакого софта не нужно
Ага. Многие и проектную документацию так ведут — в голове.
Простой пример — вы писали проект на Java. А потом в течении 2-3 лет работали над проектом С++. Не уверен, что через эти 2-3 года у тебя в голове останется все то, что было ранее.
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, <Аноним>, Вы писали:
А>>А я вот все по старинке. Пытаюсь все в голове удержать. А>>Тоже можно всегда с собой взять и вообще никакого софта не нужно
DAS> Ага. Многие и проектную документацию так ведут — в голове.
DAS> Простой пример — вы писали проект на Java. А потом в течении 2-3 лет работали над проектом С++. Не уверен, что через эти 2-3 года у тебя в голове останется все то, что было ранее.
Вопрос немного об ином был. Я так понял, что вопрос был не о проектной документации,
а о знаниях, которые очень часто бывает ненужны в конкретный момент времени,
но могут в любой момент пригодиться. Например, паттерн "одиночка".
Как бы мне его так задокументировать, что бы в нужный момент его быстро найти и адекватно использовать?
Это то, что называют пассивными знаниями.
Понятно, то можно хранить линки, доки и прочее, но пассивных знаний слишком много,
чтобы явно их упорядочить...
Если я неверно понял вопрос, то пусть Nata1111 прояснит, что она имела ввиду...
Здравствуйте, bkat, Вы писали:
B>Вопрос немного об ином был. Я так понял, что вопрос был не о проектной документации, B>а о знаниях, которые очень часто бывает ненужны в конкретный момент времени, B>но могут в любой момент пригодиться. Например, паттерн "одиночка". B>Как бы мне его так задокументировать, что бы в нужный момент его быстро найти и адекватно использовать?
B>Это то, что называют пассивными знаниями. B>Понятно, то можно хранить линки, доки и прочее, но пассивных знаний слишком много, B>чтобы явно их упорядочить...
B>Если я неверно понял вопрос, то пусть Nata1111 прояснит, что она имела ввиду...
Да-да, именно то, что Вы описали. У меня уже целый CD всяких полезностей. И вот допустим, мне сейчас нужна конкретная функция, и я точно знаю, что она у меня где-то есть. Делаю поиск по разным ключевым словам — и облом! Хоть в базу данных заноси местоположение и краткое описание. Для статей действительно помогает компиляция в chm, а вот для кода вряд ли.
G>Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне Методологий. Если интересно, могу рассказать подробнее, почему. Как сертифицированный PSP программер.
Рассказываю.
PSP? Что-ж это, блин, такое?
Методика прогнозирования сроков, контроля за выполнением и контроля качества продукта для одного разработчика.
1) Все время потраченное на разработку замеряется для каждой фазы активности (компиляция, планирование, дизайн, кодирование, отладка, и еще там кое что свое) и записывается.
2) Размеры кода в LOC (Lines of code) планируются и записываются для каждой задачи (интерес представляет количество измененных и добавленных строк). Замеряется также фактический размер после закрытия задачи.
3) Все баги (дефекты) записываются, включая ошибки компиляции. Замеряется время, потраченное с обнаружения до исправления каждого дефекта.
4) После закрытия задачи считаются следующие метрики: кол-во измененных и добавленных строк кода, плотность дефектов на 1000 строк кода (в разрезах по фазам внесения/устранения), производительность строк/час.
После того как статистика собрана, вычисляется корелляция между временем выполнения задач и размером кода. На основании этих данных специальная тулза выдает прогноз времени выполнения и плотности дефектов для последующих задач основываясь на экспертной оценке предполагаемого размера кода. Также прогнозируется количество дефектов.
Теперь, что касается собственно процесса. Так как цена исправления дефекта тем больше чем бельше промежуток времени между его внесением и исправлением (это в целом верно), методы PSP направлены на раннее обнаружение внесенных дефектов. Здесь и начинаются странности PSP.
1) Нам призванна помочь техника review (поиск ошибок методом пристального взгляда), основанная на чеклистах (список часто (!) встречающихся ошибок, снабженных _механическим_ правилом их выявления). Во время review вы должны взять cheklist и пройтись по коду/дизайну целенаправленно поискав там ошибки из чеклиста. Так как все ошибки записываются, из них типа легко составить чеклист. А ошибки, по статистике, часто повторяются! Т. е. программер туп, и склонен постоянно наступать на одно и те же грабли. Причем туп настолько, что учится без этих чеклистов не в состоянии.
2) review для кода делается ***перед*** компиляцией! И вы должны найти и записать синтаксические ошибки, в числе прочих. Потом тулза вам покажет корелляцию (или ее полное отсутствие по всем группам, как у нас) между синтаксическими и прочими ошибками. Да, все ошибки компиляции тоже фиксируются, и считается процент отлова этих ошибок на review. Это должно показать качество code review, что типа в той же пропорции выловлены риальные ашипки, чиста. Если есть корелляция, которой у нас нет. Но это не повод, чтоб в сердце мужчины закралась ненужная грусть. Ответ PSP тренера на ответ программера на письмо PSP тренера: >> The PSP data issues for this week: >> Task #xyz: review is done after compile. Is there a specific reason for that? > Yes. And you know them.
I don't. Last week when we talked you said you would follow the process. >> The PSP calls for code reviews before the first compile. >> The reasons are as follows. >> *Review time is about the same, whether done before or after compile.
Can you explain, what's wrong with this point? >> *Code reviews will find syntax defects that the compiler misses.
Can you explain, what's wrong with this point? >> *Code reviews of compiled code tend to be much less effective. >> Once a clean compile occurs, it is very difficult for a developer to convince himself/herself to do a thorough code review. Psychologically, a programmer will feel that the code is fine and there is no need for a code review. Because of this, many defects will slip though to inspection and unit test. There is conclusive industrial evidence that the code reviews are more effective when performed before compilation. >> *The compiler is equally effective before or after reviews.
Can you explain, what's wrong with this point? >> *Compile can be used as quality check for review. >> A compiler is fully-automated and is the only truly objective measure of the effectiveness of your code review. Otherwise, there is no easy way to determine quickly if your code review worked well. > Ravings. Gibberish. Nonsense. Bosh. Rubbish. In that order.
Developer should follow the defined process unless there is a compelling reason to change the process.
И это только начало. Продолжение следует.
Re[3]: Методология для разработки в одиночку. Еще о PSP.
Зададимся вопросом, что же нового есть собственно в PSP.
Идея сбора метрик? Нет, это придумал вовсе не старина Хамфри (автор PSP). Все метрики, которые мы должны собирать, стары как мир. Если разобраться по сути, то они добавили только чеклисты и review (хотя и тут не уверен до конца, но скорее всего так). Процесс разработи по PSP выглядит слежующим образом:
1) Planning
Планируем размер в LOC с разбиением по мелким (!) задачам, тулза выдает прогноз по времени на основании персональной статистики, учитывая тенденцию программера к overestimate и underestimate. Задача должна занимать от 3 до 5 дней, не больше. Т. е. мы должны сделать подробную декомпозицию ***перед*** началом High Level дизайна. Кстати, эта фаза не должна занимать много времени! Крутись как хочешь.
2) High level design. Дизайн в обычном понимании этого слова.
3) HLD Review. Начинаем ловить дефекты. Отмечаем их в тулзе. Потраченное время тоже отмечаем. Дефекты ловим по чеклисту!
4) Detailed Design. Сюрприз! Все привыкли считать это кодированием, а это таки дизайн!
Это: определения всех типов (классов), тела функций на псевдокоде будьте любезны! Ошибка в алгоритме сортировки — не предусмотрели граничные условия — это ошибка дизайна, а не реализации.
5) DD Review
(!!!) Отлаживаем алгоритмы на псевдокоде в Exeleвских таблицах (т. е. в уме), как студенты-первокурсники! Этого, правда, никто не делает. А так, — стандартно: чеклисты.
6) Coding — здесь все ясно, хотя есть нюанс. Дело в том, что после 2-х дизайнов список задач, стотавленный на фазе 1 может измениться, причем серьезно. И не торопитесь окинуть свой код взглядом с птичьего полета, с целью понять, что же за фигню вы написали (что многие делают с периодичностью 5 минут). Этого делать нельзя ни в коем случае (но все делают — куда деваться-то), иначе поплывут статистики! Только в пункте 7)
7) Code Review. Взял чеклист составленный из предыдущих ошибок, и вперед!
8) Compilation. Отмечаем ошибки компиляции. Считаем, какой процент из них мы отловили на предыдущей фазе. Сокрушаемся и качаем головой. Да, хреновый у нас review yield!
9) Testing. Отмечаем все ошибки, и время которое потрачено на исправление. Если суммарное время на исправление сильно меньше времени тестирования — вздрючат.
10) Postmortem. Вбиваем в тулзу всякую шнягу, чтобы ей было приятно (риальное кол-во строк кода). Иначе вздрючат .
Если проанализировать критерии входа/выхода для фаз, мы поймем что имеем дело с классической waterfall моделью, где фазы привязанны к виду активности (все что они несут про возможность использования PSP с инкрементальными моделями — очередной случай так называемого вранья). Что нам известно про waterfall? Если кратко, что сейчас не имеет смысла его использовать (ссылки на литературу могу привести отдельно, не помню сейчас).
Вот. Собственно, мы начали плавно подходить к основным недостаткам. Ну, может еще чего напишу, если не заломает.
Re[4]: Методология для разработки в одиночку. Еще о PSP.
Всё таки позволю себе вступиться за процесс, хотя я _НЕ_ЯВЛЯЮСЬ_ его сторонником
G>1) Planning G>Планируем размер в LOC с разбиением по мелким (!) задачам, тулза выдает прогноз по времени на основании персональной статистики, учитывая тенденцию программера к overestimate и underestimate. Задача должна занимать от 3 до 5 дней, не больше. Т. е. мы должны сделать подробную декомпозицию ***перед*** началом High Level дизайна. Кстати, эта фаза не должна занимать много времени! Крутись как хочешь.
это не совсем верно , на этом этапе _НЕ_ДЕЛАЕТСЯ_ планирование задач. Здесь мы планируем время которое будет потрачено на работу над требованиями и HLD. После HLD _ВСЕГДА_ следует перепланирование, мало того если во время рабаты над любой из фаз возникает необходимость корректировки планов, то это должно делать, если это не делается то проблема не в м(М)етодологии , а в чём то в другом .
Чеклисты — опять же, при review/inspection они используются только в качестве подмоги и использование здравого смысла не исключается, если это не так, то смотри выше .
G>2) High level design. Дизайн в обычном понимании этого слова. G>3) HLD Review. Начинаем ловить дефекты. Отмечаем их в тулзе. Потраченное время тоже отмечаем. Дефекты ловим по чеклисту!
G>4) Detailed Design. Сюрприз! Все привыкли считать это кодированием, а это таки дизайн! G>Это: определения всех типов (классов), тела функций на псевдокоде будьте любезны! Ошибка в алгоритме сортировки — не предусмотрели граничные условия — это ошибка дизайна, а не реализации. G>5) DD Review G>(!!!) Отлаживаем алгоритмы на псевдокоде в Exeleвских таблицах (т. е. в уме), как студенты-первокурсники! Этого, правда, никто не делает. А так, — стандартно: чеклисты.
пугаешь и сам же говоришь что это не так
G>6) Coding — здесь все ясно, хотя есть нюанс. Дело в том, что после 2-х дизайнов список задач, стотавленный на фазе 1 может измениться, причем серьезно. И не торопитесь окинуть свой код взглядом с птичьего полета, с целью понять, что же за фигню вы написали (что многие делают с периодичностью 5 минут). Этого делать нельзя ни в коем случае (но все делают — куда деваться-то), иначе поплывут статистики! Только в пункте 7) G>7) Code Review. Взял чеклист составленный из предыдущих ошибок, и вперед! G>8) Compilation. Отмечаем ошибки компиляции. Считаем, какой процент из них мы отловили на предыдущей фазе. Сокрушаемся и качаем головой. Да, хреновый у нас review yield!
да, review после компиляции действитльно не совсем естествено , но каким способом можно опредилить качество проделанного review как можно раньше?
G>9) Testing. Отмечаем все ошибки, и время которое потрачено на исправление. Если суммарное время на исправление сильно меньше времени тестирования — вздрючат.
не замечал , в конце концов все основные ошибки по идее должны были найдены раньше и если это не так, то есть повод задуматься: а что же буде дальше
G>10) Postmortem. Вбиваем в тулзу всякую шнягу, чтобы ей было приятно (риальное кол-во строк кода). Иначе вздрючат .
если не вколотил данные, то как планировать в будущем основывая на "накопленном" опыте?
G>Если проанализировать критерии входа/выхода для фаз, мы поймем что имеем дело с классической waterfall моделью, где фазы привязанны к виду активности (все что они несут про возможность использования PSP с инкрементальными моделями — очередной случай так называемого вранья). Что нам известно про waterfall? Если кратко, что сейчас не имеет смысла его использовать (ссылки на литературу могу привести отдельно, не помню сейчас).
я думаю, что это не совсем так, что мешает человеку совершать все перечисленные операции на каждом витке спирали? ведь PSP/TSP не процесс/модель раработки-развития-сопровождения программных продуктов, а средство для планирования, прогнозирования и анализа качества проведённых работ.
А вообще при использовании PSP/TSP, как в прочем и любой другой технологии на первом месте находится человечиский фактор . Любую хорошую идею можно извернуть так, что мало не покажеться, а можно ведь и наоборот .
Что каксается меня, то PSP прсто немного утомляет , хотя любой труд он вреден для здоровья и тут ничего не поделаешь , разве что почаще
... << RSDN@Home 1.1 beta 1 >>
Re[5]: Методология для разработки в одиночку. Еще о PSP.
Здравствуйте, sardonyx, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
S>Всё таки позволю себе вступиться за процесс, хотя я _НЕ_ЯВЛЯЮСЬ_ его сторонником
G>>1) Planning G>>Планируем размер в LOC с разбиением по мелким (!) задачам, тулза выдает прогноз по времени на основании персональной статистики, учитывая тенденцию программера к overestimate и underestimate. Задача должна занимать от 3 до 5 дней, не больше. Т. е. мы должны сделать подробную декомпозицию ***перед*** началом High Level дизайна. Кстати, эта фаза не должна занимать много времени! Крутись как хочешь.
S>это не совсем верно , на этом этапе _НЕ_ДЕЛАЕТСЯ_ планирование задач. Здесь мы планируем время которое будет потрачено на работу над требованиями и HLD. После HLD _ВСЕГДА_ следует перепланирование, мало того если во время рабаты над любой из фаз возникает необходимость корректировки планов, то это должно делать, если это не делается то проблема не в м(М)етодологии , а в чём то в другом .
Ок, здесь ты похоже прав. По самой методологии так. Это в нашем проекте когда-то так пытались делать (правда, под руководством тренера, что нас извиняет), и это есть неверно.
S>Чеклисты — опять же, при review/inspection они используются только в качестве подмоги и использование здравого смысла не исключается, если это не так, то смотри выше .
Есть такое дело. Только вот тут как раз начинает действовать человеческий фактор. Если ты эту "подмогу" не используешь, получишь гнездюлей от манагера. А вот за отсутствие здравого смысла на инспекции тебя не накажут. Что и подтверждается качеством и количеством issues на реальных инспекциях. Али что не так?
G>>2) High level design. Дизайн в обычном понимании этого слова. G>>3) HLD Review. Начинаем ловить дефекты. Отмечаем их в тулзе. Потраченное время тоже отмечаем. Дефекты ловим по чеклисту!
G>>4) Detailed Design. Сюрприз! Все привыкли считать это кодированием, а это таки дизайн! G>>Это: определения всех типов (классов), тела функций на псевдокоде будьте любезны! Ошибка в алгоритме сортировки — не предусмотрели граничные условия — это ошибка дизайна, а не реализации. G>>5) DD Review G>>(!!!) Отлаживаем алгоритмы на псевдокоде в Exeleвских таблицах (т. е. в уме), как студенты-первокурсники! Этого, правда, никто не делает. А так, — стандартно: чеклисты. S>пугаешь и сам же говоришь что это не так
Да не пугаю, а рассказываю как нас учили. ты же сам знаешь
Аутентичный PSP это то чему учат, а не то на чем работают.
G>>6) Coding — здесь все ясно, хотя есть нюанс. Дело в том, что после 2-х дизайнов список задач, стотавленный на фазе 1 может измениться, причем серьезно. И не торопитесь окинуть свой код взглядом с птичьего полета, с целью понять, что же за фигню вы написали (что многие делают с периодичностью 5 минут). Этого делать нельзя ни в коем случае (но все делают — куда деваться-то), иначе поплывут статистики! Только в пункте 7) G>>7) Code Review. Взял чеклист составленный из предыдущих ошибок, и вперед! G>>8) Compilation. Отмечаем ошибки компиляции. Считаем, какой процент из них мы отловили на предыдущей фазе. Сокрушаемся и качаем головой. Да, хреновый у нас review yield!
S>да, review после компиляции действитльно не совсем естествено , но каким способом можно опредилить качество проделанного review как можно раньше?
А ЗАЧЕМ нам это определять как можно раньше? Что за маниакальные идеи? И как ты это определишь, у тебя может быть есть корелляция между ошибками компиляции и дефектами? У меня нет, и всей нашей группы не было, и у всех моих знакомых ее нет. Да и нет никаких разумных оснований, чтобы review yield, посчитанный таким образом имел какой-то смысл (даже при наличии корелляции) — ведь синтаксические ошибки в отличии от нормальных ловятся не напрягая мозгов. Совсем.
G>>9) Testing. Отмечаем все ошибки, и время которое потрачено на исправление. Если суммарное время на исправление сильно меньше времени тестирования — вздрючат. S>не замечал , в конце концов все основные ошибки по идее должны были найдены раньше и если это не так, то есть повод задуматься: а что же буде дальше
И на курсах не замечал? Тебе повезло. А у нас задачи заворачивали. А еще да прибудет с нами сила отличать основные ошибки от второстепенных и не задумываться слишком много
G>>10) Postmortem. Вбиваем в тулзу всякую шнягу, чтобы ей было приятно (риальное кол-во строк кода). Иначе вздрючат . S>если не вколотил данные, то как планировать в будущем основывая на "накопленном" опыте?
Никак. Это я стебусь.
G>>Если проанализировать критерии входа/выхода для фаз, мы поймем что имеем дело с классической waterfall моделью, где фазы привязанны к виду активности (все что они несут про возможность использования PSP с инкрементальными моделями — очередной случай так называемого вранья). Что нам известно про waterfall? Если кратко, что сейчас не имеет смысла его использовать (ссылки на литературу могу привести отдельно, не помню сейчас). S>я думаю, что это не совсем так, что мешает человеку совершать все перечисленные операции на каждом витке спирали? ведь PSP/TSP не процесс/модель раработки-развития-сопровождения программных продуктов, а средство для планирования, прогнозирования и анализа качества проведённых работ.
А вот тут, батенька, вы и не правы. Откройте лежащую у вас (или не у вас на столе книжку про RUP и еще разок посмотрите их инкрементальный цикл разработки, и сравните. Waterfall не запрещает итерации. Он даже возвраты на фазу назад не запрещает. Проблема waterfall именно в том, что фазы привязаны к виду активности (чего нет в современных инкрементальных моделях), и ты не можешь начать следующую не закончив предыдущую. Что мы имеем и в PSP, причем персональное review выделено в отдельную фазу, что совсем противоестественно.
PSP является законченной методикой управления проектом. А такая методика невозможна без явных или неявных соглашений о цикле разработке. Так что есть там цикл, как не крути, и он регламентирован. И это waterfall.
S>А вообще при использовании PSP/TSP, как в прочем и любой другой технологии на первом месте находится человечиский фактор . Любую хорошую идею можно извернуть так, что мало не покажеться, а можно ведь и наоборот .
Но некоторые хорошие и красивые идеи предрасположенны и сами подталкивают к тому, чтобы их извернули. А хорошо-ли это?
. Внедрена эта шняга у нас на работе. По полной программе, с выпиской специально обученых тренеров из штатов. Уже год с ней работаем. У меня даже сертефикат от Карнеги-Меллонского института есть, что я типа специально обученный PSP программер (никому не пожелаю через это пройти — ужас какой-то 
. Любую хорошую идею можно извернуть так, что мало не покажеться, а можно ведь и наоборот 
ты же сам знаешь 
