У видавництва «Фабула» вийшов український переклад книги Роберта Мартіна «Чистий Agile». У ній автор розповідає що таке Agile, а також на чому потрібно зосередити увагу, щоб досягнути бажаного результату.

AIN.UA публікує уривок з шостого розділу під назвою «Упровадження Agile».

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

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

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

Без належного рівня оволодіння інструмент може зрештою стати перешкодою, а неналежне його використання навіть здатне завдати шкоди проекту та його виконавцю.

Інструменти розробки

Розробники програмного забезпечення мусять опанувати низку інструментів:

  • щонайменше — одну мову програмування, або й більше; 
  • інтегроване середовище розробки (IDE) або текстовий редактор (vim, Emacs тощо);
  • різноманітні формати даних (JSON, XML, YAML тощо) і мови розмітки (зокрема, HTML); 
  • командний рядок і сценарії для взаємодії з операційною системою; 
  • інструменти для зберігання версій (Git. А є вибір?); 
  • інструменти для безперервної інтеграції/збірки (Jenkins, TeamCity, GoCD тощо);
  • інструменти для розгортання/управління сервером (Docker, Kubernetes, Ansible, Chef, Puppet тощо); 
  • інструменти для комунікації: електронна пошта, Slack, англійська мова (!); 
  • інструменти для тестування (фреймворки для модульного тестування, Cucumber, Selenium тощо).

Ці категорії інструментів необхідні для створення програмного забезпечення. Без них у сучасному світі неможливо нічого створити. У певному сенсі вони є набором «ручних інструментів» програміста.

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

Кмітливий розробник шукає шлях найменшого опору і найвищу віддачу від використання всіх інструментів.

Що робить інструмент ефективним? 

Інструментальний «ландшафт» швидко змінюється, оскільки ми завжди вивчаємо ефективніші способи досягнення поставлених цілей. За останні кілька десятиліть ми спостерігали широке розмаїття інструментів для зберігання версій: PVCS, ClearCase, Microsoft Visual SourceSafe, StarTeam, Perforce, CVS, Subversion, Mercurial та інші. Усі страждали від певних недоліків: то надто ненадійні, то патентовані або закриті, занадто повільні, занадто агресивні чи небезпечні або ж складні. Зрештою з’явився переможець, котрому вдалося подолати більшість зауважень: Git.

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

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

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

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

Інтерфейс у Git досить добре налагоджений і  зрозумілий. Як наслідок, щойно ви навчитеся з ним працювати, про сам інструмент ви вже думати не будете.

Натомість ви переорієнтуєтеся на реальні потреби: безпеку зберігання даних, інтеграцію та управління версіями вихідного коду. Інструмент став прозорим. 

Git — інструмент потужний і складний. Та що ж означає вивчити його «досить добре»? На щастя, тут застосовується принцип 80/20: достатньо мала частина можливостей Git, вірогідно 20%, розв’язує понад 80% ваших щоденних завдань, які вам будуть зустрічатися під час управління вихідним кодом. Більшу частину з потрібного вам можна дізнатися за лічені хвилини. Решта інформації доступна в Інтернеті.

Простота та ефективність використання Git призвели до абсолютно непередбачуваних нових підходів подумати про те, як створити програмне забезпечення. Лінус Торвалдс, напевно, назвав би божевіллям використання Git як інструмента для швидкого викидання частинок коду, але саме цьому сприяють прихильники методу Mikado1 та TCR (Test && Commit || Revert)2 .

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

Чудові інструменти мають такі особливості: 

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

Ми наводимо Git як приклад чудового інструмента… станом на 2019 рік. Ви можете прочитати цю книжку колись у  майбутньому, тому пам’ятайте, що інструментальний «ландшафт» змінюється.

Фізичні інструменти Agile 

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

  • Вони допомагають зробити процес роботи видимим та керованим.
  • Інтуїтивно зрозумілі: не потребують тренувань! 
  • Не потребують значних когнітивних зусиль. Ви можете легко користуватися ними, концентруючись на інших завданнях. 
  • Вони легко підлягають екзаптації. Жоден із цих інструментів не було розроблено винятково для управління розробкою програмного забезпечення. 
  • Їх легко адаптувати. Ви можете використовувати стрічки або клейку масу, клеїти на них зображення або значки, додавати до них різні індикатори та нові кольори й ілюстрації, аби не пропустити жодного нюансу. 
  • Усі вони недорогі, і їх легко придбати.

Команди, які мають спільне розташування, можуть легко керувати величезними та складними проектами, використовуючи лише ці прості та недорогі фізичні інструменти. Ви можете поширити ключову інформацію за допомогою аркуша фліпчарту, приклеєного до стіни.

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

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

Необхідність автоматизації

Оригінальний проект C31, у процесі виконання якого було вперше застосовано екстремальне програмування, керувався здебільшого за допомогою фізичних інструментів. Із розвитком Agile зростав й  інтерес до автоматизованих програмних засобів. Для цього є цілком виправдані причини.

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

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

Ну давайте вже програмні інструменти!

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

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

Працівники використовують та контролюють інструменти, а інструменти не контролюють людей і не користуються ними.

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