Учитывая ситуацию я бы передал команде продукт этот или расшарил стек и все остальные знания

Тут просто риск именно для бизнеса

Завязки на черный ящик и золотого сотрудника в итоге приведут к печали и все равно придется переписывать если этот сотрудник решит уйти

Моделируем ситуацию: 1) человека сбил автобус и вы отдали проект команде. Они начали с ним разбираться . Время потрачено. 2) вы забрали у человека продукт и передали его команде. Команда начала с ним разбираться. Время потрачено. — Чем эти варианты отличаются? — Почему не создать ему команду?

Тем что впервом случае это катастрофа и форс мажор

Во втором управление рисками

Понял. А кроме названий?

Я кстати не говорил что надо забрать

Я имел в виду отвязать

Чтобы можно было без боли работать

не создать ему команду, потому что мне нужен ААА 3D-шутер, а его стэк - это 1С. это метафора но именно настолько его стек далёк от изменившихся нужд бизнеса. А раньше подходил. Поэтому в перспективе я всё равно перепишу продукт на другом стеке, чтобы получить шутер, но решать проблемы с его поведением мне нужно сейчас

Так боль по любому будет. Причём одинаковая, если его убирать, или он сам уйдёт. Проблема поведения - за рамками. Поговорите, съездите в баню в конце-концов вместе.

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

Понял, желаю удачи:)

👍

Результаты спринта - он делает все задачи что взял. Он и будет делать все задачи что взял. Но что будет, если я обнаружу что в прошлый месяц он играл 2 часа в рабочее время в день, а в этом уже 4? Ему ничего не мешает просто прибавлять в этом месяце 10% к истинном эстимейту, про который он знает, а в следующем- 20%

Seraph, не смотрите на "сколько сделал от того сколько взял". Смотрите на "сколько взял от вашего ожидания". Понимаете, совершенно пофиг, МОЖЕТ он сделать больше или нет - вам (вам двоим) нужно свои ожидания выровнять относительно друг друга. Ну и, да, надо отдавать себе некоторый отчёт, насколько ваши ожидания вообще согласуются с реальностью :) То есть существуют ли люди, которые за сравнимые деньги выдадут, например, вдвое больше при том же качестве. а ещё у Вас проблема (ИМХО) в том, что он - не в команде. Он сидит и пилит "СВОЁ", и потому может вести свою игру с вами, а с командой он вообще никак не завязан. Я бы смотрел, всё-таки, в сторону даже не распиливания бас-фактора (ну будет у вас другой незаменимый, или будут двое в функциональном колодце где сейчас один плещется), а подумал бы как интегрировать его работу в командные задачи. Чтобы не вы его "контролировали", а чтобы его работа была частью аутпута команды. А не его личным выхлопом. P.S. Похоже, об этом всё уже выше написали даже :)

Кажется я самое интересное пропустил... Кто нибудь советовал эксклюзивного разраба сделать скрам мастером, раз спринты есть, Seraph?

И вдогонку - привяжите производительность гуру-разработчика к проценту от прибыли.. А то выше много про наказания написали

Но человека сохранить, он хороший разраб и эту практику начал недавно

Врубите ccpm (метод критической цепи) и режьте оценки в 2 раза с переносом резерва в буфер расписания. С контролем буфера. Если буфер будет в сильно зеленой зоне то оценки можно ещё зарезать. Голдратт описывал именно ситуацию с завышенными оценками.

https://youtu.be/OCgxIMhsy60

Кажется мотивация сложнее чем просто % от прибыли.

Не реклама, просто очень хороший видос

+ здесь про аджайл, какая цепь..

https://youtu.be/OCgxIMhsy60

✌️

цепь не вредит, на мой взгляд), а дальше по обстоятельствам))

Кажется мотивация сложнее чем просто % от прибыли.

а Вы ожидали от одного комментария полного раскрытия понятия мотивация? Это лишь кейс отличный от многих выше

Нет)

Не реклама, просто очень хороший видос

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

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

в группах этот эффект сглаживается, т.к. ты один из равных, все плюс минус получают одинаково - ожидания снижаются

Я конечно весь трек не прочитал и в данном случае не понятна цель, победить прогера или запилить продукт..

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

не создать ему команду, потому что мне нужен ААА 3D-шутер, а его стэк - это 1С. это метафора но именно настолько его стек далёк от изменившихся нужд бизнеса. А раньше подходил. Поэтому в перспективе я всё равно перепишу продукт на другом стеке, чтобы получить шутер, но решать проблемы с его поведением мне нужно сейчас

Сам был и в роли "Звезды" и в Вашей роли. С точки зрения бизнеса, как мне думается, нужно смотреть не сколько человек играет в игрушки или наоборот "типа пишед код", а какой выхлоп от него. Считаем выхлоп, смотрим сколько человек могут дать такой выхлоп, за какое время и сколько это стоит. Если вам нужно ускорить работу наймите двух таких же и работа ускорится в три раза - опять же сформируется устойчивая команда. Если вам нужно дешевле, наймите вместо него трех людей попроще и подешевле. ИМХО, если вы теряете миллионы, тогда зачем вы себя мучаете? Создайте команду и получайте удовольствие и зарабатывайте свои миллионы.

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

Всем привет. Глупый вопрос в студию Кто использует jira - вы пишете с помощью user stories прямо истории, а в них уже кидаете сабтаски? e.g. user story as a [user] i want to [have a profile] to [have personalised search] sub-tasks create login, create credentials DB, create forgot password procedure Или используете user-story просто как большую задачу в которой много маленьких e.g. user story create sign in sub-tasks create sign in screen, create credentials DB, create forgot password procedure

Привет. Первое.

Всем привет. Глупый вопрос в студию Кто использует jira - вы пишете с помощью user stories прямо истории, а в них уже кидаете сабтаски? e.g. user story as a [user] i want to [have a profile] to [have personalised search] sub-tasks create login, create credentials DB, create forgot password procedure Или используете user-story просто как большую задачу в которой много маленьких e.g. user story create sign in sub-tasks create sign in screen, create credentials DB, create forgot password procedure

С связи с этим вопрос, какое различие в джире между эпиками и юзер стори ? У нас тоже сабтаски, но они под эпиками идут

Всем привет. Глупый вопрос в студию Кто использует jira - вы пишете с помощью user stories прямо истории, а в них уже кидаете сабтаски? e.g. user story as a [user] i want to [have a profile] to [have personalised search] sub-tasks create login, create credentials DB, create forgot password procedure Или используете user-story просто как большую задачу в которой много маленьких e.g. user story create sign in sub-tasks create sign in screen, create credentials DB, create forgot password procedure

На уровне команды - story, в теле стори - аксептансы, задачи - sub-tasks

На уровне программы - story, внури список юзерсторей и общее описание того, что это.

Это задачи для декомпозиции

Эпики в жире - для маркировки того, какая задача в бэклоге к какой части value stream относится.

А я думала, что Эпики — это большой кусок функционала, куда собраны стори, в которых идет декомпозиция на задачи (че конкретно нужно делать) и сабтаски, чтобы, например, не порождать задачи больше, чем 1 день

На уровне программы - story, внури список юзерсторей и общее описание того, что это.

Паша, а где ты проходил обучение по agile и продуктовым штукам? Очень развернутые ответы каждый раз, чувствуется владение предметом)

Всем привет. Глупый вопрос в студию Кто использует jira - вы пишете с помощью user stories прямо истории, а в них уже кидаете сабтаски? e.g. user story as a [user] i want to [have a profile] to [have personalised search] sub-tasks create login, create credentials DB, create forgot password procedure Или используете user-story просто как большую задачу в которой много маленьких e.g. user story create sign in sub-tasks create sign in screen, create credentials DB, create forgot password procedure

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

Паша, а где ты проходил обучение по agile и продуктовым штукам? Очень развернутые ответы каждый раз, чувствуется владение предметом)

В основном в процессе работы :)

Ребята, если у кого-то есть Specification by Example в электронном формате и вам не жалко скинуть - скиньте, пожалуйста И еще интересует если у кого-то есть опыт внедрения

Работает

Гайз, в каком формате готовите отчетность для высшего руководства? Какие ключевые показатели учитываете?

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

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

+

Ха

Гайз, в каком формате готовите отчетность для высшего руководства? Какие ключевые показатели учитываете?

Квартальные планы. Потом после каждого крупного релиза пишется письмо с самари проекта. Там указываются так же изменения в метриках

Всем привет! В описании сказано, что есть традиция представляться. Не буду её нарушать) Работаю в НТЦ Метротек. Специализируюсь в разработке под FPGA, системном программировании под Linux, Linux Kernel, embedded, телекоммуникационных сетях. Не знаю. Не уверен, что смогу быть полезен сообществу) Ищу ответ на вопросы о Jira и её плагинах. Посоветовали данный чат. В описании ужё прочёл, что есть 2 специализированных чата. Из Санкт-Петербурга. Посоветовали в devops чате.

Привет! DevOps из https://fiware.org. Подробнее в https://www.linkedin.com/in/caa06d9c/

Как, линкдин официально запрещен на территории РФ

а я не в рф живу) да и думаю в связи с РКН у большинства уже прокси стоят

Как, линкдин официально запрещен на территории РФ

Телеграм тоже, однако это не мешает вам в него писать. Пожалуйста, самовыпилитесь

Как, линкдин официально запрещен на территории РФ

Написал человек в официально запрещённом телеграмме:)

Всем привет. Армен. Project и Product в разных дейтинг проектах LovePlanet. До этого работал в Wakeapp, руководителем проекта AppCent. Собственно вместе со своей командой создал его. Ещё до этого разработка мобильный приложений в Pappico. Имею пару дипломов по скрам (давно это было и похоже все сказки). Интересны всякие методологии и все то, что облегчает разработку проекта.

Всем привет. Армен. Project и Product в разных дейтинг проектах LovePlanet. До этого работал в Wakeapp, руководителем проекта AppCent. Собственно вместе со своей командой создал его. Ещё до этого разработка мобильный приложений в Pappico. Имею пару дипломов по скрам (давно это было и похоже все сказки). Интересны всякие методологии и все то, что облегчает разработку проекта.

доброе утро, не взлетел скрам?)

Как, линкдин официально запрещен на территории РФ

Я тоже недавно узнал. Как в 2012 freegate поставил, так и не курсе, че там Роскомпозор закрывает ))

доброе утро, не взлетел скрам?)

Ещё не было прям задачи внедрять его ;) а так все по чуть чуть взлетает )

Товарищ полковник - А крокодилы летают? Нет! А товарищ генерал сказал что летают! Ну раз товарищ генерал сказал, то летают. Только низЕнько-низЕнько ... Простите за офтоп :) По теме - пока у нас все команды не перешли на скрам, с взаимодействием по LESS, была свара и склока. Потому как в скраме они сам себе задачи набирали и не овертаймили, а вне скрама продакт овнер наваливал на них все что только можно. Сейчас выровнялось все. Остались территориально распределенные люди, которых тоже в команду соберем. Они сейчас тоже ворчат, что тоже так хотят :)

Всем привет! А поделитесь, пожалуйста, примерами User Story Map'ов которые вам кажутся крутыми/правильными/подходящими для изучения. Своими или публичными, не так вижно.

Товарищ полковник - А крокодилы летают? Нет! А товарищ генерал сказал что летают! Ну раз товарищ генерал сказал, то летают. Только низЕнько-низЕнько ... Простите за офтоп :) По теме - пока у нас все команды не перешли на скрам, с взаимодействием по LESS, была свара и склока. Потому как в скраме они сам себе задачи набирали и не овертаймили, а вне скрама продакт овнер наваливал на них все что только можно. Сейчас выровнялось все. Остались территориально распределенные люди, которых тоже в команду соберем. Они сейчас тоже ворчат, что тоже так хотят :)

агонь было), LeSS +

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

доказательства найти можно в пользу любого метода. Попробуйте совместить, быть может. Вкратце - есть групповой показатель - всё пропущенное через спринт, сделанное и принятое. Есть индидидуальный - что конкретный чел сделал, как быстро и как успешно. Минусы индивидуального - будет сложнее отсдеживать, тюнить. Ну и могут раздоры пойти. Так что в целом я полагаю, что Вы правы - групповой лучше. А там уже мотивировать по грейду, к примеру

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

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

очень просто - зп не должна зависеть от результатов спринтов. и то и другое приведет только к негативу в команде.

очень просто - зп не должна зависеть от результатов спринтов. и то и другое приведет только к негативу в команде.

+

но можно делать плюшки за выполнения спринта и наоборот по итогам месяца

правильно, не справляется команда - отключить финансирование 😄

Радикальный коучинг:)

а вообще, в любом случае с каждым членом команды надо отдельно работать. есть командные цели, а есть для сотрудников. ИМХО всегда по разному приходится делать, ибо все зависит от тонны факторов, начиная от самого проекта, заканчивая местом положения сотрудника

Одно уточнение. Проекты - внутренние и заказчик соответственно внутренний (отдел маркетинга и руководство компании). Идея бонусов следующая. Опытным путем проверено, что команда за спринт переваривает 90 сторипойнтов. Соответственно 90 беру в качестве нормальной эффективности (70% от возможности команды). Все, что выше 70% - это бонусы. Все, что ниже 70% - потери в зарплате. Если коэффициент падает до 50% - это серьезный сигнал к тому, чтобы посмотреть, что в системе что-то идет не так (команда не справляется, требования завышена и тд и тп).

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

Одно уточнение. Проекты - внутренние и заказчик соответственно внутренний (отдел маркетинга и руководство компании). Идея бонусов следующая. Опытным путем проверено, что команда за спринт переваривает 90 сторипойнтов. Соответственно 90 беру в качестве нормальной эффективности (70% от возможности команды). Все, что выше 70% - это бонусы. Все, что ниже 70% - потери в зарплате. Если коэффициент падает до 50% - это серьезный сигнал к тому, чтобы посмотреть, что в системе что-то идет не так (команда не справляется, требования завышена и тд и тп).

90 sp. У вас Фибоначчи шкала?

Опять же, привязывать эффективность к велосити в сторипоинтах... Завтра команда скажет, что то, что было 8 sp теперь 13 sp - велосити вырастет, эффективность нет :)

Опять же, привязывать эффективность к велосити в сторипоинтах... Завтра команда скажет, что то, что было 8 sp теперь 13 sp - велосити вырастет, эффективность нет :)

Есть такая вероятность :) Сейчас в часах оцениваем. Как-то с фибоначчи не пошло у нас, но буду пробовать внедрять оценку в сложности задач, а не в часах.

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