Test Driven Design
WildMaN 7 апреля 2008 Комментариев: 5
Внедряя на текущем проекте систему измерения и улучшения производительности, одним из элементов стал TDD - test driven development и design в частности. Скажу честно - я думал, что я хороший дизайнер 
Но, переписывая свою документацию под TDD, получил левелап в дизайне.
Наш подход к TDD - это итеративный agile дизайн, с планированием а) геймплейно тестируемых фич, б) разработкой интерфейса параллельно фичам геймплея, и в) по фазам разработки менее недели. Реализуем core mechanics, а дальше оборачиваем ее дополнительными проверками и рюшечками.
С точки зрения дизайна такой подход потребовал две вещи. Простая - это очень тщательное документирование критериев достижения результата. По каким тестам можно сказать, что фича закончена. Сложная - это разбиение фичи на core и дополнительный функционал, где требуется от идеи “а вот круто было бы сделать так” перейти к пути “от простого к сложному”. Левелап, собственно, был на этом этапе. Раньше я описывал в дизайне фичи подробно и все-все-все, и считал это правильным дизайном. Сейчас учусь описывать части, сначала ядро, потом важный, но не ключевой функционал, потом все остальное, что было бы неплохо реализовать.
Бонус в совмещении позиции лид дизайнера и руководителя проекта, конечно, помогает - можно сразу адаптировать уже существующий agile процесс под новый подход. Выделение ядра функционала позволило раза в два сократить время отдельной задачи на итерацию. Может парадоксально, но в результате спринт мы планируем не уменьшить соответственно, а увеличить до месяца. Поскольку детализация и точная постановка задач требуют меньше коммуникации “по итогам”, обсуждений где мы налажали и что надо исправить.
PS. Еще TDD дает +5 к репутации с программистами, они любят четкие критерии
Комментариев: 5
