Дмитрий, спасибо!) Сейчас почитаю.

Можно потом тут продолжить

Можно потом тут продолжить

Дмитрий, а факт не в MD должен быть, есть ещё какая то величина? Ответ на комментарий в фб.

Дни умножить на стоимость команды это расход

Если я правильно понял то они его постфактум оценивают

Михаил, да, если команда держится на лидере, что вы и описали. Но это не «команда» в терминах Аджайла - она не самоорганизованная, не самодостаточная. Хороший лидер - хорошая команда, сменился лидер - умела команда (это неизбежно, даже если новый лидер хороший - просто он другой). Тут и грейды уместны, но надо понимать, что связь каждого члена команды с лидером будет крепче, чем между собой. А если мы говорим про команды, в которых внутренние связи сильнее, грейды им скорее мешают. Если они команде сильно нужны - команда сама внутри себя их разработает и примет. Но не снаружи.

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

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

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

Щас опять заболело :)

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

Зачем нужна самоорганизация для команды? Это какой-то корпоративный коммунизм? Каждый организует себя сам, и контролирует товарища?

Вы уверены что вам вообще agile нужен?:)

Получение грейда - это признание компетенции и принесенной ценности компании. Кто-то можно сказать, что получать признание можно и без грейдов, но это не так. Система должна быть открытой и общей для всех. Грейды обычно имеют свои зарплатные диапазоны. Что опять же снимает вопросы, а почему у Васи больше денег. Потому, что у Васи грейд больше. А грейд больше потому, что вот решение комитета и вот документ, в котором собраны его достижения

Ну тогда да на ваши вопросы. Я правда не знаю какой вы смысл для себя вкладываете в эти вопросы.

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

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

Я писал уже, напишу еще. Есть два способа варить Agile - как систему поверх формальной административной системы, или как основу для формальной системы (бирюза). То есть вопрос не в том, нужны ли грейды а в том кто их дает - некая традиционная должность или комиттет, созданные людьми. Именно комитет и есть пример самоорганизации, а не "скрам команда решает" (на низком уровне такое не рашается). Но до бирюзы нужно еще дорасти, да.

Зависит от того, что для вас означает "коммунизм" :)

С текущей культурой скорее всего никак, её-то и нужно изменять в первую очередь.

в данном случае работу на благо общей цели без амбиций, по выверенной схеме, и с двусторонним контролем))

а в рамках проекта-департамента?

Ну это как бы система работы для людей мотивированных финальным результатом. В постоянно изменяющейся среде. Без миддл менеджмента. Так как миддл менеджмент это результат тейлоризма.

Ну я не модные слова использую. Ну скажем guild

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

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

Я могу наблюдать, как один департамент внутри компании вполне успешно строит внутреннюю культуру, и постепенно вовлекает в нее остальные.

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

Если вовлекает - они круты! Но посмотрим ))) я вообще за последние пару лет железобетонно убедился в «культура компании - отражение культуры её первого лица», так что про изменение культуры из середины я скептик.

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

Приятно понимать, что спустя год жизни чата — за меня махаются другие люди уже)

Да не в слове дело, а в том, что у вас там появилось «решение комитета» на основании каких-то заслуг, и вот Вася уже не о цели команды думает, а как ему список заслуг для комитета собрать.

Приятно понимать, что спустя год жизни чата — за меня махаются другие люди уже)

Ну щас опять холивар начнется по 10 кругу =) Давайте так, вы Scrum Studio читали? Они там про Evidence-Based Management писали. И правильно писали, нужно ощущения конвертировать в измеримые категории. Определение результата туда же.

А про «комитеты» - вы Горника из Mindbox слушали? Про их систему открытых зарплат? Он там к очень важному выводу подошёл: пока компания маленькая и всё всех знают, каждый может принимать решение «я за или я против, чтобы Васе подняли зарплату». Но когда компания растёт - появляются люди, которые с Васей не работают каждый день и не знают, он того стоит или нет. И он собирается сделать промежуточную систему - зарплаты всех открыты, все знают почему, но само обсуждение «повышать или нет» идёт внутри той команды, с которой Вася работает. А вы про комитет какой-то.

Меня все время удивляет вытаскивание корпоративных артефактов. Как будто там все ок :)

Start small stay small

Они создают иллюзию контроля и снижают страхи перед неопределённостью.

Правда, потом они с треском лопаются, но люди ищут новых инструментов контроля, вместо того чтобы учиться жить в неопределённости. P.s. Если пройду отбор, буду на эту тему речь держать на AgileDays.

А про «комитеты» - вы Горника из Mindbox слушали? Про их систему открытых зарплат? Он там к очень важному выводу подошёл: пока компания маленькая и всё всех знают, каждый может принимать решение «я за или я против, чтобы Васе подняли зарплату». Но когда компания растёт - появляются люди, которые с Васей не работают каждый день и не знают, он того стоит или нет. И он собирается сделать промежуточную систему - зарплаты всех открыты, все знают почему, но само обсуждение «повышать или нет» идёт внутри той команды, с которой Вася работает. А вы про комитет какой-то.

Правда, потом они с треском лопаются, но люди ищут новых инструментов контроля, вместо того чтобы учиться жить в неопределённости. P.s. Если пройду отбор, буду на эту тему речь держать на AgileDays.

А я слился в этом году, а там Юргена подвезли, но сообщили слишком поздно Если пойдете пить после конфы — зовите, мне от дома близко

Обсуждение может быть и в команде. Но у команды должны быть какие-то guidlance, понимание какие уровни есть и какие зп можно назначать, иначе не будет alignment с бизнесом (или у вас компанда еще и функцимм финансового директора выполняет?)

SP vs MD!!! Подскажите, знающие люди!) Вопрос, что в методологии Scrum мерить в Story point'ах(SP), а что в Man day'ях(MD)? Надоел извечный спор, хочется разобраться уже. Для каких целей используются SP, для каких MD? Нужно ли то и другое одновременно или что то одно? Как менеджерам объяснить, что именно нужно и какую ценность это даёт для них? Можно ли SP переводить в MD и если да, то как и почему? Вопросов в общем много. Возможно у кого то есть полезная литература, которая отвечает на все эти вопросы. В любом случае, буду благодарен любой помощи =)

Sp - километр дороги Идеальный человеко-день - время на возведение 10 километров дороги. Когда тратим календарное время его можно сравнивать с оценкой в днях. Sp - можно сравнивать только с другими sp Отношение план/фактически потраченные рабочие дни = точность планирования показывает насколько ошибаемся. Это не хорошо и не плохо. Просто стоит учитывать в обещаниях Sp/календарные потраченные дни = скорость поставки результата . можно прогнозировать дату завершения. Пример: строим дорогу со скоростью 5 км/день bipulse у нас считает это всё.

Вопрос вроде был про использование, а не про то, где трекать

Добрый вечер. Прошу прощения, я хотела спросить: может у кого-то есть какой-то основательный и такой взрослый материал касательно грамотной (!) организации планирования разработки именно с помощью JIRA? Видео, тексты - что-либо. Была бы очень признательна за помощь. Хорошего вечера!

Добрый вечер. Прошу прощения, я хотела спросить: может у кого-то есть какой-то основательный и такой взрослый материал касательно грамотной (!) организации планирования разработки именно с помощью JIRA? Видео, тексты - что-либо. Была бы очень признательна за помощь. Хорошего вечера!

Первые три абзаца о том как использовать. Это спор о красном и холодном.

Вот в том то и проблема, что иногда пытаются груши со стульями сравнивать, а иногда и спаривать =(

Они стыкуются. но важно не то ЧТО использовать, важно ДЛЯ ЧЕГО использовать. И какой ответ нужно получить.

Попробую коротко сформировать. 1. Нужно понимать сколько MD планируется на задачу. 2. Нужно понимать сколько MD было израсходованно по факту на задачу. 3. Нужно понимать сколько SP планировалось на задачу. 4. Зачем понимать сколько SP планировалось за задачу? =) Команда планирует задачи в SP. Но ещё нужны и MD. Есть ощущение, что и SP особо не помогают, ну разве что команде понимать насколько сложная задача и стоит ли её добить на более мелкие. Иногда кто то пытается SP перевести в MD. А ещё хочется считать ROI, но надо факт считать. А в ROI хочется факт сравнить с планом =) В общем вопрос возвращаясь к началу довольно прост - какова цель использования SP и какова цель MD? Есть ли место MD, если уже есть оценка в SP? Как считать ROI без оценки плана и факта в MD? Нужно ли SP делить на план и факт (кажется бредом, но все же)? Что, если планировали, что задача в SP - S, а по факту оказалась - XXL? Вообще много вопросов получилось =)