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

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

Релевантнее было бы говорить в % соотношении. Если у компании затраты на сотни тысяч, то снижение затрат на 1% не существенно, учитывая, что возможно подключали их не просто так

ну нет компания не большая :D затраты там конечно в сотнях тысяч но не баксов

А кто-то это заметил/оценил?

сео заметил и оценил

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

ну нет компания не большая :D затраты там конечно в сотнях тысяч но не баксов

Ну так поэтому круче говорить не "я снизил на 1к$, а я снизил затраты на 10% например"

Ну так поэтому круче говорить не "я снизил на 1к$, а я снизил затраты на 10% например"

мы сейчас не о том как круче говорить :D

тестера пихнуть в команду не проблема

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

тестировщиков в каждой команде обосновать достаточно просто

особенно если отдел тестирования работает на несколько команд

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

Может и есть элементы фреймворка, но без системы. Есть представление, что agile может снизить T2M, повысить качество продукта с Т.з. Пользователей

Может и есть элементы фреймворка, но без системы. Есть представление, что agile может снизить T2M, повысить качество продукта с Т.з. Пользователей

А что сейчас с качеством продукта с т.з. пользователей?

Может и есть элементы фреймворка, но без системы. Есть представление, что agile может снизить T2M, повысить качество продукта с Т.з. Пользователей

То есть это пока просто гипотеза, которую решили проверить на себе? Это может дорого стоить

А что сейчас с качеством продукта с т.з. пользователей?

Стандартный для рынка

То есть это пока просто гипотеза, которую решили проверить на себе? Это может дорого стоить

Может. Вопроса это не снимает.

а на чем сейчас стопорится T2M?

вы его замеряли?

от момента появления идеи до ее реализации

просто agile вам не поможет T2M снизить скорее всего

вы его замеряли?

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

так agilе не за этим

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

когда неясно что нужно пользователю

если вы понимаете зачем вы пилите продукт, то agile фреймворки вам не помогут

но это не точно :D

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

крутые идеи просто тонули в менеджерском болоте :D они не могли понять что нужно делать

крутые идеи просто тонули в менеджерском болоте :D они не могли понять что нужно делать

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

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

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

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

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

разберитесь сначала в чем проблема с т2м :D

слона надо есть по кусочкам

слона надо есть по кусочкам

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

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

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

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

у Павличенко есть хендбук скрам мастера там куча идей есть.

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

На leanpub есть хорошие книжки по ретроспективам

Спасибо!

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

https://www.alpinabook.ru/catalog/ProjectManagment/117780/

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

норма керта уже советовали?

норма керта уже советовали?

не советовали, но обязательно ознакомлюсь. Перечитал кучу методик на разных ресурсах, в частности тут http://www.funretrospectives.com, но на практике они у нас как то не заводятся. Наверное простого набора методик недостаточно, нужны примеры их использования на практике, разборы проблемных кейсов.

не советовали, но обязательно ознакомлюсь. Перечитал кучу методик на разных ресурсах, в частности тут http://www.funretrospectives.com, но на практике они у нас как то не заводятся. Наверное простого набора методик недостаточно, нужны примеры их использования на практике, разборы проблемных кейсов.

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

не советовали, но обязательно ознакомлюсь. Перечитал кучу методик на разных ресурсах, в частности тут http://www.funretrospectives.com, но на практике они у нас как то не заводятся. Наверное простого набора методик недостаточно, нужны примеры их использования на практике, разборы проблемных кейсов.

Надир, попробуйте поискать видео-записи фасилитационных сессий. Когда вы повторяете техники без учета реакции, когда в смысле и пользе ретро сомневается вся команда - это лить воду в никуда. Также стоит в начале практики следовать техникам дословно, а не "я понял смысл, сделаю все то же самое, но по-своему" (принцип shu-ha-ri)

Кстати, как мне кажется большая часть внедрений аджайла выглядит вот так https://youtu.be/a-hoA97VcoU?t=600 - "большая дата, очень большая дата, машинное обучение и да, у нас конечно аджайл"

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

А, сорри, он собственно и тролит их 😂

Блин, этот олень (Осипов) вообще не понимает, что говорит

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

БМ это бизнес ПТУ. К этому надо так относится. Они учат быстро зарабатывать деньги, но не обещают что это будет долго, стабильно и тд. и тп.

Прибыль есть? Базовые основы предпринимательства дают? Финансовую грамотность клиенты изучают? В чем тогда ваша претензия к бизнесу ПТУ?)

Парень просто сильно нервничал и стремился понравиться. Хотя с достижениями его команды можно уверенно на тренажер прыгать и с него вещать)

Доброго времени суток! СПб, веб-дизайнер, сейчас учусь чтобы переквалифицироваться в качественного ux: проектирвание и аналитика.

Да там их базар фильтровать, как минимум 50 на 50 нужно. Доход конечно важно, но нужно ещё выдавать полезный продукт для людей или бизнеса, а тут какой-то тупой развод. И что за платформу они там сделали, нужно тоже смотреть, может взяли и допилили немного сторонний продукт.

Парень просто сильно нервничал и стремился понравиться. Хотя с достижениями его команды можно уверенно на тренажер прыгать и с него вещать)

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

Если мыслить в стиле ZOG))))

Всех кто-то грамотно пользует.

Нибиру прилети, всех освободи

#whois работаю с двумя западными стартапами в качестве менеджера проектов. работаем по scrum. ищу интересных статей. узнал про группу из вебинара про User story mapping

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

А нет ли тут знакомых из команды разработки HeadHunter? Мне тут рассказывали, как они отлично живут по скраму с оценкой задач в story points, но без декомпозиций. Хотел бы узнать полную версию подхода к комплектованию спринтов.

А нет ли тут знакомых из команды разработки HeadHunter? Мне тут рассказывали, как они отлично живут по скраму с оценкой задач в story points, но без декомпозиций. Хотел бы узнать полную версию подхода к комплектованию спринтов.

это как? 120 сторипоинтов и го?

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

Для одного человека по-моему 8 sp - целый спринт. Может они так и оценивают? Типа "сделаю за спринт"? Только тогда непонятно, как показывать прогресс на стендапах.

Для одного человека по-моему 8 sp - целый спринт. Может они так и оценивают? Типа "сделаю за спринт"? Только тогда непонятно, как показывать прогресс на стендапах.

у нас примерно 20 сп человеко-спринт. Но я упорно не понимаю зачем показывать прогресс на стендапах. Главное же — успеваю/не успеваю. Если люди в своих оценках по этой бинерной шкале не ошибаются и не выясняется что "не успеваю" за день до демо — то всё в порядке же.

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

На стендапах команда сама выбирает, чем заниматься.

А вот "успеваю/не успеваю" на одного человека - не слишком ли велик риск при текущих ценах на разработчиков?

Типа он скажет "ну не шмогла я" и чё Ты будешь делать?

Ты по сути просрал спринт на одного члена команды. Это дОрого.

ничего, как и в любом другом случае.

то есть ничего нельзя сделать с тем что разработчик зафакапил спринт

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

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

Её просто передают другому разработчику или иным способом на неё наседают. Другие занимаются оставшейся рассыпухой.

а задачи россыпью — прикольно конечно, но 1. нормальные разработчики не любят задачи типа "написать класс, реализующий интерфейс" 2. задачи оцениваемые в сп — это что-то ценное для бизнеса. а это крайне редко можно успеть за один-два дня сделать. по крайней мере в моём мире

Её просто передают другому разработчику или иным способом на неё наседают. Другие занимаются оставшейся рассыпухой.

ну так если у человека проблемы — он и так к другим разработчикам пойдёт за помощью, независимо от размера задачи. А если не пойдёт — то пойдёт после стендапа

"то пойдёт после стендапа" - нет. Пойдёт после проваленного спринта. Цена ошибки разная. Или проваленный день или проваленный спринт.

=== нормальные разработчики не любят задачи типа "написать класс, реализующий интерфейс" === а какие задачи любят разработчики?

"то пойдёт после стендапа" - нет. Пойдёт после проваленного спринта. Цена ошибки разная. Или проваленный день или проваленный спринт.

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

=== нормальные разработчики не любят задачи типа "написать класс, реализующий интерфейс" === а какие задачи любят разработчики?

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