Зміст:
Бути спритною командою розробників програмного забезпечення, безумовно, означає різні речі для різних людей. Існує ступінь прийняття в дуже широкому спектрі, мабуть, дуже мало організацій, які вважають, що вони це роблять добре. Згідно з опитуванням State of Agile Survey (опубліковане в квітні 2017 р.), 80% респондентів заявляють, що вони “перебувають на рівні або нижче рівня дозрівання”. На жаль, команди розробників часто не докладають багато зусиль для того, щоб “вивчити” частину ітерації. Ми хочемо поспішити і закінчити церемонії Scrum, щоб ми могли повернутися до написання коду. Зрештою, так багато роботи! Але чи справді проблемою є недостатній час кодування?
Для багатьох з нас боротьба з пожежею також може бути конкретно зазначена в нашій посадовій інструкції. Ми ходимо на роботу щодня, знаючи, що нам потрібно бути готовими ковзати вниз по стовпу за мить, хапати капелюхи і стрибати на вантажівку. Ми сприймаємо це як саме те, що є, і ми припускаємо, що ми нічого з цим зробити не можемо. Але що, якщо основною причиною нашої боротьби є сильна відсутність ефективності? Всім відомо, як важливо робити це краще, ніж та інша компанія там. Ми просто не можемо туди потрапити - здається, у нас немає пропускної здатності. Менеджери додають більше людей і збільшують розмір своїх організацій, і при цьому залишаються незмінними проблемами. Здається, ви не можете подолати горб, оскільки ваші команди не розробляють програмне забезпечення ефективно (і ви не самотні).
Принципи ефективного розвитку
Піксабай
То що призводить до того, що ми неефективні? Для більшості з нас перше, що спадає на думку, - це відсутність автоматизації (автоматизовані збірки, розгортання, тестування). "Як тільки у нас вистачить автоматики, життя налагодиться". На жаль, це лише частина рішення. Розгляньте вплив переробки на ваш проект. Найефективніший спосіб побудови функції - це побудувати її один раз правильно і ніколи не повертатися назад і не торкатися її знову. Помилки, рефакторинг та інші подібні заходи, по суті, знову відкривають пацієнта після того, як він вийшов з операційної, і з цим пов’язаний ризик. Ми не можемо усунути переробку, але нам, безумовно, слід намагатися звести її до мінімуму.
"Але хіба спритний не охоплює переробки (наприклад, рефакторинг)?" Це насправді певним чином, тому що творці agile зрозуміли, що двома основними причинами переробки є непередбачені обставини та зміна бізнес-вимог. Виявляється, люди страшно прогнозують майбутнє. Спритні творці також розуміли, що величезний внесок у неефективність - це те, що розробники називають “золоченням” - упаковка функціональних можливостей, які, на нашу думку, хтось буде використовувати, хоча кінцеві користувачі ніколи про це не просили. Це як свинина для вашого програмного продукту - повна втрата часу. "Не будуйте космічну станцію, коли все, про що вони просять, - це Volvo". Отже, компанії розумно почали залишати свинину та натомість застосовувати рефакторинг, лише додаючи функціональність, коли є явна необхідність. Але непередбачуваність життя не є єдиним рушієм для переробки, чи не так?
Пропущені деталі на будь-якому етапі розробки функції зрештою втратять час і гроші. Ефективна попередня співпраця з часом заощадить вам купу переробок (вирішення пропущених вимог, короткозорий дизайн тощо). У всіх нас є сліпі плями, і всі ми потребуємо додаткових наборів очей. Багато команд розробників приймають це на задньому плані під час перегляду коду, але вкладають набагато менше енергії для співпраці на ранніх стадіях, коли проблеми можна вирішити дешево та після мінімальних вкладень.
Скільки разів ви впроваджували функцію і виявляли суттєві недоліки наприкінці, які слід було виявити під час обговорення вимог / дизайну? Це все одно, що спробувати проїхати автомобіль з Атланти до Монтгомері і зрозуміти кілька годин у поїздці, що ви випадково їхали до Бірмінгема. Скільки часу було витрачено на спроби отримати код в самий раз, щоб потім знову відкрити пацієнта, оскільки були пропущені суттєві вимоги? Використання колективного інтелекту абсолютно заощадить час і гроші, але натомість розробники часто працюють над функціями окремо.
Традиційне роїння
Піксабай
Традиційне роїння означає, що команда спільно працює над історіями з кількома людьми, які одночасно працюють над невеликим об’єктом, скорочуючи цикл зворотного зв’язку та скорочуючи загальний час завершення об’єкта (тобто розділяй і володарюй). Це, по суті, роїться в межах кожної дисципліни (розробники серверних систем, розробники інтерфейсу тощо). Перед початком розробки розробники інтерфейсу працюють над визначенням незалежних завдань, які можна виконувати одночасно. Вони обговорюють точки інтерфейсу, щоб кожна людина знала, як її частина вписується в ціле. Потім члени команди можуть приступити до завершення доручених завдань і звести все разом наприкінці під час інтеграції. Часті коміти та періодичні перевірки коду допомагають гарантувати, що все залишається на рейках. Цей підхід вимагає співпраці між розробниками,що в будь-якому випадку допомагає досягти кращого кінцевого результату. Ми часто надаємо пріоритет часу, витраченому на написання коду (будь-якого коду), і витрачаємо час на те, щоб не писати неправильний код. Якщо врахувати потенційно збережений час, значення стає зрозумілим.
Розблокування
Піксабай
Інший цінний підхід до роїння - це зосередити увагу команди на початку пом'якшення залежності, щоб сприяти одночасному розвитку між дисциплінами. Розглянемо природний потік розвитку функції інтерфейсу користувача. Тестери автоматизації (SDET) залежать від робочого інтерфейсу для тестування, розробники інтерфейсу - від робочого інтерфейсу API, а розробники бекенда - від конфігурації, оновлень баз даних та автоматизованих збірок / розгортань. Тому розробники інтерфейсу можуть не розпочинати свою роботу, поки не закінчаться API, а SDET не можуть розпочинати свою роботу, поки функція не буде завершена. Кожна дисципліна працює ізольовано, що заважає співпраці, оскільки люди, з якими вам потрібно взаємодіяти, зайняті іншими справами.Але що, якби ви могли раніше зменшити залежності і дозволити всім дисциплінам працювати одночасно над однією і тією ж функцією?
Ось кілька прикладів:
1. Розгорнутий функціональний інтерфейс користувача із заглушками
Для того, щоб розблокувати SDET, розробники інтерфейсу можуть надати їм функціонуючий інтерфейс, який працює якраз настільки, що дозволяє писати тести. Інтеграція інтерфейсу Backend та стилі CSS все ще можуть бути очікуваними, оскільки автоматизовані тестові фреймворки, такі як Selenium, не будуть байдужими, якщо ці речі недороблені. Це все може бути дим і дзеркала. Незважаючи на те, що можуть відбутися зміни, які спричиняють певні зміни, користь від початку тестів перевищує цей ризик.
2. Розгорнуті інтерфейсні інтерфейси API (стерп-код, жорстко закодовані дані)
Забезпечення інтерфейсів API, які розробники інтерфейсу можуть перевірити, дозволяє раннє виявлення проблем інтеграції між інтерфейсом та API. Іноді ви виявляєте, що наданий API не відповідає потребам розробників інтерфейсу. Можливо, відсутні цілі дзвінки, підпис може бути помилковим або структура даних може мати проблеми. Якщо відбудеться розрив зв'язку, ви можете також дізнатись про це раніше, ніж щось застигло.
3. Створіть версію HelloWorld нових програм та служб.
Якщо потрібна нова послуга (наприклад, мікросервіс), створіть репо та створіть версію служби «привіт світ». Це дозволяє запускати ресурси розробників на робочих місцях Дженкінса та сценаріях розгортання до того, як послуга буде фактично розроблена.
Ці оптимізації сприяють ранньому циклу зворотного зв’язку, коли хтось може сказати “Мені потрібно щось інше” до завершення розробки компонента, який вимагає змін.
Загортаючи його
Неймовірно важливо, щоб ми з’ясували, як скоротити час виходу на ринок функцій, над якими працюємо. Бізнес не отримує жодної користі від наявності безлічі функцій, які тривають, і розробники вкрай потребують функцій, щоб їх швидко реалізувати, щоб дефекти могли бути усунені якомога ближче до точки введення. Розробникам також відчайдушно потрібно взаємодіяти один з одним, хоча все, що вони насправді хочуть зробити, це написати код. Це краще для всіх, хто бере участь, включаючи кінцевого користувача, який просто хоче кращого продукту. Якщо ви не дасте їм, вони підуть кудись ще, щоб знайти його.
Роїння - надзвичайно цінний інструмент у наборі інструментів вашої організації, якщо люди знаходять час, щоб навчитися це робити. Це не рамки і навіть не діяльність - це мислення. Щодо кожної історії користувача, члени команди задають собі два запитання:
- Як ми можемо організувати завдання для цієї історії, щоб змусити відразу взяти участь кількох людей?
- Який мінімум мені потрібно зробити, щоб розблокувати когось, хто мене чекає?
Що робити, якщо ваша команда швидко будує об’єкти разом, а не повільно створює купу функцій самостійно? Вони могли б насправді реагувати на мінливі вимоги бізнесу та задовольняти потреби бізнесу, коли бізнесу потрібно, щоб вони були задоволені. Конкуренти бояться вас - клієнти будуть вас любити. Це рецепт успішного бізнесу.
© 2017 Майк Шомаке