Здравствуйте, 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. Я думаю, что качество разработки прежде всего определяется квалификацией разработчиков, а уж во вторую очередь методологиями.
А есть какой-либо софт, которым ведут эти метрики?
