Agile в Беларуси

Хорошо, что такие встречи проводятся.

Но конкретно к этой встрече у меня много претензий:
* для кого проводится встреча? - я был с группой ребят, которые уже используют TDD - мы все в один голос сказали: “зря потраченное время”
* какова цель встречи? - оказалось, что по верхам расказать про TDD, хотя я например ждал чего-то для advanced уровня
* и т.д.

Предложения:
1) Мне кажется, что для инженерных практик нужно проводить (1)вводную лекцию, (2)что-то вроде круглых столов с разделением по технологиям, когда могут собраться комрады пишущие на PHP (например) и показать как конкретно они делают проекты с использованием TDD
2) Придерживаться какого-то стандарта при описании встречи, типа *уровень, *формат(лекция, семинар, круглый стол, …), *технологии(?) и т.п.

Замечания дельные! Это хорошая обратная связь. Если кто-то напишет ещё, будет из чего делать выводы. А так будем стараться более конкретно писать для какой аудитории и в каком формате будет проводиться встреча.

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

Алексей, если у вас есть ребята с опытом/вопросами по TDD, так давайте подумаем, как сделать встречу с практическим уклоном.

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

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

Также присоединяюсь к первому оратору: даже не имея навыков практического использования TDD, а только прочитав полкнижки про «Экстремальное программирование. Разработка через тестирование», из первого выступления для себя ничего нового я не почерпнул.

Кроме того, вместо просто восклицаний, что это очень круто, более действенным доказательством был бы какой-то сравнительный анализ «без» и «с» — экономический или просто на пальцах.

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

В любом случае, спасибо за старания, если впредь будет еще что-нибудь подобное, я приду

Александр, идея хорошая. Обращайтесь. Вместе можем собрать нужную аудиторию и провести подобного рода встречу. Я прорабатываю идеи следующей встречи по TDD (следующий этап, после введения с более практическим уклоном.

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

Насчет экономического обоснования - это для другой аудитории нужно.
Требуются исследования, а таких проводится очень мало. То, что использование TDD увеличивает время разработки на ~20% не значит, что разработка становится дороже на 20%. Экономически обосновать TDD сложно, т.к. нужно учитывать огромое количество факторов (и человеческий в том числе). Если найдете что-либо по этой теме, то делитесь.

Я рассказал именно то, что хотел рассказать на первой встрече, посвященной TDD. Обоснование было, возможно вы его восприняли как-то иначе.

Начал было писать с сарказмом… Павел, очень глупо себя ощущаешь, когда слушаешь простой рассказ, в котором звучит притча, показывающая, что:
1.У автора есть страх передать не тот смысл.
2.Ответственность за неверно понятый смысл переносится исключительно на аудиторию.
Довольно неудачный ход.

Остальные подробности корректней обсудить приватно, если интересно.

Коллеги, имхо имеет место быть стандартная ситуация - несовпадение ожиданий
Одни ожидали услышать про Х, коллеги готовились рассказать про Z - все считали что их ожидания\предположения очевидны, ну и в итоге как всегда одни не получили что хотели и сердиты, а другие готовились и подверглись критике и сердиты
Поэтому предлагаю поступить мудро - более тщательно описывать предполагаемый доклад, аудиторию, цели и содержание. После чего рихтовать план ДО подготовки доклада.
Через это доклад будет о том, что интересно (активной части) аудитории. Согласны?

Коллеги, пожалуйста, публикуйте конструктивные предложения. Моя и ваша задача сделать наши встречи более полезными и интересными. Давайте её и решать.

Мои выступления кому-то могут не нравиться, но я ведь и не солнышко, чтобы всем нравиться.

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

Да, я с вами согласен.

Alex Stepanov, насколько я понял, вы работаете с командой которая уже использует TDD. Поэтому, конечно же вы это и так все уже знаете и имеете опыт использования. Тогда вопрос такой: что вы ожидали от этой встречи? какие были у вас цели?

Сергей Морозов, насколько я понял то вам было бы интересно экономическое обоснование использования TDD и юнит-тестов в частности. У меня есть несколько наработок и когдато очень-очень давно Паша показывал презентацию Кирли Роберта о TDD. Вот собственно они

http://www.agile.by/2008/03/18/razrabotka-cherez-testirovanie.html
http://www.slideshare.net/Mikalai_Kardash/what-tests-are-for-presentation

Кроме того, конечно волнуют проблемы с которыми можно столкнуться попытавшись внедрять эти технлологии на своих проектах. Уверен, что многие кто внедрял TDD уже проходили через многие злоключения и могут чего понарассказывать. Например, Alex Stepanov могбы описать свой опыт работы по TDD.

Андрей Аминов, вы пришли и это очень очень хорошо. К вам вопрос: какую информацию вы хотели приобрести инвестировав свое время в эту встречу?

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

С другой стороны, при минимуме мнений мы всегда будем получать негативную оценку семинаров.