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

Перш ніж працювати над фінансовим програмним забезпеченням протягом останніх декількох років, я провів більшу частину своєї кар’єри 3d графічним програмістом, працюючи над відеоіграми та програмним забезпеченням ГІС та біометрії, і мені завжди просто доводилося занурюватися з обриву в речі і з'ясовувати, як літати. Хоча мені завжди це вдавалося, я впевнений, що не збираюся жити так довго, як це було б, якби я не вбив себе, працюючи стільки 100 годинних тижнів і місяців за один раз.

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

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

Це насправді не має великого відношення до Agile або навіть до інженерії програмного забезпечення. Це просто стосується будь-якої компанії в будь-якому бізнесі: вам потрібно виділити час для навчання. Період.

Agile має таке уявлення про "стійкий темп", що означає, що в жодному разі команда не повинна працювати важче, ніж те, що вона могла витримати протягом невизначеного часу. Тобто немає «часу хрускіт». Цього потрібно шанувати і навчанням. Отже, це стабільний темп для вашої команди - "не більше 5 годин без перерви, не більше 9 годин на день, не більше 40 годин на тиждень", і ви хочете забезпечити 10% часу для тренувань, тоді ви потрібно планувати свої проекти на 36 годинних тижнів.

Але знову ж таки, це не має нічого спільного з Agile, це просто здоровий глузд і математика початкової школи.

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

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

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

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

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

Я збираюся погодитися з більшістю того, що сказав Йорг У Міттаг , але не з твердженням, що "це насправді не має великого відношення до Agile". Ряд методик Agile підтримує навчання та розвиток людей та команд.

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

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

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

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

Що робити, якщо історія повинна мати лише 5 балів для досвідченого розробника? Можливо, це займає 3-4 завдання по 8 балів кожне. Після цих завдань на POC історія все ще може становити лише 5 балів, але принаймні ви виділяєте час для вивчення нових навичок, щоб 5-бальна історія не становила 40 балів - навіть якщо завдання з історії та POC складають до 40 балів.

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

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

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

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

Деякі інші вже згадували аспекти, але я просто хотів поділитися тим, наскільки я підходить до особистого розвитку в спритному середовищі.

1. Постійний розвиток

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

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

2. Більші зусилля під час спринту

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

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

Agile - це набір філософій, погляньте на маніфест, це ВСЕ Agile є, тому коли ви говорите, як Agile може вирішити мої проблеми, я рекомендую дізнатися більше (про багато) про Agile. Візьмемо конкретну реалізацію Agile: SCRUM. У SCRUM у нас є поняття спринт і шипи. Через ці два артефакти можна створити бюджет на навчання.

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

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

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

Цитувати з самого маніфесту Agile :

Індивіди та взаємодія над процесами та інструментами
Робоче програмне забезпечення над всеосяжною документацією
Співпраця з клієнтом над переговорними контрактами
Відповідає на зміни, випливаючи за планом

Наголос мій, підкреслюючи ті частини, які, мабуть, найбільше стосуються вас.

По суті, добре навчені спритні розробники можуть реагувати на мінливе середовище набагато краще, ніж ті, хто дозволяє наборам навичок скам’яніти.

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