CustisWiki - Вклад участника [ru]

Шаблон:Vimeoembed

2017-12-05T13:20:15Z

StasFomin:

<center>
<html><iframe src="https://player.vimeo.com/video/</html>{{{1}}}<html>?byline=0&portrait=0&rel=0" width="</html>{{{2}}}<html>" height="</html>{{{3}}}<html>" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></html>
</center>

Файл:Теория ограничений и линейное программирование.pdf

2017-09-08T01:00:18Z

StasFomin: StasFomin загрузил Файл:Теория ограничений и линейное программирование.pdf

Файл:Теория ограничений и линейное программирование.pdf

2017-09-07T07:47:15Z

StasFomin:

«Управление производством на основании численных данных» и «Теория ограничений и линейное программирование» (2009-08-03)

2017-09-07T07:46:50Z

StasFomin:

3 августа в нашей компании прошел [http://team.custis.ru/2009/08/blog-post.html ранее анонсированный мастер-класс «Управление производством на основании численных данных»].

Возможно его название звучало несколько скучно, но на самом деле, тема основана на культовой бизнес-литературе — произведениях доктора Элии Голдратта, автора производственной Теории Ограничений, основной постулат которой заключался от отказе от бессмысленной и беспощадной борьбы за тотальную производительность, вместо чего он предлагал сконцентрироваться на определении узких мест в производстве и продаже, и борьбе с ними, не взирая на падение локальных показателей оптимальности. Забавный был и способ изложения этой теории — в виде серии бизнес-производственных-романов («Цель», «Цель-2», «Критическая цепь», и др.), где главный герой, стартуя из безнадежной ситуации (бизнес разоряется, увольняют из университета, жена ушла, <small>денег нет, пиджак в пыли, под кроватью брюки…</small>) сконцентрировавшись на ключевых проблемах, находил серию эффективных решений в духе теории ограничений, и выходил победителем из сложившихся ситуаций. В общем, несмотря на некоторую инфантильность сюжета и бизнес-ситуаций с точки зрения реальностей современного мира, мы обязательно рекомендуем всем прочитать эти книги (там только о решении проблем на производстве, но и о решении семейных проблем).

[[Категория:Сергей Мартыненко]]
А конкретно этот тренинг ведущий [[:Категория:Сергей Мартыненко|Сергей Мартыненко]] основал на книге «[http://zhurnal.lib.ru/s/stepenko_a_o/the_hss.shtml Синдром стога сена]» (по ссылке перевод первой части), где на 40 страницах текста без малейшей романтики и лирики рассматривается в цифрах оптимизация некоторого модельного производства, и где «на пальцах» читателя убеждают, что для достижения максимальной прибыли нужно жертвовать локальными оптимумами, и принимать решения, часто интуитивно непонятные. Сергей также приводил [http://blog.shumoos.com/archives/186 пример], иллюстрирующий, что похожие сценарии, когда действия, вроде бы направленные на улучшение процесса, на самом деле приводят к возникновению «бутылочного горла», бывают не только в материальном производстве, но и в разработке софта.

Вот обработанное от шума видео, которое как обычно, можно просмотреть в броузере или скачать для обычного просмотра:

{{vimeoembed|5972579|640|352}}

----

Далее, был доклад Стаса Фомина: «Теория ограничений и Линейное Программирование», о возможности математического моделирования широкого класса производственных задач, в контексте и на материале того же «Стога сена». Математическое моделирование — это мощный и гуманный инструмент поиска «бутылочного горлышка» на математической модели производства, позволяющий прогнозировать изменения и дрейф ограничений, без необходимости натурных экспериментов на живых людях и работающем производстве, как происходило в романах Голдратта. А ''линейное программирование'' — простая и в то же время мощная модель, в которой каждый менеджер должен уметь формулировать подходящие задачи оптимизации. На этом докладе сначала было сделано введение в постановку задач линейного программирования на совершенно классическом игрушечном примере, а затем, за двадцать минут были вживую, с участием зрителей, сформулированы и решены все вариации задач из «Синдрома стога сена», причем оказалось, что бездушный компьютер, снабженный формулировкой задачи, нашел более оптимальное решение, чем сам Голдратт в этой книге (''это было обнаружено совершенно случайно, при подготовке презентации за час до выступления''). Таким образом, были подведены итоги:

* Человек не рожден для вычислений.
* Рассуждения в литературной форме из-за аберраций восприятия легко уводят от оптимума.
* Поиск оптимума в виде рассуждений трудно верифицировать.
* Если есть возможность — нужно составить математическую модель. Человеку ее легко верифицировать, а машине — легко решать.

Опубликован видео-скринкаст, рекомендуем его смотреть в полноэкранном режиме. Впрочем можно скачать HD-видео, оно очень компактное, 80Mb.

{{vimeoembed|5936051|640|360}}

Для очень быстрого поверхностного ознакомления опубликованы слайды презентации (но лучше смотрите видео):

{{slideshareembed|toc-and-lp-beam-090804102932-phpapp01|640|480}}

[[File:Теория ограничений и линейное программирование.pdf|256px|page=-]]

{{ActualBanner}}
{{replicate-from-custiswiki-to-lib}}
[[Категория:Открытые Семинары|У]]
[[Категория: Менеджмент (доклады)]]

User Experience Russia 2011 (Отчет Стаса Фомина)

2015-10-29T16:50:30Z

StasFomin: Новая страница: «.»

314-round-table-vcs-add-2010

2012-10-25T12:27:04Z

StasFomin: #REDIRECT Круглый_стол_по_системам_контроля_версий_(ADD-2010)

#REDIRECT [[Круглый_стол_по_системам_контроля_версий_(ADD-2010)]]

Круглый стол по системам контроля версий (ADD-2010)

2012-10-25T12:25:25Z

StasFomin: Новая страница: « == Видео == {{vimeoembed|43624089|800|450}} {{CONFIDENTIAL-BEGIN}} У нас {{UniversityMedia|channels\addconf.ru\2010\314-round-table-vcs-add-2010.av...»

== Видео ==

{{vimeoembed|43624089|800|450}}

== Примечания ==
* [http://addconf.ru/event.sdf/ru/add_2010/authors/107/153 страничка доклада на сайте конференции]

<references/>
{{replicate-from-custiswiki-to-lib}}

[[Категория:ADD-2010]]

Java vs Csharp (Круглый стол, ADD-2010)

2012-10-23T19:57:57Z

StasFomin:

== Видео ==

{{vimeoembed|43623897|800|450}}

== Примечания ==
* [http://addconf.ru/event.sdf/ru/add_2010/authors/112/159 страничка доклада на сайте конференции]

<references/>

[[Категория:ADD-2010]]
{{replicate-from-custiswiki-to-lib}}

Java-vs-csharp-add2010

2012-10-23T19:56:30Z

StasFomin: #REDIRECT Java_vs_Csharp_(Круглый_стол,_ADD-2010)

#REDIRECT [[Java_vs_Csharp_(Круглый_стол,_ADD-2010)]]

Sql-vs-nosql-add2010

2012-10-23T19:45:41Z

StasFomin: #REDIRECT SQL_vs._NOSQL_(Круглый_стол,_ADD-2010)

#REDIRECT [[SQL_vs._NOSQL_(Круглый_стол,_ADD-2010)]]

SQL vs. NOSQL (Круглый стол, ADD-2010)

2012-10-23T19:45:15Z

StasFomin: Новая страница: «== Аннотация == <blockquote> На конференции запланирован круглый стол/дискуссия на актуальную т...»

== Аннотация ==
<blockquote>
На конференции запланирован круглый стол/дискуссия на актуальную тему «SQL vs. NOSQL», чтобы выяснить, что вообще стоит за шумихой вокруг buzzword NOSQL, ведь сейчас под этой «маркой» скрываются огромный спектр разных баз данных. Там и простые распределенные словари («ключ→значение»), старинные сетевые БД, и реляционные БД без SQL → целый зоопарк, хотя обычно к NOSQL-базам причисляют те, кто жертвует целостностью и гибкостью в угоду производительности (ну и в [http://softwaremaniacs.org/blog/2010/01/31/brewers-cap-theorem/ CAP-теореме] «играет» за A и немного за P, жертвуя C).
Так что интересно разобраться, когда NOSQL необходимо применять, а когда от SQL-баз отказываются от невежества и недостатка знаний об всех возможностях реляционных СУБД.
</blockquote>

== Видео ==

{{vimeoembed|43623976|800|405}}

== Примечания ==
* [http://addconf.ru/event.sdf/ru/add_2010/authors/110/173 страничка доклада на сайте конференции]

<references/>

{{replicate-from-custiswiki-to-lib}}
[[Категория:ADD-2010]]

На каком языке говорить с СхО (Сергей Колпаков, ProductCampSPB-2012)

2012-10-23T04:50:31Z

StasFomin: /* Примечания и отзывы */

== Аннотация ==
;Докладчик: [http://ru.linkedin.com/in/skolpakov Сергей Колпаков]
<blockquote>
* Кто все эти люди CEO, CFO, CMO, CTO
* Что каждый из них желают знать о продукте
* Где взять исходные данные для оценки показателей CAPEX, OPEX, EBITDA и многих других
* Как оценить влияние продукта на показатели важные для покупателя
* Несколько практических примеров
</blockquote>

== Видео ==

{{vimeoembed|39999272|720|405}}
<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:На каком языке говорить с СхО (Сергей Колпаков, ProductCampSPB-2012).pdf|left|page=-|256px]]

{{----}}

== Примечания и отзывы ==


<references/>

http://i.imgur.com/rAF9u.png

{{replicate-from-custiswiki-to-lib}}
[[Категория:Продуктовый менеджмент (доклады)]]
[[Категория:ProductCampSPB-2012 (наша запись)]]

2012-06-07-uml-design-iofe

2012-10-22T17:52:08Z

StasFomin: #REDIRECT Проектирование_с_помощью_UML_(2012-06-07,_для_студентов)

#REDIRECT [[Проектирование_с_помощью_UML_(2012-06-07,_для_студентов)]]

Проектирование с помощью UML (2012-06-07, для студентов)

2012-10-22T17:51:49Z

StasFomin: /* Видео */

== Аннотация ==
;Докладчик: [http://vladislav-iofe.moikrug.ru/ Владислав Иофе] 

<blockquote>
В ходе семинара мы расскажем о том, что такое UML: для чего он задумывался, и для чего используется.

Вместе с вами мы рассмотрим:

* наиболее употребимые виды диаграмм с примерами
* инструменты работы с UML
* UML-анекдот

и ответим на вопросы:

* почему UML не достаточно
* блок-схема - это UML?

После чего вы попрактикуетесь в проектировании небольшой информационной системы с помощью UML.

Семинар будет полезен как молодым разработчикам, аналитикам и тестировщикам, так и совсем новичкам в IT-индустрии.

</blockquote>

== Видео ==

{{vimeoembed|44473207|800|500}}



== Примечания и отзывы ==
<references/>


{{replicate-from-custiswiki-to-lib}}

[[Категория:Семинары для студентов]]

Основы баз данных NoSQL (cеминар 2012-06-14)

2012-10-22T17:44:03Z

StasFomin:

== Аннотация ==
;Докладчик: [mailto:dolganov@custis.ru Андрей Долганов] 

<blockquote>


В мире огромных объемов информации и распределенных хранилищ данных традиционные реляционные базы данных уже не всегда позволяют удобно и быстро оперировать данными, но существует альтернатива — '''''NoSQL'''''. На семинаре мы рассмотрим это семейство технологий и сравним его с реляционными базами данных. Вы узнаете об основных типах баз данных ''NoSQL'' и применяемых для работы с ними технологиях. На примерах наиболее популярных баз данных ''NoSQL'' мы рассмотрим их особенности, сильные и слабые стороны, а также сферу их применения. На семинар приглашаются все заинтересованные в современных подходах к хранению данных, никаких предварительных знаний по теме не требуется.
</blockquote>

== Видео ==

{{vimeoembed|43623239|800|375}}



== Примечания и отзывы ==
<references/>


{{replicate-from-custiswiki-to-lib}}

[[Категория:Семинары для студентов]]

Реактивное программирование на примере Silverlight (семинар 2012-05-24)

2012-10-22T17:43:06Z

StasFomin:

== Аннотация ==
;Докладчик: [mailto:amoiseev@custis.ru Андрей Моисеев] 

<blockquote>

Интересно будет тем, кто интересуется ''асинхронными вычислениями'', ''облачными технологиями'', а также тем, кто хочет, чтобы писать ''асинхронные программы'' было также просто, как ''синхронные''.

Семинар будет состоять из трех частей. В первой части мы поговорим о '''''реактивном программировании''''' вообще. Во второй части расскажем об одном из вариантов реализации ''реактивного программирования'' на платформе ''.NET'' и языке ''С#''. И в третьей части рассмотрим пример применения ''реактивного программирования'' на практике.

Из этого семинара вы узнаете, как с помощью ''реактивного подхода'' можно на порядок упростить создание ''сложных интерактивных приложений''. Для демонстрации будет использовано приложение на ''Silverlight'', но предложенный подход полностью совместим с любой другой технологией на стеке ''.NET''.
</blockquote>

== Видео ==

{{vimeoembed|43172610|800|376}}



== Примечания и отзывы ==
<references/>


{{replicate-from-custiswiki-to-lib}}

[[Категория:Семинары для студентов]]

Разработка модульных приложений с использованием стандарта OSGI на Equinox (семинар 2012-05-31)

2012-10-22T17:42:31Z

StasFomin:

'''Аннотация'''

Докладчик [http://ivan-gammel.moikrug.ru/ Иван Гаммель].
Семинар будет состоять из двух частей: в первой, теоретической части, мы поговорим о том, как сложность проектов по разработке ПО влияет на их архитектуру, какие проблемы возникают в процессе разработки больших проектов и как их решать. Мы расскажем о разбиении программ на компоненты и модули, о том, что такое жизненный цикл компонента и как управлять зависимостями между модулями.

Вторая, практическая, часть будет посвящена стандарту OSGi и его роли в разработке Java-приложений: здесь будет краткий экскурс в историю стандарта, рассказ об организации OSGi Alliance и, конечно же, много интересного будет рассказано о плагинной архитектуре OSGi и об управлении компонентами в реализации стандарта под названием Equinox, разработанной Eclipse Foundation. В конце семинара будет продемонстрирован пример приложения на Java, использующего Equinox.

Этот семинар интересен не только разработчикам на Java, но и всем, кто интересуется архитектурой программного обеспечения.

'''Видео'''

{{vimeoembed|43623014|800|375}}
{{vimeoembed|43623154|800|375}}





{{replicate-from-custiswiki-to-lib}}

[[[[Категория:Семинары для студентов]]]]

Введение в Subversion (Лекция 2009-03-31)

2012-10-22T17:41:59Z

StasFomin:

<blockquote>
Лекция с курса «[http://team.custis.ru/2009/09/blog-post.html Разработчик СУБД]», где мы готовили разработчиков информационных систем, владеющих всем инструментарием грамотного девелопера — системы контроля версий, управления конфигурациями и задачами, вики-системы и т.п.
</blockquote>

Эта видеолекция «Введение в Subversion» — только введение, после были и практические занятия, и совместная командная работа над реальными проектами.

{{vimeoembed|5440896|640|480}}

{{vimeoembed|5954489|640|480}}

Есть и презентация (можно скачать и ее):

{{slideshareembed|subversion-intro-beam-090401054524-phpapp02|640|480}}

----

Да, в нашей компании основной системой контроля версий является именно [[Subversion]], хотя есть несколько ''legacy'' проектов, до сих пор хранимых под [[CVS]] (мы не переносим их под SVN, т.к. все это имеет хитрую интеграцию с системами сборки и «проноса» версий). Местами у нас применяются и распределенные системы контроля (<tt>Mercurial</tt> и <tt>Bazaar</tt>), но в основном только для локальных операций конфигурационного управления, либо экспериментальных проектов. В целом, мы согласны с одним из идеологов Subversion, и мы рекомендуем прочитать
[[:Категория:Статьи о Subversion|серию его статей о Subversion в нашем переводе]].

[[Категория:Семинары для студентов]]
{{replicate-from-custiswiki-to-lib}}
[[Категория:Инструменты разработки (доклады)]]

Аспектно-ориентированное программирование. PostSharp. (семинар 2011-05-12, для студентов)

2012-10-22T17:41:38Z

StasFomin:

== Аннотация ==
;Докладчик: [http://ru-george.moikrug.ru/ Георгий Русецкий] 

<blockquote>


Объектно-ориентированное программирование, пожалуй, самая популярная парадигма в мире разработки на сегодняшний день. Однако при разработке с использованием этого подхода, бывает сложно выделить часть функциональности программы в отдельные классы. Общесистемная логика журналирования, обработки исключений, аутентификации и т.п. пронизывает множество классов и методов программной системы, делая код запутанным и трудным для восприятия. В докладе рассказывается об одной из парадигм разработки, решающей проблему выделения общесистемной логики в отдельные программные модули. Мы рассмотрим:
* что такое аспектно-ориентированное программирование;
* его основные концепции;
* зачем и в каких ситуациях есть смысл использовать АОП;
* основы Postsharp - АОП фреймворка для .NET;

А также увидим примеры использования Postsharp в разработке приложений и выясним, какие преимущества даёт использование АОП.
</blockquote>

== Видео ==

{{vimeoembed|24521366|720|405}}

== Презентация ==
[[Файл:Аспектно-ориентированное_программирование._PostSharp._(семинар_2011-05-12,_для_студентов).pdf‎|center|640px]]

== Примечания и отзывы ==
<references/>


{{include-review|Блог:Team/2011-06-17_Отчет_по_семинару_от_12_мая}}

{{replicate-from-custiswiki-to-lib}}

[[Категория:Семинары для студентов]]
[[Категория: Программирование (доклады)]]

Категория:Семинары для студентов

2012-10-22T17:39:51Z

StasFomin:

Открытые семинары для студентов, проводимые в нашей компании.
Записи, как правило публикуются.

Можно {{CategoryNewPagesFeed|{{PAGENAME}}|подписаться на появление новой статьи}} (записи прошедшего семинара).

{{replicate-from-custiswiki-to-lib}}
[[Категория:Открытые Семинары]]

__NOCATEGORYCOLUMNS__

Working Effectively with Legacy Code (Майкл Физерс, AgileDays-2008)

2012-10-22T07:15:22Z

StasFomin:

Доклад [http://www.objectmentor.com/omTeam/feathers_m.html Майкла Физерса] был «guest star» всего мероприятия, хотя стоит отметить, что не все смогли выдержать плотную конференцию до самого конца — слушателей было существенно меньше, чем в начале дня.

Но тема доклада всегда актуальна, ''Legacy Code ''это вечное проклятие невезучих программистов (т.е. тех, которых бросают на поддержку чужого кода), и legacy code вечен — да, старые информационные системы умирают, но проходит пару лет, и даже твой супер-крутой код становиться ''legacy''… . Трудно удержаться и не процитировать соответствующие комиксы Дильберта:

[[Файл:Legacy systems (Dilbert).jpg|center]]

[[Файл:Legacy code support (Dilbert).jpg|center]]

На модельном примере класса «расписание» (Schedule), написанном на Java, Физер показал как сделать его тестопригодным. Основной прием свелся к N-кратному применению [http://en.wikipedia.org/wiki/Dependency_injection Dependency injection]. Причем, на наш вкус с некоторым перебором: даже статические helper-методы определения является ли день выходным или рабочим были перенесены в нестатический класс, а в тесте было предложено их «заглушить», написав соответствующего наследника. ИМХО это уже другая крайность: когда тестируется функциональность ''ровно одного класса'', а всё, что он использует, либо заглушено при помощи Stub-ов, либо эмулируется при помощи Mock-ов (см. [http://martinfowler.com/articles/mocksArentStubs.html http://martinfowler.com/articles/mocksArentStubs.html]). Это так можно получить результат как в репризе Райкина «претензии к пуговицам есть — нет, пришиты намертво…»

[[Файл:Майкл Физерс на AgileDays-2008.jpg|right]]

{{vimeoembed|25505404|720|405}}

{{vimeoembed|25520076|720|405}}

А пока, мы рекомендуем заинтересованным темой, прочитать книгу [http://www.ozon.ru/context/detail/id/2909721/ «Рефакторинг с использованием шаблонов»].

<noinclude>{{ActualBanner2}}</noinclude>

http://www.bonkersworld.net/images/2012.02.10_legacy_code.png

[[Категория:AgileDays-2008 (наша запись)]]
{{replicate-from-custiswiki-to-lib}}
[[Категория:Совершенный код (доклады)]]

Стейкхолдеры, их идеи, их приоритеты. KJ method: порядок из хаоса. (Иван Михайлов, ProductCampSPB-2012)

2012-10-22T07:10:55Z

StasFomin: /* Примечания и отзывы */

== Аннотация ==
;Докладчик: [[:Категория:Иван Михайлов|Иван Михайлов]]
[[Категория:Иван Михайлов]]
<blockquote>
Если в работе над продуктом принимают участие больше одного генератора идей, возникает проблема — как из сгенеренной сделать беклог с приоритетами.

Один из способов решения — использовать KJ метод.

Преимущества и недостатки, подводные камни.
</blockquote>

== Видео ==
{{vimeoembed|39996583|720|576}}
<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень: (
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Примечания и отзывы ==


http://www.bonkersworld.net/images/2011.12.28_inspired_generation.png
<references/>

{{replicate-from-custiswiki-to-lib}}
[[Категория:Продуктовый менеджмент (доклады)]]
[[Категория:ProductCampSPB-2012 (наша запись)]]

Коммуникативные ошибки ИТшников и как их избежать (Саша Орлов, Слава Панкратов, ADD-2011)

2012-10-22T07:07:51Z

StasFomin:

== Аннотация ==
;Докладчики:
* [[:Категория:Александр Орлов|Александр Орлов]]
* [[:Категория:Слава Панкратов|Слава Панкратов]]
[[Категория:Слава Панкратов]][[Категория:Александр Орлов]]

<blockquote>
Довольно распространено мнение, что у ИТшников не очень хорошо с коммуникациями. Долго работая менеджерами команд, а последние годы консультируя и обучая менеджеров команд, мы можем сказать, что это не вполне правда. Несмотря на то, что многие инженеры склонны к интраверсии, проводя много времени внутри своих умнейших голов, скажем, что среди ИТшников довольно много хороших коммуникаторов.

Тем не менее, есть определенные ошибки в коммуникациях, которые мы склонны совершать. Причем совершают их люди разного технического уровня, разного возраста, не всегда подозревая, что это ошибки, и как они влияют на будущее самого инженера.

О самых распространенных ошибках, а также о том, как их избежать, мы и поговорим в нашем докладе.
</blockquote>

== Видео ==

{{vimeoembed|23622294|720|405}}

{{addconf-2011-videofile|2aa-communicative-mistakes-orlov-pankratoff.avs.avi}}

<noinclude>{{ActualBanner2}}</noinclude>

{{Нужен подкаст?}}


== Слайды ==
[[Файл:Коммуникативные ошибки ИТшников и как их избежать (Саша Орлов, Слава Панкратов, ADD-2011).pdf|page=-|left|256px]]

== Примечания и отзывы ==

* [http://addconf.ru/event.sdf/ru/add_2011/authors/AlexanderOrlov/385 страничка доклада на сайте конференции]

<blockquote>Саша Орлов и Слава Панкратов отыграли классный спектакль-доклад на тему «Коммуникативных ошибок ИТшников». Первый раз видел их вместе. Круть! [http://outcorp-ru.blogspot.com/2011/05/application-developer-days-2011.html ©]</blockquote>

<blockquote>И еще я успел на окончание выступления Орлова и Панкратова, которое даже презентацией язык не поворачивается назвать. Профи, что тут скажешь, настоящее представление, с прыжками через обруч и репризами. [http://ptiz-kem.livejournal.com/67244.html ©]</blockquote>

<references/>

http://www.bonkersworld.net/images/2011.12.16_means_of_communication.png

{{replicate-from-custiswiki-to-lib}}

[[Категория:ADD-2011 (наша запись)]]
[[Категория: Менеджмент (доклады)]]

Что посмотреть сегодня вечером? Yota Play (Виталий Григораш, ProductCampSPB-2012)

2012-10-22T06:57:22Z

StasFomin: /* Слайды */

== Аннотация ==
;Докладчик: [http://vgrigorash.moikrug.ru/ Виталий Григораш]
<blockquote>
Краткая история из жизни одного пользователя, который любит смотреть кино.

Моя историю о том, как человек выбирает кино, обсуждает фильмы с друзьями и коллегами, читает о них на сайтах и в журналах, как он смотрит кино.

Моя история о том, как повседневная жизнь людей отображается в продуктах, которыми он пользуется.

Моя история про Yota Play
</blockquote>

== Видео ==

{{vimeoembed|6961847|720|304}}
<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Что посмотреть сегодня вечером? Yota Play (Виталий Григораш, ProductCampSPB-2012).pdf|left|page=-|256px]]

----
http://www.bonkersworld.net/images/2011.10.17_pre_roll.png

== Примечания и отзывы ==


<references/>

{{replicate-from-custiswiki-to-lib}}
[[Категория:Продуктовый менеджмент (доклады)]]
[[Категория:ProductCampSPB-2012 (наша запись)]]

Файл:Библиотеки и фреймворки для построения клаудов (Константин Данилов, ADD-2012).pdf

2012-10-16T19:18:33Z

StasFomin:

Frameworks4clouds-danilov

2012-10-16T19:17:36Z

StasFomin: #REDIRECT Библиотеки_и_фреймворки_для_построения_клаудов_(Константин_Данилов,_ADD-2012)

#REDIRECT [[Библиотеки_и_фреймворки_для_построения_клаудов_(Константин_Данилов,_ADD-2012)]]

Библиотеки и фреймворки для построения клаудов (Константин Данилов, ADD-2012)

2012-10-16T19:17:23Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [https://plus.google.com/106112060048784999686/about Константин Данилов] <blockquote> За посл...»

== Аннотация ==
;Докладчик: [https://plus.google.com/106112060048784999686/about Константин Данилов]
<blockquote>
За последнее время средства виртуализации достигли уровня, позволяющего использовать ее для достаточно широкого круга задач. Типичные примеры это [http://libguestfs.org/ libguestfs], [http://qubes-os.org Qubes], [https://launchpad.net/arkose Arkose]. Цель доклада рассказать, какие задачи помогает решать виртуализация и как быстро встроить ее в свою программу.

Я расскажу про основные средства управления небольшими группами виртуальных машин - подготовка, запуск, управление и мониторинг. Будут рассмотрены [http://www.libvirt.org/ libvirt], [http://libguestfs.org/ libguestfs] и сетевые библиотеки, позволяющие встроить «облако» в программу. В конце будут рассмотрены ограничения такого подхода и проведен обзор [http://www.openstack.org/ OpenStack], как облачной системы для серьезной виртуализации. Основной язык - Python, но большая часть указанных средств имеют API для всех основных языков.

;План доклада:
* Сегодняшнее состояние поддержки виртуализации.
* Как можно использовать виртуализацию.
* Что такое «облако».
* Что нужно для маленького «облака» - управление VM, управление сетями, управление дисковыми образами.
* Средства управления виртуализацией - libvirt, libguestfs, сетевые библиотеки.
* Tiny cloud, как пример встраиваемого микро-клауда на Python из 300 строк кода.
* Ограничения такое реализации.
* Обзор [http://www.openstack.org/ OpenStack], как «серьезной» облачной платформы.
</blockquote>

== Видео ==

{{vimeoembed|43623843|800|375}}
<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Библиотеки и фреймворки для построения клаудов (Константин Данилов, ADD-2012).pdf|left|page=-|256px]]

{{----}}
== Примечания и отзывы ==
* [http://addconf.ru/event.sdf/ru/add_3/authors/KonstantinDanilov/697 Страничка доклада на сайте конференции]



<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Программирование (доклады)]]
[[Категория:ADD-2012 (наша запись)]]

Автоматизация сборки и тестирования в разрезе эффективного производства (Олег Ладыгин, SQADays-11)

2012-10-16T18:52:26Z

StasFomin: /* Видео */

== Аннотация ==
;Докладчик: [http://www.linkedin.com/pub/oleg-ladygin/26/22a/a94 Олег Ладыгин]
<blockquote>
В докладе пойдет речь о внедрении систем автоматизации процессов разработки и тестирования с точки зрения эффективности производства. Рассматриваются цели внедрения автоматизированных систем, предлагаются примеры расчета трудоемкости и целесообразности.
В первой части доклада рассматриваются методы получения прибыли через развитие следующих областей:
* Ускорение циклов разработки и тестирования
* Точность соблюдения сроков
* Обеспечение заданного уровня качества продукта
* Минимизация простоя
* Выигрыш во времени на рутинные операции
* Сокращение производственных запасов
Вторая часть посвящена дополнительным преимуществам, которые может дать автоматизация. В частности, приводятся примеры достройки системы сборки проверкой орфографии, оценкой изменений в коде, проверкой стандартов на оформление документации, анализатором PL/SQL кода и т.д.
Доклад будет интересен сотрудникам, создающим или развивающим отделы автоматизации, и руководителям, понимающим необходимость повышения экономической эффективности производства.
</blockquote>

== Видео ==

{{vimeoembed|43624350|800|300}}
<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Автоматизация сборки и тестирования в разрезе эффективного производства (Олег Ладыгин, SQADays-11).pdf|left|page=-|256px]]

== Примечания и отзывы ==


<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Тестирование (доклады)]]
[[Категория:SQADays-11 (наша запись)]]

Файл:Автоматизация сборки и тестирования в разрезе эффективного производства (Олег Ладыгин, SQADays-11).pdf

2012-10-16T18:12:22Z

StasFomin:

Automating-build-and-testing-4efficient-development-ladygin

2012-10-16T18:11:30Z

StasFomin: #REDIRECT Автоматизация_сборки_и_тестирования_в_разрезе_эффективного_производства_(Олег_Ладыгин,_SQADays-11)

#REDIRECT [[Автоматизация_сборки_и_тестирования_в_разрезе_эффективного_производства_(Олег_Ладыгин,_SQADays-11)]]

Практика создания удаленного офиса тестирования (Михаил Мериин, SQADays-11)

2012-10-16T18:07:02Z

StasFomin:

== Аннотация ==
;Докладчик: [http://mihail-meriin.moikrug.ru/ Михаил Мериин]
<blockquote>
Не секрет, что нанимать сотрудников в Москве и крупных городах с каждым годом все труднее и дороже. Уже давно затраты на найм сотрудников перешагнули все разумные границы.

В таких условиях компании стремятся переводить свои офисы из Москвы в регионы.

В докладе будет освещена тема перевода ряда активностей из Москвы. Будут освещены некоторые проблемы, связанные с этим, а также выгоды и риски такого упражнения.

</blockquote>
== Видео ==
{{vimeoembed|43623779|800|375}}
<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Практика создания удаленного офиса тестирования (Михаил Мериин, SQADays-11).pdf|left|page=-|256px]]

== Примечания и отзывы ==


<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Тестирование (доклады)]]
[[Категория:SQADays-11 (наша запись)]]

Файл:Практика создания удаленного офиса тестирования (Михаил Мериин, SQADays-11).pdf

2012-10-16T18:03:32Z

StasFomin:

How-to-remote-testing-office-meriin

2012-10-16T18:02:30Z

StasFomin: #REDIRECT Практика_создания_удаленного_офиса_тестирования_(Михаил_Мериин,_SQADays-11)

#REDIRECT [[Практика_создания_удаленного_офиса_тестирования_(Михаил_Мериин,_SQADays-11)]]

Аналитика использования продукта - нужны ли вам метрики и как их раздобыть? (Алексей Ильин, ProductCampSPB-2012)

2012-10-16T04:34:54Z

StasFomin:

== Аннотация ==
;Докладчик: [http://payalnik.moikrug.ru/ Алексей Ильин]
<blockquote>
* Нужно ли вам заниматься сбором статистики?
* Какой инструмент аналитики правильнее всего использовать для вашего продукта?
* Веб-аналитика, о которой и не снилось Google Analytics
</blockquote>

== Видео ==

{{vimeoembed|39875619|800|375}}
<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Аналитика использования продукта - нужны ли вам метрики и как их раздобыть? (Алексей Ильин, ProductCampSPB-2012).pdf|left|page=-|256px]]

== Примечания и отзывы ==


http://inwebwetrust.org/~uploads/strip072_internet_marketing.jpg

<references/>

{{replicate-from-custiswiki-to-lib}}
[[Категория:Продуктовый менеджмент (доклады)]]
[[Категория:ProductCampSPB-2012 (наша запись)]]

Блог:Стас Фомин/2010-07-02 Бибичев жжот!

2012-10-09T23:37:11Z

StasFomin:

[[Категория:Андрей Бибичев]]
Кстати, [[:Категория:Андрей Бибичев|Андрей Бибичев]] продолжает активно [http://agilebasecamp.org/programm/think_diff/ зажигать на конференциях].

В частности, в Киеве он дал бой классическому софтверному менеджменту, выступив с докладом «Think Different».

<blockquote>
----
Восприятие Agile просто как набора практик, приводит к чему-то из серии Scrum Butt / Порошковый Agile / Карго-культ, что может быть вполне эффективно в среднесрочной перспективе, но не позволяет раскрыть весь потенциал ваших сотрудников и создавать по-истине уникальные атмосферу и продукты.

Чтобы сдвинуться от попугайского следования к осознанному использованию, нужно понимание ''философии'', лежащей в основе. И вот здесь начинаются настоящие трудности, так как то, что стоит за Agile-веяниями, очень сильно контрастирует с тем, к чему мы привыкли с детсадовских стульев. Возникает почти непреодолимый потенциальный барьер – необходимы серьезные перемены в нашем сложившемся сознании.

Доклад посвящен следующим метаморфозам в корпоративной, личной и профессиональной культурах:

* Мотивация → Драйв*интерес*призвание
* Карьерный рост → Самореализация
* Руководитель → Учитель
* Зона контроля → Сфера влияния
* Ответственность → Порядочность*честь
* Страх ошибки → Желание пробовать
* Знания/скилы → Способности
* Статический отлаженный процесс → Постоянные изменения
* Внимание к процессу → Уважение людей
* Архитектор → Идеолог
* Проектирование сверху-вниз → Инкрементальный дизайн
* Статическая база знаний → Динамичный обмен знаниями
* и т.д.

Во многом, это как мир и антимир. В корпоративной среде, как и в природе, материи (электронов, привычных нам форм философии) значительно больше чем антиматерии (позитронов, описанной альтернативной философии).

----

Вам придется самим выбирать свою форму существования
</blockquote>

Доклад о мотивации, но не на детском/книжном уровне (доставшие всех пирамиды Маслоу, классические менеджерские трюки типа кнута и пряника), а выстраданное понимание практически «обо всем в процессе разработки», на основе десятилетнего опыта работы именно в нашей компании.

Т.е. никакого там «совпадение с живыми людьми является случайностью» — все лица узнаваемы, да что уж там — многих называют по именам, а некоторых (людей, внутренний софт) выложили прямо на слайды.
Народу явлена истина «Истинной Мотивации», и многое, многое другое.

Пересказывать и сбрасывать остальные спойлеры не буду — думаю, я уже достаточно заинтересовал тех, кого потенциально мог заинтересовать.

<s>Технически, записи выступления нет</s>, но есть набор слайдов, и записанное аудио — в принципе, не идеально, но с этим можно жить, можно надеть наушники, включить воспроизведение звука тут (полтора часа, однако!):

{{podfmembed|happypm.podfm.ru/my/28}}

После чего приступить к листанию слайдов ориентируясь на аудио и здравый смысл (ну да, немного ручной работы, надо проверять-забегать вперед, возможны промашки, некоторые слайды померли, но жить можно):

{{slideshareembed|thinkdiff-100531023232-phpapp01|640|480}}

{{note}} Появилось и видео! Но слайды, все равно надо листать параллельно, и кроме того, на видео потеряно минут двадцать размышлений об архитекторах — для этого смотрите подкаст со слайдами.
{{vimeoembed|14061356|720|404}}

Зато, полуручной просмотр слайдов будет вознагражден ниже — я собрал ссылки на упоминаемые Андреем видео, фильмы, книги, презентации (кроме того, что элементарно загуглить).

Интересного просмотра!

----
;Update-1: Андрей развил тему в выступлении «Гики против менеджеров»: [http://vimeo.com/36543662 Видео] и [http://www.slideshare.net/biBIGine/geeks-vs-managers Слайды].

;Update-2: Вторая часть «Гиков против менеджеров», опять на AgileEE, лучший доклад, и все такое. Так вот → уже есть [http://www.slideshare.net/biBIGine/geeks-vs-managers-part-2 слайдкаст (слайды + звук)]

----

== Цитируемые Андреем культурные объекты ==
* [http://www.ted.com/talks/lang/rus/dan_pink_on_motivation.html Ден Пинк о мотивации]
* [[RuPedia:Закон Йеркса-Додсона]] — об оптимальности среднего уровня мотивации
* [http://www.youtube.com/watch?v=zfy5dFhw3ik Сцена экстремальной мотивации в фильме «Пароль:Рыба-Меч»]
* [http://community.livejournal.com/postav_odin/ Поставь кол] + [http://teh-nomad.livejournal.com/134856.html], [http://teh-nomad.livejournal.com/135264.html], [http://teh-nomad.livejournal.com/135664.html], [http://teh-nomad.livejournal.com/135884.html], [http://teh-nomad.livejournal.com/135944.html], [http://teh-nomad.livejournal.com/137337.html], [http://teh-nomad.livejournal.com/140727.html], [http://teh-nomad.livejournal.com/139082.html].
* Сериалы [http://team.custis.ru/2008/03/blog-post.html «Дильберт» и «Теория большого взрыва»]
* [http://www.ted.com/talks/lang/rus/temple_grandin_the_world_needs_all_kinds_of_minds.html Выступление об аутизме]
* [[RuPedia:Быстрый_инверсный_квадратный_корень]] — о волшебной константе из QUAKE.
----

{{SideBar|http://www.dilbert.com/dyn/str_strip/000000000/00000000/0000000/100000/40000/6000/500/146542/146542.strip.zoom.gif}}

* [http://habrahabr.ru/blogs/arbeit/61972/ Дайте мне работать-2 / Учись Работать / Хабрахабр] — схожие мысли и метафоры («Гики vs. таджики»).

<blockquote>
Затем Стив написал еще одну строку, которая вдохновила команду, вызывая у присутствующих еще больший энтузиазм: «Работать 90 часов в неделю и любить это!» Наверное, он мог бы заставить рабов, строящих пирамиды, или гребцов на римских галерах испытывать приятное возбуждение от порки и воспринимать ее как знак того, что они принимают участие в благородном деле.
</blockquote>

----
* [[RuPedia:Эксперимент_Милгрэма]]
* [http://habrahabr.ru/post/153789/ Да, я всё ещё хочу заниматься этим, когда мне исполнится 56 лет]

{{wl-publish: 2010-07-21 02:37:55 +0400 | StasFomin }}

{{replicate-from-custiswiki-to-lib}}

Блог:Стас Фомин/2010-07-02 Бибичев жжот!

2012-10-09T22:01:40Z

StasFomin: /* Цитируемые Андреем культурные объекты */

Анализ мобильного рынка и приложений для шоппинга (Яна Кузьмина, ProductCampSPB-2012)

2012-10-09T17:38:30Z

StasFomin:

== Аннотация ==
;Докладчик: [http://yana-kuzmina.moikrug.ru/ Яна Кузьмина]
<blockquote>
;Обзор рынка мобильной коммерции в России:

* Анализ рынка мобильной коммерции
** Статистика USA
** Статистика РФ 2011

* Виды приложений по отраслям:
** справочные приложения по товарам (яндекс маркет, wizee shopping и тд),
** шоппинг приложения (shoptimus, ozon итд),
** покупка билетов (smartive, awad, momondo итд),
** заказ еды (империя пиццы, стерео суши итд)
** купонаторы (Biglion, купонатор)

;Кейс Шоптимус:
* О приложении
* Почему выбрана модель агрегатора интернет-магазинов?
* iPhone vs Android, почему первая версия приложения выпущена на базе Android?
* Схема приложения (клиент-серверная модель)
* Статистика: закачки, платформы, конверсия
* Challenge: Изменение концепции после фидбека поьзователей

;Планы на будущее:
* Продвижение приложения
* Интеграция с EverFriends
* Выход на американский рынок
</blockquote>

== Видео ==

{{vimeoembed|6835460|800|375}}
<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Анализ мобильного рынка и приложений для шоппинга (Яна Кузьмина, ProductCampSPB-2012).pdf|left|page=-|256px]]

== Примечания и отзывы ==


http://www.bonkersworld.net/images/2012.10.09_reasonable_price.png

<references/>

{{replicate-from-custiswiki-to-lib}}
[[Категория:Продуктовый менеджмент (доклады)]]
[[Категория:ProductCampSPB-2012 (наша запись)]]

2010-09-22-oss-golden-mean-fomin

2012-09-27T19:20:55Z

StasFomin: #REDIRECT Золотая_середина._Открытые_системы_поддержки_разработки_(Стас_Фомин,_ADD-2010)

#REDIRECT [[Золотая_середина._Открытые_системы_поддержки_разработки_(Стас_Фомин,_ADD-2010)]]

Золотая середина. Открытые системы поддержки разработки (Стас Фомин, ADD-2010)

2012-09-27T19:19:41Z

StasFomin: /* Видео */

== Аннотация ==
<blockquote>
аша тема — системы поддержки разработки. Коллективная разработка всегда сталкивается с одними и теми же проблемами групповой работы - над кодом, документацией, тестами, ошибками и требованиями, корпоративными знаниями, и каждый решает эти проблемы по-своему. Кто-то увлекается изобретением систем собственной разработки ("изобретают велосипед"), кто-то идёт к вендорам, кто-то покупает платные специализированные узконаправленные системы.

С нашей точки зрения, разумный подход состоит в выборе, интеграции и доработке широкоизвестных систем, при этом важно учитывать не только функционал, но и открытость исходного кода.

К сожалению, интегрированность закрытых инструментов обычно означает страшную негибкость и неудобства, если отклонится от магистральных сценариев. Плюс, конечно, дороговизна.

Интегрировать разрозненные закрытые инструменты для создания удобного фреймворка сложно и неинтересно — разумно только в очень редких случаях, когда у платной системы нет альтернативного аналога с открытым исходным кодом. А сейчас такую область найти трудно - и в системах управления версиями, и в трекерах, и в вики-системах доминируют свободные решения.

Можно взять интегрированные системы с открытым исходным кодом: поставил и работает, нужно адаптировать — внес изменения. Однако существующие системы-комбайны проигрывают по функционалу отдельным проектам: слабые трекер и вики, недостаточная для коммерческой компании система прав. Они как швейцарский нож — вроде бы умеет все, но слабо.

Остается вариант с интеграцией разрозненных, но очень мощных и популярных систем с открытыми исходным кодом. Да, объем таких доработок будет относительно ничтожным, по сравнению с общим объемом системы, однако все равно эти затраты чувствительные, на что справедливо указывают продавцы платных решений.

В нашем докладе мы не просто расскажем об опыте интеграции («Talk is cheap, show me the code» © Линус Торвальдс), мы идем на большее, — мы публикуем в open-source полностью все используемые нами системы, с доработками и расширениями. Мы предлагаем сообществу совершенно бесплатно установить все это у себя, и возможно, присоединиться к развитию этого инструментального фреймворка.
</blockquote>

=== Расширенная аннотация ===

Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:

* групповая работа над кодом, документами;
* учет проблем, ошибок, требований;
* документирование, накопление и циркуляция (поиск, трансляция, агрегация) знаний компании;
* организация правильного тестирования.

Да, эффективные фреймворки сделали вебразработку достаточно легкой и быстрой, и многие увлекаются переизобретением велосипедов — реализацией собственных систем, например, учета задач и ошибок или вики-систем. Проблемы начинают проявлятся спустя время, когда обнаруживается, что приходится тратить немало времени на поддержку и развитие этих систем и обучение персонала использованию этих «самоделок», малоизвестных за пределами компании.

Поэтому дальше мы рассмотрим только разумный подход выбора, интеграции и доработки, ведь
«свято поле пусто не бывает» и существуют сотни, если не тысячи, систем для решения этих проблем.

Да, полно разных классификаций функциональности, которую должны обеспечивать эти системы
''asset management'', ''requirements management/tracking'', ''bug management'', ''issue management'', ''customer support/help desk'',
''knowledge base'', ''XXX management'' — очень легко запутаться, лично мы придерживаемся очень простой классификации,
разделяя системы в случае учета — по основному объекту учета:
;Исходный код/артефакты разработки: Системы управления версиями, вебинтерфейс к репозиториями, системы полнотекстового поиска.
;Проблемы/ответственность: системы трекинга проблем, системы управления задачами, системы баг-трекинга.
;Знания: вики-системы, блоги-форумы, коллаборативное документирование.
;Интеграция информационных потоков: RSS-агрегаторы, почта.

Но почему же «тупое» сравнение систем «по функциональности» не работает?
Почему разработчики с удовольствием используют на первый взгляд не очень функциональные, бесплатные системы,
а если их заставлять использовать дорогие, «солидные» системы от именитых производителей — они яростно бунтуют?

Мы считаем, что при выборе систем, важно смотреть на классификацию по следующим двум осям:
;Интегрированность: Снизу этой оси системы решающие частные задачи — управление версиями, вебинтерфейс к управлению версиями, поиск, совместное редактирование текстов, учет проблем и т. п. Сверху — интегрированные «комбайны», где все связано со всем (статьи-задачи-проблемы код), и центром интеграции обычно является IDE-разработчика.

Важно понимать, что это «неоднозначная ось» — интегрированней, не всегда значит лучше!
Что-то приобретается (юзабилити стандартных сценариев, например), но что-то выплескивается вместе с водой!
Теряется гибкость и некоторые возможности, которые разработчики (или, что хуже, маркетологи) посчитали ненужными!
А иногда падает и юзабилити, когда куча лишней функциональности занимает интерфейс, но не используется разработчиком.
Интегрированность иногда означает «интегрированность в рамках Одной Операционной Системы и Технологического Стека Одной Компании».
Особенно это печально, в случае закрытой, платной системы, когда нет никакой возможности, что-то исправить, изменить, срезать углы…
И уповать на платную поддержку бессмысленно — обычно платная поддержка это аутсорсинговый колл-центр, и повлиять на функциональность продукта «в свою сторону» — практически невозможно.

;Закрытость-Открытость: Да, имеется в виду именно закрытость или открытость исходного кода — именно этот фактор определяет, как развивается продукт, силами сообщества (в случае открытого кода), или исходя из внутренних инженерно-технологически-маркетинговых соображений. Вообще, «закрытость-открытость» очень сильно коррелирует с «платностью-бесплатностью», хотя есть и исключения (например, можно купить исходники Jira), но в любом случае, даже если исходники открыты, но продукт платный, его развитие определяется не сообществом — мало кто будет контрибъютить свои доработки, развивая чужой, платный продукт.

{{note}} Кстати, все больше распространяется мнение, что открытость софта позитивно коррелирует с качеством, надежностью и дешевизной техподдержки<ref>См. [http://news.cnet.com/8301-13505_3-10118123-16.html отчет Forrester]: «ПО с открытым исходным кодом характеризуется лучшим качеством (76%), более высокой надёжностью (71%) и меньшими расходами на поддержку (71%)»</ref>.

Рассмотрим существующие системы поддержки разработки под этим углом.
Для иллюстрации представим картинку напоминающую «магический квадрат Gartnerа», но, предупреждаем, — она не претендует на точность и полноту, и нужна только для иллюстрации представляемых идей.

[[Файл:Золотая середина систем поддержки разработки.svg|center|512px]]

Итак, в левом нижнем квадранте отдельные, неинтегрированные системы поддержки разработки — трекеры, системы управления версиями.
Их использование становится все менее и менее популярным, ибо даже несмотря на добротный функционал каждой из систем, разработчики не хотят тратить свое время на сложную интеграцию.
Обычно система, интегрирующую их в единое целое представляет отдельный продукт, из левого верхнего квадранта.

В левом верхнем квадранте живут монструозные платные системы, обычно интегрирующие системы вокруг IDE (Visual Studio или Eclipse), или с вебинтерфейсом.
Да, интеграция вокруг Visual Studio очень удобна для разработчика, работающего только в технологическом стеке Microsoft, и если в фирме вся разработка такая — выбор может быть вполне оправдан.

Если же часть компании работает с стеком J2EE, часть с LAMP, часть с Microsoft, часть — серверная логика на Oracle (и т. п.) — то все плюсы сразу становятся минусами.

Общая очевидная проблема — необходимость платить, причем эта проблема может стать достаточно существенной. Например, стоимость лицензий может быть больше стоимости добротного железа для разработчика. Плюс, как правило, такие систем закрыты, отсутствует возможность модификации системы и при этом, в систему жестко зашита интеграция с выбранным производителем (а не пользователем) стеком инструментов, закодированы какие-нибудь методологии и прочие «''best practices''», часто устаревшие на десяток лет, или слабоприменимые в ситуации пользователя, от которых никак нельзя избавиться. Несмотря на платность, в большинстве случаев нельзя повлиять на линию развития софта, уговорить производителя сделать нужные пользователю доработки, а платная «многоуровневая» поддержка, только изолирует разработчика системы от проблем пользователей, и зачастую неэффективна.

Так может рассмотреть открытые (бесплатные, и с открытым исходным кодом) интегрированные системы?

Такие есть, но их проблема — ограниченная функциональность,
ибо в основном они ориентируются на удовлетворение основных потребностей небольших команд разработчиков,
и как швейцарский нож — вроде бы умеет все, но слабо.
То есть да, все интегрировано, но там — слабенький трекер,
тут — слабая вики-система, где-то ещё — неразвитая система прав. (Например, у <tt>Pivotal Tracker</tt> ее вообще нет! Все имеют права на все!). Да, это удобно для небольших команд, где все друг-другу доверяют, но в коммерческой разработке, когда в компании больше 10 человек, это, вероятно, начнёт сильно жать.

В правом нижнем квадранте живут «свободные и дикие» системы, развивающиеся исключительно силой сообщества, и их жизнеспособность доказывает правильность концепций и уверенное юзабилити — иначе бы они уже вымерли, как это произошло с огромным множеством систем, заброшенных разработчиками и сообществом.

То есть, тут собрались очень мощные системы — с тысячами разработчиков и десятками тысяч пользователей.
Например,
;[[Bugzilla]]: учет задач, ошибок, проблем, ведение журналов работ, учет оргфокуса.
;[[Testopia]]: интегрированная с <tt>Bugzilla</tt> система управления тестами.
;[[MediaWiki]]: документирование, постановки задач и требований, ведение базы знаний компании, и даже блогов сотрудников.
;[[Subversion]]: вершина эволюции в централизованных системах контроля версий.

Также там находятся свободные системы, для которых нет свободных систем аналогов (и даже аналогов в мире платного софта):
;[[ViewVC]]: веб-интерфейс к Subversion, важный «клей» между Subversion и остальными вебсистемами.
;[[SVNSearch]]: полнотекстовый поиск по всей истории Subversion-репозитариев.
;[[FeedOnFeeds]]: карманный «Google Reader», то есть корпоративный RSS-агрегатор с веб-интерфейсом.

Проблемы этих систем в несколько (а иногда и сильно) хаотичном развитии, а также в том, что разные системы развиваются независимо друг от друга, у них непересекающиеся команды разработчиков, и их обычно используют по отдельности. Например, та же Bugzilla изнутри выглядит довольно страшно, хотя при этом работает и широко используется по всему миру. А в MediaWiki парсер статей не использует грамматики и не реентерабелен. На первый взгляд это вообще незаметно, но может начать «жать», когда ваши технологические процессы потребуют доработок.

Ещё пример: [[MediaWiki]] — отличная, можно сказать, ведущая вики-система, но из-за основной направленности — открытые энциклопедии, в ней не развита система прав. И более того — несмотря на то, что многие пользователи запрашивают хорошую поддержку прав в MediaWiki, её архитектура была и остаётся открытой. И более того — хорошо, если так и останется. Причина в огромном числе расширений, уже написанных, и ничего не подозревающих о системе прав, и открытом доступе к БД из любого расширения. Почему же это хорошо? Хорошо это потому, что если бы этого не было, не было бы и этого огромного числа расширений («глобально-надёжные» системы вроде неторопливой «энтерпрайз-лэвел» Java — не конёк огромных открытых сообществ разработчиков), а следовательно, и система не была бы так популярна, а следовательно, и развитие её было бы тоже замедлено.

И вообще, единая система прав и авторизации, — это самое важное, когда требуется «приручать диких животных» — то есть укрощать и интегрировать дикие вебсистемы.

Итак, наиболее выгодная стратегия, чтобы получить самую мощную функциональность (включая юзабилити) и масштабируемость по разработчикам (бесплатность и отсутствие архитектурных ошибок) — это взять наиболее мощные системы с открытым кодом, интегрировать, и доработать с учетом своих процессов.

Да, объем таких доработок будет относительно ничтожным, по сравнению с общим объемом системы (например, в MediaWiki больше 2 миллионов строчек кода и доработка/расширение в 100—200 строчек, будет меньше сотой доли процента).

И о таких подходах часто рассказывают на конференциях (как докладчики, так и участники) и в интернете.

Такие рассказы весьма полезны, ведь даже подбор правильных, не конфликтующих между собой инструментов, и проверка жизнеспособности получившейся «команды» опытом собственного использования — очень ценно.

Однако утверждать, что это абсолютно «бесплатное» решение — это некоторое лукавство.
На самом деле — эти «проценты» интегрирующего кода стоят весьма недешево,
и поэтому мало кто готов повторить чужой опыт, несмотря на его открытость.

Поэтому («Talk is cheap, show me the code» © Линус Торвальдс) мы идем на большее, — мы публикуем в open-source полностью все используемые нами системы, с доработками и расширениями.
Кстати, еще одна проблема использования open-source — пользоваться им любят многие, но при этом не любят делиться своими доработками<ref>См. «[http://www.theregister.co.uk/2010/08/13/open_source_numbers/ Open source's ardent admirers take but don't give]» или перевод «[http://habrahabr.ru/blogs/open_source/101875/ Поклонники открытого ПО не склонны делиться. Логика автостопщиков]»</ref>.

В наших доработках мы «объездили» эти дикие системы, сделав из разрозненного набора сплоченную команду, удобную для разработки в различных технологических стеках, для компании размером в несколько сотен человек.
Решена проблема с единой авторизацией и системой прав, сделано множество расширений для удобства разработчиков, аналитиков и тестировщиков, и все это проверено многолетним опытом использования.

Теперь мы предлагаем сообществу совершенно бесплатно установить все это у себя, и возможно, присоединиться к развитию этого инструментального фреймворка, ведь у вас будет отличный, гибкий
выбор — насколько вы готовы тратить свои силы, чтобы подогнать эти системы под ваши процессы, и насколько вы готовы менять свои процессы, чтобы бесплатно использовать растущий функционал этих систем, развиваемых внешним сообществом.

{{ActualBanner2}}

== Видео ==

{{vimeoembed|48432315|800|360}}

== Примечания ==
* [http://addconf.ru/event.sdf/ru/add_2010/authors/107/144 страничка доклада на сайте конференции]

<references/>

[[Категория:ADD-2010]]

{{replicate-from-custiswiki-to-lib}}

Agile Testing - What is this anyways? (Markus Gärtner, UTD-2012)

2012-09-27T18:24:58Z

StasFomin: /* Примечания и отзывы */

== Аннотация ==
;Докладчик: [http://www.shino.de/blog/ Markus Gärtner]
<blockquote>
Over the past decades we developed a very broad picture of the testing profession. In the past decade this picture has been shaken by the emergence of Agile software development processes.

On the first German Agile Testing and Exploratory Testing Workshop

(GATE) in October 2011 the participants started with a definition of what Agile Testing could be. One of the biggest insights was that the practices that help a tester on an Agile team also work well for a more traditional tester.

In this workshop the participants will work out their own definition of Agile Testing. By this discussion we will explore the differences between testing on an Agile project compared to a more traditional project. The participants will leave the workshop afterwards with at least three skills that help a tester on Agile as well as on a traditional project.

</blockquote>

== Видео ==

{{lib-vlc-media|channels/uatestingdays.com/2012/2012-08-18-UTD.uncut.mkv|00:07:52}}

<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Agile Testing - What is this anyways? (Markus Gärtner, UTD-2012).pdf|left|page=-|256px]]

{{----}}
== Примечания и отзывы ==


<blockquote>
На самый первый доклад - доклад '''Маркуса Гартнера''' я безнадежно опоздал.
Но того, что я услышал мне хватило для того, чтобы скрипеть зубами и дико желать
посмотреть запись.
Если честно, я не очень люблю доклады на английском.
Их надо слушать два или три раза.
Потому что первый раз концентрируешься на незнакомых словах, упуская основную суть.
Второй раз уже постигаешь что примерно хотел сказать докладчик.
А в третий слушаешь уже как народном языке.
[http://lazy-tester.blogspot.com/2012/08/uatesting-days-2.html ©]</blockquote>

<blockquote>
Открывал конференцию приглашенный докладчик из Германии – Markus Gärtner. Маркус выбрал довольно актуальную тему для разговора – Agile Testing. Он затронул много интересных идей и поделился своим опытом. Обидно лишь то, что говорил докладчик не очень громко. Потому услышали его только ближние ряды. Как мы не старались усилить микрофон и подсказать спикеру, что говорить нужно громче, наши попытки не увенчались успехом. Сделали выводы и записали на будущее.

[http://www.adzynia.com/2012/09/ukrainian-testing-days-2012.html ©]</blockquote>

<blockquote>
Маркус рассказывал об '''Agile Testing'''. К сожалению, подвел звук — понял где-то 80% информации. Интересное наблюдение Маркуса — когда он проводил тренинг и просил тестировщиков вешать стикеры с задачами и вопросами на [http://lisacrispin.com/wordpress/wp-content/uploads/2011/11/Agile-Testing-Quadrants.png квадранты тестирования] — победил второй квадрант. Также наш немецкий коллега еще раз сделал акцент на разнице Testing vs. Checking, чтобы дальше проще воспринимался симбиоз ATDD + Exploratory Testing и применение его в Agile-проектах.
[http://qaskills.pro/2012/08/31/uatd/ ©]</blockquote>

<blockquote>
Совсем не понравился доклад заграничного гостя Маркуса Гартнера. Он рассказал очевидные вещи о тестировании в аджайл, а хотелось бы больше послушать именно о специфике работы, какие-то примеры проектов, решения и т. д.

[http://www.dataart.ru/blog/2012/08/hersontsyi-protestirovali-odessu/ ©]</blockquote>

<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Тестирование (доклады)]]
[[Категория:UTD-2012]]

Автоматизация, как естественный процесс эволюции проекта (Екатерина Несмелова, UTD-2012)

2012-09-27T18:21:59Z

StasFomin: /* Примечания и отзывы */

== Аннотация ==
;Докладчик: [http://ekaterina-nesmelova.moikrug.ru/ Екатерина Несмелова]
<blockquote>
Что такое автоматизация? — Панацея от всех болезней проекта или ненужный груз, отнимающий время как тестировщиков, так и разработчиков? Что такое нормальная автоматизация и как её добиться?

В последнее время профессия тестировщика-автоматизатора становится всё популярнее. Зачастую, автоматизируют всё и вся, мало задумываясь о том, а правильной ли дорогой идём, товарищи?

В рамках этого доклада я обещаю поделиться своим опытом автоматизации на трёх различных проектах. Расскажу, что привело к удачной реализации проекта, а что оказалось провальным решением, и как его можно было бы избежать. Также в рамках доклада будет рассмотрено, что является естественным процессом автоматизации проекта, а также участие в разработке автоматических тестов тестировщиков и разработчиков.

</blockquote>

== Видео ==

{{lib-vlc-media|channels/uatestingdays.com/2012/2012-08-18-UTD.uncut.mkv|04:33:19}}

<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень: (
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Автоматизация, как естественный процесс эволюции проекта (Екатерина Несмелова, UTD-2012).pdf|left|page=-|256px]]

{{----}}

== Примечания и отзывы ==


<blockquote>
Следующим докладчиком была Катя Несмелова, уже проявившая себя как активный слушатель и интересный и беспомпромиссный собеседник. :)
Её доклад назывался "Автоматизация, как естественный процесс эволюции проекта "
Катин доклад был очень интересным и полезным.
Она делилась опытом автоматизации и её доклад продолжался даже больше положенного времени в ущерб печенько-тайму :)

[http://lazy-tester.blogspot.com/2012/08/uatesting-days-2.html ©]</blockquote>

<blockquote>
«Это был мой первый опыт посещения такого рода мероприятия. Впечатления — мегапозитивные. Больше всего понравился доклад Екатерины Несмеловой. Рассказывала ярко, основываясь на реальных примерах из своего опыта, активно общалась с аудиторией.
[http://www.dataart.ru/blog/2012/08/hersontsyi-protestirovali-odessu/ ©]</blockquote>

<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Тестирование (доклады)]]
[[Категория:UTD-2012]]

Exploratory Testing. Что это? (Андрей Дзыня, UTD-2012)

2012-09-27T18:18:49Z

StasFomin: /* Слайды = */

== Аннотация ==
;Докладчик: [http://adzynia.moikrug.ru/ Андрей Дзыня]
<blockquote>
Каждому из нас знакома ситуация, когда времени на выпуск продукта катастрофически не хватает. Это приводит к тому, что приходится экономить время, и чаще всего не в сторону тестировщиков. Эта спешка рушит существующий процесс, и десятки или сотни человеко-часов, которые уходили на написания и поддержку тестовых сценариев оказываются «за бортом».

Многие команды, в тех случаях, где это возможно, уходят от «шаг-за-шагом» сценариев в сторону написания так называемых чеклистов. Это помогает экономить время и тестировать быстрее. Но по какой-то причине, в мире тестирования, сформировалось мнение, что exploratory testing это и есть тестирование по чеклисту. На самом деле – это не так!

Если вы хотите расставить все точки над «и» и разобраться, что такое Exploratory Testing – приходите послушать мой доклад!

Я расскажу о том, что такое Exploratory Testing, а что воспринимается как заблуждение относительно этого подхода к тестированию. Продемонстрирую пример одной из Exploratory Testing сессий, чтобы вы увидели пример использования этого подхода на практике. В конце доклада смогу ответить на все ваши вопросы и обсудить различные проектные ситуации в кулуарах.

</blockquote>

== Видео ==

{{lib-vlc-media|channels/uatestingdays.com/2012/2012-08-18-UTD.uncut.mkv|02:21:41}}

<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
* http://www.slideshare.net/AndrewDzynia/exploratory-testing-14021565

{{----}}
== Примечания и отзывы ==


<blockquote>
Третьим докладчиком был Андрей Дзыня с докладом "Exploratory Testing. Что это?"
Поскольку я сам я вляюсь своего рода адептом эксплоративного тестирования,
то из этого доклада я вынес ммм... как бы это сказать...

не количество знаний, а качество. Андрей дополнил мою "картину мира эксплоративного тестирования" и дал стимул к новым интересным исследованиям в этой области.
Спасибо, Андрей!

[http://lazy-tester.blogspot.com/2012/08/uatesting-days-2.html ©]</blockquote>

<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Тестирование (доклады)]]
[[Категория:UTD-2012]]

Да перестаньте уже автоматизировать! (Алексей Лупан, UTD-2012)

2012-09-27T18:17:34Z

StasFomin: /* Примечания и отзывы */

Да перестаньте уже автоматизировать! (Алексей Лупан, UTD-2012)

== Аннотация ==
;Докладчик: [http://testitquickly.moikrug.ru/ Алексей Лупан]
<blockquote>
Что нас увлекает и отвлекает от общего видения и понимания происходящего на поле боя? Что работает хорошо, но недолго, только при хорошей погоде и на ограниченных участках фронта? Кто капризно требует, чтобы «заранее все было хорошо подготовленно»? Что заставляет людей так глупо и недальновидно разделяться на «своих» и «не своих»?

Все она, Автоматизация…

Посидим, помолчим о том, почему стремление к всеобщей автоматизации — бред и страдание.

</blockquote>

== Видео ==

{{lib-vlc-media|channels/uatestingdays.com/2012/2012-08-18-UTD.uncut.mkv|01:24:42}}

<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень: (
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:__FULLPAGENAME__.pdf|left|page=-|256px]]

{{----}}

== Примечания и отзывы ==


<blockquote>
Очень дельные мысли и прогнозы! Некоторые — спорные, некоторые — достойные аплодисментов. По-моему, ключевая мысль доклада: “Не стоит давать меч не умеющему танцевать” в контексте автоматизации. Сложно выразить его мысли после конференции — советую посмотреть запись доклада. Облако тегов высказываний/мыслей/прогнозов доклада:

* тестировщики будут иметь роботов как помощников
* то что используется людьми — должно тестироваться людьми. Тестирование взаимодействия машин — автоматизировано (машинами)
* ментальный процесс автоматизации чего-либо разительно противоположен процессу тестирования” ''- есть такое дело…''
* надо тестировать вообще, а не “проходить вручную” или “автоматизировать”
* Научитесь тестировать перед переходом к автоматизации ''- видали мы автоматизаторов не разбирающихся в тестировании или незнакомых с продуктом ''

[http://qaskills.pro/2012/08/31/uatd/ ©]</blockquote>

<blockquote>
Вторым докладчиком, которого я предпочел был Алексей Лупан с докладом
"Да перестаньте уже автоматизировать!"
Мне очень понравился его доклад. Алексей выстроил интересную экстраполяцию
будущего, которое может ожидать тестирование и это будущее мне очень понравилось.
Были спорные утверждения и были непонятные.
Одно уже то, что доклад породил больше вопросов, чем дал ответов меня только радует.

[http://lazy-tester.blogspot.com/2012/08/uatesting-days-2.html ©]</blockquote>

<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Тестирование (доклады)]]
[[Категория:UTD-2012]]

Переходя все границы. Vol 2 (Алексей Баранцев, UTD-2012)

2012-09-27T18:09:40Z

StasFomin: /* Примечания и отзывы */

== Аннотация ==
[[Категория:Алексей Баранцев]]
;Докладчик: [[:Категория:Алексей Баранцев|Алексей Баранцев]]
<blockquote>
Анализ границ - эту технику каждый тестировщик осваивает, наверное, самой первой.

Но в действительности применение этой техники вовсе не так просто, как может показаться на первый взгляд, потому что в реальном мире разных "границ" куда больше, чем описано в любой, даже самой хорошей спецификации. Причина этого в том, что в реальной программе существует множество технологических границ, о которых аналитик может даже не подозревать.

Что будет, если пользователь, случайно или намеренно, пересечёт такую технологическую границу - введёт слишком большое число или слишком длинную строку? Должен ли тестировщик пытаться это выяснить? Или может быть достаточно предупредить пользователей, чтобы они не вводили "плохие" данные, а кто ввёл - мы ответственности не несём? А если всё таки мы решили, что тестировщику следует пытаться всё это проверить -как искать эти границы, если они нигде не описаны?

Я расскажу свою точку зрения на применение этой техники, приведу примеры реальных багов, связанных с нарушением технологических границ, подскажу некоторые приемы, которые позволяют их обнаруживать, и дам рекомендации, когда этого можно не делать.

Это вторая, более полная версия доклада о границах, с более интересными и живыми примерами. Ведь на границах багов намного больше, чем мы можем себе представить.
</blockquote>

== Видео ==

{{lib-vlc-media|channels/uatestingdays.com/2012/2012-08-18-UTD.uncut.mkv|06:21:07}}

<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Переходя все границы. Vol 2 (Алексей Баранцев, UTD-2012).pdf|left|page=-|256px]]

{{----}}
== Примечания и отзывы ==
* Это развитие доклада [[Переходя все границы... (Алексей Баранцев, SQADays-11)]]

<blockquote>
Завершающим докладчиком был всем известный Алексей Баранцев. Который, представил внимаю вторую версию доклада о границах и дал повод еще раз задуматься о том, что тестирование это важно и нужно, и не только в программном обеспечении.
[http://www.adzynia.com/2012/09/ukrainian-testing-days-2012.html ©]</blockquote>

<blockquote>
Закрывал конференцию keynote '''Алексея Баранцева''' ''“Переходя все границы. vol 2”'' К сожалению, реально большой практической ценности для меня он представлял — доклад процентов на семьдесят повторял оный на SQA Days 11.

Но сложно не признать талант Алексея как докладчика.
[http://qaskills.pro/2012/08/31/uatd/ ©]</blockquote>



<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Тестирование (доклады)]]
[[Категория:UTD-2012]]

Переходя все границы. Vol 2 (Алексей Баранцев, UTD-2012)

2012-09-27T17:56:34Z

StasFomin: Новая страница: «== Аннотация == Категория:Алексей Баранцев ;Докладчик: [[:Категория:Алексей Баранцев|Але...»

== Аннотация ==
[[Категория:Алексей Баранцев]]
;Докладчик: [[:Категория:Алексей Баранцев|Алексей Баранцев]]
<blockquote>
Анализ границ - эту технику каждый тестировщик осваивает, наверное, самой первой.

Но в действительности применение этой техники вовсе не так просто, как может показаться на первый взгляд, потому что в реальном мире разных "границ" куда больше, чем описано в любой, даже самой хорошей спецификации. Причина этого в том, что в реальной программе существует множество технологических границ, о которых аналитик может даже не подозревать.

Что будет, если пользователь, случайно или намеренно, пересечёт такую технологическую границу - введёт слишком большое число или слишком длинную строку? Должен ли тестировщик пытаться это выяснить? Или может быть достаточно предупредить пользователей, чтобы они не вводили "плохие" данные, а кто ввёл - мы ответственности не несём? А если всё таки мы решили, что тестировщику следует пытаться всё это проверить -как искать эти границы, если они нигде не описаны?

Я расскажу свою точку зрения на применение этой техники, приведу примеры реальных багов, связанных с нарушением технологических границ, подскажу некоторые приемы, которые позволяют их обнаруживать, и дам рекомендации, когда этого можно не делать.

Это вторая, более полная версия доклада о границах, с более интересными и живыми примерами. Ведь на границах багов намного больше, чем мы можем себе представить.
</blockquote>

== Видео ==

{{lib-vlc-media|channels/uatestingdays.com/2012/2012-08-18-UTD.uncut.mkv|06:21:07}}

<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

== Слайды ==
[[Файл:Переходя все границы. Vol 2 (Алексей Баранцев, UTD-2012).pdf|left|page=-|256px]]

{{----}}
== Примечания и отзывы ==
* Это развитие доклада [[Переходя все границы... (Алексей Баранцев, SQADays-11)]]



<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Тестирование (доклады)]]
[[Категория:UTD-2012]]

Файл:Переходя все границы. Vol 2 (Алексей Баранцев, UTD-2012).pdf

2012-09-27T17:52:52Z

StasFomin:

Автоматизация, как естественный процесс эволюции проекта (Екатерина Несмелова, UTD-2012)

2012-09-27T17:34:09Z

StasFomin:

Файл:Автоматизация, как естественный процесс эволюции проекта (Екатерина Несмелова, UTD-2012).pdf

2012-09-27T17:28:35Z

StasFomin:

Exploratory Testing. Что это? (Андрей Дзыня, UTD-2012)

2012-09-27T17:23:44Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://adzynia.moikrug.ru/ Андрей Дзыня] <blockquote> Каждому из нас знакома ситу...»

== Аннотация ==
;Докладчик: [http://adzynia.moikrug.ru/ Андрей Дзыня]
<blockquote>
Каждому из нас знакома ситуация, когда времени на выпуск продукта катастрофически не хватает. Это приводит к тому, что приходится экономить время, и чаще всего не в сторону тестировщиков. Эта спешка рушит существующий процесс, и десятки или сотни человеко-часов, которые уходили на написания и поддержку тестовых сценариев оказываются «за бортом».

Многие команды, в тех случаях, где это возможно, уходят от «шаг-за-шагом» сценариев в сторону написания так называемых чеклистов. Это помогает экономить время и тестировать быстрее. Но по какой-то причине, в мире тестирования, сформировалось мнение, что exploratory testing это и есть тестирование по чеклисту. На самом деле – это не так!

Если вы хотите расставить все точки над «и» и разобраться, что такое Exploratory Testing – приходите послушать мой доклад!

Я расскажу о том, что такое Exploratory Testing, а что воспринимается как заблуждение относительно этого подхода к тестированию. Продемонстрирую пример одной из Exploratory Testing сессий, чтобы вы увидели пример использования этого подхода на практике. В конце доклада смогу ответить на все ваши вопросы и обсудить различные проектные ситуации в кулуарах.

</blockquote>

== Видео ==

{{lib-vlc-media|channels/uatestingdays.com/2012/2012-08-18-UTD.uncut.mkv|02:21:41}}

<poll>
ALTERNATIVE
REVOTE
UNIQUE
Оцените доклад «{{PAGENAME}}»:
Отлично!
Хорошо.
Нормально…
Не очень :(
Просто хочу узнать результаты.
</poll>

<noinclude>{{ActualBanner2}}</noinclude>

= Слайды ==
* http://www.slideshare.net/AndrewDzynia/exploratory-testing-14021565

{{----}}
== Примечания и отзывы ==


<references/>

{{replicate-from-custiswiki-to-lib}}

[[Категория:Тестирование (доклады)]]
[[Категория:UTD-2012]]

Agile Testing - What is this anyways? (Markus Gärtner, UTD-2012)

2012-09-27T17:14:18Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://www.shino.de/blog/ Markus Gärtner] <blockquote> Over the past decades we developed a very broad picture of ...»