Програмування як гра

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

У сучасній науці в категорію ігор потрапляє така кількість різноманітних видів діяльності, що іноді важко знайти в них щось загальне. Вітгенштейн [Wittgenstein, 1953] вважає, що обов'язковою умовою гри є проходження правилам. Як тільки учасники гри перестають слідувати її правилам, гра припиняється (таким чином, грою можна назвати тільки добровільну діяльність, за умови, що у учасників завжди є можливість припинити її і діяти іншим чином). Будь-яка гра складається з "рухів" у напрямку до або від мети і якогось обліку відстані між метою і гравцем.

Деякі ігри розраховані на одного учасника, в інші грають цілі групи людей. Одні ігри направлені на досягнення мети, інші - на взаємодію учасників. При цьому тривалість ігор може варіюватися від декількох хвилин або навіть секунд, до років або всьому життю гравця. Визначаючи місце виробництва програмного забезпечення серед інших ігор, я керуюся трьома основними характеристиками:

    * Воно може бути кінцевим або нескінченним.
    * Воно може бути засноване на конкуренції або на взаємодопомозі.
    * Воно може бути припинене після досягнення конкретної мети (включаючи припинення гри по закінченню певного терміну) або ж у нього взагалі може не бути ніякої певної кінцевої крапки (коли закінчиться, тоді і закінчиться).

Мета нескінченної гри - в її продовженні [Carse]. Люди, організації і цілі держави грають в нескінченну гру під назвою "виживання". Деякі люди грають в гру, яка називається "Зроби кар'єру" (можна, наприклад, підвищувати свою ринкову вартість за рахунок проекту) і т.д. Легко здогадатися, що окремі нескінченні ігри можуть заважати оптимальному ходу великого проекту, тому боротьба з такими перешкодами зазвичай є частиною стратегії керівництва.

Серед кінцевих ігор можна виділити ті, які закінчуються після досягнення наперед поставленої мети; інші закінчуються у будь-який момент, коли того захочуть учасники. У обох цих категоріях є ігри-змагання і колективні ігри, засновані на взаємодії і взаємодопомозі учасників. Теніс і шахи, наприклад, носять явний дух суперництва і закінчуються після досягнення мети. "Король гори", гра, в яку люблять грати діти, (один гравець захищає вершину горба від інших хлоп'ят, які винні його звідти зіштовхнути) теж будується на суперництві, проте закінчується тільки тоді, коли зовсім стемніє, або коли учасників покличуть додому: місце першого короля займає наступний, потім наступний і так до безкінечності. Покер - ще один приклад гри такого ж роду. А ось джаз або танці можна віднести до відкритих колективних ігор. У обох випадках учасники гри концентрують свою увагу на якості взаємодії і виступі всієї групи, причому продовжується така гра стільки, скільки захочуть в неї грати самі учасники.

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

Чи неправда, в цьому є щось від розробки ПО? Головна і основна мета - поставити замовникові працюючу систему. Саме так оцінюватиметься успіх або неуспіх проекту. Вже згодом люди питатимуть, наскільки цікавим був цей проект, чи добре їм керували, чи красивою вийшла програма, і чи легко буде підтримувати її в майбутньому. Якщо команда розробників не поставить замовникові ніякої програми, всі визнають, що проект закінчився невдачею. Іноді є можливість вийти з гри, коли стає зрозуміло, що мета те не коштує, і цією можливістю не варто нехтувати. Звернете увагу: це справедливо і для альпінізму, і для розробки ПО.

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

Таким чином, на відміну від альпіністів, програмісти ставлять перед собою дві мету:

    * Поставити замовникові систему;
    * Створити основу для наступної гри.

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

Обидві ці цілі конкурують між собою і претендують на обмежені ресурси команди. Розробники можуть поставити замовникові продукт набагато швидше, якщо в майбутньому цей продукт не треба буде змінювати і доповнювати. (А наскільки швидше це можна було б зробити, якщо не займатися виправленням помилок в програмі!) З іншого боку, розробники можуть згаяти час на створення більш продуманої архітектури додатку, написання документації і передачу системи команді наступників - але все це відкладе термін постачання готової системи (а іноді може і взагалі перешкодити успішному завершенню проекту).

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

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

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

На світі немає формули, що дозволяє вигравати в іграх. Є тільки стратегічні прийоми і навики, які можуть бути корисні в тій або іншій ситуації. Навіть одне розуміння цього може виправдати весь "ігровий" підхід до процесу розробки ПО. Люди, що працюють над реальними проектами, починають усвідомлювати, що для перемоги в грі їм необхідно постійно використовувати свій розум і кмітливість - спостерігати за ситуацією, що змінюється, і робити відповідні висновки, запам'ятовувати і застосовувати відомі стратегічні прийоми, тут же винаходити і випробувати нові. І при цьому завжди пам'ятати, що в такій складній і переобтяженій вимогами області, як проект по розробці ПО, досягти обох мети неможливо, тому треба визначити, яка з них має найбільший пріоритет і рухатися до неї в збиток інший.

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

Як тільки гравцям стане нецікавий, гра закінчиться. У цьому сенсі розробка програмного забезпечення з відкритим початковим кодом більше схожа на музичні джем-сейшни або на конструктор LEGO. Це колективна гра, яка не направлена на досягнення кінцевої мети і не передбачає керівництва або розподілу обмежених ресурсів. Тому ті прийоми, які чудово працюватимуть в проектах з відкритим кодом, не спрацюють в звичайних проектах по розробці ПО - обмежених в ресурсах і направлених на досягнення кінцевої мети колективних іграх.