Быстрый цикл разработки и оптимизация

Реализация (прототипа или продукта) — весьма дорогостоящая деятельность, ко­торая является лишь средством достижения цели, но не самой целью. Ниже приведе­ны некоторые подходы и методы, направленные на повышение эффективности реа­лизации.

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

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

Полезное правило. Не беспокойтесь о том, чтобы проявить необъективность при анализе результатов тестирования. Трудно утверждать, когда вы добьетесь ко­личественного и качественного улучшения продукта.

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

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

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

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

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

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

Методы совместной разработки. Поддерживать высокий уровень уча­стия и активности пользователей в процессе отбора результатов и потенциальных решений по-прежнему остается полезной практикой применительно к итеративной разработке.

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

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

Важно знать, когда остановиться. Прежде чем начать, следует понять, когда остановиться. Итеративный подход— средство достижения цели, и трудно предсказать, сколько и какой продолжительности итераций потребуется для дости­жения цели. Рейтинг пользовательской удовлетворенности большинства продуктов показывает отметку где-то чуть выше нейтрального значения. Покорение вершины достигается за счет организованной, целенаправленной и самоотверженной работы руководства и технического персонала. Поскольку большинство конкурентов прово­дят итеративное проектирование на основе создания прототипов, количество необ­ходимых итераций продолжает расти.