3-4 июля: TDD .NET in Action, Днепропетровск

TDD .NET in Action или Как за 2 дня .NET-разработчику научиться жить без отладчика

Какие проблемы мучают разработчиков?
Средство, которое решает все эти проблемы
Зачем нужен тренинг?
Аудитория
Тренеры
Стоимость
Контакты и регистрация

Какие проблемы мучают разработчиков?

Непонятно с чего начинать реализацию очередной фичи

Трудно работать с чужим кодом: никогда не знаешь, что где сломается, если его поменять
Страх перед улучшением архитектуры приложения: "не меняй то, что работает"
Починка багов:
- нужно обнаружить поломку
- затем ее починить
- нет гарантий, что исправление одних багов не породит другие
Долгое ожидание обратной связи: ошибки обнаруживаются на стадии тестирования, и возвращаются к разработчику в то время, когда он занят другими делами.

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

Средство, которое решает все эти проблемы

Test-Driven Development (или TDD) - это как раз оно. Если ваша команда практикует TDD, значит:

Есть уверенность, что в репозитории лежит работающий код
Нет страха вносить изменения любой сложности
Нет чужого кода - можно смело изменять любой код в системе и быть уверенным, что он будет работать
Ошибки находятся легче и чинятся намного быстрее
Код сам собой получается чистым и понятным
Архитектура приложения тоже сама собой стремится к чистоте
И самое главное - есть постоянное ощущения успешного движения вперед. Каждый добавленный “зеленый” тест - это шаг вперед.

Зачем нужен тренинг?

Несмотря на свои преимущества, TDD не так просто внедрить, как кажется. При своей внешней простоте практики часто не приживаются в командах. Основных причин две:

Отрицание: Команда не понимает, какую пользу принесет TDD.
Неумение: Польза понятна, но непонятно, как нужно внедрять.

Одним из лучших способов понять, зачем и как нужно использовать TDD - попробовать его в деле под руководством профессионалов.

Подробнее о тренинге >>>

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Основополагающие принципы Agile-манифеста

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

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

Поиск по этому блогу