ребята из ICAgile на тренинге говорили, что LESS Huge существует только на бумаге и успешных примеров нет

ребята из ICAgile на тренинге говорили, что LESS Huge существует только на бумаге и успешных примеров нет

с обычным, вроде, тоже так себе

просто на слайде выше указывают прирост скорости аж 200-400% вот и возник вопрос :)

это типа если 2-4 команды вместо одной над одной задачей работают? ))

Весьма спорный слайд

LeSS Huge: https://less.works/case-studies/nokia-networks-high-capacity-network-gateway.html

Весьма спорный слайд

Да он вообще не очень убедителен )

И другие кейсы в этом разделе

LeSS Huge: https://less.works/case-studies/nokia-networks-high-capacity-network-gateway.html

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

Привет всем! Есть ли исследования или просто примеры эффективности разработки ПО в кроссфункциональных командах? Можете дать ссылку на такое исследование, где прирост измерили количественно?

Коллеги, привет! Почти в тему пост На #agilekitchen конкурс Накидайте лайков, пожалуйста https://www.instagram.com/p/BcuRXmWHECN/

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

Рассказывают про масштабирование гибких практик

Владимир Ряшенцев. Томск. Компания СибирьСофтПррект. Проект связан с автоматизацией бизнес процессов в нефтянке. Я зам. руководителя проекта. )) Хочу лучше понять agile. Чем могу быть полезен сообществу - затрудняюсь сказать.

Рассказывают про масштабирование гибких практик

И че рассказывают? Был я тут давеча на семинаре ThoughtWorks про то, как они масштабируют Agile. Если в кратце, система такая - 4 уровня целепологания: Vision, Goals, Bets, Iniciatives, все это мэпится на команды (тот же OKR по сути), у каждой команды (одна инициатива - одна команда) есть своя проектная команда из менеджеров и аналитиков. Жизненный цикл инициативы (я бы их назвал эпиками, но они их называют инициативами) такой: Pre-Discovery, Discovery, Delivery, Post-Delivery. На каждом этапе есть ряд своих инструменов, напримем kick-off митинг для pre-discovery и так далее. Discovery оканчивается написанием документации на инициативу. Delivery по сути обычный Scrum, Post-delivery это wrap-up проекта (инициативы то есть)

Из интересного еще - у них нет фиксированных команд, на каждую инициативу она собирают новую.

Из интересного еще - у них нет фиксированных команд, на каждую инициативу она собирают новую.

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

и какие есть? safe вот это все?

Про safe тоже был докладик. Там чувак аргументировал, что суть safe и похожих фреймоврков - возьмем традиционную организацию, аналатикиов обзовем PO, а прожектов скрам-мастерами и готово.

и какие есть? safe вот это все?

Safe и многие другие

Тут http://www.agilescaling.org/ask-matrix.html их все сравнили

Тут http://www.agilescaling.org/ask-matrix.html их все сравнили

не смотрел, но одобряю 😉

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

Несколько сервисных или подерживающих команд (как Continuous Integration System Team) в таком случае - нормальное явление. Важно что они не интегрируют сами, а поддерживают систему интеграции.

👋🏼 #whois Мади, занимаюсь поддержкой энерго/водных стартапов в Dubai Future Accelerators

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

Так сделайте фейкого пользователя и назначайте на него.

Я вешаю на себя, на владельца продукта

Ребята потом сами растаскивают

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

фейковый это + пользователь. Что изначально все на себя назначать вариант.

а sub-tast используете или все в tast?

tasty issues 😄

Не спускались до сабтасков. Стори и тасков хватало. Мы вопрос нагромождения этого дерева решили путем расширения доски с Plan Do Done , до план, анализ , разработка, qa+описание, дон

Так привычнее оказалось

Полного универсализма в команде вряд-ли добьемся , поэтому так

test cases по такому же маршруту?

мы просто время на тестирование также планируем. Через JIRA время на тестирование в burndown можно отражать?

Аналитика для описания верхнеуровневого тестейсов. По нему производится разработка фанка и автотестов, после этого Стори уходит метологам, которые описывают фанк и в тоже время тестят .

Потом ещё тестирование командой девопса, но это не в нашей команде

Так сделайте фейкого пользователя и назначайте на него.

А в чем фишка? Можно же делать unassigned?

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

В каком месте РЭ по Scrum написано что так делать нельзя?

А в чем фишка? Можно же делать unassigned?

фишка в том, что у нас не Jira a TFS :)

Кстати а рефакторинг как оценивать на планировании?)

Кстати а рефакторинг как оценивать на планировании?)

Учитывается при оценке или влияет на "точность планирования". Рефакторинг есть всегда, вопрос в объеме.

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

Учитывается при оценке или влияет на "точность планирования". Рефакторинг есть всегда, вопрос в объеме.

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

А блин. Я на какой-то другой комментарий отвечал

Про противоречие скрамгайду

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

Люди важнее инструментов....... Эх...

Про противоречие скрамгайду

все, что не запрещено и не противоречит ценностям ;)

В каком месте РЭ скрама требует самоорганизацию команды?

Что такое РЭ скрама?

Что такое РЭ скрама?

The Scrum Guide(™) РЭ - Руководство по эксплуатации или Руководство по применению. Руководство по Скраму Исчерпывающее руководство по Скраму:

(Источник: The Scrum Guide, перевод издания 2017 года) 1. о назначении РЭ:: Самоорганизующиеся команды самостоятельно решают, как выполнять свою работу, а не следуют внешним указаниям. Кейс (Михаил): .... (мы) назначали сразу на исполнителя. тут: "мы" = это решение внутри команды, а значит их правило. 2. о "внезапном планировании на дейли" РЭ:: Встреча не должна занимать более 15 минут, за которые Команда разработки планирует свою работу на ближайшие 24 часа. Команда оптимизирует взаимодействие между её членами и повышает свою производительность, анализируя сделанное за последние сутки и прогнозируя оставшуюся на этот Спринт работу Тут: ничего нету про "привязку" задачи к исполнителю, ровно как и запрещение такой привязки. 3. о своих правилах в Scrum : РЭ:: Скрам – это фреймворк(1) , предназначенный для разработки, поставки и поддержки сложных продуктов. (1) Фреймворк — это набор базовых элементов и правил, своего рода каркас, на котором строится процесс разработки (здесь и далее — прим. переводчиков) Тут: Scrum это "каркас", также как каркас дома. Но стены и фасады у всех домов разные, а несущая конструкция или каркас дома почти одинаковая. Также и процессный каркас Scrum - определяет только минимум действий и ролей которые общие в организациях разного типа но общих в условиях достижения целей.

@sbase тут: "мы" = это решение внутри команды, а значит их правило. ложное предположение. вопроса "кто такие "мы" - никто не задал. соответственно вся логическая цепочка ложная

@sbase тут: "мы" = это решение внутри команды, а значит их правило. ложное предположение. вопроса "кто такие "мы" - никто не задал. соответственно вся логическая цепочка ложная

Предположение не может быть ложным, так как нет утверждения обратного что "мы" - это "Я, как менеджер (снаружи команды) решил что нужно делать так...." - здесь явно внешнее управление. Поэтому, единственное, с чем могу согласиться это : предположние "мы" требует уточнения, "так ли это".

В каком месте РЭ скрама требует самоорганизацию команды?

это первое свойство определения development team тащем то

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

:)

Точка банк?

Там вообще все Бирюзово

Там вообще все Бирюзово

Кто то может меня просвятить, как бюрюзовая парадигма связана со скрамом ?

Ну в той области где люди важнее процессов и все такое

Альфа разве таким не хвалилась? Продуктовые команды?

Альфа да . Но не вся а местами

Но это естественно :)

https://youtu.be/p3fVTauR4V8

Ну в той области где люди важнее процессов и все такое

Коллеги, не путаем понятия Agile философии и Scrum фреймфорк

Скрам фреймворк живёт в рамках аджайл философии

Я б даже сказал исповедует

Для меня лично неотделимо

Либо все это КАРГО

Скрам фреймворк живёт в рамках аджайл философии

Вот прям в рамках? А без Agile, не? Почему?

Либо все это КАРГО

И что? Это всегда плохо или как?

Ну ээээ..потому что есть овощи а есть фрукты . А среди овощей есть яблоки

ну в конечном итоге ДА, этой мой личный опыт, может у кого-то и работает.

А чтоб выглядеть совсем правым добавлю что среди фруктов есть картошка

ну в конечном итоге ДА, этой мой личный опыт, может у кого-то и работает.

Плохо, что Карго? А если работает и карго - почему плохо-то? Или не может работать отдельно? Почему?

Ну ээээ..потому что есть овощи а есть фрукты . А среди овощей есть яблоки