В нашем вузе принято на специальности программирование делать выпускные проекты. Большим плюсом считается, если «на выходе» есть прототип программного продукта. Студенты, которые занимались проектами в университете, позже занимают ключевые позиции в ИТ компаниях города и страны.

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

Начало работы

С чего все началось. Некоторые студенты изъявили желание выучить предмет «Веб-программирование» более углубленно. Причем отличительной чертой этих студентов была мотивация.

Сам курс включает 2 больших раздела и несколько вспомогательных:

• программирование клиентской части (разметка (html, xhtml, html5), стили (CSS), клиентское программирование(Javasricpt+Libraries),
• серверное программирование: (PHP5, ООП, основы баз данных (MySql), Frameworks)
• сопровождение (публикация на сервер, настройка серверов и тд).

Углубление было по вышеуказанным темам, расширение за счет изучения основ ведения проектов (redmine, git, wiki, documentation)

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

Выбор остановился на двух вариантах: сделать аналог redmine или систему управления задачами. Поскольку время было ограничено (я планировал около 3-х месяцев), то выбор очевидно падал на второй вариант. На мой взгляд, выбор был сделан правильно.

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

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

О проекте концептуально

Системы управления задачами – одна из классических тем для начальной разработки. Все что было сделано, уже было сделано до нас. Я сам являюсь приверженцем систем типа GTD, с удовольствием пользуюсь сервисами типа Remember the milk или Пинарик. Но, все-таки, когда пользуешься системами, всегда что-то можно улучшить.

Системы управления задачами делятся на 2 большие категории: управление списками и ежедневники (управление задачами на день). Remember the milk — пример сервиса, ориентированного на работу со списками, пинарик – на работу с днями. Конечно есть пересечения, но тип можно выделить однозначно.

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

Я пользовался различными системами, и понимал, чего мне бы хотелось на самом деле.

Начнем с определения типов задач

Типы задач

Обычная задача

Такая задача привязана к дню, но не привязана ко времени. Обычно время ее выполнения несущественно.
Примеры:

1. В субботу сходим в зоопарк.
2. В среду записаться в спортзал.
3. Сегодня подписать документы у руководителя.

Задача с привязкой к времени

Такая задача привязана как к дню, так и ко времени. Осуществление ее не вовремя может привести к срыву задачи.
Примеры:

1. В 2 часа совещание.
2. Сходить в кино на 20:00
3. Свидание на 5:15
4. Послушать новости в 5 часов вечера

Задачами такого типа оперируют календари.

Повторяющиеся задачи

Такие задачи повторяются с некоторой периодичностью. Они могут быть как привязаны к времени, так и нет. Совокупность повторяющихся задач образуют серию.
Примеры:

1. Каждый понедельник, среда, пятница 19:00 — спортзал
2. По пятницам баня с друзьями
3. Раз в шесть месяцев сделать ТО.

Типизация по приоритету и по продолжительности

Приоритеты

Любая задача из 4 вышеперечисленных типов может иметь приоритеты. Будем выделять приоритеты нормальный и высокий.

Продолжительность

Любую задачу из “Обычная задача” или “Задача с привязкой по времени” или “Повторяющаяся задача” можно отметить как continued. Смысл такой отметки в том, что задача начинает показываться раньше времени, чтобы не пропустить. Дата (и время) такой задачи служат для обозначения крайнего срока (deadline).
Примеры:

1. Написать статью к 20 ноября.
2. Подготовить документы к 12:00 17 числа
3. Подготовить доклад к понедельнику
4. Собраться к поездке на выходных

Дополнительные типы

Задача на будущее

Такие задачи не привязаны к дню и ко времени. Они позже переходят в задачи уровня “Обычная задача” или “Задача с привязкой по времени”, или уточняются.
Примеры:

1. Поехать в Крым
2. Написать статью о крылатых
3. Купить второй магазин
4. Заказать визитки

Просроченные задачи

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

Выполненные задачи

Задачи с пометкой “Выполнено”

Вот, в принципе, и все о типах задач. Они полностью охватывают наши потребности в планировании.

Операции над задачами

Конечно, задачи меняют свое состояние.

Опишу только основные:

• Пометить задачу как выполненнуюневыполненную
• Отредактировать задачу
• Поменять приоритет
• Поменять порядок задач
• Перенести задачу на другой день
• Перенести задачу в другой список

Организация процесса

Проект велся по Agile методологии, итерации были по 1-2 недели, в зависимости от задач. В основном 2 недели. На итерацию выносились наиболее актуальные в данный момент задачи.

Как багтрекер использовался redmine, git – система контроля версий, документация – в вики.

Интерфейс

При проектировании интерфейса основным принципом был принцип KISS. После книг Айзексона и Купера проникаешься пониманием важности классного и хорошо спроектированного интерфейса без излишеств.

Минимум настроек, максимальная интуитивная понятность, минимализм в дизайне – вот к чему стремились.

Примерами были ранний твиттер и современный Gmail.

На будущее – аккуратно вписать в существующий интерфейс остальные функции, чтобы не усложнить его.

Пара мокапов для демонстрации улучшений интерфейса.

Первая версия:

Последняя версия:

Дизайн

Дизайн был минимальный, основанный на возможностях twiiter bootstrap с небольшими доработками.

Пример исходных файлов от дизайнера:

Как это выглядит в конечном варианте (мокап с дизайном, скриншот с сайта):

Технологии

Хвала Богам, сейчас в свободном доступе есть все под рукой, причем опенсурс продукты не уступают проприетарным.

В проекте были задействованы следующие технологии и инструменты.

• Верстка — HTML5, twitter bootstrap.
• Клиентское приложение – Javascript, Jquery, twitter bootstrap plugins.
• Серверное программирование PHP5, CakePHP.
• База данных – MySql.
• Внешняя система идентификации – Loginza
• Captcha — ReCapthca.

На будущее – дописатьпереписать JS application с использованием фрейморка, например backbone.js.

Прочие задачи

На такие задачи, как дизайн, тексты привлекались знакомые и товарищи студентов.

Качество

Отдельно тестировщиков не было, поэтому тестировали «перекрестно». Часть кода покрыты UnitTests. Позже планируется покрыть полностью все значимые участки кода.

Ревью кода я делал постоянно, на CakePHP там все красиво, в JS относительно, после использования backbone.js все будет на порядок лучше.

Текущее состояние

Сейчас проект находится в публичной альфе. Реализована минимально необходимая функциональность (и только часть от всех типов задач). Часть функций (например мобильная версия) «закомментирована» перед публикацией из-за того, что есть баги и недоработки.

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

Следить за развитием можно на сайте проекта www.prettytasks.com ^[1]

Выводы

Этот проект – проба пера, как делать проект (не прототип) в условиях обучения студентов. В основном при разработке прототипов остаются без внимания такие моменты, как: качество, процессы разработки, документация, публикация, оптимизация, тексты и тд. Процессы в командах студентов тоже часто строятся хаотически.

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

То есть как минимум получили уровень junior developer (на мой взгляд даже выше).

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

По ведению проектов можно сделать следующие выводы.

1. В большинстве своем при работе в команде даже студенты старших курсов не готовы заниматься управлением проектами. Причин много, от недостаточной квалификации и недостатка времени, до простой недисциплинированности и молодости. Такие проекты со временем превращаются в зомби, вроде все «типа» готово, но пользоваться невозможно. Очень хорошо, если проект будет вести знающий и заинтересованный человек.
2. В основном в учебных проектах делают параллельно разработку требований и программирование. Очень важно иметь хорошо расписанные требования к началу программирования. И снова, как показывает практика, студенты не очень справляются с этой задачей. Или же использовать agile подход, но тогда должен быть хороший и главное доступный product owner.
3. Как показывает практика, основной проблемой больших учебных проектов (этот проект весьма небольшой) является преемственность работы. Выпускники уходят, и знания о проекте уходят вместе с ними, а часто и код. Поэтому документация, во всех смыслах этого слова, очень важна. К сожалению, только около 5-10% студентов используют системы контроля версий (хотя в последнее время эта цифра растет). Документацию же практически не пишет никто. Поэтому важнейшей задачей организации учебных проектов является именно организация сохранения знаний о проекте в «письменном» виде.
4. Перед началом работы очень желательно достаточно точно оценивать объем проекта, чтобы браться только за те, которые можно довести до конца за отпущенное время.

Ну и наконец, общий вывод: учебные проекты – это очень полезный инструмент формирования профессиональной компетентности будущих программистов.

Автор: krugvs