Сегодня хочу поделиться своим опытом по руководству командой девелоперов над разработкой одной небольшенькой системы учета. Система проектировалась на базе Microsoft SQL Server 2005 с клиентским приложением на NET 2.0 (C#).
Если честно, я немного побаивался этого проекта, ведь руководить людьми мне тогда предстояло впервые. Начитавшись умных книжек про управление командой и прочий менеджмент, я привел свои знания в еще большую кашу.
Посему решено было применить принцип - Разделяй и Властвуй! в структуре приложения. Девелоперов было три, посему обычная система учета была разбита на 3 слоя: слой работы с данными, слой бизнес-логики и интерфейс. Классическая 3-tier application architecture.
Я сделал архитектуру всех необходимых классов, начиная от базовой формы интерфейса и заканчивая прототипами методов бизнес-логики. Труд творческий, но я решил сделать это сам, чтобы иметь представление обо всех участках проекта и структуре взаимодействия компонентов в нем. Плюс, вся оптимизация SQL кода была тоже на мне.
Что получилось в итоге? Все плюсы 3-tier application architecture были на моей стороне - независимость действий кодеров, заранее спланированное взаимодействие между ними, возможность распределить обязанности по квалификации программистов. И самое главное - возможность оценить готовность проекта по готовности составных модулей и отличный контроль за исполнением и его качеством.
Уже после, оценив трудоемкость работы трех человек, я пришел к выводу, что она несколько завышена, но было сэкономлено время на синхронизацию действий и управление командой. Ну, и основную системную работу по планированию и системной архитектуре сделал я сам. Этой рыбой структуры данного типа приложения пользуюсь до сих пор :)
Мораль сей басни такова: планирование работы над проектом до его начала и разделение обязанностей участников настолько тщательно, насколько это возможно для уменьшения количества взаимосвязей в проекте. Принцип Разделяй и Властвуй в действии.
Автор: Дядя Эдик.
Полезные ссылки в тему:
Комментарии:
vasyas
>> Я сделал архитектуру всех необходимых классов, начиная от базовой формы интерфейса и заканчивая прототипами методов бизнес-логики.
Как я пониманию, это очень объемная часть работ по проекту. Имеет ли смысл взваливать на себя столько работы ? Нельзя ли отдать (хотя бы частично) ее разработчикам (например, поделив работу вертикально, по функциям, а не горизонтально, по слоям) ?
Дядя Эдик
vasyas - работа объемная, но система небольшая. Все работы у меня заняли часов 16. Просто при имеющихся наработках мне было гораздо проще строить архитектуру, я не рисовал ее с нуля. Еще на такое распределение повлияла квалификация кодеров. Один был совсем зелен :) поэтому отвечал только за отрисовку и базовые операции по интерфейсу.
vasyas
если система небольшая, как вы считаете, имеет ли смысл ее реализацию делить на нескольких человек ? не было бы более эффективным делать ее в одиночку ?
Дядя Эдик
Дело в том, что система хоть и небольшая (договора + информация по ним, всего 5 предметов учета), но сроки поджимали совсем. Посему и было выбрано несколько человек, для одного слишком много кода. А несколько почти независимых частей - самое то. Основной минус был в том, о чем я писал - синхронизация действий команды: когда например иньерфейснику нужны были дополнительные фичи, которые еще не сделал человек бизнес-логики. Но, к счастью, таких затыков было мало.
0 коммент.:
Отправить комментарий
Ваш комментарий появится в блоге после проверки администратором