У вас маленькая команда, коммуникации налажены ... Для начала сформулируйте ПОЧЕМУ вам нужны именно процессы, ПОЧЕМУ вы хотите вообще что-то улучшить ... что не устраивает в текущей практике работы? С какими проблемами вы сталкиваетесь? Что вы ожидаете от улучшения процессов. Какова ваша текущая практика. Какой софт вы разрабатываете (грубо -- это автоматизация бизнес-процессов или драйвера к "железу", это "одноразовые" проекты на заказ или разработка "коробки"?). Как вы разрабатываете и управляете требованиями, изменениями, конфигурациями ... есть ли у вас проблема с качеством ПО .... ?
Если мы поймем вашу ситуацию, то вполне возможно сможем подсказать вам что-то, что будет полезным.
Спасибо за предложение. Расскажу коротко свою историю - скорее, для того чтобы самому осмыслить сложившуюся ситуацию.
В компании работает 8 человек, из них двое занимаются продажами, остальные шестеро - собственно разработкой софта.
Софт - приложения для POS терминалов (не универсальных кассовых аппаратов, а специализированных терминалов для приёма банковских карт), включая как традиционные финансовые, так и нефинансовые top-up приложения, а также сопутствующие приложения для PC (сервера загрузки параметров, в том числе с обращением к базам данных, межпротокольные конвертеры, конфигураторы и т. п.)
Плюс собственное API для разработки терминальных приложений, которым мы пользуемся сами и которое поставляем своим партнёрам.
Компания развивалась, наверное, по довольно типовому сценарию. Сначала в ней было всего два человека - один занимался продажами, другой (я) писал софт. Постепенно, по мере появления новых проектов, разрастались, набирая сначала только программистов, потом выделяя из них менеджера проектов и аналитика, сравнительно недавно дозрели до того, чтобы взять специального человека на позицию тестировщика (с достаточно широкими обязанностями).
Проблемы, скорее всего, тоже традиционные: требования практически не документированы, концепция основных приложений существует только в голове программистов, тестирование выполнялось самими разработчиками. Это до некоторого времени не создавало проблем, поскольку почти все программисты "вылетели из одного гнезда" (работали раньше в одной компании, которая сейчас свернула разработку ПО в России) и представление о конечных продуктах практически не расходилось даже в мелочах. Да и софт был достаточно простым, пока работал только с картами с магнитной полосой.
Но, конечно, по мере развития основных приложений и открытия новых проектов эти представления расходились всё больше и больше. Сначала обнаружилась необходимость в выполнении различных видов тестирования. Основное приложение состоит из общего ядра, разделяемого всеми вариантами сборки, и "довесков", разрабатываемых для конкретных клиентов. Постепенно пришли к ситуации, что изменения, сделанные по требованию одного клиента, противоречат требованиям другого, и каждый релиз, отправляемый любому клиенту, должен проходить через особую процедуру проверки.
Переход на чиповые стандарты карт сразу изменил статус софта с "достачно простого" на "довольно сложный". Хотя заложенные изначально концепции продолжают работать, но кое-что в архитектуре уже пора серьёзно пересматривать.
Для новых нефинансовых приложений потребовалось проводить проектирование с самого начала, на предыдущий опыт и разделяемое всеми представление в них уже не опереться.
Некоторые инструмены внедрялись постепенно, в хронологическом порядке:
- контроль версий (VSS) - с самого первого дня, без него работы я вообще не представляю;
- управление текущимим задачами (календарное планирование на ближайший месяц) - как только число программистов превысило три. Были перепробованы какие-то открытые средства, MS Project отвергнут по причине громоздкости и неудобства, в конце концов разработал свой движок с веб-интерфейсом, привязав его к базе данных проектов;
- учёт запросов клиентов (баг трекер и запросы на изменения) - изначально вёлся в виде отдельных таблиц Excel, по мере роста количества клиентов пробовали BugZilla (не смогли настроить
![Улыбающийся :)](http://www.uml2.ru/forum/Smileys/classic/smiley.gif)
), MANTIS (слишком громоздкий), потом открыли в интернет трекер опять на основе собственного движка;
- управление тестированием - прошли несколько итераций в выработке шаблонов планов тестирования, сначала в MS Word (невозможно анализировать и собирать статистику, пока не просмотришь весь документ), потом в БД на основе MS Access (неудобный интерфейс, не совместим со стандартным SQL и глючит со страшной силой), вопрос пока остаётся открытым. Используем простые неформальные планы тестирования, а отчёты о результатах помещаем в баг-трекер и в истории проектов;
- учёт требований - что-то записывается в ту же базу данных проектов и периодически используется для подготовки тестов. Но это всё не автоматизировано, о какой-либо полноте требований пока не может быть и речи, никакой трассировки требований и тестов нет. Слова вроде UML и Use Case пока, похоже, знаю только я.
![Улыбающийся :)](http://www.uml2.ru/forum/Smileys/classic/smiley.gif)
Требования меняются постоянно и иногда непредсказуемо. Одно только отслеживание требований основных платёжных систем (MasterCard, VISA и EMV) требует постоянного внимания и временных затрат.
Слишком много проектов уже начато, при этом поддержку старых никто не отменял. В результате приходится отодвигать некоторые работы с более низким приоритетом. Приоритеты, конечно, обсуждаются с руководстовм, но сразу после их согласования "низкоприоритетные" клиенты садятся на телефон и начинают названивать директору. Иногда после этого приоритеты волшебным образом меняются.
![Улыбающийся :)](http://www.uml2.ru/forum/Smileys/classic/smiley.gif)
Несмотря на кажущийся хаос, всё это пока работает. IMHO, работает именно благодаря тесному взаимодействию внутри команды. Сбои, конечно, возникают, но обычно анализируются, придумываются и внедряются способы их устранения.
Некоторые процедуры документированы и используются в реальной жизни, хотя программистов периодически приходится "пинать", чтобы не забывали о некоторых обязательных шагах, которые им кажутся необязательными, особенно во время очередной "запарки". Это пошаговые процедуры выпуска релизов, учёта запросов, отправок, проведения демонстраций и некоторые другие. Кстати, в этих процедурах я использую понятия "входные документы" и "выходные документы", которые вполне укладываются в термин Work Products, но не совсем подходят под artifacts.
До фиксации ролей и их чёткого определения в каждом проекте мы дошли своим умом.
![Улыбающийся :)](http://www.uml2.ru/forum/Smileys/classic/smiley.gif)
Роли у нас в настоящее время такие:
- бизнес-аналитик
- системный аналитик
- программист
- тест-менеджер
- тестировщик
- ответственный за поддержку клиентов
- координатор проекта
- разработчик пользовательской документации (роль есть, но она всегда оказывается совмещённой либо с тех. поддержкой, либо с координатором проекта)
Как мне представляется в настоящий момент, основные проблемы у нас накопились в следующих областях:
0) Нет чёткого долгосрочного планирования. Мы над этим работаем, но это зависит не только и не столько от меня.
1) Не систематизированы выявление и учёт требований. Это ведёт к расплывчатости концепций (приходится устранять частыми обсуждениями уже в процессе кодирования, нередко с переделкой уже готовых компонентов), к трудностям при выборе необходимых тестов и соотвествующим снижением качества продукта.
2) Нет какой-либо единой методологии выработки концепций и разработки архитектуры. Тут мы ходим по граблям: иногда получаем от сэйлзов так называемое "ТЗ", которое они получили от клиента, но забыли согласовать с нами, или когда бизнес-представление не учитывает или противоречит существующим наработкам.
Вот, кстати, только что обсуждал с директором один новый проект и поймал себя на том, что по привычке "размазываю" ознакомление с документацией и разработку архитектуры по этапам реализации отдельных компонентов. Пришлось немного поспорить и выбить ещё десять дней на "подготовку концепции", хоть никто толком и не понял, что это такое.
![Улыбающийся :)](http://www.uml2.ru/forum/Smileys/classic/smiley.gif)
3) Самая болезненная для меня проблема - нехватка ресурсов. Но, как мне кажется, их распределение можно ещё оптимизировать. Много времени тратится впустую именно из-за недостатков в предварительном планировании.
Почему я заинтересовался OpenUp? Он, как мне всё ещё кажется, даёт модель, в рамках которой я, по крайней мере, более-менее представляю дальнейшие шаги по определению необходимых этапов и контрольных точек разработки. И эта модель может быть освоена в сравнительно короткий срок на моём уровне, для неё не нужно проходить дополнительное обучение или приглашать специальных консультантов.