Отправляет email-рассылки с помощью сервиса Sendsay

Разработка проектов и управление командой разработчиков

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Левитас: Больше денег от Вашего бизнеса" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Июль 2004   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
26.07.2004
00:36:42
00:59:44
27
28
29
30
31
Автор
Александр Левитас

Статистика

2.032 подписчиков
-1 за неделю
←   Все выпуски   →

Разработка проектов и управление командой разработчиков


Информационный Канал Subscribe.Ru 
Здравствуйте, уважаемые подписчики!

 

Процесс разработки проекта.

 

Спасибо за письма, которые пришли и приходят от читателей рассылки. Большое спасибо за дельные советы, рекомендации и добрые пожелания.

 

Мне не всегда удается сразу ответить на приходящие письма, поэтому если ответ задерживается, вышлите, пожалуйста, повторное письмо.

 

Некоторые из писем и переписку с читателями, я хотел бы опубликовать в выпусках рассылки. Поэтому, пожалуйста, указывайте в письмах можно ли направлять Ваше письмо в рассылку.

 

Константин Берлинский прислал свою книгу, в которой ему удалось собрать и упорядочить материал из десятка других источников о разработке ПО. Очень рекомендую.

 

Я попросил Константина сделать небольшую презентацию своей книги и самого себя:

Опубликована электронная версия книги "НАБОР СЕРЕБРЯНЫХ ПУЛЬ. Справочник удачных проектных решений при разработке ПО".

 

Книга расположена по адресу: http://www.vbstreets.ru/Projects/NSP_Book/default.aspx

Обсуждение на форуме: http://bbs.vbstreets.ru/viewtopic.php?t=8337

 

Аннотация:

 

Войны ИТ-методологов не затихают. Каждые несколько лет нам преподносится совершенно новая, быстрая,

легкая, простая, эффективная методика (или новая версия "старой"). И уж она наконец-то решит главную

проблему - построение качественного ПО в срок.

 

Я думаю, что правда о методологиях заключается в том, что их не существует-

 

Есть лишь УПР - удачные проектные решения, - которые могут сработать (или нет) в конкретной ситуации

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

ИТ-сообщество к дальнейшему их поиску и классификации-

 

Об себе:

 

Константин Берлинский, разработчик ПО ИТ-отдела компании Maximum, Республика Молдова.

Возраст - 24г./опыт коммерческой разработки ПО - 3г./5 реализованных проектов (автоматизация

документооборота, бухгалтерии, торговых и складских операций).

Профессиональные интересы: разработка КИС, ООП, паттерны, .Net, C#, MS SQL, Remoting, CASE (продукты Rational)

 

Очень рекомендую прочитать эту книгу. Кстати в конце книги приводится список на полезные ресурсы инета. Скажу сразу, что, только начав читать книгу Константина, у меня тут же появилось желание поделиться с автором парочкой полезных ссылок на этот счет.

 

И что самой забавное, оказалось, что все эти и многие другие ссылки уже были приведены в конце книги. Супер!

 

Теперь можно вернуться к процессу разработки проектов.

 

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

 

Но сами по себе эти документы бесполезны, если они не включены в процесс разработки проекта. Спецификации в сторону и с головой в девелопмент.

 

Еще раз повторюсь. Здесь я говорю о разработке средних и крупных проектов, где задействовано от 5-10 человек в девелопменте и срок пол года и больше.

 

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

 

Еще раз. Для команды процесс выпуска программного продукта выглядит немного по-другому, чем для свободного  художника – разработчика.

 

Да, надо сделать еще одну оговорку. Мы в основном занимаемся разработкой не коробочной продукции. Наши проекты переживают новые версии каждые 2-3 недели. Если бы я был строже, то этот период был бы не чаще чем 1 раз в месяц.

 

Но клиенты, есть клиенты, есть рынок и есть конкуренция. И надо быть быстрее и лучше что бы работать с крупными клиентами.

 

Все верно скорость и качество не всегда проходят безболезненно. Но что делать. Сложности лишь помогают выявить слабые звенья в команде и повысить ее профессионализм.

 

В начале своей профессиональной деятельности меня пугали и приводили в оцепенение требования клиентов и настойчивые «просьбы» менеджера продукта решить задачу прямо сейчас и что бы все было гладко.

 

Это еще только вступление такое. Дальше будет веселее, так как задачи мы все таки решали  за то время,  которое нам ставили. И знаете что? Мы находили решения, от которых потом приходили в восторг.

 

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

 

Да и что самое главное, все это способствует развитию проекта и команды, конечно же.

 

Теперь ближе к самому процессу.

 

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

 

В качестве аргумента мне было предложено использовать мировые стандарты. И в качестве такого стандарта был предложен UML в обрезанном виде.

 

Читатель рассылки писал, что с клиентами они рисуют схемы, связи и обсуждают их. И что клиенты довольны и все понимают.

 

Я в начале не мог  понять почему это не будет работать у меня. Так вот это не будет работать для меня по одной простой причине.

 

Наш клиент – это несколько компаний в лице 20 менеджеров, которые оцениваю функционал и вид.

 

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

 

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

 

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

 

А блоки и стрелки, это не картинки. И сколь большим воображением  не обладай, все равно не представишь, как на форме будут расположены элементы управления.

 

Так вот моя функциональная спецификация включает в себя диаграммы, но только как вспомогательные элементы, для видения картины целиком.

 

А дальше? А дальше детали, детали и еще раз детали.

 

Прочитав подход Microsoft по разработке ПО я был восхищен. Стадии, этапы, контроль рисков, выпуск версий и т.д.

 

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

 

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

 

В начале процесса разработки мы собираем требования. Здесь все стандартно. Чем больше информации тем лучше. Главное суметь ее обработать всю и не забыть то, что получили от клиентов. Ведь информация поступает как: через почту, через систему ведения проектов, через личное общение, через документацию, через msn и yahoo ну и еще есть пару способов, о которых лучше не вспоминать.

 

Следующий шаг это первая версия спецификации с копиями пользовательских экранов. А потом еще и еще версия.

 

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

 

Чем больше уточнялась версия, тем больше приходилось уделять времени внешнему виду. Для веб-проектов готовили сразу PSD и вставляли их в спецификацию в обработанном виде.

 

Затем отдавали PSDшники HTML кодеру и готовили презентационные HTML версии.

 

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

 

Поисковики выдали тысячи ссылок. В форумы были отправлены десятки сообщений.

 

Одним из требований было: решение должно быть дешевым или еще хуже бесплатным. И что вы думаете, – мы его нашли.

 

Волшебные три буквы нас выручили.  Ничего вульгарного. CVS – система контроля версий файлов. Она была известной, широко поддерживаемой и бесплатной.

 

С налету разобраться не удалось. Опять в инет и ищу специалиста, что бы автоматизировать работу. И нашелся один такой «товарищ», который не поленился позвонить и сказать, что надо с системой самостоятельно разбираться.

 

Я был немого в шоке, но потом благодарности этому парню не было предела. Как оказалось надо знать тонкости, что бы успешно применять CVS.

 

Весь проект положили в CVS, и осталось замкнуть процесс отсылкой уведомлений и настройкой прав.

 

Уведомления пришлось отправлять через Outlook и через Linux. CVS мы поставили на Windows и поэтому никто не хотел замарачиваться с настройкой рассылок под эту операционку.

 

В итоге со спецификациями процесс получился такой. Спецификация обновляется и прямо в документе указывается дата внесения изменения, и что было изменено. Затем она  выкладывается в CVS и народ получает уведомления определенного образца. В уведомлении указывается имя спецификации, дата обновления, версия и список изменений. Мда. Все, в общем-то, просто.

 

Идем дальше. Дальше уже начинается разработка самого проекта и БД.

 

С уважением,

Сергей

prj_management@list.ru

 

 

http://subscribe.ru/
E-mail: ask@subscribe.ru		 Адрес подписки
 Отписаться
В избранное