Часто задаваемые вопросы по ретроспективам, Naresh Jain (билингва-перевод)
Представляю вашему вниманию билингва-перевод статьи Naresh Jain “Retrospectives: FAQs”:
Retrospectives: FAQshttp://blogs.agilefaqs.com/2006/06/25/retrospectives-faqs/ Naresh Jain |
Часто задаваемые вопросы по ретроспективамNaresh Jain перевод – Алексей Тигарев, http://nlp.od.ua/ |
| What is a retrospective? |
Что такое ретроспектива? |
| Retrospective (from Latin retrospectare, “look back”) generally means to take a look back at events that already have taken place. |
Провести ретроспективу (от латинского retrospectare, “смотреть назад”) означает посмотреть назад, на уже произошедшие события. |
| In the software world, a retrospective is a meeting held with a project team at the end of a project or process to discuss what was successful about the project, what could be improved, and how to incorporate the successes and improvements in future projects. |
В мире разработки программного обеспечения ретроспектива — совещание, которое проводится с проектной командой в конце проекта с целью обсудить, что было успешно в проекте, что может быть улучшено, и как включить усовершенствования в будущие проекты. |
| In the agile software world, a retrospective is a meeting held by the project team at the end of every iteration/sprint to discuss what we learnt as a team, what we can improve as a team and plan the future iteration/sprint based on this learning. |
В мире гибких методологий разработки, ретроспектива — собрание, которое проводит проектная команда в конце каждой итерации/спринта, чтобы обсудить, чему мы научились, как команда и строить планы на следующие итерации/спринты, основываясь на извлечённых уроках. |
| Why do we need retrospectives? |
Зачем нам нужны реторспективы? |
|
1. Ретроспектива помогает усовершенствовать процесс обучения. Рефлексия — ключевой шаг в обучении на основе опыта. Ретроспектива помогает сделать слепок непрерывного процесса обучения команды и продвинуть его на шаг вперёд. |
|
2. Ретроспективы — элемент Коммуникации и Обратной связи (Communication, Feedback — ценности XP, прим. перев.) для любой agile-команды. |
|
3. Помогает команде адаптировать процессы, основываясь на её опыте, понимании, что работает, а что нет. Другими словами, ретроспектива является для команды способом адаптировать процесс к своим условиям. |
|
4. Помогает команде сознательно работать над улучшением качества работы, повышением удовлетворения от неё и культурой работы. |
|
5. Помогает команде организовать себя, распределяя полномочия между членами команды. |
| What should be the scope/focus of a retrospective? Technical/Process/People? |
Какие факторы должны рассматриваться на ретроспективе? Технические, процессные, человеческий фактор? На чём она должна фокусироваться? |
| Retrospectives should be focused at improving customer and team satisfaction. Which means, we have to focus heavily on people and the process around them, their interactions/communication patterns, workspace and work culture. Everything else is secondary. |
Ретроспективы должны сосредотачиваться на том, как улучшить удовлетворённость заказчика и команды. Это означает, что мы должны сосредотачиваться на людях, процессах вокруг них, шаблонах их взаимодействия/ коммуникации, культуре рабочего пространства и работы. Всё остальное вторично. |
| How long should a retrospective be for? |
Сколько должна длится ретроспектива? |
| They can be 15 mins to 2 days. As long as the group have or feel something important to discuss. If retrospectives are always lengthy, it might mean you need to increase their frequency. Even after increasing the frequency does not solve the problem, it means something important on the project is broken and it needs to be fixed. |
От пятнадцати минут до двух дней. Столько, сколько можно себе позволить, столько, сколько команда считает нужным уделить на обсуждение. Если ретроспективы постоянно оказываются долгими, значит, нужно проводить их чаще. Если увеличение частоты не решает проблему, значит, что-то важное в проекте сломалось и должно быть починено. |
| How do you decide the frequency of retrospectives? |
Какую частоту проведения ретроспектив установить? |
| Lots of factors contribute towards this. Team size, experience working together, nature of the work, etc. Ideally you need frequent retrospectives to begin with, but as you go on, it should become less frequent and shorter. Most of the agile projects end of the iteration/sprint is a good time to have a retrospective. |
На это влияет множество факторов. Размер команды, опыт совместной работы, природа самой работы и т. д.. В идеале начинать следует с частых ретроспектив, но по мере продвижения вперёд, они должны становиться короче и проводиться с меньшей частотой. В большинстве agile-проектов конец итерации/спринта отлично подходит для проведения ретроспективы. |
| When should one schedule/time a retrospective? |
Когда проводить ретроспективу? |
| The schedule of a retrospective is very important. Trying to mix them up with lots of other meetings on the same day can make it very ineffective. Participants should not feel like it‘s just another meeting. I would ideally conduct a retrospective at the end of the iteration/sprint and before the planning meeting. Outcome of the retrospective can greatly affect the next iteration/sprint planning. |
Место ретроспективы в расписании весьма важно. Смешивание ретроспективы со многими другими совещаниями в течение того же рабочего дня может сделать её очень неэффективной. Участники не должны думать, что это просто ещё одно совещание. Лучше всего проводить ретроспективу в конце итерации и перед собранием по планированию следующей итерации. Результат ретроспективы может оказать сильное влияние на последующее планирование спринта/итерации. |
| What is the best location to hold a retrospective? |
Где лучше всего проводить ретроспективу? |
| Same location as the team room can be a mind block. [Too much of the same thing.] I prefer a conference room with a lot of white boards, open walls [visible surface] to stick cards/posters and food. It should be away from people‘s workstations and phones. Some people prefer going to a bar/pub for these meetings. |
Проведение ретроспективы в комнате команды может блокировать сознание (слишком много одного и того же). Я предпочитаю проводить их в конференц-комнате со множеством досок, свободными стенами (видимым пространством) для цепляния карточек/постеров и с едой. Это должно быть вдали от рабочих станций и телефонов участников. Некоторые люди предпочитают устраивать подобные встречи в баре или пабе. |
| Who should facilitate the retrospective? |
Кто должен проводить ретроспективу? |
| It is difficult to say who would be a good facilitator. But it‘s easy to say who should not play the role of the facilitator. Team leads, Iteration Managers, Scrum Masters, Managers, etc are a big NO NO. You want an unbiased person who has sufficient knowledge about the project and process. Having someone from the team facilitate has the risk of turning the discussion towards personal goals. Getting someone from outside can reduce personal conflicts. But at the risk of not having a focused discussion targeted towards the real pain points. The discussion can turn out to be very superficial. |
Сложно сказать, кто будет хорошим фасилитатором. Однако, сказать кто им НЕ будет — легко. Тимлиды, руководители итераций, скрам-мастера, менеджеры — это большое НЕ-НЕ-НЕ. Вам нужен человек, который одноврменно свободен от предвзятого отношения к вопросу и достаточно осведомлён о проекте и процессе. Если доверить фасилитацию кому-то из команды, есть риск смещения дискуссии в сторону его личных целей. Привлечение кого-то со стороны способно свести к минимуму личные конфликты. Но в этом случае есть риск, что не получится сосредоточенного обсуждения в отношении действительных болевых точек. Обсуждение может оказаться очень поверхностным. |
| Who should take the responsibility of following up on the action items? |
Кто должен быть ответственным за выполнение принятых решений? |
| Ideally the team and not just the manager. We want to build self organized teams who can constantly learn and fix problems. |
Лучше всего — сама команда, а не менеджер. Мы хотим строить самоорганизующиеся команды, сопособные постоянно учиться и решать проблемы. |
| Should retrospectives just try to identify issues or should they try to come up with resolutions? |
Достоточно ли на ретроспективах просто идентифицировать проблемы, или нужно пытаться найти решения? |
| Retrospectives are brainstorming session which should try to identify issues, find the root cause and try to come up with an unanimous resolution. |
Ретроспективы — это сеансы мозгового штурма, на которых мы пытаемся идентифицировать проблемы, найти их корни и предложить решение, которое будет единодушно поддержано. |
| If we just identify issues and leave them, what next? Who would resolve it? This would make the retrospectives a bitch session. Trying to come up with a unanimous resolution drives home the team ownership aspect. |
Если мы просто идентифицируем проблемы и оставим их, что дальше? Кто будет их разрешать? Так ретроспектива превратится в место для пересудов и высказывания претензий. Стремление найти приемлемое для всех решение добавляет необходимый аспект — ответственность команды. |
| Should the team vote for top x [say 3] issues? |
Надо ли голосовать за важнейшие x вопросов (скажем, 3) ? |
| Mixed feelings. While we need to start somewhere, the way to identify top 3 issues can be very difficult. If you have different number of people playing different roles [Dev, QA, Analyst, etc] on the team, the voting would be heavily biased towards the majority of people in a role. Developers might get their issues prioritized while QA issues might be neglected. Often different people rate issues differently. Letting team members own the issues and resolve them based on their priority can help the team overall. |
Смешанные чувства по этому поводу. Хотя необходимо выбрать, с чего же начинать, идентификация трёх важнейших вопросов может быть очень сложной. Если в команде разные роли (разработчики, QA, аналитики и т. д.), результаты голосование будут сильно зависеть от того, представители каких ролей составляют большинство. Разработчики могут протолкнуть свои вопросы на первые места, в то время как вопросы QA будут проигнорированы. Часто разные люди оценивают важность проблем по-разному. Дать членам команды возможность брать ответственность за решение тех или иных вопросов и разбираться с ними в порядке их индивидуальной оценки приоритетов помогает команде в целом. |
| Are retrospectives optional? |
Обязательно ли посещение ретроспектив? |
| Team members skipping retrospectives is a big project smell. Even if someone is not interested/willing to speak, they can still listen to other team member‘s perspectives. The team should focus on creating a work environment where all the team members have the sense of ownership. Once this happens, even if you try to stop people from attending retrospectives, they won‘t miss it. |
Члены команды, пропускающие ретроспективы — симптом серьёзных проблем в проекте, «плохой запах» (плохими запахами в Agile-литературе традиционно называют внешние — не всегда очевидные — признаки проблем). Если даже кто-то не собирается говорить на ретроспективе, они могут выслушать точки зрения других. Команда должна стремиться к созданию такой рабочей обстановки, в которой все члены команды чувствуют ответственность за общий результат. Как только это появляется, люди перестанут пропускать ретроспективы, даже если вы станете пытаться их туда не пускать. |
| Who all should participate in a retrospective? Who should be a part of the retrospectives? |
Кто должен участвовать в ретроспективе? |
| The whole team including the customers. Some times it is helpful to have chickens, other team members as silent spectators. It is important to have honest and open communication with in the whole team. Retrospectives have really helped my team build trust with the customer by improving communication and increasing visibility thru retrospectives. |
Вся команда, включая представителей заказчика. Иногда имеет смысл, чтобы присутствовали «цыплята» (так в Agile называют людей, вовлечённых в проект, но не выполняющих непосредственную работу — заказчики, менеджеры и т. п. - прим. перев.) и члены других команд в качестве молчаливых наблюдателей. Важна открытая и честная коммуникация, вовлекающая всю команду. Ретроспективы реально помогли моей команде построить доверительные отношения с заказчиком, улучшая коммуникацию и делая процесс более прозрачным через ретроспективы. |
| Can retrospectives be distributed? |
Могут ли ретроспективы быть распределёнными? |
| Mixed feelings. Retrospective is a way to resolve communication problems and give feedback. By having distributed people participate in retrospectives we might introduce the same issues with low quality of communication. Flip side is, if you do not involve distributed teams, each team might drift away into separate islands. A middle round can be worked out, where each team conducts their local retrospectives and then representatives from each location have a cross location retrospective. Preferably face to face. |
Смешанные чувства по этому поводу. Ретроспективы — способ разрешить коммуникативные проблемы и дать обратную связь. Если участники распределены, с самой ретроспективой могут возникнуть те же самые пробемы низкого качества коммуникации. Оборотная сторона этого — если вы не вовлекаете распределённые команды, каждая команда может дрейфовать в своём направлении, находясь как бы на острове. Можно устроить совместный «тур переговоров». При этом каждая команда/локация выделяет своих представителей и представители каждой локации устраивают межкомандную ретроспективу. Предпочтительнее - лицом к лицу, а не через интернет. |
Скачать перевод в виде pdf:
http://nlp.od.ua/download/agile/Retrospective_FAQs_bilingua.pdf
Еще нет комментариев.