Software Project Manager середнього проекту - хто він?

Євген Ігумнов Геокад плюс (Новосибірськ)

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

За моїми спостереженнями, основна маса проектів, які роблять Російські офшорні фірми, зазвичай тривають не більше двох місяців за участю одного або двох програмістів. Багато фірм навіть навмисне не беруть замовлення середнього розміру, розраховані на півроку або рік за участю 6 або 10 програмістів. Деякі фірми вирішуються на такі проекти, але їм доводиться проводити реструктуризацію організації для того, що б було можливо виконувати такі замовлення.

Загальновідомо, що поняття "проект" має на увазі під собою процес, що має точні часові обмеження, тобто дату початку і дату закінчення. Ключову роль у будь-якому проекті відіграє так званий Керівник Проекту (Project Manager). Природно, що Керівник Програмного Проекту (Software Project Manager) має специфічні особливості, пов'язані з галуззю створення програмного забезпечення. У цій статті я спробую розповісти про функції керівника середніх проектів, а також про стадії, через які повинен пройти проект під його керівництвом. У статті я роблю ставку на об'єктно-орієнтовані проекти і упускаю з уваги такі речі як тестування та управління ризиками.

На мій погляд, керівник проекту повинен володіти знанням технологій, на яких буде реалізований проект. Уявімо, що на чолі проекту стоїть керівник, що має тільки загальне уявлення про роботу своїх підлеглих -- програмістів. У кращому випадку ви отримаєте наглядача, який завжди покладається на чесність програмістів, а в гіршому - нахлібника, якому будуть «Пудрити мізки» «спритні» програмісти і проект буде, м'яко кажучи, відставати від графіка, а, швидше за все, взагалі не прийде до стадії завершення. За якою причини я виставив такі вимоги до керівника проекту, буде видно з подальшого матеріалу. Справа в тому, що один кваліфікований програміст з великим досвідом працює в десять разів ефективніше початківця, так стверджує Брукс або Йордан, але, як правило, фірми не поспішають наймати високооплачуваних програмістів. У ситуації, що склалася набагато ефективніше з такого фахівця зробити керівника проекту і дати йому в підпорядкування не таких дорогих програмістів. Але ні в якому разі не потрібно робити навпаки, тому що забивати цвяхи мікроскопом це дуже дороге і не ефективне заняття. Іншими словами, керівник проекту повинен мати дуже високу кваліфікацію, а не заважати своїми нерозумними вказівками занадто розумному виконавцю.

Існує маса книг зарубіжних авторів на тему Software Project Management, які орієнтовані на великі проекти і, природно, управління такими проектами відрізняються від управління середніми проектами. У цій статті я постарався виділити конструктивні моменти діяльності та обов'язків керівника саме середнього проекту.

Аналіз предметної області - концептуальна модель

Перш ніж приступити до реалізації будь-якого проекту, керівник проекту повинен добре представляти предметну область поставленої перед ним завдання. Наполегливо рекомендую почати з побудови діаграм варіантів використання системи (use case diagram). Приклад такої діаграми зображено на рис.1. Дана діаграма була запозичена мною з некомерційного проекту "Агент Інтелектуальних Послуг ", проект в якому я брав участь.

Рис.1.

На рис.1 зображені укрупнені прецеденти, які можна буде надалі деталізувати. Чоловічками позначаються актори, які взаємодіють з розробляється системою і виконують певні ролі. Овали показують види цих взаємодій або прецедентів використання системи. Акторами можуть бути як користувачі, так і частини самої системи, які функціонують самостійно. Більш докладну нотацію даного виду діаграми можна знайти в будь-якій літературі з UML.

Після того, як керівник проекту усвідомив, хто і як буде користуватися майбутньої системою, необхідно переходити до розробки концептуальної (понятійної) моделі системи або, іншими словами, скласти словник понять предметної області, з якими працює розробляється система та встановити зв'язки між поняттями. Для цієї мети я пропоную побудувати діаграму класів (class diagram). Приклад такої діаграми зображено на рис.2.

Рис. 2

Дану діаграму я запозичив з того ж проекту. Поняття з предметної області необхідно об'єднати в класи і показати між ними зв'язку. Зв'язки повинні мати назви і кратності. Наприклад, споживач може послати нуль або багато повідомлень, але кожне повідомлення має мати одного споживача, це видно з зв'язку між класами Consumer і Message. Більш докладну нотацію даного виду діаграми також можна знайти в літературі з UML.

Після побудови цих діаграм керівник проекту отримає, по-перше, функціонально орієнтовану картину системи, а по-друге, об'єктно-орієнтовану. Перше необхідно, для того щоб зрозуміти, що відбуватиметься всередині і зовні системи, а друга для того, щоб отримати основу для майбутньої об'єктно-орієнтованої системи.

Настійно вимагайте це від своїх керівників проектів. З одного боку, це змусить їх краще розібратися із завданням, яке вони вирішують, а з іншого, ви отримаєте контрольні точки у вигляді діаграми використання, за якими зможете відслідковувати стан проекту, питаючи з керівника проекту, які прецеденти використання вже реалізовані.

Розробка специфікації архітектури системи - перехід від концептуальної моделі до програмної моделі

Після того, як керівник проекту отримав функціонально-орієнтовану і об'єктно-орієнтовану картину системи, йому необхідно «об'єднати» їх воєдино і отримати специфікацію системи, яку можна видавати програмістам на реалізацію в програмний код.

Необхідно взяти частину прецедентів використання і побудувати для кожного з них діаграму взаємодії, наприклад, діаграму кооперації (collaboration diagram). Приклад такої діаграми зображено на рис.3.

Рис. 3.

Під час побудови діаграм взаємодії будуть виділені публічні (public) методи класів, а також з'являться класи чисто синтетичної природи, які не мають аналогів у реальному світі. Цей етап, на мій погляд, самий складний і в ньому можна допустити помилки, які будуть тягнутися протягом всього проекту. Ось з цієї причини керівник середнього програмного проекту повинен вміти не тільки програмувати, але і мати навички роботи програмним архітектором (Software Architect).

Існують так звані шаблони проектування (design patterns), які слід застосовувати на цьому етапі. Постає проблема розподілу обов'язків між об'єктами та розробці взаємодії об'єктів. Для успішного конструювання слід систематизувати і ретельно проаналізувати принципи розробки. Такий підхід до розуміння і використання цих принципів грунтується на застосуванні шаблонів розподілу обов'язків GRASP. Другий набір шаблонів -- шаблони GoF, які не строго орієнтовані на розподіл обов'язків, а орієнтовані на повторне використання дизайну і є чисто синтетичними конструкціями, що не мають ніякого відношення до об'єктів реального світу. Всього виділяються три групи шаблонів. Твірні шаблони проектування абстрагує процес створення об'єктів. У структурних шаблонах розглядається питання про те, як з класів та об'єктів утворюються більш великі структури. Шаблони поведінки пов'язані з алгоритмами і розподілом обов'язків між об'єктами. Результатом дизайну буде кілька діаграм класів. Приклад такої діаграми показано на рис. 4.

Рис.4.

Після одержання гарного дизайну системи слід розбити систему на пакети, які будуть об'єднувати класи, що мають загальну функціональну спрямованість і працюють разом над здійсненням якийсь об'єднує їх завдання. Можливо, що розбивка на пакети керівник проекту зробить під час цього етапу, а не в його кінці, але якщо він про це задумався якраз в останній момент, то розбиття системи на пакети повинне відбитися на дизайні класів. Варто також побудувати діаграму пакетів. Приклад такої діаграми зображено на рис.5.

Рис.5.

На цій діаграмі зображені залежності між пакетами. Залежність показує використання класів з одного пакету класами іншого. Іншими словами, поки класи другого пакету не будуть реалізовані, класи першого пакету не зможуть функціонувати. Хоча, звичайно, цю проблему можна обійти, використовуючи заглушки. Досліджуючи отриману діаграму, можна побачити які пакети треба писати першими, а які пакети доведеться взагалі писати паралельно. Наприклад, пакет server.client.model.fact не залежить від інших пакетів, але від нього залежать багато хто. Значить, його слід реалізувати в першу чергу. От власне, яка практична цінність цієї діаграми.

Планування мереж - Хто? Коли? Скільки?

Після того, як керівник проекту отримав специфікацію системи, як-то: діаграми пакетів, діаграми класів цих пакетів і діаграми взаємодії, - то слід приступати до мережного планування завдань з реалізації коду між програмістами, які знаходяться в його підпорядкуванні. З цією метою, на мій погляд, слід застосовувати діаграму Ганта. Приклад такої діаграми зображено на рис. 6.

Рис.6

Спочатку керівник проекту повинен створити всі ресурси, тобто програмістів. Потім створити завдання великого порядку, наприклад, їх можна запозичити з назв пакетів, і пов'язати ці завдання, щоб встановити порядок їх виконання на основі залежностей між пакетами. Кожній задачі потрібно призначити її попередню тривалість. До отриманим завданням прикріпити ресурси (програмістів), які буде їх виконувати. Слід уважно стежити за тим, що б програміст не отримав завдань які вимагають від нього не 8-ми, а 16-ти годинний робочий день. Далі, слід розбити великі завдання на більш дрібні підзадачі. З допомогою так званого work breakdown structure керівник проекту повинен отримати ієрархію завдань. Це необхідно для того що б з одного боку точніше оцінити часові витрати на завдання вищого порядку, а з іншого боку, точно сформулювати - що і коли повинен робити кожен програміст. Для цього етапу рекомендую використовувати MS Project. Він дозволить зручно і швидко розподілити завдання і роздрукувати листочки з завданнями для програмістів.

Після того, як керівник проекту отримає сітьовий графік у першому наближенні, то вже можна більш реалістично побачити, скільки часу триватиме проект і скільки ресурсів він потребує.

Контроль версій файлів системи - велика бочка меду з ложкою дьогтю

Проект переходить від стадії проектування і планування до стадії реалізації. Коли в проекті працюють кілька програмістів над загальними файлами, починається проблеми з приводу того, що програмісти починають заважати один, другу вносячи зміни, у файли, затірая чужі зміни. Так само встає проблема, як відслідковувати самі останні версії файлів і поширювати їх між програмістами.

Для того, що б уникнути цих проблем слід використовувати програмний продукт для контролю версій файлів. Існує велика кількість комерційних продуктів на цю тему. Але я б рекомендував некомерційний продукт CVS.

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

Принцип функціонування CVS досить простий. Існує репозитарій (бібліотека) всіх вихідних файлів проекту, там зберігаються всі версії кожного файлу. Програмісти можуть підключитися до цього репозитарій і забрати з нього самі останні версії вихідних файлів проекту або будь-якої його версії. Продукт CVS відповідає за синхронізацію локальних копій файлів проекту на машинах програмістів з репозітарієв і за вирішення конфліктів при спільному редагуванні одного файлу.

Керівнику проекту слід ввести одне очевидне правило роботи з CVS для програмістів: "Ніколи не посилати в репозитарій файл свідомо не компілюються!".

Механізм збирання всієї системи - хто написав цей не вибирає файли?!

Процесу збирання слід приділити увагу в перші ж дні реалізації проекту. Справа в тому, що програмісти вважають за краще працювати в різних оболонках для редагування та компіляції вихідних кодів від простого текстового редактора notepad до складного і багатофункціонального рішення, такого як Together. Внаслідок чого доведеться кожному з них постійно возитися з настройками процесу компіляції. І це буде постійною проблемою, оскільки у міру реалізації проекту процес складання системи ускладнюється і зазвичай кардинально змінюється.

Керівнику проекту слід запровадити єдиний для всіх інструмент для складання проекту і розмістити сценарій збирання системи в репозитарії CVS. Таким чином, будь-який з програмістів, отримавши за допомогою CVS останню версію сценарію збирання, зможе без проблем зібрати всю систему у себе на робочому місці і в будь-який момент модернізувати цей сценарій у разі зміни сценарію збирання підсистеми, яку він реалізує. Можливо, що один з програмістів краще за всіх розбирається в сценарії збирання, і інші звертаються до нього по допомогу при зміну сценарію.

Збірку системи слід проводити на початку робочого дня, після того, як всі програмісти відіслали останні версії своїх файлів на CVS. На жаль, після збирання і запуску системи виявляються конфлікти і помилки, на усунення яких йде якийсь час (ризикну сказати - чверть робочого дня).

Висновок

В висновку хочу сказати, що керівник середньої програмного проекту є ключовою фігурою. Вилучення його з проекту або заміна буде мати катастрофічні наслідки і може поставити хрест на багатьох місцях роботи цілого колективу програмістів. Під час реалізації проекту його керівник повинен постійно займатися уточненням графіка роботи, контролем виконання завдань і служити додатковим «довідковим посібником» до специфікації системи, яку реалізують програмісти.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/