Просмотр сообщений
631
RUP EUP AUP OpenUP / Re: Создание русскоязычной версии и развитие процесса OpenUP/Basic
« : 17 Августа 2007, 00:19:22 »Софт - приложения для POS терминалов (не универсальных кассовых аппаратов, а специализированных терминалов для приёма банковских карт), включая как традиционные финансовые, так и нефинансовые top-up приложения, а также сопутствующие приложения для PC (сервера загрузки параметров, в том числе с обращением к базам данных, межпротокольные конвертеры, конфигураторы и т. п.)
Плюс собственное API для разработки терминальных приложений, которым мы пользуемся сами и которое поставляем своим партнёрам.
Пока не понял, нужны ли вам те же юзкейсы, о которых вы упоминаете ниже ... думаю вам вполне подойдет отмодифицированные user stories, или просто неформализированные сценарии. Но боюсь, что управлять ими придется с использованием инструментария RDM или как минимум wiki.
Проблемы, скорее всего, тоже традиционные: требования практически не документированы, концепция основных приложений существует только в голове программистов, тестирование выполнялось самими разработчиками. Это до некоторого времени не создавало проблем, поскольку почти все программисты "вылетели из одного гнезда" (работали раньше в одной компании, которая сейчас свернула разработку ПО в России) и представление о конечных продуктах практически не расходилось даже в мелочах. Да и софт был достаточно простым, пока работал только с картами с магнитной полосой.
Вот проблемы уже обозначили, и понятно в какую сторону бежать ... для начала наведите порядок с требованиями и их изменениями ... учитывайте их как минимум. Потом трассируйте их на тесты и технические решения.
Но, конечно, по мере развития основных приложений и открытия новых проектов эти представления расходились всё больше и больше. Сначала обнаружилась необходимость в выполнении различных видов тестирования. Основное приложение состоит из общего ядра, разделяемого всеми вариантами сборки, и "довесков", разрабатываемых для конкретных клиентов. Постепенно пришли к ситуации, что изменения, сделанные по требованию одного клиента, противоречат требованиям другого, и каждый релиз, отправляемый любому клиенту, должен проходить через особую процедуру проверки.
Управление конфигурациями и изменениями .... самое оно. Иметь CCB и регламент внесения изменений.
Переход на чиповые стандарты карт сразу изменил статус софта с "достачно простого" на "довольно сложный". Хотя заложенные изначально концепции продолжают работать, но кое-что в архитектуре уже пора серьёзно пересматривать.
Нужно уделять время на синхронизацию виденья архитектуры всеми "петрящими" в этом членами команды .. .т.е. как минимум разработчиками. Управляемые коммуникации это ваше ВСЕ ... :-).
Некоторые инструмены внедрялись постепенно, в хронологическом порядке:
- контроль версий (VSS) - с самого первого дня, без него работы я вообще не представляю;
Можно использовать бесплатный SVN ...
- управление текущимим задачами (календарное планирование на ближайший месяц) - как только число программистов превысило три. Были перепробованы какие-то открытые средства, MS Project отвергнут по причине громоздкости и неудобства, в конце концов разработал свой движок с веб-интерфейсом, привязав его к базе данных проектов;
Думаю вас бы вполне могла устроить Jira для этих целей, настроить только соответствующим образом.
- учёт запросов клиентов (баг трекер и запросы на изменения) - изначально вёлся в виде отдельных таблиц Excel, по мере роста количества клиентов пробовали BugZilla (не смогли настроить), MANTIS (слишком громоздкий), потом открыли в интернет трекер опять на основе собственного движка;
Jira рулит.
- управление тестированием - прошли несколько итераций в выработке шаблонов планов тестирования, сначала в MS Word (невозможно анализировать и собирать статистику, пока не просмотришь весь документ), потом в БД на основе MS Access (неудобный интерфейс, не совместим со стандартным SQL и глючит со страшной силой), вопрос пока остаётся открытым. Используем простые неформальные планы тестирования, а отчёты о результатах помещаем в баг-трекер и в истории проектов;
можно хранить тест-кейсы в wiki или в инструментарии RDM.
- учёт требований - что-то записывается в ту же базу данных проектов и периодически используется для подготовки тестов. Но это всё не автоматизировано, о какой-либо полноте требований пока не может быть и речи, никакой трассировки требований и тестов нет. Слова вроде UML и Use Case пока, похоже, знаю только я.
Как я говорил выше, не факт что UC вам нужны ... а вот инструментарий для работы с требованиями пригодился бы.
Требования меняются постоянно и иногда непредсказуемо. Одно только отслеживание требований основных платёжных систем (MasterCard, VISA и EMV) требует постоянного внимания и временных затрат.
Jira + RDM tools рулят (плюс регламент ессесно ... )...
Слишком много проектов уже начато, при этом поддержку старых никто не отменял. В результате приходится отодвигать некоторые работы с более низким приоритетом. Приоритеты, конечно, обсуждаются с руководстовм, но сразу после их согласования "низкоприоритетные" клиенты садятся на телефон и начинают названивать директору. Иногда после этого приоритеты волшебным образом меняются.
Product Manager и Project Manager должны быть как класс ... роли я имею ввиду. Которые и должны отстаивать договоренности по приоритетам .... критерий можно взять один -- "кто больше платит того и тапки" :-)
Несмотря на кажущийся хаос, всё это пока работает. IMHO, работает именно благодаря тесному взаимодействию внутри команды. Сбои, конечно, возникают, но обычно анализируются, придумываются и внедряются способы их устранения.
Ну пока хаос только кажущийся ...
Как мне представляется в настоящий момент, основные проблемы у нас накопились в следующих областях:
0) Нет чёткого долгосрочного планирования. Мы над этим работаем, но это зависит не только и не столько от меня.
Долгосрочное планирование в вашей ситуации бесконечных и непредсказуемых изменений ... хм ... только если "внутренние" проекты, по переходу например на другие библиотеки, средства разработки, изменение архитектуры и т.п.
1) Не систематизированы выявление и учёт требований. Это ведёт к расплывчатости концепций (приходится устранять частыми обсуждениями уже в процессе кодирования, нередко с переделкой уже готовых компонентов), к трудностям при выборе необходимых тестов и соотвествующим снижением качества продукта.
Работайте над этим ... вобщем все больше убеждаюсь что вам нужно смотреть в сторону Scrum а не на UP.
2) Нет какой-либо единой методологии выработки концепций и разработки архитектуры. Тут мы ходим по граблям: иногда получаем от сэйлзов так называемое "ТЗ", которое они получили от клиента, но забыли согласовать с нами, или когда бизнес-представление не учитывает или противоречит существующим наработкам.
Srum митинги, причем с участием сейлов, чтобы тоже варились в этой каше .... и управляемые коммуникации .. это ваше ВСЕ.
3) Самая болезненная для меня проблема - нехватка ресурсов. Но, как мне кажется, их распределение можно ещё оптимизировать. Много времени тратится впустую именно из-за недостатков в предварительном планировании.
Сбрасываете простую рутину на студентов, если есть простая рутина и студенты, и время их ввести в курс дела :-).
Почему я заинтересовался OpenUp? Он, как мне всё ещё кажется, даёт модель, в рамках которой я, по крайней мере, более-менее представляю дальнейшие шаги по определению необходимых этапов и контрольных точек разработки. И эта модель может быть освоена в сравнительно короткий срок на моём уровне, для неё не нужно проходить дополнительное обучение или приглашать специальных консультантов.
Scrum для вас самое оно ... а консультанта по нему лучше таки пригласить -- дешевле выйдет, если консультант толковый. Но приглашать только когда сами поймете что такое Scrum .... если что - могу подсобить с консультантом :-).
