Каковы некоторые ситуации, где Гибкий является несоответствующим? [закрытый]
Да, вы можете сделать это. Однако должно быть место, где вы указываете браузер, который будет открыт.
-
Имя открываемого браузера может быть передано в качестве аргумента методу настройки
from selenium import webdriver def setUp(self, browserName): if browserName == "Firefox": self.browser = webdriver.Firefox() elif browserName == "Chrome" : self.browser = webdriver.Chrome() -
Имя открываемого браузера может быть прочитано из некоторой конфигурации / файл свойств.
from selenium import webdriver def setUp(self): browserName = #Code to read value from configuration file if browserName == "Firefox": self.browser = webdriver.Firefox() elif browserName == "Chrome" : self.browser = webdriver.Chrome()
11 ответов
Я не думаю, что одна методология может управлять ими всеми.Мне жаль. Я - твердый сторонник нахождения правильной модели для правильного проекта. Например, то, как Вы чувствовали бы, были ли Ваш в хирургию, и Вы знали машину, которая поддерживала Вас, было разработано в быстром повторяющемся цикле с небольшим дизайном заранее.
Но так или иначе, по Вашему вопросу. Я - крупный сторонник гибких подходов, хранения Ваших коротких повторений, фокусируясь на том, что пользователь хочет, и не создание линкора, но только создание точно, в чем Вы нуждаетесь. Я сказал бы, что 95% всех проектов могли использовать гибкие подходы, и если они не могут он обычно быть культурной проблемой, не проблемой проекта.
Теперь до BDUF (Большой Дизайн впереди), мы имели большой успех с 20 командами человека на 4-месячном проекте, мы взяли проект, разломал его на 3 четырехнедельных цикла, в начале каждого цикла, который все мы встречаем в комнате и сказали хорошо, вот то, что мы должны создать, вот то, как мы создадим его, и мы попробовали то, на что будут похожи наши интерфейсы, в каких данных мы нуждались и т.д... Но это был только удар, мы затем вернулись к нашим столам, и кто бы ни владел различными частями, спугнул детали.
По существу мы сделали достаточно BDUF заранее для придания импульса команды (И гарантировать, что мы покрыли все бизнес-требования). Мы раньше называли эти Дни разработчика сессий, и это был хороший способ инициировать команду. Если у Вас есть наличное взятие команда от сайта, можно наполнить их в конференц-зале в отеле, подают их много спама и наблюдают, что соки текут.
простое решение имеет 2 шага:
- не оценивайте затраты и расписания для проектов, оценочные затраты и расписания для функций
- имейте размеры и достаточно рекордная информация для вычисления скорости и ошибок оценки
начните с малого и внутренний, если это возможно, для получения некоторых оснований системы счисления. Если Вы все еще хотите сделать 'большой первичный дизайн', сделайте это для отдельных функций. Это поможет Вашим первоначальным оценкам быть более точным, и также какой гранулярностью 'функции' Вы довольны.
Примечание: это будет только работать, если клиент посвятит себя, вносят свой вклад, а именно, чтобы быть высоконадежным разработчикам (для ответа на вопросы, запишите истории и протестируйте описания, и др.), и не передумать во время повторения
удача с Вашим переходом, и сообщила нам, как это идет!
Безусловно самое большое противопоказание, которое я видел, является несоответствием значений. Экстремальное программирование полагается на уважение, коммуникацию, обратную связь, храбрость и простоту. В организации, которая ведет себя на основе несовместимых значений, применяя XP, вызовет трение и не приведет ни к какому длительному изменению (IME).
Это зависит от того, кого Вы спрашиваете и верят ли они в гибкий или нет...
Что касается этого:
Я хотел бы найти, что одна методология управляет ими всеми.
http://www.opaquelucidity.com/facepalm.jpg
Действительно ли все Ваши клиенты являются тем же? Вы уже сказали, что продолжительности варьируются дико... Почему Вы предположили бы, что весь способ отличающихся проектов будет подходить для одной единственной методологии?
Поиск, что делает Гибкий сбой практики... Если Вы поняли 1-2 мысли несовершеннолетних, идут для него, Вы найдете способ пробежаться через них. Еще, Вы ищущий отказ. И после того как Вы перестали работать, у Вас не будет другой возможности попробовать его. Даже если это не Гибкая практика, которая перестала работать...
Запустите с внутренних проектов получить некоторый опыт с тем, как Ваш гибкий процесс работает и как можно лучше всего оценить, сколько времени дела идут взять. Когда Вы чувствуете, что Вы готовы взять настоящего клиента, выберите тот, с которым Вы имеете большое доверие и выбираете довольно маленький проект запуститься с. Ключ здесь - то, что Вы хотите создать атмосферу доверия. Объясните, что Вы делаете и почему - Вы хотите предоставить лучшее программное обеспечение им, которое лучше отражает их приоритеты раньше - и покажите им, как Вы были успешны на своих внутренних проектах. Выполните свои обещания - так как я верю в гибкие методы, я не думаю, что это будет слишком трудно сделать.
После того как Вы следовали (и ошеломили клиента), они попросят, чтобы Вы использовали метод на их других проектах. После того как у Вас есть один счастливый клиент, можно начать расширяться до других, с помощью первого клиента в качестве ссылки. Довольно скоро Вы найдете, что методы, Вы используете работу так хорошо, что они вползают в Ваши процессы "водопада" также. В конечном счете Вы выпьете достаточно kool-помощи быть похожими на остальную часть нас agilists.:-)
О. И да, существуют проекты, которые не особенно поддаются гибким методам. Вещи как жизнь, критические системы, управление атомной электростанции, высоко отрегулировали отрасли промышленности, могут все потребовать более первичного дизайна, и процесс, чем гибкий позволяет. Большинство из нас никогда не работает над этими проектами.
Scott Ambler является хорошими полномочиями для ответа на этом. Его статья делает хорошее задание выделения некоторых ловушек фиксированной цены, но это определенно возможно. Alistair Cockburn соглашается, что это возможно также, но указывает, что часть пользы, которую Вы извлекаете из гибкого, потеряна в контрактах фиксированной цены.
Одной основной проблемой с "большим дизайном заранее" (BDUF) является время, проведенное, разрабатывая функциональность, которая редко является, если когда-либо, используется. Если у Вас должно быть готовое изделие через месяц или меньше, проблема должна быть действительно четко определена заранее.
Что касается стоимости отказа, это - очень обоснованное опасение. Одно преимущество Гибких - то, что любые отказы происходят ранее и по намного менее стоимости, чем они были бы в проекте после методологии водопада. Способность извлечь уроки из тех отказов и получить хороший продукт в конце не является результатом, который может обеспечить методология водопада. У федерального правительства есть достаточное количество высококлассных отказов проектов программного обеспечения, которые следовали за методологией водопада и BDUF. Я вел блог о Виртуальном отказе проекта Досье ФБР.
Какие методологии, которые Вы используете, будут определены так же соответствием с Вашей командой как тип программного обеспечения, которое Вы создаете, и Ваши клиенты. tvanfosson совершенно правилен о проектах, которые не подходят для гибких методов. Я соглашаюсь с Kent Beck на идее несоответствия значений. Некоторые организации не готовы к Гибкому с культурной точки зрения, независимо от ее достоинств и успеха в другом месте.
Позвольте мне ответить на Ваши проблемы детально:
Нет ли минимальный размер для этого? Большой дизайн впереди должен быть более эффективным для трех или четырехнедельного проекта... Правильно?
Я не уверен, что заставляет Вас думать, что рисование прямоугольников на бумаге должно быть быстрее, чем рефакторинг кода.
Так или иначе, даже если бы это было, вопрос того, платит ли BDUF, была бы намного больше функция того, сколько изучения Вы ожидаете во время проекта, чем размера проекта. Чем больше можно ожидать узнавать что-то о дизайне, требованиях, и т.д. при реализации системы, тем больше честного дизайна становится потраченным впустую.
Я должен все же встретиться с проектом, где я не изучил значительные вещи при реализации системы.
Наши клиенты обычно требуют фиксированных цен. Они должны знать то, что они имеют дело с, кроме особых случаев, где мы противостоим очевидной черной дыре, и даже затем люди более довольны ограничением. Таким образом, как можно обеспечить кавычку, если Вы идете с процессом, который терпим к продолжающимся изменениям требования?
Только примите изменения требования, которые не изменяют общее усилие. Таким образом, когда новые требования входят, отбрасывают менее важные. Позвольте клиенту решить так, чтобы он мог получить большую часть удара для маркера.
Вы не извлечете всю пользу из Гибких этот путь, но это столь хорошо, как фиксированная цена может добраться, насколько я могу сказать.
Я понимаю, что Гибкий может обеспечить лучшие разногласия успеха в более сложных проектах, но разве он не завысит затраты для клиента?
Вы предполагаете, что проекты работают, Гибкий путь являются более дорогостоящими, чем традиционные проекты? Существуют на самом деле компании там, которые испытали противоположное до снижения затрат на 50%.
И конечно существует стоимость отказа рассмотреть - возможно, мы вернулись в минимальном вопросе о размере здесь.
Стоимость отказа понижается с Гибким проектом из-за ранней обратной связи. Можно заметить отказ - и поэтому решить отменить проект - намного ранее.
Как в мире Вы объяснили бы этот парадоксальный подход к клиентам? У заинтересованных сторон Non-technicial не могло бы быть опыта перенести их головы вокруг чего-либо вне Водопада.
Почему Гибкая разработка программного обеспечения платит?
Даже для внутренних проектов, существуют бюджеты. Что я пропускаю?
Я не знаю. Гибкий хорошо работает с бюджетами - реализуют самые высокие приоритетные опции, пока бюджет не израсходован. У Вас есть самая ценная система, которая, возможно, была реализована за те деньги.
Кажется, что существует некоторая обратная реакция против Гибкого в последнее время. Что-то еще собирается начать наращивать обороты скоро?
Была обратная реакция против него с самого начала. И поскольку это становится более популярным (и это!), просто естественно, что Вы также видите больше обратной реакции.
Минимизированная Разработка программного обеспечения наращивает много оборотов. Это не находится на конкуренции Гибкой разработке, а скорее дополнительно, все же. Сообщества на самом деле являются довольно перекрывающимися.
Относительно "одной методологии для управления их всех" - смотрят на "Кристаллическое" семейство Alistair Cockburn Гибких процессов. Он спорит (вполне со знанием дела), что для каждого проекта нужен свой собственный процесс, и что даже процесс одного проекта должен измениться в течение проекта. И он служит легкой основой для разработки Вашего процесса.
Как делает Толпу, как я думаю об этом. Толпа на самом деле не говорит Вам очень о том, как выполнить Ваш проект, но намного больше о том, как узнать то, что работает и как позволить команде адаптироваться к тем результатам.
Я предложил бы против Гибкого при разработке новой системы управления воздушным движением.
Я не обязательно буду использовать Agile для проекта, где все известно заранее. Agile хорошо работает, когда вероятность изменений высока. В случае, если изменение не является вероятным, можно использовать процесс прогнозирования или водопад для управления таким проектом.
Ниже приведены ответы на ваши конкретные вопросы: Разве нет минимального размера для этого? С практической точки зрения Agile не зависит от размера. При этом, чем крупнее проект, тем больше вероятность изменений. Если проект достаточно небольшой, тогда все можно узнать, и изменения маловероятны.
Большой предварительный дизайн должен быть более эффективным для трех-четырехнедельного проекта ... Верно? Простой и эволюционный дизайн, основанный на TDD, всегда более эффективен. У вас должно быть достаточно архитектуры, чтобы знать, где падают основные части. Не используйте архитектуру, чтобы угадать, что вы собираетесь делать, только фиксируйте то, что можно узнать. Пусть простой и эволюционный дизайн позволит вам развивать детальный дизайн по мере создания приложения.
Наши клиенты обычно требуют фиксированных цен. Им нужно знать, с чем они имеют дело, за исключением особых случаев, когда мы сталкиваемся с очевидной черной дырой, и даже тогда людям удобнее пользоваться крышкой. Итак, как вы можете предоставить расценки, если вы используете процесс, допускающий постоянные изменения требований? Сначала требуется некоторое образование. Вы должны составить список отставаний по продукту, попросить владельца продукта расставить приоритеты, а затем сделать первоначальную оценку работы. Это действительно требовало, чтобы владелец продукта установил линию отсечения в невыполненной документации для фиксированной ставки. Затем вы определяете команду и продолжительность, чтобы соответствовать оценке. Затем в контракте говорится, что вы будете использовать фиксированную вместимость команды в установленный временной интервал. Это позволит владельцу продукта сосредоточиться на графике и бюджете при выполнении приоритетных вызовов по отставанию.
Я понимаю, что Agile может обеспечить больше шансов на успех в более сложных проектах, но не приведет ли это к увеличению затрат для клиента? Успешный проект всегда дешевле провалившегося.
Как бы вы объяснили этот нелогичный подход клиентам? Нетехнические заинтересованные стороны могут не иметь опыта, чтобы осмыслить что-либо, кроме Waterfall. Обучение (например, agile boot camp) и посещение успешных agile-команд очень помогут. Тогда запустите команду. Работа будет держать их занятыми, а результаты продадут их.
Даже для внутренних проектов есть бюджеты. Что мне не хватает? Похоже, что в последнее время наблюдается некоторая негативная реакция на Agile. Будет ли что-то еще набирать обороты в ближайшее время? Единственная обратная реакция, о которой я знаю, - это гибкие проекты, в которых неэффективно используются инженерные практики (например, только SCRUM). Команда, использующая SCRUM и XP эффективно, преуспеет в доставке и устойчивом темпе.
Имхо:
Гибкий или нет, вы должны спроектировать то, что известно, прежде чем внедрять - прежде, чем «просто пробовать». Рекурсивно разбивайте вещи на управляемые задачи, а затем проектируйте то, что известно, будь то мельчайшие детали или просто общие концепции. Такие вещи, как пользовательский интерфейс и повседневные бизнес-требования, почти никогда не высекаются на камне до разработки, тогда как функции моделирования самолетов могут быть такими.
Один из способов попытаться «продать» гибкость клиентам - предоставить им два варианта: 1. Водопад, где нет отмены, пока мы (разработчики) соблюдаем свою часть соглашения. 2. Agile, где вы получаете еженедельные обновления статуса, практические демонстрации по мере их появления и право прекращать обслуживание каждые 2 недели (на случай, если вам не нравится наша работа).