Home

Международная конференция для специалистов по обеспечению качества программного обеспечения — SQA Days 2009 — прошла с 28 по 29 октября в Москве в рамках Международной восточно-европейской научно-практической конференции по программной инженерии (для специалистов по разработке программного обеспечения) — CEE-SECR 2009.

Сегодня мы публикуем интервью с Андреем Бибичевым, ex-руководителем отдела технологического развития компании ООО «Заказные ИнформСистемы» (CustIS), Москва. Разговор шел о его докладе «Проектирование больших информационных систем в Agile», о преимуществах тестировщиков, которые разбираются в моделях предметной области, и о людях, которые мыслят себя аналитиками.

Расскажи вкратце, о чем ты делал доклад на конференции.

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

Есть мнение о том, что разработка программного обеспечения по agile подходит только для небольших проектов, а какие-то серьезные вещи уровня enterprise при помощи agile либо очень рискованно делать, либо нельзя делать вообще.

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

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

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

Под agile большинство подразумевают SCRUM, некоторые — eXtreme Programming. Но есть еще одна agile-методология под названием Feature Driven Development (FDD).

В отличие от Scrum и XP, FDD зародилась на очень большом, долгосрочном проекте — в 1997 году около пятидесяти разработчиков на протяжении полутора лет писали большой софт для большого сингапурского банка. Это было уже третьей попыткой написать этот софт, представьте себе состояние участников проекта. Но все прошло очень успешно.

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

То есть ничто не ново под солнцем agile?

С одной стороны это не ново, с другой...

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

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

Из-за этого возникло мнение о том, что сперва надо всё смоделировать, а потом уже реализовывать. По понятным причинам, в среде разработчиков ПО достаточно негативное отношение и к такому подходу, и к UML в частности. Разработчики ругают UML, хотя боги разработчиков вроде Фаулера постоянно используют UML в работе и пишут об этом в своих книгах.

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

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

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

А что получается на практике?

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

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

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

Например, у себя в CustIS мы практикуем следующее — если заказчик разрешает, мы привозим разработчиков к ним в офис, чтобы программисты смотрели, как люди работают. Как они, например, мучаются со старой системой... Многое в этот момент проясняется.

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

Есть какие-либо практики, которые помогают преодолевать разрыв между моделью и ее имплементацией? Или все делом во внимательности и воображении?

Надо пытаться сделать имплементацию в коде максимально близкой к исходной модели предметной области. Чтобы разрыв был минимальным. Чтобы глядя в код, можно было понять, на основании какой модели он написан, и наоборот, чтобы взяв модель, можно было достаточно несложно понять, как она будет реализована в коде, пусть это делается и не автоматически. В целом это неплохо работает, сейчас на Западе Domain Driven Design — очень модная тема, у нас об этом на конференциях почему-то почти не говорят.

Для этого нужны грамотные аналитики в разработке программного обеспечения.

Как организовано тестирование в подходе Domain Driven Design?

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

У нас в CustIS тестировщик выполняет часть функций аналитика за счет того, что он общается с заказчиком, и ему интереснее потом тестировать.

А как они справляются с регрессионным тестированием?

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

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

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

Я собеседовал много аналитиков. Это такое расстройство...

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

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

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

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

На самом деле, это не такая уж сложная тема. Это те вещи, без которых нельзя кидаться в agile, иначе получаются какие-то игрища и забавы. Остаются только общие темы, основы, например, налаживание коммуникаций. Да, у программистов бывают проблемы и с коммуникациями, и с соблюдением сроков. Да, на тренингах по agile даются какие-то основные техники, которые позволяют эти основные проблемы преодолеть. Ну, научились мы ходить друг к другу в гости и общаться, ну и что? Куда дальше-то идти? Это остается совершенно «белым полем», и сейчас многие подходят, говорят «О, у нас agile!» и начинают жаловаться, какой этот agile, как они его одолевают, и что у нас стало лучше, но открылся следующий пласт проблем, которые надо решать...

Интервьюировал Алексей Лупан.