>>А как разрабатывается общая «архитектура» (структура) разрабатываемого приложения?
Тут есть несколько случаев.
1. архитектура предопределена. Это случай так называемого расширения удаленной команды (team extension). Т.е. есть выделенный архитектор снаружи который все уже нарисовал или рисует архитектуру.
2. архитектура стандартная. Например заказчик хочет получить несложный динамический сайт. Тогда архитектура диктуется фреймворком — Rails для Ruby, Spring для J2EE и т.д. В этом случае в команде все должны понимать термины фреймворка (Entity, DTO, Relation… ) и говорить на одинаковом языке.
3. случай, который наверное Вас наиболее интересует. Например нужно создать и подключить нативный модуль. Или синтегрироваться с неколькими ванешними системами. В этом случае у нас назначается Архитектор в команде, который принимает решения.
В общем процесс коротко трудно описать, но при построении архитектуры мы используем простые и хорошо себя зарекомендовавшие подходы — слоистый паттерн, шина, веб сервисы для интеграции с нами, модуль протоколов для интеграции с внешними системами, шаблон интерпретатора если система будет в каком-то плане интенсивно препрограммироваться или обучаться.
Специально для создания и вникания остальных людей в архитектуру у нас в начале каждой фазы идет Архитектурная Итерация. Она не имеет или имеет мало функциональной нагрузки. Ее задача — создать общий каркас для последующей работы команды.
>>просто вот я замечаю, что довольно трудно передать понимание даже через прямое общение
Да это верное наблюдение. Передать картину из одного мозга в другой — пожалуй цивилизационная проблема. Ее можно решать например Моделингом (UML и т.д.) но у нс не прижилось. Пробуем объясняться словами, жестами, рисунками и какакулями на доске :).
Steps:
1. Verify that there is a breadcrumb component which contain chainlet of subcategories for which was selected comparative dataset view.
Click on first segment of breadcrumb(category name) and verify that you was redirected to category view page
2. Click on second segment of breadcrumb(subcategory name) and verify that you was redirected to subcategory view page
… обрезано…
Author:
Ivan Petrov
Pass/Fails:
Pass
Remarks:
— Эти тест кейсы смотрит и подтверждает Product Owner.
Впоследствии они используются в процедуре «обрубания хвостов»
Мы используем Bugzilla для спецификации багов, Google Docs для Test Cases, *наш инструмент* все связывает между собой. Он показывает итерационный Гантт с прогрессами задач собранными из микроблогов. Баги на этом Гантте показаны только их именами, во втором бэклоге, со ссылкой на Bugzilla.
У нас в команде была задача в этой области. Необходимо было построить интерактивный Гантт. Т.е. чтобы пользователь мог, скажем, увеличить длительность или передвинуть задачи. Интересно что режим редактирования на порядок сложнее режима отображения. При рендеренге как правило поступают уже готовые старты-финиши-связи задач. При редактировании нередко приходится пересчитывать весь Гантт в результате только одной операции. 4 типа связей между задачами добавляют ошибки и зацикливание, растягивается баг-фикинг.
В то время мы решили, естественно, разрабатывать этот кусок функционала самостоятельно и в результате заказчику наша реализация обошлась в сопоставимую сумму.
Хотя я конечно согласен что с ценообразованием ребята погорячились. Можно было спокойно цену уменьшить раз в 10 — рост покупателей принес бы им в результате больше.
Очень хороший подход. Business domain хорошо известен аудитории. Все студенты готовы к построению объектной модели.
На мой взгляд этот пример стоит проходить в 2 итерации. Первая итерация — как Вами описана. Вторая — с добавлением *Требований* и критериев качества к будущей объектной модели.
Требования позволят не распыляться на все возможные процессы, протекающие в кинотеатре. А сосредоточиться на небольшом их подмножестве. Кроме того можно будет сравнивать между собой модели предложенные отдельными студентами или их группами.
Требования можно описывать в виде коротких User Stories:
— Пользователь имеет возможность начать игру на автомате. Для этого он должен вложить в него жетон.
— Пользователь имеет возможность разменять монеты для получения жетонов.
и т.д.
Для сравнения объектных моделей которые получают студенты можно воспользоваться критерием(ями) оценки. Например та модель лучше, в которой меньше классов.
какакулями на доске
->
каракулями на доске
:)
Тут есть несколько случаев.
1. архитектура предопределена. Это случай так называемого расширения удаленной команды (team extension). Т.е. есть выделенный архитектор снаружи который все уже нарисовал или рисует архитектуру.
2. архитектура стандартная. Например заказчик хочет получить несложный динамический сайт. Тогда архитектура диктуется фреймворком — Rails для Ruby, Spring для J2EE и т.д. В этом случае в команде все должны понимать термины фреймворка (Entity, DTO, Relation… ) и говорить на одинаковом языке.
3. случай, который наверное Вас наиболее интересует. Например нужно создать и подключить нативный модуль. Или синтегрироваться с неколькими ванешними системами. В этом случае у нас назначается Архитектор в команде, который принимает решения.
В общем процесс коротко трудно описать, но при построении архитектуры мы используем простые и хорошо себя зарекомендовавшие подходы — слоистый паттерн, шина, веб сервисы для интеграции с нами, модуль протоколов для интеграции с внешними системами, шаблон интерпретатора если система будет в каком-то плане интенсивно препрограммироваться или обучаться.
Специально для создания и вникания остальных людей в архитектуру у нас в начале каждой фазы идет Архитектурная Итерация. Она не имеет или имеет мало функциональной нагрузки. Ее задача — создать общий каркас для последующей работы команды.
>>просто вот я замечаю, что довольно трудно передать понимание даже через прямое общение
Да это верное наблюдение. Передать картину из одного мозга в другой — пожалуй цивилизационная проблема. Ее можно решать например Моделингом (UML и т.д.) но у нс не прижилось. Пробуем объясняться словами, жестами, рисунками и какакулями на доске :).
Если команда распределенная — то Skype, все инструменты Web based…
Таблица в Google Spreadsheet
ID | Description | Steps | Author | Pass/Fail | Remarks
Заполняется QA инженером. Пример:
ID:
2
Description:
Breadcrumb
Steps:
1. Verify that there is a breadcrumb component which contain chainlet of subcategories for which was selected comparative dataset view.
Click on first segment of breadcrumb(category name) and verify that you was redirected to category view page
2. Click on second segment of breadcrumb(subcategory name) and verify that you was redirected to subcategory view page
… обрезано…
Author:
Ivan Petrov
Pass/Fails:
Pass
Remarks:
— Эти тест кейсы смотрит и подтверждает Product Owner.
Впоследствии они используются в процедуре «обрубания хвостов»
В то время мы решили, естественно, разрабатывать этот кусок функционала самостоятельно и в результате заказчику наша реализация обошлась в сопоставимую сумму.
Хотя я конечно согласен что с ценообразованием ребята погорячились. Можно было спокойно цену уменьшить раз в 10 — рост покупателей принес бы им в результате больше.
На мой взгляд этот пример стоит проходить в 2 итерации. Первая итерация — как Вами описана. Вторая — с добавлением *Требований* и критериев качества к будущей объектной модели.
Требования позволят не распыляться на все возможные процессы, протекающие в кинотеатре. А сосредоточиться на небольшом их подмножестве. Кроме того можно будет сравнивать между собой модели предложенные отдельными студентами или их группами.
Требования можно описывать в виде коротких User Stories:
— Пользователь имеет возможность начать игру на автомате. Для этого он должен вложить в него жетон.
— Пользователь имеет возможность разменять монеты для получения жетонов.
и т.д.
Для сравнения объектных моделей которые получают студенты можно воспользоваться критерием(ями) оценки. Например та модель лучше, в которой меньше классов.