#whois Работаю разработчиком + скрам-мастером в компании reg.ru. Участвую в команде аджилизации компании. Большой опыт в удаленной командной разработке и готов им поделиться. От сообщества хотелось бы получить помощи в более глубоком познании гибкой разработки по. Про группу узнал из поиска телеграма.

Подписка на #whois

Ребят, а кто нибудь пробовал CCPM? Я тут о нем недавно узнал, выглядит здорово, но интересно, как работает на практике.

Ребят, а кто нибудь пробовал CCPM? Я тут о нем недавно узнал, выглядит здорово, но интересно, как работает на практике.

Нормально работает. Но применимость зависит от ваших условий. Если вам важно выполнять проекты вовремя, то смысл есть. Иначе, лишние движения на планирование поставки, контроль буфера. Мы скрещиваем его с agile/scrum для операционно- тактического управления.

Ребят, а кто нибудь пробовал CCPM? Я тут о нем недавно узнал, выглядит здорово, но интересно, как работает на практике.

Приходи на SECR доклады в секции TOC+ТРИЗ

Интересно

Нормально работает. Но применимость зависит от ваших условий. Если вам важно выполнять проекты вовремя, то смысл есть. Иначе, лишние движения на планирование поставки, контроль буфера. Мы скрещиваем его с agile/scrum для операционно- тактического управления.

То есть вы реально сокращаете время на выполнение задач в два раза?

Вернее на треть

Или в два - не помню

То есть вы реально сокращаете время на выполнение задач в два раза?

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

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

А сколько вы уже применяете этот подход?

А сколько вы уже применяете этот подход?

Уж лет 5 будет.

Здорово, нужно будет изучить и попробовать

>>For the first time in about 30+ years the German Unions demanded a reduction of working hours again. Last time they did that, it went down as one of Germany's toughest fight in history, which resulted in working hours being reduced from 40h/week to 38.5h/week and then years later to 35h/week. The newest demand is to bring it down to 28h/week!

умнички

Откуда новость ?

Нашла https://www.reuters.com/article/us-germany-election-work/german-wage-talks-to-include-new-focus-reduced-working-hours-idUSKCN1BP0KF

умнички

могут не дергаться, роботы быстрее лишат работы

могут не дергаться, роботы быстрее лишат работы

До роботов еще далеко

До роботов еще далеко

Да, ещё лет 10-15... https://www.theguardian.com/technology/2014/feb/22/computers-cleverer-than-humans-15-years

Да, ещё лет 10-15... https://www.theguardian.com/technology/2014/feb/22/computers-cleverer-than-humans-15-years

Им, да. Нам побольше

Тут есть кто-нибудь, кто занимается machine learning в Нижнем Новгороде?

хорошо хоть не в Брюгге

Тут интересный диалог был с товарищем (он девелопер). Он тут давеча собеседовался в Amazon. Он как девелопер сильный, но его в итоге определили как SDE I, то есть джуниор. Есть подозрение, что это не из-за депелоперских скилов, а из-за ответов на поведенческие тесты soft-skills. Вопросы были по типу представьте у вас с коллегой конфликт - например у вас одна точка зрения, а у него другая по какому-то вопросу. Как будуте решать? Интересуют ваши ответы и что бы почитать на эту тему что бы быть в курсе?

Рассмотреть плюсы и минусы обоих решений

Это понятно. Но в жизни не бывает, что у чего-то одни плюсы, а у чего-то одни минусы. Будет и то и то для обоих решений. Но для разных людей какие-то минусы не так критичны, а какие-то плюсы более значимы

надо пойти к скрам-мастеру на фасилитацию

Это хорошая штука в плане синхронизации, быть на одной волне

Я бы вот такой ответ предложил: если из плюсов и минусов решения невозможно однозначно сделать выбор (если бы можно было бы, то и спора не было, кто-то бы просто привел весомый аргумент и все), это означает что для принятия решения не достаточно данных. Можно а) найти данные на стороне - пригласить в дискуссию кого-то, кто более компетентен, или провести эксперимент б) Если времени нет, а решение нужно срочно, то провести голосование, а дальше "disagree and commit"

надо пойти к скрам-мастеру на фасилитацию

Я вот точно знаю, что на западе за аппелирование к начальству сразу reject как за не командное решение

скрам мастер - начальтсов

?

Это правда, идти к эксперту за оценкой, но не помощью в виде авторитета

если к нему ходят разрешать конфликты - то он точно начальство. вообще просто ходить к кому-то, кто авторитетен так себе

Я как-то слышал решение, что спор должен разрешать кто-то, кто авторитетен для обоих участников. Но тут опять выйдет, что это будет какой-нибудь скарм мастер или cheif architect, на практике

Денис, я просто в каком-то документе прочитал что это такая роль, которая помогате решать конфликты, а фасилитация это такой процесс психотерапии которые позволяет людям разобраться в разных вопросах

Тут интересный диалог был с товарищем (он девелопер). Он тут давеча собеседовался в Amazon. Он как девелопер сильный, но его в итоге определили как SDE I, то есть джуниор. Есть подозрение, что это не из-за депелоперских скилов, а из-за ответов на поведенческие тесты soft-skills. Вопросы были по типу представьте у вас с коллегой конфликт - например у вас одна точка зрения, а у него другая по какому-то вопросу. Как будуте решать? Интересуют ваши ответы и что бы почитать на эту тему что бы быть в курсе?

Можно спросить, почему коллега настаивает на данном решении. Рассказать, почему сам выбирает другое. Обсудить цели вообще проекта, вместе оценить оба решения относительно целей и метрик проекта. Всё решения принимаются на основе ценностей человека. Задача - сделать их понятными и определить общие

Был у нас парень, с РФ, пришел и давай использовать начальство для пуша своих, неоптимальных решений с очень негативными последствиями

скрам-мастер называется

Можно спросить, почему коллега настаивает на данном решении. Рассказать, почему сам выбирает другое. Обсудить цели вообще проекта, вместе оценить оба решения относительно целей и метрик проекта. Всё решения принимаются на основе ценностей человека. Задача - сделать их понятными и определить общие

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

Команда посмотрела и перестала проявлять инициативу, фасилитируя этим решения как можно больше. Как только начальство увидело, какой финансовый ущерб нанесен — пнуло авторитета и новенького

Пуш в аджайле)

Так по честному, во всех спорах надо вспоминать поговорку "Argue for clarity, not to win.", и сначала разбираться у кого какое clarity и нет ли тех, кто "to win". ;)

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

Не обязательно разные. Скорее обращаются в моменте к разным. Полезно спросить, почему данное решение важно коллеге, какую проблему он решает. На одну проблему можно найти несколько решений

Давайте на пример. Вот пример из практики, у меня был такой спор - товарищ предлагал переделать два модуля системы (они общаются друг с другом), а я предлагал переделать только один, хоть это и костыльное решение, зато работа будет меньшими итерациями.

Рефакторинг надо начинать с изоляции)

Тут всем ясно какие плюсу и минусы решения. Но все это качетсвенные оценки, и у нас разное восприятие (для товарища важнее техническое совершенство, а мне важнее снизить риски),

Из плюсов — меньше область поражения

Давайте на пример. Вот пример из практики, у меня был такой спор - товарищ предлагал переделать два модуля системы (они общаются друг с другом), а я предлагал переделать только один, хоть это и костыльное решение, зато работа будет меньшими итерациями.

Почему важно сократить итерации? Или снизить риски? Как одно и другое влияет на pnl?

Из минусов — медленней, есть шанс увидеть слишком маленький кусок функционала

Почему важно сократить итерации? Или снизить риски? Как одно и другое влияет на pnl?

Отвече вопросом на вопрос - а как архитектурные красивости влияют на pnl? В защиту итераций скажу, что они позволяют получить быстрый фидбек, что позволит быстрее выявить те самые факторы, которые влияют на pnl

На что мне товарищ мог сказать, выявим или нет - не факт. А вот костыли плодить в системе точно стоимость поддержки увеличивает

Архитектура задает пространство для изменений

В общем если сидеть и думать можно выбумывать любой аргумент на аргумент оппонетна, было бы желание =) Я в этом споре могу любую позицию принять и топить за нее, благо опыт позволяет

Что в принципе можно разложить по матрице эйзенхауэра

Ну аджайл позволяет сделать пристрелку

Что наиболее значимо и принесет импрувмент в процесс наименьшим изменением

Итогом будет не решение но шаги для оценки

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

В общем у нас тогда спор как-то сам разрешился (по-моему времени тупо уже не оставалось и товарищу пришлось согласиться)

Но вообще надо было собрать команду и коллективный разум пусть решает.

Мы делали скилл матрикс

По технологиям используемым в проекте

Эксперты были вовлечены в оценку

Как правило после наработки нового скилла эксперт готовил сессию для быстрого ознакомления с технологией

А команда подтверждала навык, что собственно качало неявно разработчикам софтскиллы

Тащить всех подряд нет смысла

Выработка шагов, далее оценка и попадание в бэклог, где команда прогруммит еще раз

коллеги, а вот скажите - есть тут у нас спецы по настройке  jira? youtrack? redmine? у нас есть несколько специфических хотелок, и нам нужна консультация. платная. возможно, по результатам нам нужен будет контракт на обслуживание этого всего