[Высокая производительность, Программирование] Парное программирование. Быть или не быть?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет. Меня зовут Вадим Бараненко. С украинским офисом EPAM я сотрудничаю в роли архитектора решений. И в этом материале я хотел бы поделиться своими взглядами и опытом в такой интересной теме, как парное программирование (далее — ПП). С ПП я впервые познакомился около 9 лет назад и практиковал этот подход на разных проектах — часть в харьковском офисе EPAM, часть на территории заказчика в Англии. И этот опыт показался мне интересным и полезным. Первый проект, на котором я столкнулся с ПП, был для одного из крупнейших ритейлеров Англии. Клиент использовал гибкие методологии разработки, экстремальное программирование (ХР), в частности ПП, test-driven development. Во время этой работы я заинтересовался практиками повышения продуктивности. В тоже время у EPAM появился заказчик, который хотел получить команду с такими навыками. Поэтому я согласился собрать и отстроить инженерные практики. Вскоре появилась потребность в еще одной команде, и я перешел туда — стартовать процессы в роли лида. Позже переехал в Англию и стал работать уже на стороне клиента. Там у нас была настоящая Agile-команда без лидов, хотя все инженеры были очень опытными. Работать рука об руку с людьми из разных стран и с разным культурным опытом было довольно интересным вызововм. В коллективе были инженеры из Нигерии, Индии, Египта, Англии, Украины. Интересности происходили даже на уровне языка. Теперь мне все чаще встречаются проекты со значительным объемом работ и конкретными бюджетами. В таком формате едва ли можно позволить двум программистам работать над одной задачей. Однако иногда использовать ПП все-таки можно. Так, три года назад проблема на продакшин «упала» поздно вечером. И вместе с лидом проекта мы сели в пару. Код писали по принципу TDD, чтобы быть уверенными, что ничего не сломаем. И в который раз убедились: когда над кодом работает два инженера с разным мышлением, то вероятность ошибки значительно уменьшается. Простой пример: я увидел в коде пять потенциальных дефектов, столько же — мой партнер. Три дефекта совпали, но в общем мы нашли еще больше огрехов, которые могли привести к ошибкам в продакшине. Почему ПП — не слишком популярная практика «Продать» заказчику ПП довольно сложно. Большинство не понимает, почему над одной задачей должны работать два инженера. Поверхностные подсчеты показывают, что проект потребует в два раза больше времени и средств. Чтобы согласиться на ПП, клиент должен или с самого начала позитивно относиться к Agile-методологиям, или проходить через трансформацию собственного бизнеса, желая понять и разобраться в этих процессах. Важно, чтобы ИТ-отдел клиента был готов к гибким технологиям, а сам клиент — настроен платить за качество. ПП дает возможность вывести на рынок практически идеальный продукт в спокойные и ожидаемые сроки. Для жестких дедлайнов, наверное, ПП — не лушчая идея. Но давайте по порядку. Экстремальное программирование (XP) было создано во второй половине 90-х и на тот период выводило изветсные подходы к созданию продуктов на новый уровень. 25 лет назад, во времена расцвета каскадной модели разрабоки, существовали трудности с тем, чтобы интегрировать, тестировать, создать дизайн разных частей продукта и наладить коммуникации между разработчиками. Одной из практик ХР, которая обещала быстрый обмен знаниями о системе, ревъю кода фактически в режиме реального времени и своевренное создание дизайна системы, стало парное программирование. ПП и сегодня дает возможность заниматься кодом вместе и делать существенно меньшие релизы. Это упрощает внесение изменений и улучшает качество продукта. Как организовать ПП: наша версияПроцесс ПП можно строить по-разному. Существует канонический подход, который рекомендует Кент Бек (один из основателей ХР): пары инженеров сидят за большим столом с одним монитором, одной мышкой и клавиатурой. Однако в ЕРАМ мы несколько модифицировали этот подход. ПространствоДва программиста сидят за большим столом с одним системны блоком, но двумя мониторами, мышками и клавиатурами. Так, по нашему мнению, работать удобнее. Стол должен быть прямым. Вначале мы использовали угловые, но практика показала, что это не очень удобно. При таком подходе иногда приходилось передвигать мебель, чтобы сидеть рядом, иметь нормальное пространство для общения. Такие манипуляции — лишнее время и суета. Командная работаЧтобы построить процессы, вы должны иметь авторитет. Ведь иногда сложно объяснить заказчику, менеджменту и инженерам важность ПП. Если клиент и менеджмент этот подход принимают, а сложности остаются только с командой, вам следует уделить время на построение хороших отношений. Культура должна базироваться на взаимопомощи, а не осуждении. В ПП один (ведущий) пишет код, другой — наблюдает, осмысливает и корректирует процесс, чтобы он отвечал требованиям дизайна. Такое взаимодействие напоминает связку пилота и штурмана в раллийных гонках. Такой подход требует частой смены ролей, чтобы каждый имел возможность и писать, и проверять код, над которым работает напарник. Еще одна полезная техника — объединение TDD и ПП, когда один пишет текст, а второй — имплементацию. Потом запускаем тест и меняем роли. При таком подходе никто не заскучает. Также пары должны постоянно меняться. Благодаря этому каждый программист в команде имеет представление о всей системе, а не только об одной ее части. Сперва мы пренебрегали этой рекомендацией. Во время планирования спринта выдавали одну User Story на пару, а в процессе разработки уже не могли ее разделить. Позже, когда одна пара заканчивала работу над User Story, другие обычно еще продолжали работаь над своими. Конечно, их также нельзя было разделить. Уже в Англии я столкнулся с подходом, который, по моему мнению, работает лучше. Нужно, чтобы задачу брал один программист, а второй ему помогал. Во-первых, мы решаем психологический вопрос, когда некоторым инженерам комфортно работать с одними людьми, но крайне некомфортно — с другими. Во-вторых, решаем вопрос логистический, т.к. помощнику не нужно переносить свои вещи на новое место для непродолжительной работы. Поэтому пару следует создавать на один день или задачу. Инженеры в паре должны смотреть на одну и ту же самую часть кода, общаться между собой голосом. «Штураману» не следует перебирать управление в свои руки. Хорошая практика — обратить внимание на огрехи, рассказать и обсудить, что можно сделать иначе. Мой опыт доказывает, что в паре можно качественно натренировать Junior’ов. Это несколько не соответствует канонам, т.к. программисты должны быть близки по своему профессиональному уровню. Но, если подходить к процессу разумно, не отбирать у новичка «руль» и общаться, вполне может сработать. Надеюсь, я смог объяснить, что ПП может быть полезным на проекте. А теперь перейдем к плюсам и минусам этого подхода. Преимущества ППОбмен знаниями. Вы можете оперативно делиться информацией и не зависеть от одного человека. Если кто-то из команды пойдет в отпуск или на больничный, другие все равно будут иметь полную картинку. Этого можно достичь, если регулярно менять пары. Качество кода повышается. Разные подходы к работе и взгляды на параметры кода могут дать хорошие результаты. Лучше дизайн на разных урвонях продукта. Если перед тем как писать код, программисты обсуждают его, то качество кода будет выше во всей системе. Конечно, ХР учит нас, что команда меньше времени уделяет дизайну продукта, чтобы сразу сфокусироваться на коде. Знаете, как часто молодые инженеры начинают писать код, едва получив задание? Вот в таких случаях работа в паре помогает больше думать и экономить время на исправление дефектов. На мой взгляд, это даже эффективнее, чем два программиста, которые работают над двумя разными задачами параллельно. Выше эффективность команды. Как уже отмечал, если кто-то присматривает за работой специалиста, он выполняет ее лучше, чем в одиночку. И это не история о так называемых low-перформерах (т.е. тех, кто демонстрирует посредственные результаты). Это элементарная психология. Меньше контроля со стороны менеджеров. Ведь в ПП члены команды контролируют друг друга. Общая ответственность за выполнение задания мотивирует показывать более высокие результаты. Недостатки ППИнженерам психологически сложно начать работать с кем-то в паре. Во-первых, не всем нравится, когда за их работой бдительно следят. Так, когда в 2012, будучи Senior-уровня, я начинал работать в паре, то боялся, что могу чего-то не знать, ищу ответы на некоторые вопросы в Сети. Теперь же я — архитектор решений, и практика доказала, что люди не могут знать все и это нормально. Во-вторых, не все стремятся работать 100% рабочего времени. Хороший результат — шесть продуктивных часов. Больше — и команда может дойти до выгорания, исчерпать свои ресурсы. Чтобы избежать этого можно внедрить в парах известный метод Pomodoro: так инженеры будут работать 20-30 минут вместе, а потом уходить на 10-минутный перерыв, чтобы переключиться. Не каждому заказчику можно легко доказать важность ПП. Самое сложное — доказать эффективность такого подхода клиентам, далеким от ИТ-сферы (ведь зачем двоим работать над тем, что может сделать один?). А самое простое — клиентам, проекты которых имеют фиксированные дедлайны и объемы работы на конкретный период. Такие проекты идут вразрез с некоторыми принципами гибких методологий, ведь команда только частично контролирует процесс, однако ПП позвояет эффективнее решать сложные задачи. Когда с процессами что-то пошло не так. Например, лид, Scrum-мастер или другой ответственный человек пропустил кризисную ситуацию. Скажем, или никто сразу не установил правила работы в парах, или посадил за один стол совсем разных по темпераменту или профессиональному уровню специалистов, или вовсе забыл о необходимости смены пар... Все это ломает подход к ПП, плохая репутация проекта распространяется со скоростью света, и привлекать новых инженеров становится все сложнее. Самые большие трудности возникают, когда люди не взаимодействуют эффективно, не доверяют друг другу и не понимают, зачем им работать вместе. Работать удаленно и применять ПП практически нереально. Есть некоторые онлайн-инструменты, но я практически никогда ими не пользовался. Здесь не хватает главного — живого контакта людей. И минутка стереотипов Бытует мнение, что программисты не очень людям иметь дело с другими людьми. Мол, им больше по душе общаться с «железками», а в ПП придется активно взаимодействовать с другими членами команды, постоянно объяснять свои действия. На самом деле, ПП действительно может раздражат и подходит далеко не всем. Вы все-таки решились внедрить ПП. Что дальше?Начните с пиара Расскажите команде, менеджменту и заказчикам зачем вы это делаете, каких сложностей при помощи ПП можете избежать, как сделать так, чтобы ПП работало правильно. Попробуйте внедрять его не сразу, а постепенно. Например, когда будут сложные задания. Во время планирования позволяйте инженерам самим выбрать задание по душе и приглашать коллег присоедениться к работе. Если в вашей команде есть человек с опытом ПП, постарайтесь, чтобы он поработал по очереди с каждым членом команды. Так делал я, когда настраивал процессы ПП и TDD на ряде новых проектов. Фактически — был ментором и показывал лучшие практики новичкам. Перед тем, как начать работу, попробуйте определить страхи вашей команды, связанные с внедрением ПП. Объясните, что никто никого не будет осуждать за ошибки или неидеальные решения, а время на кофе останется. Акцентируйте внимание на том, что благодаря такой работе можно выучить много нового и подсмотреть лучшие практики своих коллег: вот Игорь, скажем, делает классные тесты, а Срегей замечательно испарвляет баги. Опыт каждого члена команды станет богаче благодаря ПП, это хорошо не только для понимания продукта, а и для самоорганизации. Конечно, «в плюсе» будут и менеджеры — в паре люди работают эффективнее, ведь валять дурака перед коллегой как-то стыдно. ПП — не серебрянная пуля, но может будет полезным для некоторых проектов. Расскажите, доводилось ли вам работать в паре? Может, знаете классные ресурсы, чтобы погрузиться в тему? Буду рад пообщаться и обменяться опытом в комментариях.Вот немного моих полезных ссылок:
- Kent Beck, Extreme Programming Explained: Embrace Change, 2nd Edition.
- Robert Martin, The Clean Coder: A Code of Conduct for Professional Programmers.
- Видео от Роберта Мартина
===========
Источник:
habr.com
===========
Похожие новости:
- [Высокая производительность, Облачные вычисления, Развитие стартапа, Процессоры] Ampere начнет выпускать серверные чипы с собственными вычислительными ядрами
- [Криптография, Программирование, *nix, Автомобильные гаджеты] Тесла верит своим Богам! Так она находит путь
- [Программирование, Карьера в IT-индустрии, Умный дом, Интернет вещей, Интервью] Интервью с менеджером проектов АСУ: цифровизация, интернет вещей и «умные» города
- [Open source, Python, Программирование, PDF] Создание PDF-документа на Python с помощью pText (перевод)
- [Программирование, Разработка мобильных приложений, Flutter] Flutter: флип-анимация (перевод)
- [Программирование, Анализ и проектирование систем, Аналитика мобильных приложений] Какие ошибки совершает аналитик в первые полгода работы и как их избежать
- [Программирование, Машинное обучение, Научно-популярное, Искусственный интеллект] Дождались: IBM научит ИИ писать код и создает CodeNet (перевод)
- [Программирование, Управление проектами] Неожиданная сложность простых программ
- [Программирование, Разработка мобильных приложений, Конференции, Flutter] Анонс эфира Flutter live-coding сессии
- [Программирование, Разработка робототехники, Развитие стартапа, Робототехника] Анализ рынка детского технического образования в России / Планы на будущее
Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_programmirovanie (Программирование), #_parnoe_programmirovanie (парное программирование), #_blog_kompanii_epam (
Блог компании EPAM
), #_vysokaja_proizvoditelnost (
Высокая производительность
), #_programmirovanie (
Программирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:08
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет. Меня зовут Вадим Бараненко. С украинским офисом EPAM я сотрудничаю в роли архитектора решений. И в этом материале я хотел бы поделиться своими взглядами и опытом в такой интересной теме, как парное программирование (далее — ПП). С ПП я впервые познакомился около 9 лет назад и практиковал этот подход на разных проектах — часть в харьковском офисе EPAM, часть на территории заказчика в Англии. И этот опыт показался мне интересным и полезным. Первый проект, на котором я столкнулся с ПП, был для одного из крупнейших ритейлеров Англии. Клиент использовал гибкие методологии разработки, экстремальное программирование (ХР), в частности ПП, test-driven development. Во время этой работы я заинтересовался практиками повышения продуктивности. В тоже время у EPAM появился заказчик, который хотел получить команду с такими навыками. Поэтому я согласился собрать и отстроить инженерные практики. Вскоре появилась потребность в еще одной команде, и я перешел туда — стартовать процессы в роли лида. Позже переехал в Англию и стал работать уже на стороне клиента. Там у нас была настоящая Agile-команда без лидов, хотя все инженеры были очень опытными. Работать рука об руку с людьми из разных стран и с разным культурным опытом было довольно интересным вызововм. В коллективе были инженеры из Нигерии, Индии, Египта, Англии, Украины. Интересности происходили даже на уровне языка. Теперь мне все чаще встречаются проекты со значительным объемом работ и конкретными бюджетами. В таком формате едва ли можно позволить двум программистам работать над одной задачей. Однако иногда использовать ПП все-таки можно. Так, три года назад проблема на продакшин «упала» поздно вечером. И вместе с лидом проекта мы сели в пару. Код писали по принципу TDD, чтобы быть уверенными, что ничего не сломаем. И в который раз убедились: когда над кодом работает два инженера с разным мышлением, то вероятность ошибки значительно уменьшается. Простой пример: я увидел в коде пять потенциальных дефектов, столько же — мой партнер. Три дефекта совпали, но в общем мы нашли еще больше огрехов, которые могли привести к ошибкам в продакшине. Почему ПП — не слишком популярная практика «Продать» заказчику ПП довольно сложно. Большинство не понимает, почему над одной задачей должны работать два инженера. Поверхностные подсчеты показывают, что проект потребует в два раза больше времени и средств. Чтобы согласиться на ПП, клиент должен или с самого начала позитивно относиться к Agile-методологиям, или проходить через трансформацию собственного бизнеса, желая понять и разобраться в этих процессах. Важно, чтобы ИТ-отдел клиента был готов к гибким технологиям, а сам клиент — настроен платить за качество. ПП дает возможность вывести на рынок практически идеальный продукт в спокойные и ожидаемые сроки. Для жестких дедлайнов, наверное, ПП — не лушчая идея. Но давайте по порядку. Экстремальное программирование (XP) было создано во второй половине 90-х и на тот период выводило изветсные подходы к созданию продуктов на новый уровень. 25 лет назад, во времена расцвета каскадной модели разрабоки, существовали трудности с тем, чтобы интегрировать, тестировать, создать дизайн разных частей продукта и наладить коммуникации между разработчиками. Одной из практик ХР, которая обещала быстрый обмен знаниями о системе, ревъю кода фактически в режиме реального времени и своевренное создание дизайна системы, стало парное программирование. ПП и сегодня дает возможность заниматься кодом вместе и делать существенно меньшие релизы. Это упрощает внесение изменений и улучшает качество продукта. Как организовать ПП: наша версияПроцесс ПП можно строить по-разному. Существует канонический подход, который рекомендует Кент Бек (один из основателей ХР): пары инженеров сидят за большим столом с одним монитором, одной мышкой и клавиатурой. Однако в ЕРАМ мы несколько модифицировали этот подход. ПространствоДва программиста сидят за большим столом с одним системны блоком, но двумя мониторами, мышками и клавиатурами. Так, по нашему мнению, работать удобнее. Стол должен быть прямым. Вначале мы использовали угловые, но практика показала, что это не очень удобно. При таком подходе иногда приходилось передвигать мебель, чтобы сидеть рядом, иметь нормальное пространство для общения. Такие манипуляции — лишнее время и суета. Командная работаЧтобы построить процессы, вы должны иметь авторитет. Ведь иногда сложно объяснить заказчику, менеджменту и инженерам важность ПП. Если клиент и менеджмент этот подход принимают, а сложности остаются только с командой, вам следует уделить время на построение хороших отношений. Культура должна базироваться на взаимопомощи, а не осуждении. В ПП один (ведущий) пишет код, другой — наблюдает, осмысливает и корректирует процесс, чтобы он отвечал требованиям дизайна. Такое взаимодействие напоминает связку пилота и штурмана в раллийных гонках. Такой подход требует частой смены ролей, чтобы каждый имел возможность и писать, и проверять код, над которым работает напарник. Еще одна полезная техника — объединение TDD и ПП, когда один пишет текст, а второй — имплементацию. Потом запускаем тест и меняем роли. При таком подходе никто не заскучает. Также пары должны постоянно меняться. Благодаря этому каждый программист в команде имеет представление о всей системе, а не только об одной ее части. Сперва мы пренебрегали этой рекомендацией. Во время планирования спринта выдавали одну User Story на пару, а в процессе разработки уже не могли ее разделить. Позже, когда одна пара заканчивала работу над User Story, другие обычно еще продолжали работаь над своими. Конечно, их также нельзя было разделить. Уже в Англии я столкнулся с подходом, который, по моему мнению, работает лучше. Нужно, чтобы задачу брал один программист, а второй ему помогал. Во-первых, мы решаем психологический вопрос, когда некоторым инженерам комфортно работать с одними людьми, но крайне некомфортно — с другими. Во-вторых, решаем вопрос логистический, т.к. помощнику не нужно переносить свои вещи на новое место для непродолжительной работы. Поэтому пару следует создавать на один день или задачу. Инженеры в паре должны смотреть на одну и ту же самую часть кода, общаться между собой голосом. «Штураману» не следует перебирать управление в свои руки. Хорошая практика — обратить внимание на огрехи, рассказать и обсудить, что можно сделать иначе. Мой опыт доказывает, что в паре можно качественно натренировать Junior’ов. Это несколько не соответствует канонам, т.к. программисты должны быть близки по своему профессиональному уровню. Но, если подходить к процессу разумно, не отбирать у новичка «руль» и общаться, вполне может сработать. Надеюсь, я смог объяснить, что ПП может быть полезным на проекте. А теперь перейдем к плюсам и минусам этого подхода. Преимущества ППОбмен знаниями. Вы можете оперативно делиться информацией и не зависеть от одного человека. Если кто-то из команды пойдет в отпуск или на больничный, другие все равно будут иметь полную картинку. Этого можно достичь, если регулярно менять пары. Качество кода повышается. Разные подходы к работе и взгляды на параметры кода могут дать хорошие результаты. Лучше дизайн на разных урвонях продукта. Если перед тем как писать код, программисты обсуждают его, то качество кода будет выше во всей системе. Конечно, ХР учит нас, что команда меньше времени уделяет дизайну продукта, чтобы сразу сфокусироваться на коде. Знаете, как часто молодые инженеры начинают писать код, едва получив задание? Вот в таких случаях работа в паре помогает больше думать и экономить время на исправление дефектов. На мой взгляд, это даже эффективнее, чем два программиста, которые работают над двумя разными задачами параллельно. Выше эффективность команды. Как уже отмечал, если кто-то присматривает за работой специалиста, он выполняет ее лучше, чем в одиночку. И это не история о так называемых low-перформерах (т.е. тех, кто демонстрирует посредственные результаты). Это элементарная психология. Меньше контроля со стороны менеджеров. Ведь в ПП члены команды контролируют друг друга. Общая ответственность за выполнение задания мотивирует показывать более высокие результаты. Недостатки ППИнженерам психологически сложно начать работать с кем-то в паре. Во-первых, не всем нравится, когда за их работой бдительно следят. Так, когда в 2012, будучи Senior-уровня, я начинал работать в паре, то боялся, что могу чего-то не знать, ищу ответы на некоторые вопросы в Сети. Теперь же я — архитектор решений, и практика доказала, что люди не могут знать все и это нормально. Во-вторых, не все стремятся работать 100% рабочего времени. Хороший результат — шесть продуктивных часов. Больше — и команда может дойти до выгорания, исчерпать свои ресурсы. Чтобы избежать этого можно внедрить в парах известный метод Pomodoro: так инженеры будут работать 20-30 минут вместе, а потом уходить на 10-минутный перерыв, чтобы переключиться. Не каждому заказчику можно легко доказать важность ПП. Самое сложное — доказать эффективность такого подхода клиентам, далеким от ИТ-сферы (ведь зачем двоим работать над тем, что может сделать один?). А самое простое — клиентам, проекты которых имеют фиксированные дедлайны и объемы работы на конкретный период. Такие проекты идут вразрез с некоторыми принципами гибких методологий, ведь команда только частично контролирует процесс, однако ПП позвояет эффективнее решать сложные задачи. Когда с процессами что-то пошло не так. Например, лид, Scrum-мастер или другой ответственный человек пропустил кризисную ситуацию. Скажем, или никто сразу не установил правила работы в парах, или посадил за один стол совсем разных по темпераменту или профессиональному уровню специалистов, или вовсе забыл о необходимости смены пар... Все это ломает подход к ПП, плохая репутация проекта распространяется со скоростью света, и привлекать новых инженеров становится все сложнее. Самые большие трудности возникают, когда люди не взаимодействуют эффективно, не доверяют друг другу и не понимают, зачем им работать вместе. Работать удаленно и применять ПП практически нереально. Есть некоторые онлайн-инструменты, но я практически никогда ими не пользовался. Здесь не хватает главного — живого контакта людей. И минутка стереотипов Бытует мнение, что программисты не очень людям иметь дело с другими людьми. Мол, им больше по душе общаться с «железками», а в ПП придется активно взаимодействовать с другими членами команды, постоянно объяснять свои действия. На самом деле, ПП действительно может раздражат и подходит далеко не всем. Вы все-таки решились внедрить ПП. Что дальше?Начните с пиара Расскажите команде, менеджменту и заказчикам зачем вы это делаете, каких сложностей при помощи ПП можете избежать, как сделать так, чтобы ПП работало правильно. Попробуйте внедрять его не сразу, а постепенно. Например, когда будут сложные задания. Во время планирования позволяйте инженерам самим выбрать задание по душе и приглашать коллег присоедениться к работе. Если в вашей команде есть человек с опытом ПП, постарайтесь, чтобы он поработал по очереди с каждым членом команды. Так делал я, когда настраивал процессы ПП и TDD на ряде новых проектов. Фактически — был ментором и показывал лучшие практики новичкам. Перед тем, как начать работу, попробуйте определить страхи вашей команды, связанные с внедрением ПП. Объясните, что никто никого не будет осуждать за ошибки или неидеальные решения, а время на кофе останется. Акцентируйте внимание на том, что благодаря такой работе можно выучить много нового и подсмотреть лучшие практики своих коллег: вот Игорь, скажем, делает классные тесты, а Срегей замечательно испарвляет баги. Опыт каждого члена команды станет богаче благодаря ПП, это хорошо не только для понимания продукта, а и для самоорганизации. Конечно, «в плюсе» будут и менеджеры — в паре люди работают эффективнее, ведь валять дурака перед коллегой как-то стыдно. ПП — не серебрянная пуля, но может будет полезным для некоторых проектов. Расскажите, доводилось ли вам работать в паре? Может, знаете классные ресурсы, чтобы погрузиться в тему? Буду рад пообщаться и обменяться опытом в комментариях.Вот немного моих полезных ссылок:
=========== Источник: habr.com =========== Похожие новости:
Блог компании EPAM ), #_vysokaja_proizvoditelnost ( Высокая производительность ), #_programmirovanie ( Программирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:08
Часовой пояс: UTC + 5