o Різні точки зору на бригадну модель.
o Навички, необхідні для розробки.
o Підхід до формування навичок.
o Навички керівництва.
o Аналогія.
Продовження обговорення проекту: бригада по розробці продукту, орієнтована на користувачів.
Ергономіка розробки ПО
Якби розробка продуктивного ПО була більш легкою справою і якби цій справі було нескладно вивчитися, кількість різних програмних продуктів було б набагато великим. Насправді навіть наявні на даний момент програмні продукти і ПІ у своїй масі дуже посередні і не задовольняють потреб користувачів і організацій.
Але в чому ж причина такого положення справ? Спираючи на існуючі методи і знання в області програмної інженерії, дуже важко розробляти програмні продукти. Однак навіть при використанні найбільш зроблених процесів розробки ПО жонглювання цифрами ще не досить для досягнення бажаного результату. Успіх у даному випадку полягає в професіоналізмі розроблювачів, що повинні мати наступні здібності.
" Працювати з різними людьми як в організаціях, що займаються розробкою, так і в комерційних організаціях.
" Розуміти існуючі запити користувачів, а також їхні майбутні потреби і мети.
" Вміти уточнювати і розширювати до необхідного ступеня деталізації неясно сформульовані вимоги.
" Використовувати засоби і методи, що необов'язково призначені для розробки ПО.
" Швидко й ефективно оцінювати і відновлювати проект і реалізацію.
Нагадаємо, що ергономіка займається приладжуванням людини до роботи і при-лаживанием роботи до людини. Не всі люди підходять для виконання деякої роботи, також як і робота і засоби її виконання не обов'язково підходять для більшості людей.
Якщо говорити про всі аспекти розробки ПІ, то вони вимагають обліку неисчисли-мого безлічі визначених деталей. Потенційно існують величезні розходження в користувачах, групах і організаціях, а також тисячі зв'язаних з ними питань, що вимагають дозволу. Відомі переходи від замовників до ділових лідерів, до користувачів, вимогам до продукту, до моделей ПІ, до засобів ПІ, до інфраструктури проекту, реалізації (програмному коду), до інформації, тестовим прецедентам, посібникам користувачів, до розгортання. Застосування кращих зразків процесів розробки ПО (на зразок проектування орієнтованого на користувача), безумовно, допомагає, а використання кращих засобів, що підтримують перехід від вимог через реалізацію і тестування, виразно, повинне полегшувати роботу. Наступним кращим підтримуючим фактором виступають вірно підібрані люди з належними навичками і відносно деталізованим і прагматичным підходом, що дозволяє справитися з величезним обсягом питань.
Передумови розробки ПО
Набрати належних людей з належними навичками, в орієнтовану на користувачів бригаду по розробці продукту, організовану відповідним чином, - от, що вам потрібно; принаймні , цей підхід найкраще зареко-мендовал себе на практиці.
Корисне правило. Проблеми організаційного, групового й індивідуального характеру, що виникають при проектуванні продукту, відрізняються набагато більшою складністю, чим технічні проблеми. 80% проблем зв'язані з людьми і тільки 20% носять технічний характер. Вираження "Із мною не вважаються!" у тій чи іншій формі можна почути практично від кожного з членів традиційної команди розроблювачів ПО. В орієнтованій на користувачів бригаді розроблювачів програмного продукту подібна фраза про відсутність поваги звучить набагато рідше. Причиною подібного відношення може стати одна з приведених нижче ситуацій.
" Недолік індивідуальних навичок, що не заповнюється.
" Слабкі навички міжособистісних відносин.
" Слабка групова динаміка.
Члени проектної бригади розроблювачів програмного продукту підбираються як фахівці в основних областях, зв'язаних з розробкою ПО. Крім того, у бригаду включаються інші важливі учасники проекту, такі як спонсори і представники колективу користувачів. У залежності від характеру розроблювального проекту можуть знадобитися професіонали в інших чи областях учасники проекту.
Найважливіші цілі. Головна мета проектної бригади складається в ефективному постачанні продукту, що задовольняє вимогам до практичності, ПІ і согла-сованности. Крім того, бригада вимагає чіткого керування проектом, підтримки керівництва, інструментальних засобів, устаткування і вірного настроя, щоб справитися з нелегкою роботою.
Найважливіші професійні навички. Термін "інженерія" (тут автор веде мову про програмну інженерію, чи інженерії програмних засобів. - Прим. ред.) застосуємо до багатьом областям професійної діяльності, оскільки немає таку чи людину групи, які б мали вірні відповіді на всі питання, що навіть стосуються їхній професійний області. У результаті для досягнення рішення використовуються ітеративний і еволюційний підходи. Проектування і розробка ПІ для сучасних стилів ПІ і більшості комерційного ПО являє собою роботу, що вимагає високого професіоналізму і значних групових зусиль. У залежності від характеру розроблювального продукту необхідний набір фахівців може включати співробітників, здатних виконувати інженерні задачі в інших областях професійної діяльності. У табл. 4.1 приведений набір основних видів професійної діяльності, необхідних для розробки сучасного ПО.
Корисне правило. Значення різних професійних навичок і участі в проекті відповідного кількості фахівців, що володіють кожним типом навичок, вимагає ретельного планування для досягнення впевненості в успіху проекту.
Таблиця 4.1. Потенційні області професійних навичок
Основні навички Потенційні області
навичок
Стиль ПІ операційної системи Реклама
Стиль ПІ додатка Компонування
Знання бізнесів-процесів Планування випуску продуктів
Людські фактори Підтримка продуктів
Графічний і візуальний дизайн Керування
Проектування інформаційної підтримки Лідерство
Проектування/розробка прототипів Комунікації
Архітектура/проектування/розробка продукту Групова динаміка
Стилі і стандарти ПІ Організаційне поводження
Професійні навички відображаються на специфічні ролі в рамках про-ектной бригади, як показано в табл. 4.2. У деяких випадках навички, так само як і сфери відповідальності, перекриваються. Однак належне визначення ролей, що поставляються компонентів і колективна робота дозволяють усунути будь-як невизначеності. Одна людина може виконувати одну чи кілька ролей. Наприклад, лідер проекту може виконувати ролі, зв'язані з проектуванням ПІ, виробленням стандартів і розробкою прототипів. Член бригади з навичками дизайнера графіки може виконувати ролі дизайнера графіки і проектувальника інформаційного забезпечення. Як би там ні було, для гарантії успіху потрібно встановлення тісних робочих взаємин між учасниками бригади.
Корисне правило. Кожен фахівець повинний мати достатніми про-фессиональными навички і бути готів, згодний і здатний виконувати кілька ролей. Варто підбирати в бригаду всебічно обдарованих людей.
Розробка користувальницького інтерфейсу. Для успішного створення продукту найважливіше значення має висококваліфікований персонал, що володіє навичками в таких областях, як технологія розробки ПІ, стандарти ПІ, інструментальні засоби реалізації і використання ПІ в додатках. Фахівці з проектування ПІ відповідають за вироблення підходів для концептуальних моделей, визначення об'єктів і дій, структуру екранів і логіку їхніх викликів при відображенні, зовнішній вигляд і поводження ПІ, а також за всі дрібні деталі, зв'язані з взаємодією користувача із системою і реакцією системи. Проектувальник ПІ може відповідати за документування напрямків розробки і специфікацій для продукту.
Таблиця 4.2. Основні ролі в орієнтованій на користувачів бригаді розроблювачів продукту
Корисне правило. Члени бригади, що займається створенням прототипу ПІ, повинні розуміти розходження в проектуванні і реалізації програмного забезпечення прототипу і продукту.
Розробка Графіки і мультимедиа. Для розробки ПІ вимагаються фахівці з проектування, а також реалізації візуальних і графічних конструкцій. Для GUІ і WUІ може знадобитися розробка специфічних наочних тим і проектування графічних елементів на зразок піктограм, побітових відображень, файлів форматів JPEG і GІ. Інженер-графік може залучатися до задач розробки аудио- і відеопродукції для створення компонентів, що поставляються, мультимедиа й анімації.
Розробка засобів інформаційної підтримки. До складу проектної бригади необхідно уключити фахівців в області проектування і реалізації засобів навчання, посібників, систем допомоги й електронної експлуатаційної підтримки. У задачу цих фахівців входить проектування і реалізація інформаційних засобів, що можуть виявитися корисними і зручними для підтримки початкового навчання, виконання нестандартних задач і рішення проблем.
Пророблення питань практичності. Украй важлива присутність у бригаді фахівців із психології й ергономіки, що володіють знаннями в області людського поводження, сприйняття, навчання і пізнання. Навички в області людських факторів і інженерної психології вимагаються при проектуванні і вивченні запитів користувачів, а також для оцінки практичності системи.
Розробка бізнес процесів. Для бригади істотна наявність спе-циалистов, що мають навички виконання робіт і складають реальні бізнес процеси. Інженер по бізнесах-процесах - це реальний користувач, що активно виконує ділової функції, моделюючи дії людини, для якого бізнеси-процеси - звична справа. Тут вимагаються знання предметної області, бізнесів-правил , даних і цінностей, що мають важливе значення для ведення бізнесу, а також критеріїв користувальницького успіху. Не слід недооцінювати знання критеріїв ділового успіху і факторів, що мають важливе значення при прийнятті компромісних рішень. Інженер по бізнесах-процесах повинний бути знаком з використанням існуючої системи стосовно пропонованого продукту.
Спонсор/керівник бригади розроблювачів продукту, орієнтованої на користувача. Поряд з технічним лідером бригади необхідно призначити відповідального керівника для нагляду над орієнтованою на користувачів бригадою розроблювачів продукту. Разом з технічним лідером бригади спонсор/керівник бригади відповідає перед керівниками виробництва за постачання продукту, що відповідає вимогам у рамках прийнятих обмежень.
Інші важливі навички. При виконанні проекту можуть знадобитися ще інші навички і знання. Одному з членів бригади варто доручити вивчення інших потенційних областей діяльності і їхнього можливого впливу на розробку продукту і бригаду. Деякі області діяльності (наприклад, бізнес-планування, перетворення бізнесу, керування змінами, оцінка продуктивності, керування проектами і потоками робіт) можуть виявитися потенційно важливими для роботи орієнтованої на користувачів бригади розроблювачів продукту.
Корисне правило. Постійно спілкуйтеся зі співробітниками, знаючими у во-просах технології, вивчайте нові концепції і потенційні можливості їхнього застосування в проекті, робіть допомогу колегам якнайшвидше .
Різні точки зору на бригадну модель
Уже багато було сказано про тім, наскільки успішними виявляються зусилля не-великої бригади, особливо якщо мова йде про реалізацію нової технології. Однак якщо взяти до уваги великі і глобальні проекти, то результати виявляться не настільки вражаючими. Невеликі бригади добре зарекомендували себе в умовах залучення відповідних фахівців і забезпечення належні мотивації, заохочення, керування і підтримки (мал. 4.2).
Головна проблема для великих і глобальних проектів - формування концепції бригад як невеликих високопродуктивних колективів, що працюють спільно і домагаються високоефективних результатів.
Корисне правило. Одна з задач, що коштує перед лідерами й участника-ми бригад, полягає в тім, щоб зберегти атмосферу і специфіку, властивій невеликій бригаді, незалежно від того, скільки людей вовлечено в проект.
Корисне правило. Краще відразу об'єднати порядних людей, чим чекати, поки стануть порядними ваші підлеглі.
Заповзятливість. Створення примітних продуктів вимагає, щоб усередині організації-розроблювача панував дух підприємництва. У багатьох відносинах високоефективних результатів не можна досягти не відриваючись від "повареної книги". Бригада, зосереджена на тім, щоб користувачі одержали в результаті її роботи високоякісний продукт, при необхідності повинна бути готова відкинути прийняті правила.
Орієнтація на ринок. Ще один спосіб збереження підприємницької жилки полягає в тім, щоб настільки неухильно концентруватися на користувачах і їхніх реальних потребах, як це не вдається нікому з конкурентів. Підтримка конкурентного духу вимагає знання своїх конкурентів, їхньої сильної і слабкої сторін, а також бажання походити на них у їхніх кращих рисах і виробляти якості, що дозволяють скористатися їхніми слабостями.
Формування бригади. Лідер бригади і її керівництво повинні зробити все необхідне для забезпечення ефективної роботи команди і налагодження зв'язків усередині її (просто помістити людей в одну кімнату ще не значить створити бригаду). Групова динаміка - надзвичайно важливий фактор. Існує чимало методів формування бригади, що дозволяють установити довіра між членами бригади, витягти переваги з індивідуальних особливостей учасників, ефективно взаємодіяти і вирішувати загальні проблеми. Найбільш важливий фактор, що забезпечує ефективну роботу бригади, - це встановлення ясних цілей разом з чіткою відповідальністю за їхнє досягнення. Не менш важливим є ефективне керівництво з боку як технічних, так і адміністративних лідерів бригади.
Корисне правило. Побудові орієнтованої на користувача високо-продуктивної бригади розроблювачів безсумнівно варто приділити досить часу, енергії і зусиль.
Формування професійного вигляду бригади. Технічна кваліфікація учасників бригади повинна бути достатньої для виконання проекту. Багато бригад розроблювачів мають великий досвід в області застарілих, так званих успадкованих додатків. Як правило, у подібних випадках замовникам потрібно перенести наявні в них розробки і додатки з існуючої платформи в нове чи середовище пристосувати їх під новий ПІ, що базується на GUі-интерфейсе.
Додатка, засновані на GUі-интерфейсе, надають у розпорядження бригади розроблювачів ПО, що переходить із систем на основі мейнфреймов чи мини-эвм до додатків на основі GUі-интерфейса, щонайменше три потенційно нових технології (нове апаратне забезпечення, нові ОС і новий стиль ПІ). Усі ці технології, чи явно побічно, повинні бути зазначені окремим рядком у планах розробки. Хоча GUі-интерфейс іноді в жарт називають WіMP-интерфейсом (WІNCUW-ІMAGE-MENU-POІNTER - оконно - графічний інтерфейс із покажчиками і меню. Тут гра слів- wіmp по-англійському значить "нудний", "повсякденний". - Прим. ред.), розробка GUі-ориентированных додатків не розрахована на слабкі нерви, плани-графіки і бюджети. Щоб одержати потенційні вигоди від GUі-ориентированных додатків, потрібно добре навчена і дисциплінована бригада.
Колективна робота. Найбільша відповідальність орієнтованої на користувачів бригади розроблювачів продукту полягає в тому, щоб виробити творчий і новаторський підхід, достатній для забезпечення необхідних результатів. Бригада повинна виконувати необхідну роботу і розділяти відповідальність за її результати.
Правила колективної роботи. Кожна бригада повинна установити правила поведінки. При цьому найважливішу роль грають чесність, взаєморозуміння і прагнення домогтися успіху, так сказати "переможний дух" у команді. Варто подбати про формування ефективної технічної бригади.
Залучення користувачів у колектив. Залучення користувачів у роботу з розробки проекту більш докладно розглядається в главі 6. До найбільш важливих проблем інтеграції користувачів у бригаду розроблювачів відносяться перебування загальної мови, розуміння взаємних потреб і створення робочих
взаємин, що сприяють створенню продукту, що задовольняє тре-бованиям користувачів, організацію-замовника і розроблювачів.
Навички, необхідні для розробки
Тепер більш докладно розглянемо вимоги до навичок, який повинні володіти розроблювачі GUі-ориентированных додатків. В основу вивчення даного питання покладені особистий досвід і спостереження автора, зв'язані з численними програмними проектами по створенню ПІ. Основи навичок можна одержати за тиждень, а на те, щоб навчитися володіти цими навичками в досконалості, потрібно набагато більше часу.
Мови програмування. Базу для всіх систем, заснованих на исполь-зовании GUІ, складають різні варіанти мови програмування С. Для ори-ентированной на користувача бригади розроблювачів продукту, що зіштовхуються з можливістю перенесення програмного додатка з однієї GUі-ориентированной системи в іншу, як мінімум потрібно знання мови Зі стандарту ANSІ. Для складних Web-орієнтованих додатків необхідний досвід роботи з одним з варіантів мови Java. Існує безліч курсів по навчанню основам мов програмування. Елементарні знання можна одержати за тиждень, однак на глибоке освоение методів програмування ідуть роки.
Власна операційна система. Подібно курсам по навчанню основам мов програмування існують курси, що навчають основам ОС. Базові знання можна одержати на тижневих курсах, однак освоєння будь-якої операційної системи вимагає часу.
Основи ПІ. Перш ніж приступити до розробки GUІ-, Web- чи PDA-ориен-тированного додатка, бригада розроблювачів повинна вивчити, яким образом його проектувати. Також існують курси, що навчають основам ПІ й орієнтованим на процеси підходам до розробки. І знову, для ознайомлення з базовими знаннями в цій області досить тижня, а на глибоке вивчення й освоєння необхідно більш тривалий час. Що стосується GUі-ориентированных додатків, то в порівнянні з іншими типами інтерфейсу вони відрізняються великою кількістю деталей, що приходиться враховувати розроблювачу.
Власні інструментальні засоби. Набір інструментальних засобів- це сукупність можливостей, наданих у розпорядження додатка ОС чи апаратною платформою для одержання вхідної інформації від користувача, обробки цієї інформації і відображення системного висновку, наприклад при введенні з чи клавіатури миші, а також під час уведення вихідної інформації на пристрій відображення. Звичайно початковий курс для основних понять цієї області займає біля тижня. На освоєння основ і більш глибоке вивчення потрібно більше часу.
Розвиті МОВИ програмування. Як і для інших мов про-граммирования, тут існують основні методи, на освоєння яких також потрібно чимало часу.
ООА/ООР/ООП. Знання объектно-ориентированной технології може потре-боваться в трьох аспектах процесу розробки: объектно-ориентированного аналізу (ООА), объектно-ориентированного проектування (ООПР) і объектно-ориентированного програмування (ООП). Навички в області ООА вимагаються для перетворення результатів аналізу в проектні моделі, що представляють об'єкти, класи об'єктів, ієрархії класів і спадкування. Навички в області ООПР вимагаються для представлення проектних моделей у мові реалізації. Фактично, для вивчення базової термінології і конструкцій досить однотижневого курсу навчання. Однак програмісти з досвідом в області процедурно-орієнтованого програмування випробують труднощі при переході до объектно-ориентированному підходу в програмуванні. Для переходу до объектно-ориентированному стилю архітектури ПО може знадобитися від двох до трьох місяців не вважаючи вивчення объектно-ориентированного мови програмування.
Крос платформні інструментальні засоби розробки ПІ. Для деяких проектів потрібно, щоб те саме ПО можна було перенести на кілька різних платформ, зберігши при цьому стиль ПІ додатка. Наприклад, існує цілий ряд додатків, що повинні функціонувати під керуванням Mac, Wіndows і UNІ. Для подібних ситуацій рекомендується використання крос платформного набору інструментальних засобів. У випадку використання однієї платформи досить її "рідного" інструментарію.
У своїй основі крос платформні засоби являють собою ПО для конст-руирования ПІ, що оснащено можливостями перенесення ПІ додатка з одного середовища в іншу. Звичайно багато елементів ПІ перетворяться зі стилю одного інструментарію в іншій. Однак завжди існують низкоуровневые деталі, на зразок чи шрифту кольору, що повинні бути набудовані вручну. Для розгляду даної проблеми досить однотижневого навчання.
Розвиті користувальницькі інтерфейси і методи. Дотепер ми розглядали основні підходи до одержання Пи-ориентированных додатків, відкритих для кінцевих користувачів. Однак існують розвиті Пі-орієнтовані додатки, для реального застосування яких недостатньо базових знань і навичок. У міру того як орієнтована на користувачів бригада розроблювачів продукту освоює базові засоби і мови, їхнє застосування стає реальним. Стають доступними класи для розширення базового знання про ПІ у виді більш творчих підходів до проектування і реалізації.
Навички людського спілкування. У більшості організацій-розроблювачів неявно передбачається, що люди знають, як працювати спільно. Проте , необхідно провести невелике офіційне навчання по груповій чи динаміці організаційному поводженню. Варто організувати тижневий курс навчання цим навичкам і їхньому практичному застосуванню.
Інші технології і навички. Якщо проект включає інші технології, не забудьте виділити час на офіційне навчання, вивчення і застосування обов'язкових навичок. Інші навички, необхідні орієнтований на користувачів бригаді розроблювачів продукту, зв'язані з іншими дисциплінами і включають графічний дизайн, написання нетехнічних документів, контроль версій, тестування, оцінку ефективності, людські фактори, оцінку ПО і керування проектами. Джерелами цих навичок може служити інший персонал, що підтримує орієнтовану на користувачів бригаду розроблювачів продукту. Однак основам цих дисциплін варто навчити всю бригаду розроблювачів ПО.
Навчання крок за кроком. Якщо ви починаєте з нуля, проходження курсу навчання по основних областях займе 8 тижнів (табл. 4.3). Однак предмети можна вивчати частинами. Після вивчення кожної частини дається час на її засвоєння й апробацію на практиці перед тим, як перейти до наступного. Якщо потрібно вивчити більша кількість мов і інструментальних засобів, таблиця відповідно розширюється.
Таблиця 4.3. Одержання базових знань
Навички Час (тиждень) Джерело
З чи Java 1
Власна ОС 1
Власний інструментарій 1
Основи ПІ 1 Рівень випускників ВУЗОВ
і аспірантів
Розвиті навички З чи Java 1
Кроссплатформенные засобу 1
ПІ
Розвитий ПІ 1 Рівень випускників ВУЗОВ
і аспірантів
Люди 1 Аспіранти-психологи/соціологи
ВСЕГО 8
Деякі курси можна проходити в різному порядку, а деякі теми можуть вивчатися на старших курсах університетів. Необхідно дати час на засвоєння й оволодіння отриманими знаннями, на що може знадобитися від трьох до шести місяців. Вивчення технології, придатної для Пи-ориентированных додатків, займає від року до двох років.
Замість елементів табл. 4.3 можна підставити більш сучасні стилі ПІ і мови, такі як HTML/DHTML, XML, JavaScrіpt і інші чи мови операційні системи. Курси, що приводяться в таблиці, не включають аналогічні курси по графіці, інформаційній підтримці, оцінці практичності, людським факторам і навичкам з інших областей обчислювальної техніки. Якщо бригаді вимагаються додаткові навички, чи технології мови, таблиця відповідно розширюється.
Корисне правило. Побудуйте таблицю і дайте розроблювачам час на изуче-ние й освоєння необхідних навичок.
Підхід до формування навичок
Хоча на перший погляд ця задача і може показатися нездійсненної, перебороти "вершину" формування навичок для розробки Пи-ориентированных програмних додатків цілком досяжно. Якщо ви спершу навчаєтеся, як "лазать, бігати і літати" крізь реалізацію, інші Пи-ориентированные якості прийдуть самі собою. Існує кілька способів вивчення того, "як це робиться" стосовно до розробки Пи-ориентированных програмних додатків.
Курси. У залежності від індивідуального стилю навчання для швидкого оволодіння знаннями підходять офіційні курси. Іноді може бути досить одне-тижневих курсів. Якщо ж по визначеній темі пропонується навчання на рівні старших курсів університету, однотижневого курсу може виявитися недостатньо. Варто врахувати, що для формування чи навичок вивчення вузівського курсу необхідно додатковий час. Для багатьох розглянутих вище тем найкраще підходять семінарські заняття.
Самоосвіта. Один з розповсюджених підходів одержання необхідних навичок - це самоосвіта. Для придбання навичок підходять курси, супроводжувані читанням додаткової літератури і виконанням вправ. Деякі книги служать гарною підмогою у вивченні власного инструмен-тального набору визначеної платформи. По можливості варто навчатися на прикладах.
Починайте з малого. Після початкового навчання отримані базові навички корисно застосувати для конструювання невеликого Пи-ориентированного додатка. Наприклад, при конструюванні GUі-приложения бажано виконати наступні задачі проектування і реалізації.
" Спроектуйте для додатка Пи-ориентированные елементи, такі як піктограму робочого столу, його вікно, меню, діалог і екран довідки.
" Реалізуйте піктограму для власного робочого столу і відкрийте вікно за допомогою щиглика на піктограмі.
" Відобразите віконні меню з використанням покажчика миші і клавіатури.
" Відобразите командний діалог і довідкові вікна.
Початкові результати. Спочатку плани повинні включати розробку дуже скромного Пи-ориентированного програмного забезпечення. Недоліком першої розробки може бути тривалий час відповіді, ненадійність, що приводить до аварійного відмовлення системи, складності з відтворенням, проблеми з тестуванням. Усе це складає частину так називаної кривої навчання.