https://www.dushevoi.ru/products/mebel-dlja-vannoj/komplektuishie/zerkalnii-shkaf/ 
А  Б  В  Г  Д  Е  Ж  З  И  Й  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч  Ш  Щ  Э  Ю  Я  A-Z

 

Любой бизнес, который привык вначале разрабатывать план, а затем действовать в строгом соответствии с этим планом, будет сильно конфликтовать с командой, которая намерена постоянно менять план своих действий по мере работы над проектом.
Любой план предусматривает использование емкой, достаточно большой и тщательно продуманной спецификации. Если заказчик или менеджер настаивает на составлении полной спецификации или подробного анализа или разработке полноценного дизайна перед тем, как можно будет сесть за написание кода, тогда возникает сильное трение между культурой команды и культурой заказчика или менеджера. В рамках проекта все же можно будет использовать ХР, однако это будет непросто. Вы предлагаете заказчику или менеджеру способ работы над проектом в форме диалога (игра в планирование), который подразумевает, что они будут находиться в постоянной связи с проектом. Для человека, который и без того очень сильно занят, это может оказаться неприемлемым.
Но однажды я работал для одного банка, представители которого просто очень любили большие куски бумаги. В процессе работы над системой они постоянно настаивали на том, чтобы мы документировали систему. Мы постоянно отвечали им, что если они хотят получить меньше функциональности и больше бумаги, мы будем рады удовлетворить их просьбу. Мы слушали их просьбы о документации в течение нескольких месяцев. По мере того как проект продвигался вперед и становилось ясным, что тесты не только обеспечивают стабильность системы, но и отлично описывают ее поведение, требования о документировании становились все тише и тише. Все же они продолжали настаивать на своем. В самом конце работы над проектом менеджер по разработке сказал нам, что все, что ему нужно, это четырехстраничное обозрение основных объектов системы. Он пришел к выводу, что любой человек, который не в состоянии получить необходимую ему информацию из кода и тестов, вообще не должен трогать код.
Еще одна культура, в рамках которой не следует применять ХР, это культура, в рамках которой вы должны работать внеурочное время для того, чтобы доказать свою преданность компании. Вы не можете работать в стиле ХР, если вы устали. Если объем работы, выполняемый командой, работающей с максимальной скоростью, недостаточен для компании, значит, ХР – это не ваше решение. Если вы работаете над проектом ХР сверхурочно в течение двух недель подряд – это верный признак того, что вы делаете что-то не так. Вместо того чтобы продолжать работать в напряженном режиме, лучше попытаться обнаружить проблему и устранить ее.
Иногда очень умные программисты с трудом овладевают ХР. Для очень умных людей тяжело поменять их умение делать правильные дальновидные предположения на тесную коммуникацию и постоянную эволюцию системы.
Огромное значение имеет масштаб проекта. Скорее всего, вам не удастся эффективно использовать ХР, если над проектом работает сотня программистов. Пятьдесят программистов – это тоже слишком много. Скорее всего, и двадцать программистов будет много. Десять программистов – это определенно подходящее количество. Если в команде всего три или четыре программиста, вы можете безбоязненно отбросить некоторые из методик, сфокусированных на координации, например игру в планирование итерации. Объем функциональности, который требуется реализовать, и количество людей, которые работают над реализацией этой функциональности, связаны зависимостью, которая ни в коем случае не является линейной.
Если у вас крупномасштабный проект, вы можете экспериментировать с ХР – попробуйте использовать ее в течение месяца с небольшой командой, чтобы проверить, как быстро будет продвигаться разработка. Наиболее узким местом при использовании ХР в крупных проектах является однопоточный интеграционный процесс. Вы должны как-либо расширить этот процесс, чтобы обеспечить интеграцию нескольких источников кода на одном компьютере.
Вы не можете использовать ХР в случае, если имеете дело с технологией, которая подразумевает экспоненциальный рост затрат, связанных с внесением в систему изменений. Например, если вы имеете дело с мэйнфреймом, планируете использовать установленную на нем реляционную базу данных и не уверены в том, что схема реляционной базы данных в точности соответствует тому, что вам нужно. В подобной ситуации вы не должны использовать ХР. ХР основывается на чистом и простом коде. Если вы усложняете код для того, чтобы избежать модификации 200 существующих приложений, в самом скором времени вы потеряете гибкость, ради которой вы, собственно, и решили использовать ХР.
Еще одним технологическим барьером, препятствующим использованию ХР, является рабочая среда, в которой для обратной связи требуется слишком длительное время. Например, если для компиляции и компоновки вашей системы требуется 24 часа, вы вряд ли сможете интегрировать, собирать и тестировать по несколько раз в день. Если перед тем, как приступить к использованию системы на производстве, вы вынуждены пройти двухмесячную процедуру проверки качества, вы не сможете быстро получать сведения о том, как ведет себя система в условиях реального производства при добавлении или изменении той или иной функциональности.
Я работал в средах, в которых было невозможно тестировать программное обеспечение в обычном смысле этого слова, – в условиях производства система работает на компьютере стоимостью в один миллион долларов, который загружен до предела, и у вас нет еще одного лишнего миллиона долларов. Или существует такое большое количество комбинаций возможных проблем, что вы просто не можете выполнить маломальски осмысленный набор тестов за время, меньшее, чем один день.
В подобной ситуации самым правильным решением будет заменить тестирование длительным предварительным размышлением. Однако в этом случае то, что вы делаете, нельзя будет назвать ХР. Когда я программирую в рабочей среде подобной категории, я не чувствую себя способным свободно видоизменять дизайн системы. Я обязан сформировать необходимую гибкость заранее. В этом случае вы по-прежнему можете производить качественное программное обеспечение, однако при этом вы не должны использовать ХР.
Помните историю о программистах, офисы которых размещались в разных концах здания? Если вы работаете в неподходящих физических условиях, ХР не будет работать. Как было отмечено, для целей ХР я использовал большую общую комнату с мощными компьютерами в центре и с небольшими отделениями вдоль стен. Однако это только один из возможных вариантов. Вард Каннингхэм (Ward Cunningham) рассказывал мне о проекте WyCach, при работе над которым каждому программисту выделили по отдельному небольшому рабочему месту, отделенному от внешнего мира перегородками из ДСП. Однако каждый такой мини-офис был достаточно просторным для того, чтобы вместить двух человек. Если два человека хотели работать в паре, они выбирали один из офисов. Если вы абсолютно точно не можете передвигать столы, если уровень шума высок настолько, что сильно мешает разговору, если вы не можете расположиться достаточно близко для того, чтобы обеспечить хорошую коммуникацию, вы не сможете использовать ХР с максимальной эффективностью.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
 бриклаер анна 60 

 мозаика на кухне фото