Часто можно услышать от коллег, что в их команде не проводятся стендапы, потому что это не эффективно и превращается в бесконечный балаган. На самом деле стендап очень полезная церемония, которая помогает держать команду на одной волне. В статье "5 обязательных правил проведения эффектного стендапа" мы рассказываем, как сделать стендап полезным, быстрым и эффективным.
#agile_который_работает #владельцу_продукта
https://oros-it.ru/blog/five-steps-for-effective-stendup?utm_source=tg&utm_medium=article&utm_campaign=tg_post
#agile_который_работает #владельцу_продукта
https://oros-it.ru/blog/five-steps-for-effective-stendup?utm_source=tg&utm_medium=article&utm_campaign=tg_post
Сегодня поговорим о том, как владельцу продукта (ПО) наладить контакт со своей командой разработки. Поговорим про то, как стоит действовать и чего стоит избегать, чтобы получить доверие команды. Делитесь со своими ПО, чтобы проверить, знают ли они эти правила?
#agile_который_работает
#владельцу_продукта
#настройка_процессов
https://oros-it.ru/blog/how-can-po-deal-with-it-team?utm_source=tg&utm_medium=article&utm_campaign=tg_post
#agile_который_работает
#владельцу_продукта
#настройка_процессов
https://oros-it.ru/blog/how-can-po-deal-with-it-team?utm_source=tg&utm_medium=article&utm_campaign=tg_post
Почему важно правильно описывать задачи на разработку?
Если задача описана правильно и содержит в себе всю необходимую информацию для ее реализации, то исполнителю не приходится отвлекаться от на уточнения деталей и ждать ответа, выходя при этом из контекста и меняя свое техническое решение под каждую новую деталь. При этом, хорошо описанная задача, сводит к минимум вероятность неточной оценки и нарушения сроков. Такая задача проработана при постановке, у нее понятна цель и целевая аудитория, а значит это всегда функционал, который действительно нужен и не будет отложен в долгий ящик после реализации.
Принимая во внимание всю важной правильной постановки задачи, мы собрали для вас все самое важное для правильного описания задачи в одной статье. Разберем, как правильно описывать задачу, что такое критерии готовности задачи к разработке, критерии готовности задачи и критерии приемки, и чем эти понятия отличаются друг от друга.
#agile_который_работает #владельцу_продукта
https://oros-it.ru/blog/how-create-tickets-for-development?utm_source=tg&utm_medium=article&utm_campaign=tg_post
Если задача описана правильно и содержит в себе всю необходимую информацию для ее реализации, то исполнителю не приходится отвлекаться от на уточнения деталей и ждать ответа, выходя при этом из контекста и меняя свое техническое решение под каждую новую деталь. При этом, хорошо описанная задача, сводит к минимум вероятность неточной оценки и нарушения сроков. Такая задача проработана при постановке, у нее понятна цель и целевая аудитория, а значит это всегда функционал, который действительно нужен и не будет отложен в долгий ящик после реализации.
Принимая во внимание всю важной правильной постановки задачи, мы собрали для вас все самое важное для правильного описания задачи в одной статье. Разберем, как правильно описывать задачу, что такое критерии готовности задачи к разработке, критерии готовности задачи и критерии приемки, и чем эти понятия отличаются друг от друга.
#agile_который_работает #владельцу_продукта
https://oros-it.ru/blog/how-create-tickets-for-development?utm_source=tg&utm_medium=article&utm_campaign=tg_post
Орос IT
Как правильно описывать задачи на разработку
В статье про самоорганизующиеся команды мы говорили о том, как важны для хорошо и правильно описанные задачи на разработку. Давайте поговорим о том, как создать условия для того, чтобы задачи всегда описывались правильно и как это правильное описание должно…
Навигация по каналу
У нас набралось уже довольно много материалов. Чтобы вы не терялись мы сделали удобную навигацию по тегам. Она будет всегда в закрепленных сообщениях и мы будем ее дополнять по мере появления новых рубрик.
#разборкейса - разборы кейсов, вы можете прислать свой кейс на почту info@itleadassist.io
#чеклист - бесплатные чеклисты
#agile_который_работает - материалы по Agile в том виде, который реально работает
#настройка_процессов - материалы по процесса в команде
#построение_команды - все о построении команды, от структуры до обязанностей каждой должности
#владельцу_продукта - все что будет полезно для представителей бизнеса
#тимлиду - все что будет полезно тимлиду и любому руководителю
#советы - рубрика советов и статьи с советами
#ответы_на_вопросы - ответы на ваши вопросы
У нас набралось уже довольно много материалов. Чтобы вы не терялись мы сделали удобную навигацию по тегам. Она будет всегда в закрепленных сообщениях и мы будем ее дополнять по мере появления новых рубрик.
#разборкейса - разборы кейсов, вы можете прислать свой кейс на почту info@itleadassist.io
#чеклист - бесплатные чеклисты
#agile_который_работает - материалы по Agile в том виде, который реально работает
#настройка_процессов - материалы по процесса в команде
#построение_команды - все о построении команды, от структуры до обязанностей каждой должности
#владельцу_продукта - все что будет полезно для представителей бизнеса
#тимлиду - все что будет полезно тимлиду и любому руководителю
#советы - рубрика советов и статьи с советами
#ответы_на_вопросы - ответы на ваши вопросы
Как правильно трактовать Agile-манифест
Часто неправильная трактовка Agile-манифеста вредит работе команды, приводит к неправильному построению процессов, переработкам и падению качества продукта. Поэтому очень важно не просто знать Agile-манифест, а уметь правильно его трактовать, чтобы он помогал строить эффективную работу над действительно правильным продуктом. Поэтому в нашей рубрике #agile_который_работает мы будем разбирать основные идеи и принципы Agile в ключе правильного построения работы. Начнем с общих подходов, которые нужно использовать при трактовке Agile-манифеста, а в следующих постах подробно разберем каждый пункт.
Одно не исключает другое
Во всех основных идеях манифеста мы читаем противопоставление, на пример: “люди и взаимодействие важнее процессов и инструментов”. И это “важнее” многих сбивает с толку. Частая ошибка заключается в том, что основные идеи трактуются как “одно исключает другое”. И это совершенно неверно. Ни в одной основной идея Agile одно не исключает другое. Они лишь расставляют приоритеты в спорных ситуация (не в каждодневной работе), но не говорят о том, что в Agile не должно быть процессов (весь Agile в общем-то помогает строить процессы) или о том, что вы должны отменить все свои официальные контракты. Без процессов и документооборота работа не строится и не должна. Agile это всегда про гибкость и именно ее отражают основные идеи. Позже мы разберем каждую из них подробнее, сейчас лишь сформулируем основную мысль: основные идеи Agile не про исключение, они про гибкость.
Используйте здравый смысл
Принципы Agile, также, как и идеи, не должны трактоваться как безусловные правила без исключений. Если работающее программное обеспечение - лучше измеритель прогресса, это ни в коем случае не значит, что это единственный показатель прогресса. И то что лучше работают самоорганизующиеся команды, не значит, что только они имеют право на существование. Не каждая команда со старта готова к самоорганизации, да и условия для этого еще нужно создать. Поэтому не рассматривайте основные принципы как нерушимую истину, смотрите на ситуацию и используйте здравый смысл, чтобы понять, как правильно применить этот принцип в своей команде.
Одно не должно противоречить другому
Хорошим помощником в правильной трактовке манифеста является сравнение решения со всеми остальными принципами. Часто люди знают только про “люди важнее процессов” и “изменения приветствуются даже на поздних стадиях” - это очень удобно для манипуляции командой и трактуется как “долой процессы - привет необдуманным изменениям на любых стадиях”. Но принципы Agile-манифеста не должны использоваться в отрыве от всего остального. Простая сверка с другими принципами подскажет, что и процессы важны и изменения должны вводится не во вред техническому совершенству, уважению к команде и постоянному темпу. Поэтому никогда не концентрируйтесь на одном принципе, проверяйте чтобы ваше трактование не противоречило другим принципам. Иначе ваши процессы начнут разваливаться.
Основная идея Agile - гибкость, ничто не должно противоречить ей
Agile в своем названии не просто так отражает гибкость. Это сама основа Agile. И манифест в первую очередь строится таким образом, чтобы помочь развернуть мышление в нужную сторону. Но чтобы не запутаться в трактовке манифеста всегда нужно помнить основную мысль, что работа должна строится на гибкости. Это значит, что взяв за основу основные фреймворки Agile вы должны в первую очередь смотреть на то работает ли все это для вашей конкретной команды. И если что-то для нее не работает, то оно должно гибко подстраиваться под вашу конкретную ситуацию. Если, на пример, вы работаете с людьми, которые не могут работать в личном взаимодействии и постоянно нарушают договоренности, то отменяйте для себя этот принцип, потому что он для вас не работает. Ставьте на первое место жесткие процессы и документирование любых договоренностей, потому что для вас это работает только так (по крайней мере на данном этапе). Потому что самый важный принцип Agile - гибкость, с помощью которой он идеально адаптируется под любые ситуации.
Часто неправильная трактовка Agile-манифеста вредит работе команды, приводит к неправильному построению процессов, переработкам и падению качества продукта. Поэтому очень важно не просто знать Agile-манифест, а уметь правильно его трактовать, чтобы он помогал строить эффективную работу над действительно правильным продуктом. Поэтому в нашей рубрике #agile_который_работает мы будем разбирать основные идеи и принципы Agile в ключе правильного построения работы. Начнем с общих подходов, которые нужно использовать при трактовке Agile-манифеста, а в следующих постах подробно разберем каждый пункт.
Одно не исключает другое
Во всех основных идеях манифеста мы читаем противопоставление, на пример: “люди и взаимодействие важнее процессов и инструментов”. И это “важнее” многих сбивает с толку. Частая ошибка заключается в том, что основные идеи трактуются как “одно исключает другое”. И это совершенно неверно. Ни в одной основной идея Agile одно не исключает другое. Они лишь расставляют приоритеты в спорных ситуация (не в каждодневной работе), но не говорят о том, что в Agile не должно быть процессов (весь Agile в общем-то помогает строить процессы) или о том, что вы должны отменить все свои официальные контракты. Без процессов и документооборота работа не строится и не должна. Agile это всегда про гибкость и именно ее отражают основные идеи. Позже мы разберем каждую из них подробнее, сейчас лишь сформулируем основную мысль: основные идеи Agile не про исключение, они про гибкость.
Используйте здравый смысл
Принципы Agile, также, как и идеи, не должны трактоваться как безусловные правила без исключений. Если работающее программное обеспечение - лучше измеритель прогресса, это ни в коем случае не значит, что это единственный показатель прогресса. И то что лучше работают самоорганизующиеся команды, не значит, что только они имеют право на существование. Не каждая команда со старта готова к самоорганизации, да и условия для этого еще нужно создать. Поэтому не рассматривайте основные принципы как нерушимую истину, смотрите на ситуацию и используйте здравый смысл, чтобы понять, как правильно применить этот принцип в своей команде.
Одно не должно противоречить другому
Хорошим помощником в правильной трактовке манифеста является сравнение решения со всеми остальными принципами. Часто люди знают только про “люди важнее процессов” и “изменения приветствуются даже на поздних стадиях” - это очень удобно для манипуляции командой и трактуется как “долой процессы - привет необдуманным изменениям на любых стадиях”. Но принципы Agile-манифеста не должны использоваться в отрыве от всего остального. Простая сверка с другими принципами подскажет, что и процессы важны и изменения должны вводится не во вред техническому совершенству, уважению к команде и постоянному темпу. Поэтому никогда не концентрируйтесь на одном принципе, проверяйте чтобы ваше трактование не противоречило другим принципам. Иначе ваши процессы начнут разваливаться.
Основная идея Agile - гибкость, ничто не должно противоречить ей
Agile в своем названии не просто так отражает гибкость. Это сама основа Agile. И манифест в первую очередь строится таким образом, чтобы помочь развернуть мышление в нужную сторону. Но чтобы не запутаться в трактовке манифеста всегда нужно помнить основную мысль, что работа должна строится на гибкости. Это значит, что взяв за основу основные фреймворки Agile вы должны в первую очередь смотреть на то работает ли все это для вашей конкретной команды. И если что-то для нее не работает, то оно должно гибко подстраиваться под вашу конкретную ситуацию. Если, на пример, вы работаете с людьми, которые не могут работать в личном взаимодействии и постоянно нарушают договоренности, то отменяйте для себя этот принцип, потому что он для вас не работает. Ставьте на первое место жесткие процессы и документирование любых договоренностей, потому что для вас это работает только так (по крайней мере на данном этапе). Потому что самый важный принцип Agile - гибкость, с помощью которой он идеально адаптируется под любые ситуации.
Как плохие владельцы продукта обманывают команду
Сегодня я хочу продолжить разбирать ошибки трактования Agile-манифеста и поговорить про ценность "Готовность к изменениям важнее следования первоначальному плану", которая искажается чаще всего и приносит больше всего вреда процессам в ИТ-компаниях.
Здесь я представлю краткий разбор, но за более подробным с примерами рекомендую все же почитать полный разбор на нашем блоге.
#agile_который_работает
Сегодня я хочу продолжить разбирать ошибки трактования Agile-манифеста и поговорить про ценность "Готовность к изменениям важнее следования первоначальному плану", которая искажается чаще всего и приносит больше всего вреда процессам в ИТ-компаниях.
Здесь я представлю краткий разбор, но за более подробным с примерами рекомендую все же почитать полный разбор на нашем блоге.
#agile_который_работает
Верхнеуровневая и точная оценка сроков
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает
Как ограничения влияют на креативность
Думаю многие слышали о недавнем дефиците бумаги. Вот и я стала свидетелем этой проблемы и хочу с вами разобрать, чему мы можем научиться на этом примере. На днях мне нужно было посетить частную клинику. Обычно процесс посещения сопровождается выдачей листочка с направлением к врачу, затем врач свой листочек с проведенными процедурами отдает вам для оплаты. В этот же раз все было иначе. В регистратуре не выдали листочка, врач находил пациента по имени в компьютере. Так же проходила и оплата. Весь процесс полностью построен без использования бумаги. Мне сразу пришла мысль, что ничего не мешало сделать так и раньше, ведь процесс по сути не меняется. Но пока у вас нет дефицита, вам нет нужды задумываться об оптимизации процесса.
Ограничения пробуждают креатив
Это работает подобным образом в любой сфере. В готовке, стиле, построении процессов, написании кода - чем больше ограничения, тем более креативные решения рождают. При наличии ограничений вы вынуждены думать о том, что вам действительно нужно, а что можно отбросить. Вы больше задумываетесь о том, как построить решение, чтобы не тратить больше ресурсов, чем нужно. И этот принцип также является одной из главных движущих сил в Agile.
Ограничения и продукт
В разработке продукта также существуют ограничения, на пример, рабочая сила, время и стоимость. Часто они воспринимаются, как нечто негативное. Однако, без этих ограничений развитие продукта может пострадать также сильно, как и при слишком сильном дефиците этих ресурсов. Дефицит ресурсов заставляет команду думать о том, что в продукте действительно важно, а не делать все подряд. Когда сроки начинают поджимать, правильная стратегия это взять бэклог продукта и хорошенько подумать, что в этом бэклоге соответствует цели продукта или релиза, а что, возможно, лишнее для поставленной цели. Это делает продукт более выверенным и более нацеленным на тот результат, которого мы хотим достичь.
В этом, в том числе, помогают и цели, которые мы ставим на спринт. Они помогают фокусировать команду в моменты нехватки ресурсов. Являются направляющей, по которой нужно распределять усилия команды. Именно поэтому этих целей ни в коем случае не должно быть много - это убивает саму идею, которой они служат.
В целом, когда вы сталкиваетесь с какими-то ограничениями, постарайтесь не воспринимать их только негативно, подумайте над тем, как они вам помогают и что вы можете улучшить благодаря им.
Александра Шаламова.
#разработчику #agile_который_работает
Думаю многие слышали о недавнем дефиците бумаги. Вот и я стала свидетелем этой проблемы и хочу с вами разобрать, чему мы можем научиться на этом примере. На днях мне нужно было посетить частную клинику. Обычно процесс посещения сопровождается выдачей листочка с направлением к врачу, затем врач свой листочек с проведенными процедурами отдает вам для оплаты. В этот же раз все было иначе. В регистратуре не выдали листочка, врач находил пациента по имени в компьютере. Так же проходила и оплата. Весь процесс полностью построен без использования бумаги. Мне сразу пришла мысль, что ничего не мешало сделать так и раньше, ведь процесс по сути не меняется. Но пока у вас нет дефицита, вам нет нужды задумываться об оптимизации процесса.
Ограничения пробуждают креатив
Это работает подобным образом в любой сфере. В готовке, стиле, построении процессов, написании кода - чем больше ограничения, тем более креативные решения рождают. При наличии ограничений вы вынуждены думать о том, что вам действительно нужно, а что можно отбросить. Вы больше задумываетесь о том, как построить решение, чтобы не тратить больше ресурсов, чем нужно. И этот принцип также является одной из главных движущих сил в Agile.
Ограничения и продукт
В разработке продукта также существуют ограничения, на пример, рабочая сила, время и стоимость. Часто они воспринимаются, как нечто негативное. Однако, без этих ограничений развитие продукта может пострадать также сильно, как и при слишком сильном дефиците этих ресурсов. Дефицит ресурсов заставляет команду думать о том, что в продукте действительно важно, а не делать все подряд. Когда сроки начинают поджимать, правильная стратегия это взять бэклог продукта и хорошенько подумать, что в этом бэклоге соответствует цели продукта или релиза, а что, возможно, лишнее для поставленной цели. Это делает продукт более выверенным и более нацеленным на тот результат, которого мы хотим достичь.
В этом, в том числе, помогают и цели, которые мы ставим на спринт. Они помогают фокусировать команду в моменты нехватки ресурсов. Являются направляющей, по которой нужно распределять усилия команды. Именно поэтому этих целей ни в коем случае не должно быть много - это убивает саму идею, которой они служат.
В целом, когда вы сталкиваетесь с какими-то ограничениями, постарайтесь не воспринимать их только негативно, подумайте над тем, как они вам помогают и что вы можете улучшить благодаря им.
Александра Шаламова.
#разработчику #agile_который_работает
5 ошибок, делающих ваше ретро бесполезным
Ретроспектива - это одна из самых важных церемоний Agile, она помогает команде улучшать свои процессы и повышать эффективность от спринта к спринту. Но бывает так, что ретро есть, а улучшений нет. Давайте рассмотрим ошибки, которые могут быть этому причиной.
Ретро проводится нерегулярно
В погоне за сроками и бизнес целями команды часто жертвуют своими процессами, чтобы успеть свои основные задачи. И это само по себе уже очень большая ошибка. Именно процессы помогают не тратить время на лишнюю работу и успевать задачи в срок. Что касается ретро, то, во-первых, оно поможет выявить проблемы и исправить их в следующем спринте, что даст прирост производительности команды (мы ведь спешим правда?). Во-вторых, если не провести ретро сразу, то проблемы забудутся и их решение отложится до следующего инцидента (если после него снова не будет пропущено ретро). В-третьих, некоторые проблемы, не будучи отловленными у самых истоков, могут стрельнуть в будущем намного сильнее и иногда их уже очень сложно исправить.
На ретро не назначается ответственный за проблему
Итак, вы собрались на ретро, накидали проблем, сказали, что надо что-то с этим делать и пошли дальше работать. И проблемы пошли работать вместе с вами. Я наблюдала, как месяц за месяцем команды писали на ретро одни и те же проблемы, сокрушались над ними и через две недели процедура повторялась. Чтобы этого не происходило в вашей команде, для каждой проблемы должен быть назначен ответственный за ее решение, ему должны быть поставлены соответствующие задачи и выделено время на решение этой проблемы. Дальше задачи на решение проблем проходят обычный цикл, как и любые задачи на разработку. Лучше всего вести список для каждого ретро, где будет указано какая проблема обсуждалась и кто назначен ответственным. Так всегда можно будет просмотреть историю ретро и оценить их эффективность. Заведите правило: начинать ретро с проверки списка прошлой встречи.
На ретро приглашаются лишние люди
Многим людям тяжело говорить о проблемах. Поэтому, собирая состав ретро, важно помнить, что на встрече должны быть только люди из команды, которые могут свободно (насколько это возможно) общаться и обсуждать свои проблемы. На этих встречах не должно быть представителей бизнеса, какими бы друзьями вы с ними не были, и, в особенности, не должно быть незнакомых команде людей. Даже если вы с ребятами из соседнего отдела работали вместе в этом спринте, не надо звать их на ретро свой команды. Особенно хорошо нужно помнить об этом тимлидам, которые много общаются с представителями других команд и чувствуют себя с ними более свободно, думайте прежде всего о комфорте вашей команды, иначе рискуете получить ретро для галочки.
На ретро начинают искать решение проблемы
Еще один момент, о котором я как-то говорила в статье про правила проведения стендапа, на ретро не должно искаться полное решение проблемы, иначе встреча превратится в балаган. Во-первых, некоторые проблемы невозможно решить за 5 минут, начиная обсуждать решение проблемы, вы можете увязнуть надолго и за все ретро успеть обсудить только один вопрос (и то ни к чему не прийти). Во-вторых, помните, что в многофункциональных командах на ретро могут быть люди, которых не касается конкретная проблема, от обсуждения чужих проблем ваши коллеги только утомятся и потеряют интерес ко встрече. Проблема фиксируется, для нее выделяется ответственный и команда движется дальше.
У ретро нет ведущего
Здесь я скажу коротко - у совершенно любой встречи должен быть ведущий. И ретро здесь не исключение. Кто-то должен следить за правилами проведения ретро, фиксировать проблемы, следить за дисциплиной, помогать выбирать ответственного для проблемы. Конечно в идеале это скрам-мастер, но он есть не во всех командах. Тем не менее ведущий должен быть, иначе встреча будет не эффективной.
Надеюсь вам поможет разбор этих ошибок сделать вашу ретроспективу более эффективной. Если вам интересно больше узнать о церемониях Agile, то ставьте пальцы вверх этому посту и я напишу следующий.
Александра Шаламова
#agile_который_работает
Ретроспектива - это одна из самых важных церемоний Agile, она помогает команде улучшать свои процессы и повышать эффективность от спринта к спринту. Но бывает так, что ретро есть, а улучшений нет. Давайте рассмотрим ошибки, которые могут быть этому причиной.
Ретро проводится нерегулярно
В погоне за сроками и бизнес целями команды часто жертвуют своими процессами, чтобы успеть свои основные задачи. И это само по себе уже очень большая ошибка. Именно процессы помогают не тратить время на лишнюю работу и успевать задачи в срок. Что касается ретро, то, во-первых, оно поможет выявить проблемы и исправить их в следующем спринте, что даст прирост производительности команды (мы ведь спешим правда?). Во-вторых, если не провести ретро сразу, то проблемы забудутся и их решение отложится до следующего инцидента (если после него снова не будет пропущено ретро). В-третьих, некоторые проблемы, не будучи отловленными у самых истоков, могут стрельнуть в будущем намного сильнее и иногда их уже очень сложно исправить.
На ретро не назначается ответственный за проблему
Итак, вы собрались на ретро, накидали проблем, сказали, что надо что-то с этим делать и пошли дальше работать. И проблемы пошли работать вместе с вами. Я наблюдала, как месяц за месяцем команды писали на ретро одни и те же проблемы, сокрушались над ними и через две недели процедура повторялась. Чтобы этого не происходило в вашей команде, для каждой проблемы должен быть назначен ответственный за ее решение, ему должны быть поставлены соответствующие задачи и выделено время на решение этой проблемы. Дальше задачи на решение проблем проходят обычный цикл, как и любые задачи на разработку. Лучше всего вести список для каждого ретро, где будет указано какая проблема обсуждалась и кто назначен ответственным. Так всегда можно будет просмотреть историю ретро и оценить их эффективность. Заведите правило: начинать ретро с проверки списка прошлой встречи.
На ретро приглашаются лишние люди
Многим людям тяжело говорить о проблемах. Поэтому, собирая состав ретро, важно помнить, что на встрече должны быть только люди из команды, которые могут свободно (насколько это возможно) общаться и обсуждать свои проблемы. На этих встречах не должно быть представителей бизнеса, какими бы друзьями вы с ними не были, и, в особенности, не должно быть незнакомых команде людей. Даже если вы с ребятами из соседнего отдела работали вместе в этом спринте, не надо звать их на ретро свой команды. Особенно хорошо нужно помнить об этом тимлидам, которые много общаются с представителями других команд и чувствуют себя с ними более свободно, думайте прежде всего о комфорте вашей команды, иначе рискуете получить ретро для галочки.
На ретро начинают искать решение проблемы
Еще один момент, о котором я как-то говорила в статье про правила проведения стендапа, на ретро не должно искаться полное решение проблемы, иначе встреча превратится в балаган. Во-первых, некоторые проблемы невозможно решить за 5 минут, начиная обсуждать решение проблемы, вы можете увязнуть надолго и за все ретро успеть обсудить только один вопрос (и то ни к чему не прийти). Во-вторых, помните, что в многофункциональных командах на ретро могут быть люди, которых не касается конкретная проблема, от обсуждения чужих проблем ваши коллеги только утомятся и потеряют интерес ко встрече. Проблема фиксируется, для нее выделяется ответственный и команда движется дальше.
У ретро нет ведущего
Здесь я скажу коротко - у совершенно любой встречи должен быть ведущий. И ретро здесь не исключение. Кто-то должен следить за правилами проведения ретро, фиксировать проблемы, следить за дисциплиной, помогать выбирать ответственного для проблемы. Конечно в идеале это скрам-мастер, но он есть не во всех командах. Тем не менее ведущий должен быть, иначе встреча будет не эффективной.
Надеюсь вам поможет разбор этих ошибок сделать вашу ретроспективу более эффективной. Если вам интересно больше узнать о церемониях Agile, то ставьте пальцы вверх этому посту и я напишу следующий.
Александра Шаламова
#agile_который_работает
4 признака, что в вашей команде проблемы с процессами
Проблемы с процессами это слабое место многих компаний. Они напрямую ведут к потере прибыли, лишним тратам и созданию ненужного пользователю продукта. Самое коварное в ошибках процесса кроется в том, что они строятся на нашей психологии и мы можем даже не замечать, когда их совершаем. А самый важный шаг навстречу решению проблемы - осознать и признать ее наличие. Поэтому давайте разберем некоторые признаки, которые помогут вам выявить проблемы в процессах.
Постоянно вымотанная команда
Одно из последствий плохих процессов это переработки, которыми приходится компенсировать проседающий процесс. Переработки могут случатся в случае форс-мажора, но если компания на постоянной основе живет в таком ритме это признак плохо выстроенных процессов. От этого чаще всего страдает команда разработки и это можно заметить простым наблюдением. Люди уставшие, могут быть дергаными и нервными, с отсутствием инициативы и энтузиазма, общение в такой команде обычно не очень развито, потому что общаться никогда, да и не приветствуется.
Слишком много времени тратится на коммуникацию
Коммуникации невероятно важны в команде и могут помочь решить очень многие проблемы быстро и эффективно. Но иногда ими пытаются полностью заменить процессы. Если вы замечаете, что утопаете в коммуникациях, то стоит обратить внимание на правильность выстроенных процессов.
Начинаются новые фичи, когда старые еще не закончены
Нередко встречается такой стиль работы бизнеса, когда команде отдается крупный эпик, команда начинает его делать, и одновременно с этим бизнес приходит с новой большой фичей, которую срочно нужно делать. И такая работа ведется на постоянной основе. После этого на проекте обычно остаются части разного функционала, но единство продукта совершенно теряется. Здесь проблема в самом начале процесса - построении бизнес видения. Когда бизнес видение плохо составлено, то проект не сможет развиваться целостно, его будет мотать из одной стороны в другую.
Постоянные проверки руководителем
Случается, что руководитель, или представитель бизнеса, буквально стоит у вас над душой, когда вы решаете какую-то задачу. Постоянно пишет с вопросами: готова ли задача, а когда она будет готова, а чем сейчас занимаешься, а что потом будешь делать? Это все просто кричащий пример отсутствия процессов.
Таких признаков можно найти еще много, но эти встречаются чаще всего. Увидели в каком-то пункте свою команду? Тогда делитесь со своими коллегами, чтобы вместе обсудить проблему.
А мы пока готовим очень мощный материал по практическому применению Agile-практик. Тем, кто уже давно пробует Agile, он поможет понять, почему некоторые вещи не работают и как это исправить. А тем, кто никогда не работал с Agile, он поможет с нуля разобраться, как все должно работать именно на практике. Полный анонс будет чуть позже, так что оставайтесь с нами, вы все узнаете первыми!
Александра Шаламова
#agile_который_работает
Проблемы с процессами это слабое место многих компаний. Они напрямую ведут к потере прибыли, лишним тратам и созданию ненужного пользователю продукта. Самое коварное в ошибках процесса кроется в том, что они строятся на нашей психологии и мы можем даже не замечать, когда их совершаем. А самый важный шаг навстречу решению проблемы - осознать и признать ее наличие. Поэтому давайте разберем некоторые признаки, которые помогут вам выявить проблемы в процессах.
Постоянно вымотанная команда
Одно из последствий плохих процессов это переработки, которыми приходится компенсировать проседающий процесс. Переработки могут случатся в случае форс-мажора, но если компания на постоянной основе живет в таком ритме это признак плохо выстроенных процессов. От этого чаще всего страдает команда разработки и это можно заметить простым наблюдением. Люди уставшие, могут быть дергаными и нервными, с отсутствием инициативы и энтузиазма, общение в такой команде обычно не очень развито, потому что общаться никогда, да и не приветствуется.
Слишком много времени тратится на коммуникацию
Коммуникации невероятно важны в команде и могут помочь решить очень многие проблемы быстро и эффективно. Но иногда ими пытаются полностью заменить процессы. Если вы замечаете, что утопаете в коммуникациях, то стоит обратить внимание на правильность выстроенных процессов.
Начинаются новые фичи, когда старые еще не закончены
Нередко встречается такой стиль работы бизнеса, когда команде отдается крупный эпик, команда начинает его делать, и одновременно с этим бизнес приходит с новой большой фичей, которую срочно нужно делать. И такая работа ведется на постоянной основе. После этого на проекте обычно остаются части разного функционала, но единство продукта совершенно теряется. Здесь проблема в самом начале процесса - построении бизнес видения. Когда бизнес видение плохо составлено, то проект не сможет развиваться целостно, его будет мотать из одной стороны в другую.
Постоянные проверки руководителем
Случается, что руководитель, или представитель бизнеса, буквально стоит у вас над душой, когда вы решаете какую-то задачу. Постоянно пишет с вопросами: готова ли задача, а когда она будет готова, а чем сейчас занимаешься, а что потом будешь делать? Это все просто кричащий пример отсутствия процессов.
Таких признаков можно найти еще много, но эти встречаются чаще всего. Увидели в каком-то пункте свою команду? Тогда делитесь со своими коллегами, чтобы вместе обсудить проблему.
А мы пока готовим очень мощный материал по практическому применению Agile-практик. Тем, кто уже давно пробует Agile, он поможет понять, почему некоторые вещи не работают и как это исправить. А тем, кто никогда не работал с Agile, он поможет с нуля разобраться, как все должно работать именно на практике. Полный анонс будет чуть позже, так что оставайтесь с нами, вы все узнаете первыми!
Александра Шаламова
#agile_который_работает