@agile_ru - страница 823 - Telegram web archive

Yuriy

Ну вот и нужно ее делать так, чтоб она могла легко меняться :)

👍👍

Igor

а трудоемкость это разве не то сколько ты потратишь в часах?

Глебка

Есть ещё риск, неопределенность не?)

Igor

нет не слышал

Igor

надо его предыдущий видос найти где таж порграмма

Igor

там он рассказывал как сторипоинты считать

Igor

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

Igor

нашел старый видос

Igor

https://www.youtube.com/watch?v=ZIAuc_P-rOw

Igor

что называется если выпал снег и вам холодно можно подогреть пердак

Pavel

что называется если выпал снег и вам холодно можно подогреть пердак

Ой, да тут регулярно про крутой водопад рассказывают

Pavel

Как-то не цепляет уже

Igor

такой крутой водопад что не знают чо с ним делать?)

Pavel

Опять же PMBoK != водопад.

Pavel

И в целом для проектного управления там много полезного

Igor

он там еще говорит что гдет скрам внедряет

Igor

яб посмотрел на этот цирк

Глебка

посмотрел

Глебка

ну так се

Igor

работу твою напомнило?)

Глебка

ну не совсем)он все же говорил что надо обсуждать и тд, и говорил что не надо микроменеджмента)

Igor

нельзя просто так взять и не заниматся микроменеджментом

Pavel

Во сколько лет вы начали заниматься микроменеджментом? Сколько раз в неделю вы занимаетесь микроменеджментом? Достигаете ли вы делегирования при микроменеджментом?

Mikhail

перестали ли вы заниматься микроменеджментом по утрам?

Konstantin

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

Pavel

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

Как-то так. Любые активности стоят времени. Можно делать вид, что в <подставьте имя своего ad-hoc процесса, котоырй лучше и инновационнее скрамом> время на коммуникации не тратится, но это, мягко говоря не так. В лучшем случае вы не ведете учет этих затрат, в худшем - вы планируете без учета этих затрат

Konstantin

Ну и еще момент: в армии каждый приказ повторяется для контроля. В деловых играх после итерации - сверяют договоренности. Вы будете смеяться, но я видел как после 10-ти минутного цикла каждый оппонент по своему трактует "достигнутые" договоренности. Так что так ... Не стоит гнобить артефакты скрама ...

Sergey

А вот как вам такой поворот? Это пока проект. https://drive.google.com/file/d/1j2s636WFUnLkA680_2IPzBvZhjSh_lK8/view

Chyngyz

А вот как вам такой поворот? Это пока проект. https://drive.google.com/file/d/1j2s636WFUnLkA680_2IPzBvZhjSh_lK8/view

👍

Konstantin

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

Он как раз ничего не говорил про уменьшение избыточности Он говорил что сесть и написать что-то по времени не факт что больше если каждый день это обсуждать

Konstantin

Ну и еще момент: в армии каждый приказ повторяется для контроля. В деловых играх после итерации - сверяют договоренности. Вы будете смеяться, но я видел как после 10-ти минутного цикла каждый оппонент по своему трактует "достигнутые" договоренности. Так что так ... Не стоит гнобить артефакты скрама ...

В армии приказы не повторяют а дублируют состояние что бы было понятно всем Стоп машина, Есть стоп машина

Igor

В армии приказы не повторяют а дублируют состояние что бы было понятно всем Стоп машина, Есть стоп машина

Не всем а тому кто приказ выполняет

Igor

Этож типичный фидбек луп. В Макдаке например приучают говорить спасибо :D типо иди мой унитаз - спасибо иду мыть унитаз

Igor

Это даёт понять принят ли приказ и даёт иллюзию того что все всё поняли

Sergey

Так это и в классическом менеджменте применяется. Когда указание даешь - просишь повторить своими словами указание. Работает очень хорошо.

Konstantin

В армии приказы не повторяют а дублируют состояние что бы было понятно всем Стоп машина, Есть стоп машина

Ну я не хотел канцелярщины. У моряков репетуют.

Konstantin

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

Konstantin

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

А сказанное всеми понимается по своему и забывается

Konstantin

Поэтому и 4 петли обратной связи в схеме. И 15 действий по её получению за 2 недели, в среднем.

Max

Как-то так. Любые активности стоят времени. Можно делать вид, что в <подставьте имя своего ad-hoc процесса, котоырй лучше и инновационнее скрамом> время на коммуникации не тратится, но это, мягко говоря не так. В лучшем случае вы не ведете учет этих затрат, в худшем - вы планируете без учета этих затрат

В самом плохом взаимодействия действительно нет..

Andrey

опять терминатор не справился(

Pavel

В самом плохом взаимодействия действительно нет..

Взаимодействия и в скраме регулярно нет:) А коммуникаций не быть не может.

Maxi

Ребята, посоветуйте как работать с большой командой на проекте. Всего 12 человек (3xUXUI/3xFrontend/3xBackend/2xQA/1xDevops). Проект для заказчика, т.е. мы не исследуем фичи - просто разрабатываем. Раньше пиэмил только в командах меньше семи специалистов, но подозреваю что в составе 12 человек уже проблематично проводить всеобщие дейли и другие подводные камни появятся

Timur

Ребята, посоветуйте как работать с большой командой на проекте. Всего 12 человек (3xUXUI/3xFrontend/3xBackend/2xQA/1xDevops). Проект для заказчика, т.е. мы не исследуем фичи - просто разрабатываем. Раньше пиэмил только в командах меньше семи специалистов, но подозреваю что в составе 12 человек уже проблематично проводить всеобщие дейли и другие подводные камни появятся

По канбан может?

Nina Romanova 😍

Сходи на https://erickson.ru/trainings/coaching-tools/visitauthor.htm

Привет. В группе давно, завтра только вчера, чтр затронули тему КОУЧИНГА. Есть вот такой чат: t.me/coachspot 😋😋 Мне тоже интересно.

Maxi

По канбан может?

Пока не работал по нему. А какой от него профит придет?

Konstantin

По теории 12 человек развалится на 2 команды или вам нужно гораздо больше усилий для ее удержания в куче. Лучше сразу на 2 команды разбивать.

Konstantin

Ну разбивать не разбивать вам решать

Konstantin

Можно и не разбивать, но потом не стоит задавать некоторых вопросов "А почему ...".

Timur

Пока не работал по нему. А какой от него профит придет?

Настроите поток задач, с учётом загруженности ресурсов

Timur

Сформируете задачи на вход для себя и будете брать постепенно в реализацию с учетом лимитов на этапах

Yuriy

По теории 12 человек развалится на 2 команды или вам нужно гораздо больше усилий для ее удержания в куче. Лучше сразу на 2 команды разбивать.

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

Konstantin

Это не правильно. Команды должны быть кроссфункциональные. Единственно может сделать 2 команды и центр компетенции на 2 команды. Хотя не стоит. ;)

Andrey

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

Maxi

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

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

Timur

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

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

Konstantin

Сеньор как таковой это антипаттерн имхо ;) его нужно юзать для передачи/прокачки компетенции в другую команду. а работать должен в одной. просто одна команда в теории будет посильнее и пошустрее.

Андрей Тарасов

Ура, я буду жить) Всем привет!

Pavel

И тебе привет, выживший.

Andrey

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

в ожидании может находиться до 10-15-ти задач, пушить средне получится, так как это зависит от процессов других команд, к примеру графиков релизов

Андрей

ИМХО - Делать доску верхнего уровня, на которой суммируется ваша работа и работа третьей стороны. Визуализировать где затыки и считать вклад обеих команд в lead time / cycle time. Задачи на общую доску вы точно будете брать вместе - тут и будет место для обсуждения. Долго думать :) Ну а дальше всё зависит от того, насколько обе стороны заинтересованы в скорейшем выпуске и что вы можете сделать с третьей стороной.

Maxi

Сеньор как таковой это антипаттерн имхо ;) его нужно юзать для передачи/прокачки компетенции в другую команду. а работать должен в одной. просто одна команда в теории будет посильнее и пошустрее.

Спасибо!