Команда, это гораздо больше, чем группа людей, назначенных на проект. В эффективную команде подбираются люди, соответственно работе, которую они будут делать и несут ответственность за результаты в своей части. Наличие четко обозначенного участка работы и соответствие его способностям человека повышают результаты и устраняют препятствия к высоким достижениям.
Наличие эффективной модели команды позволяет достичь следующего:
Предлагаемый состав команды (все учащиеся распределены заранее по результатам их предыдущего обучения)
Это модель команды сотрудников, работающих независимо для достижения общей цели. Каждый участник команды играет свою особенную роль и участок работы, вклад каждого имеет значение. Такой подход вызывает чувство ответственности за свою работу, что в результате дает более качественный программный продукт.
Учится организовывать взаимодействие, обучение, отдых. Узнает требование у "заказчика", добывает вспомогательную информацию. Разрабатывает требования к программе, планирует функциональность. Прорабатывает способы использования программы и показывает границы возможного "заказчику", чтобы проект не обманул ожиданий. Решает спорные вопросы (одно из решений - обратиться ко мне). Его оценка напрямую зависит от успеха команды в целом.
Отвечает за подготовку документации к программе (встроенной помощи, руководства пользователя, руководства по установке, сайта программы, если таковой будет), проводит представления программы. Кроме того, решает, каким будет внешний дизайн программы. Ее (или его) решения по дизайну является окончательным и может быть изменено только организатором.
Кроме того, обучает пользователя работе с программой (разрабатывает план обучения), старается сделать программу более простой для использования и понимания.
Реализует встроенную помощь, программу инсталляции (или пользуется встроенной), другие вспомогательные утилиты, если надо (например, решает вопросы автоматического обновления предыдущей версии). Разрабатывает сценарий тестирования программы.
Реализует логическую часть программы (объектную модель, среднее звено трехзвенки, ...).
Реализует сохранение объектов логической модели, взаимодействие с другими приложениями (в частности с программой конкурирующей команды).
программист пользовательского интерфейса
Реализует формы и отчеты :)
Ищет ошибки в программе и несоответствия в документации. Отвечает за соответствие программы требованиям к ней. Принимает решение о допуске или не допуске программы к "производству" (демонстрации).
Принимает критические решения, необходимые для создания качественного продукта в нужное время. Координирует решения для соответствия их стандартам и требованиям по взаимодействию с другими программами. Отвечает за взаимодействие частей программы, планирование времени реализации, устранение найденных ошибок.
Кто разрабатывает что-либо, тот и отвечает.
Если кто-либо не согласен с мнением участника, отвечающего за данную часть работы (например, кто-либо не согласен с организатором), то можно обратиться ко мне. Конфликты, которые не улаживаются сами мирным путем и доходят до меня, буду решать я, однако на рейтинг команды это будет влиять отрицательно.
Инструмент не может быть для разных задач одновременно эффективным и универсальным. Для каждой задачи выбирают подходящий инструмент, например ткань - режут ножницами, а деревья - рубят топором.
В качестве средства реализации мной выбрана платформа .NET, так как в ней есть, сборка мусора, среда разработки программ, библиотеки для создания форм и доступа к данным. Кроме того, C# проще в изучении, чем C++ и похож на Java.
Почему не Java? Потому что пока ее поддержка инструментальными средствами оставляет желать лучшего.
Почему не Delphi? Я не знаю, есть ли в нем автоматическая сборка мусора (в последней версии, с которой я работал, пятой - не было). Это очень важно, т.к. сильно упрощает программирование.
Проект будет построен по спиральному циклу (еще бывает "модель водопада"). Режим итеративного развития снижает риск провала проекта.
В конце триместра к защите должна быть представлена разработанная, документированная и полностью функционирующая система. В следующем триместре должны быть проанализированы пожелания и замечания, учтены преимущества продукта "конкурента" и реализована следующая версия программы.
Рекомендуется использовать план с "вехами", ориентируясь на поставленные задачи и имеющееся время.
Рекомендуется выделить четыре этапа: Создание образа, планирование, разработка и отладка. Каждый этап должен иметь четко обозначенную дату окончания. К этой дате должны быть оформлены результаты этапа.
Наличие первого этапа позволяет отвлечься от сиюминутных задач и охватить работу в целом. Создание набора требований к программе заканчивается утверждением их "заказчиком". Требования менее важны, чем создание общего образа продукта
Планирование определяет что, когда, кем и каким способом будет сделано. Этап заканчивается вехой "план одобрен". В плане предпочтение должно быть отдано срокам, установленным "заказчиком", а не тому, как хочется команде. Каждая веха - это возможность уточнить пожелания заказчика к программе.
Разработка заканчивается вехой "функции реализованы".
Стадия стабилизации заканчивается вехой "программа готова к 'производству'". Предпочтение следует отдать постепенному увеличению функциональности. Как правило, используется более качественный продукт, хоть и с меньшим количеством функций. Захваченный "рынок" тяжело отвоевывать ;)
Планирование с вехами позволяет принимать более качественные решения, приводит к меньшему количеству переделок (которые потеря времени) и к созданию более качественного продукта. Кроме того, оно уменьшает риск срыва проекта.
Программа должна быть построена по модульному принципу
Здесь программа 1 - это например программа для составления расписания, программа 2 - это программа для учета учеников (куда поступили выпускники и т.п.)
На этом же рисунке можно рассмотреть части системы.
Гладко это на бумаге, кто покажет мне овраги?