Процес затвердження анти-шаблону, Різне, Програмування, статті

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


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


Шаблони і анти-шаблони


Шаблони являють собою компоненти інструментарію фахівців з програмного забезпечення. Зокрема, ми вивчали шаблони проектів – способи проектування програм, що дозволяють зробити їх більш надійними, гнучкими і правильними. Еріх Гамма (Erich Gamma) розробив основи принципу шаблонів проектування програмного забезпечення у своїй дисертації на здобуття наукового ступеня доктора філософії на початку 90-х років. Натхненником Еріха Гамма став Крістофер Александер (Christopher Alexander), архітектор, який досліджував ідею шаблонів в архітектурі (у звичайній архітектурі, а не архітектурі програмного забезпечення). Шаблони увірвалися в розробку програмного забезпечення завдяки публікації в 1995 році книги Design Patterns (Шаблони проекту).


Шаблон являє собою перевірений підхід до вирішення часто виникаючих проблем. Шаблон не є конкретним рішенням, яке можна вирізати і вставити через буфер обміну, це принцип, який може допомогти вирішити проблему. Шаблон – це не трафарет, з яким ми стикаємося, заповнюючи різні бланки.


Шаблони не винаходять. Зіткнувшись з проблемою, ви не сідаєте спеціально за винахід нового шаблону, який допоможе вирішити цю проблему. Той факт, що ми думаємо про шаблони як про елементи багаторазового використання, повинен навести нас на думку про те, що ми швидше відкриваємо шаблони, ніж винаходимо їх. Часто ми можемо думати, що збираємося написати компонент програми багаторазового використання, на Насправді, багаторазове використання в першу чергу має на увазі використання. Тому до тих пір, поки хто-небудь не використовує наш компонент, а потім хтось ще знову не використовує його, ми, по суті, не знаємо, чи добре ми зробили свою роботу зі створення якогось компонента багаторазового використання. Це ж справедливо і відносно шаблонів. Своїм студентам я часто пропоную просте правило великого пальця: Один раз – це випадковість, два рази – збіг, три рази – привід подумати, не відкрили ви шаблон.


Шаблони стали популярними, тому що вони дозволяють розробникам говорити на одній мові. Розробники використовують терміни на зразок “адаптер” або “фасад” приблизно так само, як столяри використовують термін “Ластівчин хвіст”. Мова збагачує наш словниковий запас словами, які несуть приголомшливий обсяг семантичного сенсу. Як тільки в моду увійшли шаблони проектів, шаблони стали з’являтися і в інших областях розробки програмного забезпечення, таких як процеси, аналіз вимог і т. д. Кожна область спеціалізації хоче долучитися до цього нового погляду на світ. Шаблони були “next big thing” 90-х. В даний момент існують книги та статті з шаблонами для процесів, управління вимогами, архітектури програмного забезпечення, тестування, управління проектами і т. д. Практики та теоретики прагнуть докласти хорошу ідею до всього, чим вони займаються. Я так любив свою об’єктно-орієнтовану ручку в середині 80-х. Я просто говорив pen.write, і вона, як за помахом чарівної палички, робила свою справу.


Це невгамовна прагнення до пошуку шаблонів призвело, на мій погляд, до класичної ситуації: за деревами ми не помічаємо лісу. Всі раптом виявилося шаблоном, від використання стандартного коду до перегляду коду та вибору мови програмування. Застосування шаблону вимагає осмислення, розуміння проблеми, оцінки наслідків використання шаблону і досвіду.


Одним з наслідків відкриття та застосування шаблонів стало те, що шаблони, як і ліки, можна неправильно використовувати. Іншими словами, ми можемо “прописати” додатком даний шаблон і виявити, що, на наш жаль, пацієнту (в нашому випадку, організації з розробки програмного забезпечення), стало гірше, і він, можливо, навіть помре. Спостерігаючи це явище, ми відкрили анти-шаблони. Анти-шаблон виникає, якщо здається підходящим підхід до вирішення проблеми в дійсності посилює проблему. Думаю, що перший анти-шаблон описав Фред Брукс (Fred Brooks), який виявив, що якщо додати в проект, який не вкладається в терміни, більше співробітників, то це призведе до ще більшого відставання проекту.


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


Опис анти-шаблонів процесу розробки


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



Застереження


Форма, яку я вибрав для представлення опису анти-шаблонів, не є унікальною. Я спробував скопіювати велику частину ідей з книги Organizational Patterns of Agile Software Development (Організаційні шаблони динамічної розробки програмного забезпечення), автори Коплін (Coplien) і Харрісон (Harrison). Я рекомендую цю книгу кожному, хто хоче дізнатися, як підвищити ефективність розробки програмного забезпечення в організації.


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


Тепер до шаблонів …























Назва: Прийміть відразу всі таблетки
Контекст  Процес, як ліки – це благо. Він допомагає привнести порядок і здоров’я в організацію і сприяє більш рівномірному ходу подій. У деякий момент часу організація розуміє, що необхідно модернізувати спосіб розробки програм і вирішує внести удосконалення в свій виробничий процес.
Доводи  Процес важливий саме сьогодні. Ми повинні пережити перевірки і відповідність технічним нормативам. Ми повинні бути як можна більш ефективними. Існує багато компаній, консультантів і книг, які допоможуть нам перетворити наш хаотичний спосіб життя в економічний чудовий механізм для розробки програм на заздрість усій галузі. Наше керівництво придбало ідею удосконалення процесу і наказує нам: “Повний вперед!”
Рішення  Ми прийняли рішення ввести у всій організації процес по типу Software Development Life Cycle, SDLC (Життєвий цикл розробки програмного забезпечення). Ми підготували навчальні матеріали, найняли найкращих консультантів і супровід, яких тільки можна було знайти за гроші, і призначили дату анонсування нового процесу. З цього дня кожен буде думати несуперечливим і передбачуваним способом, який можна вимірювати і постійно покращувати.
Наслідки  На жаль, коли ми застосували цей підхід, справи не покращилися, вони стали ще гірше. Зміни, особливо позитивні зміни, вимагають часу. Окремі співробітники і організації можуть сприйняти невеликі порції змін без великих потрясінь. Тим не менш, ми хочемо вірити, що якщо випити цілий бульбашка ліки під назвою “процес,” то всі наші хвороби моментально зникнуть. Єдине, що відбувається насправді – колективи та їх члени змушені витрачати абсолютно невиправдане кількість часу і зусиль, щоб слідувати процесу, і зовсім незначний час саме на вирішення тих проблем, які вони повинні вирішувати. Зрештою, люди перестають забезпечувати роботу процесу і (або) створювати програмне забезпечення.
Альтернатива:  Приймайте процес в малій дозуванні. Визначте ключові галузі, в яких, як ви думаєте, процес може принести найбільшу користь. Реалізуйте, оцініть результати, а потім підготуйте наступний невеликий крок. Якщо Ви заробите корисну інформацію про те, чи будуть працювати зміни і як вони будуть працювати, то будь-хто зможе зрозуміти переваги і захоче прийняти наступну зміну.

Я завжди дивуюся, як часто проявляється цей анти-шаблон. Мені завжди здавалося, що покрокове введення змін диктується звичайним здоровим глуздом. Незважаючи на це, в останні десять років я спостерігав багато організацій, які намагалися внести великомасштабні зміни в свій спосіб роботи. Причому абсолютно не має значення, який процес вони намагалися реалізувати. Аналогічний феномен я спостерігав в організаціях, намагалися ввести Rational Unified Process, Або RUP, модель технологічної зрілості організації інституту программотехнікі (CMM) і динамічні процеси, наприклад, eXtreme Programming (XP). Люди хочуть вірити, що найкращий спосіб запровадити новий процес – Просто припинити виконувати роботу так, як вони робили це раніше, і перескочити на нові способи роботи. Занадто часто ми відмовляємося від цінних методів роботи в наших організаціях тільки тому, що вони не знайшли відображення в нових, кращих, більш сучасних процесах.























Назва: Залучення експертів з боку
Контекст  Коли ми переходимо на нові методи роботи, нам потрібно переконатися, що ми правильно їх розуміємо. Ми не бажаємо витрачати час, намагаючись використовувати нові методи тільки для того, щоб виявити, що ми робимо все неправильно, тому ми наймаємо консультантів, які повинні прийти до нас і негайно запустити новий процес.
Доводи  Час – гроші, і з огляду термінів, які маячать перед нами, ми можемо дозволити собі витратити часу менше, ніж грошей. Крім того, експерти досконально вивчили процес і знають, чого очікувати і як провести нас через небезпечні течії змін, щоб ми не розбилися об скелі або не сіли на мілину. Наймані консультанти в наші дні стали способом життя в корпоративному світі, тому це саме те, що ми можемо довести нашим керівникам.
Рішення  Найміть експертів-консультантів і зобов’яжемо їх впровадити нові методи.
Наслідки  Це рішення може бути успішним, але шанси на те, що це буде не так, дуже великі. Навіть якщо все пройде добре, то, ймовірно, таке рішення не матиме постійного ефекту в організації. По суті, ви зняли з себе відповідальність і поклали управління своїм колективом на консультантів. Члени колективу можуть працювати краще до тих пір, поки експерт стежить за ходом речей, але коли експерт йде, все повертається на вихідні позиції.
Альтернатива:  Запросіть експерта-куратора, який допоможе членам колективу виробити базу знань і впевненість у самостійній реалізації процесу змін.

У китайців є таке прислів’я: “Дай людині рибу, і ти нагодуєш його на весь день. Навчи його ловити рибу, і ти забезпечиш його їжею на все життя.” Аналогічну логіку можна застосувати до модернізації процесу. Скажи співробітникові, як зробити щось краще, і він буде робити це, поки ти на нього дивишся. Навчи його як слід обдумувати та приймати рішення з приводу того, які зміни можуть допомогти, і він стане господарем змін і зробить все сам.


Кент Бек (Kent Beck) якось зауважив, що розробка програм – це просто слухання, тестування, кодування та проектування, а той, хто говорить щось ще, просто намагається вам щось продати. Хоча я не можу погодитися з тим, що набір дій по розробці програм вичерпний, думаю, що в цьому твердженні є певна мудрість. Консультанти теж роблять бізнес і дещо продають – себе. Чим більше ви продаєте, тим більше заробляєте, тому якщо їм вдасться довести свою незамінність, вони продадуть і зароблять більше. Це один з можливих поглядів на стан речей. Я думаю, що по-справжньому хороші консультанти по процесам і методології – це люди, які хочуть допомогти вам і вашій організації вивчити і засвоїти знання, які у них є, і допомогти вам оволодіти ними. Вони щасливі, йдучи з успішної зустрічі, на якій ви стали самостійними. Такі консультанти працюють з вами, а не тільки для вас.























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

Коли я носив прізвисько “буркотун RUP,” у мене була можливість відвідувати і спостерігати багатьох споживачів. Одним з найбільш пам’ятних став візит на завод Volvo в місті Гетеборг, в Швеції. Борис Карлссон і його співробітники відповідали за реалізацію процесу в групі розробки програмного забезпечення. Борис і його колектив працювали над реалізацією процесу точно так само, як вони виконували проекти програм. Вони зібрали вимоги, запланували дії, необхідні розробнику для розуміння того, як використовувати новий процес, а потім запустили пілотні проекти для різних колективів розробників. Вони розробили навчальні модулі і програми навчання точно за розкладом і курирували весь колектив. Це було одне з найбільш успішних розгортань RUP, яке я коли-небудь спостерігав.


























Назва:  Колективне право власності
Контекст  Щоб привернути увагу членів колективу до нового процесу, кожному надається “право власності” на процес.
Доводи  Люди краще реагують на зміни, якщо вони беруть участь в процесі та мають деякий контроль над його зміною. Надаючи окремим членам колективу право власності на реалізацію процесу, ви отримуєте їх участь і бажання взяти процес і працювати незважаючи на потрясіння, які, природно, можливі при введенні нових методів. Організація хоче залучити співробітників до прийняття рішень. Внаслідок важливості впровадження процесу членам колективу надається можливість – а іноді й обов’язок – визначати специфіку процесу і план реалізації. Участь співробітників в управлінні дійсно працює. Існує багато прикладів компаній, які описують успішні випадки колективного управління, наприклад, гуртки якості.
Рішення  Члени колективу визначають процес і згодні з введенням самого процесу і з тим, як він буде вводитися, до того, як почнеться його розгортання.
Наслідки  У цього підходу є два негативних наслідки. По-перше, може статися, що новий процес ніколи не буде запущений. Люди вважають, що у них є право вето на все, що їм не подобається, і вони прагнуть використовувати його, щоб викликати розкол на зборах, де може бути досягнутий реальний прогрес. В результаті вони вбивають ініціативу, так само, як законодавці вбивають законопроекти, розглядаючи їх на засіданнях комітетів. По-друге, якщо вводяться зміни процесу, вони є комбінацією улюблених методів, які просто не працюють разом і виявляються гірше, ніж будь-який процес, який мав місце до введення змін.
Альтернатива:  Специфічні зміни процесу визначаються невеликою групою співробітників. Ця група потім запрошує інших членів колективу, щоб представити процес і отримати зворотній зв’язок і внести зміни, які має сенс зробити до запуску змін.

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























Назва: Малі збільшення, нетривалі ітерації
Контекст  Ви вирішили організувати удосконалення процесу за образом проекту розробки програмного забезпечення: зробити його ітеративним і поетапним. Здається, проекти програмного забезпечення виходять краще, якщо ці прирости невеликі, а ітерації робляться як можна менш тривалими.
Доводи  Вам потрібна модернізація, і вас змушують провести зміни настільки швидко, наскільки це можливо. Ми думаємо, що якщо окремі приросту будуть менше, то введемо їх швидше. Як тільки ми закінчили впровадження першого зміни, ми починаємо вводити наступне. Люди можуть навчитися за один раз тільки чомусь одному, і здається справедливим, що цей підхід дійсно зменшить загальну тривалість змін процесу, і ми зможемо пожинати переваги, надані змінами, як тільки вони будуть реалізовані. Результуючий ефект повинен бути кумулятивним.
Рішення  Ви створюєте групи впровадження, навчальні матеріали та навчальні сесії для кожної зміни, плануючи їх таким чином, що між окремими хвилями, або ітераціями, які вводять новий метод, залишається дуже короткий проміжок часу.
Наслідки  Цей підхід веде до плутанини. Якщо ви тільки що розповіли про що-небудь, це ще не означає, що люди це зрозуміли і можуть застосувати на практиці. Людям потрібні різні проміжки часу, щоб хоча-б частково стати компетентними у використанні нових методів. Якщо просто швидко і безперервно підкидати їм нові зміни, це насправді збільшить час, необхідний для впровадження зміни, і може навіть, як не сумно це звучить, привести до загального провалу модернізації процесу.
Альтернатива:  Визначте невеликі набори змін, які спрямовані на конкретні області організації процесу. Наприклад, навчіть людей застосовувати корисні приклади для аналізів вимоги, проектів систем і тестування. Навчайте людей на курсах перепідготовки весь цей час. Дозвольте їм використовувати нові методики у всьому проекті. Потім вводите наступний набір методів і змін. На все потрібен час. Поки ви не надасте людям можливість засвоїти нові методи, випробувати їх, адаптувати до окремих проектів і, нарешті, остаточно навчитися їх використовувати, у вас небагато шансів на те, що вони дійсно впораються з ними. Це саме той випадок, коли поспішиш – людей насмішиш.

Висновок


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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*