Test Driven Development

Всем привет!
21 августа, в Питере прошел тренинг "Test Driven Development". Тренинг прошел на одном дыхании, ребята даже на кофе-брейки не хотели выходить :) Я думаю, все вышли после тренинга "test infected" :)
Фото прилагается.

Чем отличатся методологии?

Почему так много методологий?

Вы задавали себе вопрос – почему методологий так много? Если у нас одна цель, то все должно быть просто: один гениальный подход должен победить. Видимо, есть какие-то важные отличия.

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

Если представить некоторую табличку различных подходов к оптимизации процессов, получится нечто следующее.

Подход	Метод оптимизации	Комментарий
Code&Fix	Максимальная эффективность здесь и сейчас	Процесс определяется менеджментом исходя из краткосрочных целей повышения производительности. Никаких практик здесь не определено по следующим причинам: повысить производительность «сегодня» можно только снижением качества работы.
Waterfall	Максимальная эффективность достижения очень четко поставленной задачи	Определяется четкий план достижения конечной цели. Критерием эффективности является мера отклонения от плана.
RUP	Закрытие рисков практиками и артефактами	RUP описан в виде набора ролей, активностей и артефактов. Процесс строится следующим образом: менеджер выбирает и внедряет подходящие практики. Необходимость практики определяется наличием соответствующего риска. Например, если в проекте путаница с требованиями, имеет смысл ввести роль «requirements engineer» Особенность RUP в том, что огромный упор делается на архитектурные риски.
CMMi, ISO9001 и прочие стандарты качества	Соответствие лучшим практикам индустрии/компании/ Организации	Процесс сверяется с некоторым золотым стандартом. Стандарт существует на уровне целей (goals) и доопределяется на уровне компании соответствующими практиками. Процесс проекта «тейлорится», то есть из процесса, определенного на уровне компании, выбрасываются ненужные на уровне проекта практики либо добавляются новые.
Scrum	Максимальная устойчивость к изменениям	С изменениями Scrum борется, используя следующие принципы: итеративность, инкрементальность, самоорганизация. Практики Scrum обеспечивают максимальную эффективность следования принципам
Extreme Programming	Максимизация качества кода	Принципы KISS (Keep It Simple, Stupid), и YAGNI (you ain’t gonna need it) дополняются практиками OOP, Test Driven Development, Refactoring, Continuous Integration и другими. Итеративность также считается необходимой.
Kanban	Максимизация пропускной способности	Определены три практики Kanban: Limit WIP, визуализация и каденция.
Lean Development	Минимизация lead time (времени с начала разработки) и потерь (waste)	Определены семь принципов: Eliminate Waste, Amplify Learning, Decide As Late As Possible, Deliver As Fast As Possible, Empower The Team, Build Integrity In и See the Whole. Метод использования следующий: существующий процесс компании оптимизируется устранением потерь, простоев и т.д. (waste). Командный принцип работы. На уровне разработки часто используется Scrum и другие разновидности Agile.

Чтобы меня не заклевали суровые ревнители чистоты определений надо сделать следующее пояснение.

В таблице приведены вещи далеко не одного порядка. Например, Waterfall – это определение жизненного цикла, а RUP – описание методологии. Вместе в одной табличке они потому, что за ними стоят разные цели оптимизации.

Совместимость подходов

В принципе, из таблички становятся понятно, какие методологии совместимы, а какие нет. Например, Code&Fix не совместим ни с чем, так как фундаментально противоречит на уровне методов оптимизации. Некоторые сочетаются очень и очень хорошо, например Scrum и Extreme Programming.

Опишу вкратце несколько на практике встречающихся связок и соответствующих кейсов

Waterfall и RUP. «Классический» вариант внедрения RUP. Если из RUP выкинуть итеративность, но оставить фазы, получится водопадный процесс. Он будет «обогащаться» морем артефактов и ролей. Такой процесс чрезвычайно эффективен для высасывания денег из заказчика. Если заказчик будет менять требования, выписывайте «Запрос на изменение» и требуйте оплаты вперед :-)!

Scrum & XP. Итог смешения – классический Agile с быстро меняющимися требованиями, короткими итерациями и пристальным вниманием к техническому совершенству. Подходы дополняют друг друга. Практики самоорганизации из Scrum позволяют команде эффективнее добиваться высокого качества, и качество обеспечивает дешевизну изменений.

XP & Code&Fix. XP будет полностью соответствовать подходу Code&Fix, если вы аккуратно выберете оттуда подходы KISS и YAGNI, общения с заказчиком лицом к лицу и «отсутствия документации», но выкинете очень дорогие практики по автоматизации тестирования и парному программированию. На вопросы «где план?» и «где требования?» страшно обижаться и отвечать «у нас же XP!» :-)

Scrum & RUP. Короткие итерации и большой упор на архитектурные риски. Короткие итерации и самоорганизация позволяет справляться с вызовами постоянных изменений. Упор на архитектуру решает трудности технически сложных проектов. Scrum станет намного богаче, если вы будете знать, что такое Feasibility Study и как оно проводится, как разбивать систему на компоненты, как использовать Use Cases и т.д.

RUP & XP. Это означает RUP и практики из XP с упором на техническое совершенство кода, в частности Test Driven Development и Refactoring.

Scrum & Kanban. Сам по себе канбан очень прост и внедрение его без понимания «духа Agile» может превратить разработку в слабоуправляемый хаос, который будет очень далек от оптимального. Например, разделение технологической цепочки может узаконить отсутствие кроссфункциональности: «я программист, это моя колонка на доске». В итоге часть времени программист будет простаивать. Внедрение некоторых принципов и практик Scrum (таких, как самоорганизация и daily scrum) превращает канбан-команду в очень эффективную.

Lean & Scrum. На уровне разработки Scrum сам по себе полностью соответствует принципам Lean. На более высоком уровне оптимизации процесса компании Scrum не применим. Здесь сработает Lean.

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

Тренинги в Новосибирске

В начале сентября состоится грандиозное нашествие Никиты Филиппова - великого специалиста по управлению продуктом на землю Новосибирскую :)
Приходите! Приходите! Никита покажет чудеса управления продуктом :)) Чтобы попасть на такое зрелище и увидеть владение мастерством необходимо зарегистрироваться на сайте

Конференция AgileEE

Похоже, конференция AgileEE становится мероприятием, которое преступно глупо пропускать. Лично меня сами доклады интересуют постольку поскольку. Все-таки самым мощным событием будут мастер-классы.

Во-первых, сам Мери и Том Поппендик. Они придумали адаптировать Lean и TPS к разработке ПО. И если на уровне команды использование Agile в виде Scrum и XP позволяет добиваться впечатляющих успехов, то на уровне организации без Lean не обойтись. И черт побери, это опыт из первых рук!

Во-вторых, если вы профессионально занимаетесь внедрением Agile у себя в организации, или в стране :-) то сходить на семинар David Hussman стоит. Других шансов перенять опыт у такого опытного коуча может и не оказаться.

И наконец, две сертификации - на Scrum Master и на Product Owner. Просто очень качественные тренинги + раздача сертификатов, которые можно поставить в рамочку :-)

Лично я просто рвусь на части между Hussman и Poppendieck.

Встреча AgileRussia "Метрики в Agile"

18 августа, во вторник, состоится очередная встреча сообщества AgileRussa. На этой встрече мы обсудим тему «Метрики в Agile». Очень часто на Agile-методологии смотрят, как на некоторый "непредсказуемый" подход к работе – нет четких переходов от одной стадии проекта к другой, нет четких сроков завершения проекта и т.п. В классическом подходе существует набор метрик, позволяющих ответить на типичные вопросы бизнеса – во сколько обойдется проект, насколько он будет окупаться, как определить критерии качества и завершенения. А что в Agile? На встрече мы обсудим следующие вопросы: Нужны ли метрики в Agile? Если да, то Какие? Что вы используете Вы в своей практике? От каких проблем вам удалось избавиться с их помощью? Какие проблемы принесло их внедрение? Место проведения: центр Москвы, офис компании Заказные ИнформСистемы Условия участия: Бесплатно. Регистрация обязательная. Просто заполнитерегистрационную форму или напишите письмо на askhat@agilerussia.ru Ждем :-). be ag;)e

Онлайн-Конференция Вэб «404»: Интервью с Никитой Филипповым, ScrumTrek

На вопросы онлайн конференции "404" отвечал Никита Филиппов, основатель компании «ScrumTrek», которая ставит команды разработчиков на рельсы гибких методик разработки, решающая проблемы компаний путем улучшения процессов. Никита и его коллеги тренировали такие известные вэб-проекты, как Тематические медиа (Habrahabr.ru, Autokadabra.ru), АФИША, Auto.ru, Badoo, e-signals.

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

Как это сделать? Что может не получиться? Как быть в нетривиальных ситуациях? Вопросы и Ответы смотрим смотрим здесь

Как тестировать в Agile? Принимаются вопросы!

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

В подкасте будут участвовать:

* Илья Гаврилов, Exigen

* Яков Котляр, Black&Veatch

* Асхат Уразбаев, ScrumTrek

* Алексей Лупан, testitquickly.com

Тестирование в Agile

Этот доклад был представлен на конференции SQA Days’2009 24 апреля. Его можно послушать в виде слайдкаста (слайды, снабженные звуком) тут. Алексей Лупан (testitquickly.com) был настолько любезен, что перевел его в текст. Я его совсем чуть-чуть поправил и снабдил картинками в тех местах, где без них нельзя было понять текст.

Текст доклада