Что нужно сделать при старте нового проекта?

Прочитал статью Титова А.А. «Двадцать основных принципов, без которых нельзя обойтись при создании надёжного программного обеспечения». Появились такие выводы:

1.      Статья носит декларативный, а не процедурный характер.

2.      Сведения, изложенные в статье, известны и преподаются в любом вузе, обучающем специальности «программное обеспечение вычислительной техники и автоматизированных систем».

3.      Проблемы с внедрением процессов разработки ПО связаны не с тем, что люди не знают, ЧТО нужно делать. Они связаны с тем, что люди не понимают, КАК это нужно делать.

4.      Чтобы статья была полезной, она должна содержать методики и конкретные примеры применения изложенного в статье материала. Иными словами, статья должна отвечать на вопрос «КАК», а не «ЧТО».

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



Планирование

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

На этапе планирования необходимо:

1.      Выбрать компилятор и среду разработки.

2.      Выбрать программу для распределённой компиляции (например, Incredibuild).

3.      Выбрать инструментарий для автоматизации сборки. Например:

3.1.   Make

3.2.   NAnt

3.3.   Batch-файлы и питоновские скрипты.

3.4.   И т.д.

4.      Выбрать систему контроля версий.

4.1.   Perforce.

4.2.   SVN.

4.3.   Git.

4.4.   CVS.

4.5.   И т.д.

5.      Организовать «рабочее пространство» в системе контроля версий:

5.1.   Определить, где будет лежать рабочая ветка проекта.

5.2.   Определить, где будут лежать бранчи майлстоунов.

5.3.   Связать систему автоматической сборки и тестирования с системой контроля версий.

6.      Выбрать систему контроля задач и баг-трекер. Например:

6.1.   JIRA.

6.2.   Redmine.

6.3.   DevTrack.

6.4.   Hansoft.

6.5.   Bugzilla.

6.6.   И т.д.

7.      Выбрать инструмент для ревью кода (например, Code Collaborator).

8.      Выбрать инструменты для создания документации. Например:

8.1.   Microsoft Office.

8.2.   Google Docs.

8.3.   Microsoft Visio.

8.4.   SmartDraw.

9.      Создать группы e-mail рассылок:

9.1.   для всего проекта;

9.2.   для инженеров;

9.3.   для менеджеров и лидов;

9.4.   для QA.

9.5.   для дизайнеров и художников;

9.6.   и т.д.

10.  Выбрать почтовую программу (e-mail клиента).

10.1.                   MS Outlook.

10.2.                   Thunderbird.

10.3.                   Gmail.

11.  Создать график проекта с указанием майлстоунов.

Например, здесь показывается, как такой график можно «нарисовать» при помощи Excel.

12.  Создать организационную диаграмму проекта и список контактов.

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

Список контактов нужен для того, чтобы в случае необходимости не искать мобильный телефон сотрудника, а иметь его всегда под рукой.

13.  Выбрать программу и место хранения рабочей документации:

13.1.                   Система контроля версий.

13.2.                   Sharepoint.

13.3.                   Папка на файл-сервере.

13.4.                   Google Drive.

14.  Организовать рабочее пространство для рабочей документации. Например, можно завести подпапки для каждой дисциплины:

14.1.                   для продюсеров и гейм-дизайнеров;

14.2.                   для инженеров;

14.3.                   для менеджеров;

14.4.                   для QA.

Создание качественных требований

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

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

1.      В существующий экран с таблицей нужно добавить в таблицу ещё одну строку. Если сделать это «в лоб», то таблица на экране будет выглядеть некрасиво – станет слишком высокой, будет неправильно выровнена по вертикали. Как лучше её разместить на экране?

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

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

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

Что это означает? Это означает, что гейм-дизайнер должен описать:

1.      Как игрок начинает новую игру? Какие шаги он совершает? Какие экраны будут представлять эти шаги?

2.      Как игрок продолжает уже начатую игру? Какие шаги совершает? Какие экраны будут показываться?

3.      Какие действия игрок совершает входе одиночной битвы (гонки, матча и т.п.)? Какие решения принимает? В каком порядке?

4.      Каков механизм прогрессии во всей игре? Что игрок прокачивает – отдельного персонажа, команду? Как одиночные битвы (гонки, матчи и т.п.) складываются в целую игру?

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

Таким образом, индустрии нужны не просто светлые призывы «пишите требования» и «пишите требования правильно», а рабочие методики того, как это делать.