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

Прежде чем работать над финансовым программным обеспечением в течение последних двух лет, я провел большую часть своей карьеры программиста по трехмерной графике, работая над видеоиграми, программным обеспечением для ГИС и биометрии, и мне всегда просто приходилось нырять с обрыва в вещи и выяснять, как летать. Хотя я всегда добивался успеха, я уверен, что не проживу так долго, как если бы я не убивал себя, работая так много сотен часов и недель подряд.

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

Может быть, agile просто не решает эту проблему, но если это так, я не нашел где, и я был бы признателен за любые знания или опыт или опыт, который кто-либо имеет с этим.

На самом деле это не имеет ничего общего с Agile или даже с разработкой программного обеспечения. Это просто верно для любой компании в любом бизнесе: вам нужно выделить время на обучение. Период.

У Agile есть идея «устойчивого темпа», что означает, что ни в коем случае команда не должна работать усерднее, чем то, что она могла бы поддерживать в течение неопределенного периода времени. Т.е. нет "хруста". Это должно быть учтено и обучением. Таким образом, для вашей команды это устойчивый темп «не более 5 часов подряд без перерыва, не более 9 часов в день, не более 40 часов в неделю», и вы хотите предоставить 10% времени на тренировки, а затем вы нужно планировать свои проекты на 36 часовых недель.

Но опять же, это не имеет ничего общего с Agile, это просто здравый смысл и математика начальной школы.

Лично я думаю, что что-то вроде предоставления полчаса в день, одного полдня в неделю и одной полной недели в квартал позволит команде быстро и стабильно получать знания разного размера.

Существуют также некоторые Agile-практики, которые помогают с передачей знаний, т. Е. Сглаживают различия в уровне знаний между группами:

• ежедневные ретроспективы
• ретроспективы на спринт
• ретроспективы на проект
• парное программирование
• пинг-понг (замена драйвера и навигатора после каждого шага цикла «красный-зеленый-рефакторинг»)
• беспорядочные пары (без фиксированных пар, пары назначаются случайным образом и меняются каждое утро и обед)
• нечетное количество членов команды (если вы занимаетесь парным программированием, один член команды может свободно учиться)
• программирование мобов (вариант парного программирования, когда вся команда использует один компьютер и экран, назначенный член команды просто «машинистка», а другие говорят ему, что писать)
• разнородные команды (разработчики случайным образом назначаются командам каждый день / каждый спринт)

Парное и мобильное программирование обеспечивает не только постоянный просмотр кода, но и постоянный обмен знаниями. Соединение в пинг-понг не позволяет одному человеку «зацепить клавиатуру». Беспорядочные пары распространяют знания среди всей команды, разнородные команды распространяют знания по всей компании и гарантируют, что каждый разработчик знает каждый проект и каждую кодовую базу; это также приведет к высокой степени стандартизации в коде (ах). Хотя основной целью ретроспективы является предоставление обратной связи о процессе разработки и соответствующей адаптации, ее также можно использовать для сообщения о необычной проблеме и способах ее решения.

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

Я согласен с большей частью того, что сказал Йорг В. Миттаг , но не с утверждением, что «это не имеет большого отношения к Agile». Ряд Agile методик поддерживает обучение и развитие отдельных людей и команд.

Гибкие методы, как правило, основаны на приращениях или непрерывном потоке. В любом случае, работа упорядочивается на основе учета таких факторов, как приоритет, ценность и зависимости. Поскольку основное внимание уделяется краткосрочной работе, команда может определить знания, которые необходимы для предоставления, и, если недостаток знаний является проблемой, спланировать получение этих знаний точно в срок. Видимость и прозрачность также, как правило, являются ключевыми аспектами различных гибких методов, поэтому заинтересованные стороны могут видеть, над чем работает команда и как они работают над улучшением своих способностей приносить прибыль. Когда необходимо обширное обучение, оно может быть запланировано на ближайшее будущее или текущую итерацию.

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

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

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

Так что, если история должна быть только 5 баллов для опытного разработчика? Может быть, это занимает 3-4 задания по 8 баллов каждый. После этих заданий POC история все еще может составлять всего 5 баллов, но вы, по крайней мере, выделяете время для изучения новых навыков, чтобы история из 5 баллов не составляла 40 баллов - даже если история и задания POC складываются до 40 баллов.

Скрам имеет идею «шипа». Если команда внедряет новые технологии или возможности, всплеск - это история, которая заключает в себе эту работу. Таким образом, в то время как история в гибкой версии представляет собой функциональную часть, ориентированную на пользователя, результатом всплеска является документация того, что было изучено, и разбивка работы для практического применения в реальном приложении.

На практике я обнаружил, что это хороший способ управлять, по крайней мере, мелкомасштабным обучением - достаточно, чтобы освоить разработчиков с новой системой или структурой, при этом оставаясь подотчетным расписанию.

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

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

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

1. Текущее развитие

Это самый простой способ: уменьшайте свои возможности в каждом спринте, пока у вас не будет достаточно времени для постоянной разработки. Трудная часть, как правило, придерживается вашего плана, а также выполняет разработку, если есть другие задачи, которые нужно решить. Если у вас есть чрезвычайные ситуации, вы можете пожертвовать это время от времени, но в противном случае нет.

Поскольку вы сократили свои возможности, все, что вы делаете в этой категории, несколько выходит за рамки непосредственного беспокойства других членов команды, и у них, вероятно, нет особых оснований беспокоиться об этом или обновлять планирование специально для каждого отдельного спринта.

2. Большие усилия во время спринта

Я обнаружил, что если вы запланировали что-то с большим эффектом (например, 2-дневная тренировка во время спринта), вы должны обновить спринт, чтобы отразить это. Я не уверен, каково теоретическое решение для этого, но я часто видел, что люди просто помещают задачу по обучению на доску, чтобы убедиться, что кто-то этим занимается.

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

Agile - это набор философий, взгляните на манифест, это ВСЕ Agile, поэтому, когда вы говорите, как Agile может решить мои проблемы, я рекомендую узнать (много) больше о Agile. Давайте рассмотрим конкретную реализацию Agile: SCRUM. В SCRUM есть понятия о спринте и шипах. С помощью этих двух артефактов можно создать бюджет для обучения.

Если вы смотрите на спринт как круговую диаграмму, вы можете разделить приоритеты по темам, одной из таких тем может быть ... изучение новых навыков!

Спайк - это исследовательская задача по спринту, которая включает оценку осуществимости чего-либо, обычно путем обучения.

Наконец, то, что вы делали, все еще находится на столе, и вы можете научиться КОГДА делать то, над чем вы работаете, и в этот момент вы можете попытаться увеличить сюжетные очки / способность справиться с технической задачей.

Чтобы процитировать сам Agile Manifesto :

Лица и взаимодействие над процессами и инструменты
Работа программного обеспечения более всеобъемлющей документация
сотрудничества с клиентами по контракту переговоров
Реакции на изменения в течение следующего плана

Акцент мой, выделяя те части, которые, вероятно, наиболее применимы к вам.

По сути, хорошо обученные гибкие разработчики могут гораздо лучше реагировать на изменение среды, чем те, кто позволяет своим навыкам окаменеть.

Если я могу добавить свое собственное определение agile, мы также можем включить «взаимодействие с клиентами». Я считаю, что лучшее определение agile - это определение, основанное на идее гибкости - если клиент (или среда) радикально меняется, насколько хорошо вы справляетесь? Если вы создаете среду для совместной работы с клиентами, они будут заинтересованы в том, чтобы ваша команда знала, что они делают.