есть процессы в голове менеджера "я настроил продажи, там такая-то воронка" например, а есть факт, факт - живой

Давай про факт - мне реально интересно, как в топологии канбана есть что-то "живое" в отрыве от циклов предприятия. Т.е. я не то что бы шучу или пишу бред - интересно, как именно эволюционировали части "old style production management".

могу вместо живого использовать "на самом деле"

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

и на этом этапе они оперирует галлюцинациями о текущих процессах

А есть тут кто, кто может соединить канбан/agile с системной инженерией? Там есть минимальная моделька "как на самом деле"

https://www.slideshare.net/abayda/essence-syseng-omg20jun13v41?next_slideshow=1

Ой блин essence

это настолько далекая технология от людей

умрет потому что сложная

на эту тему надо отдельный чат организовать и там будет 3 человека

вы Цепков

и еще кто-то

:)))

и на этом этапе они оперирует галлюцинациями о текущих процессах

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

“The OS Canvas” @aarondignan https://medium.com/the-ready/the-os-canvas-8253ac249f53

Просто у меня этот канвас вызывает ощущение того, что можно проще на всё смотреть (без натягиваемой за уши системной инженерии) - а agile как процессная функция поверх. Для меня самый блевотный уровень "псевдо-agile" - это подмена управляемости процессами управляемости организацей.

"agile как процессная функция поверх" - AGILE?

"agile как процессная функция поверх" - AGILE?

Поясни вопрос, плз

ну тут подмена понятия

agile сам по себе не может никакой функцией быть

это в лучшем случае - соглашение

(с формальной тз)

это вроде тот самой нонсенс который происходит - "компании покупают agile" :)

Сейчас ищу слова, которые бы не указывали на https://goo.gl/PK7Rfz =) пару минут

Практика показывает, что Kanban в компании можно начинать с Personal Kanban, это выступает диагностической фазой и дает базовое представление о том какие процессы в принципе ЖИВЫЕ

Слушай, я сейчас заметил, что ответил на свой вопрос сейчас, который увидел через твои буквы. Мой вопрос - "как соединить EA (Enterprise Architecture) с Agile?" Интересный ответ даёт https://www.slideshare.net/dannygreefhorst/agile-togaf-and-enterprise-architecture-will-they-blend

Картинко

Что думаешь?

Чем больше мутных определений тем больше успешности манагера

хорошая картинка

так слева все что угодно можно поставить и вывести плюсы аля софт скиллз, ежедневное общение и тд. ответьте на вопрос как вы текущую архитектуру банка, менять по agile будете... u

Я бы предложил на планировании сказать команде (в которой все и аналитики, и дизайнеры, и разработчики): Ребята, вот нам нужно, чтобы пользователь залогиниться мог. Команда обсудит, что для этого нужно, она самоорганизуется. Все что для этого нужно, это снять всякие преграды типа личных kpi, отделов и тд, поставить общую задачу и норм SM, который предотвратит всякие личностные конфликты.

Привет, у меня как у ПО пока не получилось навязать такой процесс. РЕально очень тяжело старые порядки изменить. У нас конкретно все уперлось в качество стори - насколько она должна быть прописана перед процедурой Планирование спринта https://en.wikipedia.org/wiki/INVEST_(mnemonic) Есть стори которые я не знаю как расписать на небольшие, тк сложный технический контекст. самые спорные два момента в описании сторей - обсуждаемость и размер

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

Привет, у меня как у ПО пока не получилось навязать такой процесс. РЕально очень тяжело старые порядки изменить. У нас конкретно все уперлось в качество стори - насколько она должна быть прописана перед процедурой Планирование спринта https://en.wikipedia.org/wiki/INVEST_(mnemonic) Есть стори которые я не знаю как расписать на небольшие, тк сложный технический контекст. самые спорные два момента в описании сторей - обсуждаемость и размер

По мне, формализм тут как раз убивает - слова "навязать" итд https://www.slideshare.net/vmysla/scrum-at-spotify Тут парни меняют саму структуру управления - сквады, трайбы, гильдии - и кросс-функциональность всей этой машинки рождает живой интерес, а не "навязанный"

Разбираю статьи Aaron Dignan'а (Founder @theready, angel investor) - https://medium.com/the-ready "And they organize the work, the teams, and the individuals around a purpose — unpacked for each context. If these themes sound familiar, that’s because they’re the traits associated with workplaces that create intrinsic motivation" Я вот в этом чате вопрос задаю: как выглядит ваш BoO (Body of Organisation)? Потому что грамотные перцы уже работают с Agile как с частью постоянного орг.проектирования -> мини-компаний (как "миссия-ценности-цели", а не юр.форма)-> задач. И какими обратными связями связан BoO с такими же организациями и вовлечёнными лицами (stakeholders)? Короче, как перестать практиковать "не-Agile" и начать жить? :)

Привет, у меня как у ПО пока не получилось навязать такой процесс. РЕально очень тяжело старые порядки изменить. У нас конкретно все уперлось в качество стори - насколько она должна быть прописана перед процедурой Планирование спринта https://en.wikipedia.org/wiki/INVEST_(mnemonic) Есть стори которые я не знаю как расписать на небольшие, тк сложный технический контекст. самые спорные два момента в описании сторей - обсуждаемость и размер

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

не, даже не начинаем , тк спорим

делаем по старинке в итоге пока - ПО и аналитик отдельно работают - а девтим на вход только рафинированное принимает

тоже пришли к этому, что сначала работают аналитики, потом дизайнеры, потом разработка.

кажется, что это не аджайл..

но тогда разработчики не чувствуют вовлеченности в процесс и не понимаю, какую ценность приносит их труд кастомеру

А их это же устраивает

А их это же устраивает

в версии "2002 год" - да в версии 2017 - нет - спросите живого разработчика образца 2017 года

разберите такой кейс: отдали команде US - я, как пользователь, хочу залогиниться, чтобы купить товар. команда организовалась и запила форму логина пароля из локальной БД. потом пришел ПО и говорит: 1. при обрыве связи надо сделать форму с указанием телефона, 2. надо сделать логин через фейсбук, контак и гмайл. это будет новая US, реворк старой или что-то другое? по факту: запилил не совсем то.

в версии "2002 год" - да в версии 2017 - нет - спросите живого разработчика образца 2017 года

а что изменилось?

разберите такой кейс: отдали команде US - я, как пользователь, хочу залогиниться, чтобы купить товар. команда организовалась и запила форму логина пароля из локальной БД. потом пришел ПО и говорит: 1. при обрыве связи надо сделать форму с указанием телефона, 2. надо сделать логин через фейсбук, контак и гмайл. это будет новая US, реворк старой или что-то другое? по факту: запилил не совсем то.

в кейсе же изначально дисфункция PO должен постоянно работать с командой и еще при разборе истории это должно было всплыть

разберите такой кейс: отдали команде US - я, как пользователь, хочу залогиниться, чтобы купить товар. команда организовалась и запила форму логина пароля из локальной БД. потом пришел ПО и говорит: 1. при обрыве связи надо сделать форму с указанием телефона, 2. надо сделать логин через фейсбук, контак и гмайл. это будет новая US, реворк старой или что-то другое? по факту: запилил не совсем то.

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

;)

не вредничайте)

разберите такой кейс: отдали команде US - я, как пользователь, хочу залогиниться, чтобы купить товар. команда организовалась и запила форму логина пароля из локальной БД. потом пришел ПО и говорит: 1. при обрыве связи надо сделать форму с указанием телефона, 2. надо сделать логин через фейсбук, контак и гмайл. это будет новая US, реворк старой или что-то другое? по факту: запилил не совсем то.

но, если уже ситуация такая, то это отдельная история, почему нет

это зависит от возможностей платформы, например

в кейсе же изначально дисфункция PO должен постоянно работать с командой и еще при разборе истории это должно было всплыть

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

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

нет, если вы внутренний продукт пилите ;)

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

на любом PO это член скрам команды, он ПОСТОЯННО с ней взаимодействует. Это может всплыть на планирование (и, скорее всего, всплывет), это может всплыть уже в процессе реализации (но тогда, на ретро, логично поднять вопрос, почему так поздно всплыло), но если это всплывает уже после реализации, то это прям плохо)

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

почему не всплывает?))

потому что мало общаетесь

а какая разница когда всплывает

вы пытаетесь стандартизировать

нет, я пытаюсь понять как делать, чтобы не всплывало

вот так

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

плохо кому

2 человека на картинке справа - скучают...

ну вот вы сейчас написали* - нет поощрения культуры ошибки

усе :)

поэтому у вас много противоречий

проект, сроки все дела

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

в версии "2002 год" - да в версии 2017 - нет - спросите живого разработчика образца 2017 года

устраивает моих)) вообще дисфункция все что дальше кодирования

потому что удачно планировать можно только в понятном домене, там agile нет

быстро переделывать понятие относительное...

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

то есть выносить анализ в отдельные спринты?

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

на любом и особо качественно на Планировании спринта

спринты тут не при чем

просто можно сказать - ДО разработки

если вы закладываетесь в анализ

спринты только мешают

вы не можете ограничить аналитиков