Ми, методологи, проектуємо складні системи, але не беремо до уваги робочі характеристики активного компонента цих систем, компонента, який відомий своєю нелінійністю і мінливістю - людини. У цій статті коротко перераховані ті теорії та проекти, які мені довелося вивчити, щоб усвідомити цей абсолютно очевидний факт, а також визначити, які риси людської психіки повинні враховуватися в створенні методології і більш загальних рекомендаціях стосуються процесу розробки. Саме за цими якостями можна робити найбільш вірні прогнози щодо майбутнього перебігу проекту та застосування до нього будь-якої методології.
Шлях помилок важких
Будь-яка методологія може привести до провалу проекту.
Чотири основні властивості
Людина - істота товариська
Всі люди різні
Люди як нелінійні і найбільш важливі компоненти в створенні програмного забезпечення
Цей звіт базується на моєму особистому досвіді, який я придбав, вивчивши близько 40 проектів за останні 20 років.
Основна ідея цієї статті полягає в наступному: методологи розробляють складні системи, у яких є вельми мінливі і нелінійні компоненти - люди. При цьому їм якось вдається взагалі не помічати ці компоненти і той вплив, який вони чинять на проектовану систему. Після деякого роздуми такий стан справ здається абсурдним, однак, в нашій галузі зовсім не багато дослідників, що приділяють час серйозного вивчення впливу людського фактора на розробку програмного забезпечення.
Найбільш помітними винятками з цього правила є Джеральд Вайнберг (Gerald Weinberg [Wei]) і Том Демарк (Tom DeMarco [Dm]), чиї книги публікуються зараз в ювілейних (!) Виданнях. Їх роботи так популярні в нашій галузі, що, здавалося б, вони повинні були тільки підвищити інтерес до цього предмету і викликати активізацію досліджень у цій області. Зараз все більша кількість консультантів починає ставитися до людей як до головного фактору в розробці ПЗ [B99] [Hi], однак, в цілому, співтовариство розробників програмного забезпечення продовжує ігнорувати той факт, що саме людина повинна бути центральною темою досліджень. Це я вважаю серйозним упущенням - все одно, що не брати до уваги металеві перекриття в стінах і скаржитися на погану роботу радіоприймача.
Раніше і я розглядав людей, що беруть участь в проектах, як якийсь другорядний фактор. Це тривало до тих пір, поки після декількох років роботи дослідником і методологом, я не помітив, що мої рекомендації як методолога не відповідають моєму ж власного досвіду в розробці ПЗ. Проблема була не в тому, що робили мої розробники (вони справлялися з роботою досить успішно). Проблема була в іншому: то, що я писав, не відповідало тому, що ми робили.
Протягом останніх п'яти років я болісно намагався визначити (мені важко це зробити навіть зараз) "що ж знаходиться у мене перед очима". Поступово мені стало ясно, що в моєму (та й будь-якому іншому) методологічному рівнянні не вистачає однієї змінної - впливу на методологію такого поняття як "людина".
Тепер, коли я почав враховувати цей параметр, мої методологічні прогнози і висновки стали відповідати тому, що я бачу в реальному житті. Тепер я вважаю, що люди - це головний. першочерговим двигун проекту.
Чим же це відрізняється від того, що писали в "Peopleware" Демарк і Лістер (Lister)? Вони висловили думку, що люди являють собою важливий фактор, і вказали на деяку специфіку питання. Мене ж цікавить те, як групові та індивідуальні особливості людини впливають на проектування способів розробки ПО (іншими словами, на методології), в застосуванні до різних груп, що працюють над різними видами завдань.
Мої ідеї вельми схожі з тими, які викладав Вайнберг в розділі "Teaming" ( "Робота в команді") своєї книги "The Psychology of Computer Programming" ( "Психологія програмування"). Особливо все те, що стосується протиставлення двох стилів керівництва - управління завданнями (task management) і управління підтримкою (maintenance management). Це дуже близько до того, що намагаюся отримати я - деякі властивості і рекомендації, які з них випливають. Вайнберг грунтується на тих проектах, які він досліджував в 60-і роки. Однак його висновки залишаються справедливими і корисними і зараз, 30 років потому, що ще раз підтверджує стабільність і важливість людського фактора в розробці ПЗ. Мені здається, вже настав час ретельно вивчити подібні фактори, і почати ставитися до наступних з них рекомендацій як до основ розробки ПО, а не відкривати їх для себе кожні 30 років.
У цій статті я розповім про ту роботу, яку виконав, щоб зрозуміти, що саме люди є головною запорукою успіху проекту. В даний час для прогнозування я використовую саме людський фактор. Я пишу цю статтю від першої особи, тому що формальний, академічний стиль не дуже підходить для опису пошуків чогось абсолютно очевидного і при цьому не зовсім зрозумілого. Найкраще подати це у вигляді розповіді від першої особи.
Шлях помилок важких
Року так в 1987, коли я займався формальної розробкою програмного забезпечення, існувало таке переконання: "У розробці ПО проблема полягає в тому, що при постановці завдання і проектуванні допускається занадто багато неточностей. Все буде добре. Якщо ми зможемо змусити людей працювати з математичним формалізмом ". Однак, попрацювавши трохи в цьому напрямку, я виявив, що перед нами стоять:
Проблема 1. Людям, зайнятим в проекті, абсолютно нецікаво вивчати нашу систему.
Проблема 2. Вони цілком можуть обійтися і без методологів, і при цьому успішно створювати програмне забезпечення. Я пішов від формальних розробок, в той час як мої колеги висунули нову ідею: "Вся проблема - в навчанні. Все буде добре. Якщо ми дамо розробникам необхідні математичні знання набагато раніше, ще в середній школі". Однак моє знання людей підказувало, що таке бажання нездійсненне. Не те, щоб я ставив під сумніви очевидні переваги формальної розробки ПО, просто я сумнівався в нашій здатності переконати 10 мільйонів чоловік зайнятися математикою. Правильно було б поставити питання таким чином: "За яких обставин і для чого потрібно включати в проект фахівця з формальної розробці?"
Я перейшов до розробки інструментальних засобів, і став працювати настільки етноцентричність, наскільки це було можливо. При цьому я спостерігав за тими, хто проектував комунікаційні протоколи і обговорював з ними, які проблеми виникають у них під час роботи. І мої колеги, і я прийшли до єдиного висновку: "Вся проблема полягає в тому, що люди до сих пір вважають за краще малювати на дошці. Все буде добре. Якщо ми надамо в їх розпорядження спеціальний програмний інструмент, за допомогою якого вони зможуть малювати безпосередньо в комп'ютері і бачити, як будуть реалізовуватися їхні проекти на ранній стадії роботи ".
Ми витратили декілька років, щоб розробити спеціальний генератор, що трансформує діаграми послідовності і взаємодії в архітектуру програмного продукту і систему правил [Ci]. Багато компаній працювали (і працюють) над подібними завданнями, наприклад, виконуваними кінцевими автоматами Херел (Harel's executable finite state machines) [Ha].
Проблема 1. Людям, зайнятим в проекті, абсолютно нецікаво вивчати нашу систему.
Ті команди, які успішно працюють над своїми проектами, використовують інкрементні процеси розробки [Co95]
При проектуванні будь-яка техніка, складніше "CRC-карток" [B87] вважається занадто складною і не використовується [Co94].
У тих, хто займається проектуванням, завжди є можливість відмовитися від будь-якого програмного продукту або техніки, які їм не подобаються. Досить сказати начальнику: "Це уповільнює роботу. Якщо я буду цим користуватися, то чи не вистачить і термін", і він дозволить проектувальникам чинити на власний розсуд. У той час це спостереження не здавалася мені особливо важливим, але, тим не менше, я його записав і н.
Швидка навігація назад: Ctrl + ←, вперед Ctrl + →
Текст книги представлений виключно в ознайомлювальних цілях.