OpenQuality.ru

Разработка программного обеспечения

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

В то же время Золушка может стать принцессой, не затмив своим сиянием скорость разработки и стоимость продукта. Сообществу разработчиков известны подходы и практики, которые оказались эффективными в показателях качества, времени и стоимости разработки. Наиболее популярными на текущий момент являются методологии гибкой разработки приложений (Agile Software Development). На первый план выступает оперативная реакция на запросы пользователей путем точечного улучшения программного продукта. Обновления выпускаются часто, формализм сведен к минимуму, возможны значительные изменения в ранее запланированной функциональности, присутствуют эффективные коммуникации и гибкая организация труда разработчиков. Слово "agile" стало настолько популярным, что в эту категорию спешат занести чуть ли не все существующие методики – ибо известную гибкость можно найти в любой модели. К гибким методикам и практикам разработки можно без сомнений отнести следующие:

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

Extreme Programming. Частые релизы, парное программирование, регулярные сессии code review, модульные тесты, простая структура управления проектом, эффективная обратная связь.

TDD (Test Driven Development). Модульные тесты пишутся до создания самого кода. Вот хорошее введение в эту тему.

BDD (Behavior Driven Development). Во главу угла принимается эффективное взаимодействие между всеми участниками процесса разработки и внедрения приложений: программистами, тестировщиками, аналитиками. Акцент ставится не на технические детали продукта, а на сферы его применения. Определяются потенциальные сценарии использования приложения, на основе которых создаются прототипы и приемочные тесты.

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

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

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

Качество ПО и девушка мечты: дорогу осилит ищущий. Ночь. Жуткий ветер и проливной дождь. Вы ведете машину и на перекрестке останавливаетесь у автобусной остановки. Под открытым небом, прижавшись друг к другу, стоят три человека, совсем продрогшие...

Последняя миля в разработке ПО. Программный продукт создается для конечного пользователя. Последней милей для него будет тот участок, после прохождения которого пользователь с радостью скажет “Да, то что нужно!” и преисполнится к нам признательностью и уважением. Это тот участок, на котором обладатель нашего продукта получит то, что он хотел получить. Очень важно, чтобы последняя миля не стала последней каплей доверия пользователя.

Загадки Ubuntu, или знаем ли мы своих пользователей? Многообразие предлагаемых решений говорит о том, что существует простое решение. Правда, Фаина Раневская говорила, что “оптимизм – это недостаток информации”. Но надо действовать. Подобно лягушке в банке со сметаной: если сильно барахтаться, то обязательно выберешься...

Билет в пустоту, или SOS в недрах SLES. Сбой в программной системе может нарушить работу предприятия и спасти человеческую жизнь.

Разработка ПО: что скрывает ложь? Этого не может быть. Нет, нет, нет, этого не должно быть. Мы не можем этого допустить, потому что тогда вместо челнока полетят сроки. Иными словами, “этого не может быть, потому что не должно быть никогда”.