Вот смотрите - Рывок

Что это такое в agile? :)

(пишу agile, говорю про scrum)

Вот смотрите - Рывок

шо это за ужас

не надо так

))

Ужас не ужас, продается :)

Слава, делись :) скрам, переложенный на русскую модель управления - интересно!

практика системного бизнеса

.рф

А кроме превращения спринта в рывок было там что? :) Выглядит все по-домашнему, должно людям помогать.

единый список задач = бэклог

там ещё такое было :)

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

Что-то в стиле Issue Reaction Time, Issue Lifespan, Issue Comments Count, и т.д.

Оу...

Чтоу?

метрики :) про метрики можно говорить много, но любая внедренная метрика деформирует сознание тех, кто о ней знает, поэтому метрика если вообще есть должна отвечать конечной цели бизнеса

поэтому лучше чем прибыль метрики нет :)

Оу:) по чьим задачам метрики?

поэтому лучше чем прибыль метрики нет :)

Осталось только формулу для Issue Profit вывести 🤑🤑🤑 ;))

%))

Оу:) по чьим задачам метрики?

Хороший вопрос, но скорее по всем)

Если конкретно – разработка

Тут придумал элемент геймификации и сплочения команды : говоришь ребятам - мы будем снимать вот такие метрики и закручивать гайки. Ваша задача - хакнуть систему метрик и продуктивно кодить. Если хакните - по итогам квартала 3х за премии.

Слишком часто в последнее время разработку померить хотят . раз в пару дней в чатике всплывает эта тема :)

В SP измеряйте)) (шутка)

Вопросы обо всем = вопросы ни о чем. Вот метрика - дельта между тем сколько потратил на команду разработки, и сколько заработал с нее в период времени

Это важная метрика тоже, но она не защищает от негативного значения) Чтобы его предотвратить, как раз и операционный KPI (level 1) и нужен.

Если конкретно – разработка

Разработка работает над какими задачами? Pure design&development, или есть поток support&bugfix?

И основной вопрос: вам эти измерения что дадут? Вот кинутся люди их улучшать - по существу девелопмент лучше станет? Более качественный продукт будут делать?

ггг :)

Когда человек долго работает в интеграторе, он видит везде KPI-и ;)

Разработка работает над какими задачами? Pure design&development, или есть поток support&bugfix?

Development, Support, Bugfix. Иногда ещё изменения в сторону дизайна.

И основной вопрос: вам эти измерения что дадут? Вот кинутся люди их улучшать - по существу девелопмент лучше станет? Более качественный продукт будут делать?

Да, скорей всего это поможет. Сейчас есть эффект, что задачи постоянно возвращаются на доработку

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

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

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

а тестирование привлекается при постановке задачи от заказчика команде разработки?

Вот можно же сразу все проверить тщательно. Но мы гонимся за количеством задач. Переводим на QA. Он находит элементарные баги. Возвращает. При этом транзакционные издержки растут.

а тестирование привлекается при постановке задачи от заказчика команде разработки?

Пока нет, а как это можно сделать? Спринтов явных нет. Просто просить QA описать сценарии проверки?

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

А кто постановку задачи делает? Есть ли definitions of done? Есть ли соглашение между dev и QA о том, как передаются задачи?

А можно ссылками, как это может выглядеть?

Звучит интересно.

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

Тайминг реакции и "интенсивность" взаимодействия имеет смысл KPI-ить только в операционных функциях, где есть SLA, план продаж и вот это всё:) или в командах мазохистов, исследующих себя :)

По теме, как построить процесс, чтоб получить качество, у Максима Цепкова был вот такой классный доклад: http://www.slideshare.net/custisppt/ss-69586718

Присоединюсь к нему обеими руками :)

У меня был похожий кейс: недоскрам, QA вне постановки задач, нет DoD, за передачу сделанного на сторону стейкхолдеров никто не отвечал, PM курил бамбук. Закончилось это тем, что за 3 недели до major release date аналитико-QA занимался пересбором бизнес-требований и установкой новых процессов взаимодействия в авральном режиме... А метрики "реакций", если померить, были бы хорошими.

Сдавался четырехмесячный бэклог миграции :)

В статье, кстати, есть отсылка на материал о "русской модели управления", была такая нашумевшая книжка в своё время. https://thebigplans.ru/russian-management-model

Какая там реклама мегаплана то

Какая там реклама мегаплана то

Так это же статья Ильяхова времён мегаплана. Концовку можно опустить, остальное - краткий пересказ книги Прохорова.

Коллеги, в феврале-марте будем в Москве проводить DevOpsDays - https://www.devopsdays.org/events/2017-moscow/welcome/ Я беру на себя смелость разместить аннонс в этом чате, так как конференция некоммерческая и по правилам конференции зарабатывать на ней нельзя, так что это не реклама. Во-первых, там уже открыта предварительная регистрация, билеты будут стоить 3-5к рублей, но по предварительной регистрации для вас будет скидка. Во-вторых, нам нужны докладчики и мы ждем заявки на доклады по ссылке — https://www.devopsdays.org/events/2017-moscow/propose/ там внизу гугл-форма для докладов. Доклады про то, как DevOps помогает становлению Agile и как у вас устроен процесс разработки ПО будут очень полезны. В-третьих, я приглашаю активных участников этого чата принять участие в отборе докладов, для этого добавляйтесь в телеграмм-группу https://telegram.me/joinchat/B1EIREEbj29uKKeo5a_0VA Пишите вопросы, я на них отвечу.

у яндекса есть чудесные вопросы к вакансиям ПМ-ов например, https://yandex.ru/jobs/vacancies/proj_man/tech_proj_man_market/

а в какой книжке найти ответы на них?

Просто посмотрите история создания сервисов в гугл

И расскажите от себя

а в какой книжке найти ответы на них?

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

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

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

у яндекса есть чудесные вопросы к вакансиям ПМ-ов например, https://yandex.ru/jobs/vacancies/proj_man/tech_proj_man_market/

Кстати, прикольные вопросы. У меня еще как-то было веселое собеседование на менеджерскую позицию – я заодно рассказал, как подделывать документы, приемы вытягивания денег и растягивания сроков и еще несколько манипуляций.

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

точно не могу сказать, но на мой взгляд, если есть опыт - они становятся очевидными

а чуваки из яндекса их составили именно с этой целью

че от проджекта то и от продакта обычно надо: 1) знать продукт 2) уметь работать

а в какой книжке найти ответы на них?

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

а в какой книжке найти ответы на них?

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

Если чего я не шутил :) Я там был

Вопросы чтобы проверить как вы мыслите, все равно самое интересное на очном интервью

Вопросы чтобы проверить как вы мыслите, все равно самое интересное на очном интервью

Ну если это Яндекс, то я не уверен.

Ну если это Яндекс, то я не уверен.

а чего там реально хотят от ПМ?

чтобы работал за еду, в идеале :)

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

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

методы приоретизации задач, оценки рисков - пмбок

а чего там реально хотят от ПМ?

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

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

ну можно кейсы порешать, как-то мб и поможет, но насколько эффективно...)

общение с командой - надо не быть гавнюком и может какие курсы по фасилитации

вопрос для этой анкеты: "вы гавнюк?"

методы приоретизации задач, оценки рисков - пмбок

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

есть процесс А, он состоит из подпроцессов Б,В и Г, переходит в процесс Д

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

ну да, чистая теория, а че хотят книжку стань ПМ-ом за 7 шагов?