1366
Вакансии / Re: Ищу тестировщика, аналитические способности и навыки приветствуются
« : 03 Марта 2012, 23:14:49 »
Имхо, требуется тестировщик-сопровожденец

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
По поводу парного программирования - ты как раз и применил тот метод подбора пары, который мы и обосновали в статье.Эксперимент парного программирования - не моя заслуга. Думаю это заслуга руководителя проекта или/и особое стечение обстоятельств. Просто места было мало, поставили одни большой стол, воля неволей будешь вместе трудится. Но в целом ребята реально сдружились, были неразлейвода.
А можно поподробнее насчет конфликта? Что именно произошло?Это слишком конфиденциально. Могу в личке кратко обсказать намеки. Но реально, наверное, они еще и переросли парное программирование, каждый захотел быть соло
Спасибо, к сожалению сравнение в ЕА сделано очень не удобно, например в powerdesigner намного лучше продумано.Согласен, но ЕА и дешевле существенно + имеет довольно развитые инструменты автоматизации
Поскольку у нас демократия, то 80% довольных побеждают 20% недовольныха я слышал, что при демократии должно быть наоборот. Мол демократия должна защищать меньшество, а большинство и так себя защитит
> Ретроспективный анализ.Надо же, а я в это время в армии был. И тихо сопереживал товарищу из-за Чернобыльской катастрофы
Меня тренировали его просводить на тренингах по управлению в 1986 году. Скрама в то время не то что в проекте не было...
СУТ не используем, но есть идея произвести реверс-инжиниринг требований и загнать их в СУТ (Sparx EA). Но пока не пойму - нужно это или нет, какие плюсы и минусы.У нас не прижилось, хотя сделали довольно обширную работу по фиксации требований.
Кстати, думаю в ближайшее время поделиться этим опытом организации и написать развернутый пост в своём блоге.будет интересно почитать.
И все равно отраслевое решение для каждого свое.В нашем случае оно единое. У нас система как ДНК или РНК (биологам виднее). Заложены все возможности. В определенной среде проявляются нужные свойства
Мне кажется это довольно обширная тема. Надо как то сформулировать более точечно.Да вы правы:
Например,
Проект срок 3 года, модификаций 20 (т.е решений которое было поставлено у 1 клиента , это минимум, дальше у других уже более улучшенные ).
Вспомнили, что ничего не документировано на 10 модификации.
Теперь задача - выяснить, а зачем разрабатывалась функция которая есть в 7 модификации, которая сейчас уже не нужна (т.е. в 20 модификации ее нет)? Какое было требование.
И вот как бы все учесть - описать существующие и не упустить что-то что есть в старых модификациях?
И что же делать, когда ресурсов на описание старого нет, да и на новое не особо много?
Это скорее вопрос ведения компетенции по проекту. Если хочется оторвать компетенцию от команды и участников проекта, то можно вводить дополнительные инструменты. Только надо учитывать, что накладные в таком случае на работу появляются и достаточно большие, поскольку необходимо отслеживать связные требования, устанавливать связи и все такое прочее.Да, конечно, мы это понимаем.
Из собственного опыта: мы ситуацию с противоречивыми требованиями решали введением итераций разработки (версий). Версия должна быть обозрима, но при этом достаточно длительна для удобства разработчиков. Длительность версии определяется исходя из набора требований-изменений, которые могут быть оценены на непротиворечивость и реализуемость.Спасибо за опыт. Правда, стоит уточнить. К сожалению в нашем случае противоречивость зачастую ожидаемый эффект. Клиенты могут иметь совершенно диаметральные представления по использованию одной и той же функции. Далеко невсегда это выясняется на стадии выявление потребности и даже реализации. Зачастую это возникает уже в ходе эксплуатации. В результате "потеря лица", необходимость спешно что-то переделывать срыв планов будущего релиза
Процедура планирования включала два этапа:
1. Выбор из всего набора нереализованных требований самых важных и необходимых. При этом все требования фиксировались в беспрерывном режиме, а отсечение дубликатов и откровенно лишних происходило на этом этапе.
2. Оценка для реализации на совместимость и возможность принципиальной реализации. Здесь же появлялись и оценивались сроки.
Эдуард, ты сильно затронул тему, которую я заявил на ЛАФ'12Извини, я не хотел![]()
Если есть желание, то можем обсудить или объединить усилия, я тебе вышлю свои наработки на выходных.