Таймлайн для любимых подписчиков: 01:34 - Программирование и незаконченная аспирантура 05:49 - Приход в менеджмент через компьютерное зрение и установку камер 09:36 - Высшая Школа Экономики и MBA 10:37 - РЕКЛАМА 13:06 - Статьи на хабре и первые выступления 14:16 - Про ломку при уходе из программирования 16:13 - Менеджмент не благодарная наука 17:51 - Agile и альтернативы 24:12 - Канбан не про доски! 26:11 - мИФ ПРО ТАЙОНУ И КОНВЕЕР И БЕРЕЖЛИВОЕ ПРОИЗВОДСТВО 30:24 - О бережливом производстве 33:15 - Скрам или канбан 34:23 - Ради чего это нужно? 36:46 - "когда это будет сделано?" 38:38 - Статистические методы оценки 40:21 - Как проводить изменения 42:36 - Можно ли использовать канбан вместо скрама 48:52 - А чё разработчикам от этого канбана 53:33 - Скрам 2.0, скрамно, скрамбан 56:39 - Почему канбан НЕ МЕТОДОЛОГИЯ 01:00:13 - Как разработчику понять что на проекте канбан 01:07:25 - Что уйдет из скрама, если появится в проекте канбан 01:09:45 - Не берите канбан со старта проекта! 01:10:49 - Книги 01:12:45 - БЛИЦ 01:24:26 - КОНКУРС
Кратко о видео: кто понял тот понял, кто не понял, тот не понял P.S Действительно согласен с комментариями что ни логических примеров, ни что такое agile, ни scrum, ни kanban не было сказано для обычных людей.
Может и вправду тяжело просто и понятно рассказать о Канбан, но обычно чем человек лучше разбирается в теме, тем проще и понятнее доносит информацию... Чувство, как будто в тебя воды влили нехило так.
Идёт середина видоса и я до сих пор ничего не понимаю... что такое канбан я хз.. типа все что улучшает - это и есть канбан. Такое чувство, что меня заставляют нанять коуча по канбану))
Ответь себе (только честно), а знаешь ли ты, что такое ПРОЕКТ, сможешь ли дать одно из классических определений, сможешь ли объяснить, чем проектная деятельность отличается от операционной (функциональной)? То-то и оно. Это русский мир, батенька :). Это генотип. Тупиковый проект Творца.
"Вы можете использовать канбан, чтобы улучшить ваш Скрам." "Использовать Канбан, не вместо Скрама, поверх!", "Канбан - способ, улучшить этот процесс", "Термина "Мы работаем по Канбан" - нет, как и термина "Мы внедрили канбан"". "Контекст, в котором Скрам - перестал подходить, ты можешь использовать Канбан либо начали использовать по ошибке Скрам, где он не подходит - нужно использовать Канбан" :)
посмотрел видео про Скрам - все понял, плюс немного почитал стало многое ясно. Тут же...подумал, что я не догоняю, полез в комменты...фух, оказалось все со мной впорядке) спасибо комментам.
На habr очень хорошо написано про scrum vs kanban) Scrum- гибкий, kanban- ещё более гибкий. Scrum- для этапов создания продукта (долгий, трудоёмкий процесс, поэтому и задачи решаются довольно долго) kanban- вы уже зарелизили продукт, получаете фидбэки и фиксить и апдейтить надо буквально ежеминутно, что как раз и позволяет делать kanban) Ну как-то так это представляется лично мне)
Также для себя понял. Типа если в компании говорят, что работают по канбан, значит продукт хотя бы в mvp уже есть и его апгрейдят и баги убирают Ну либо люди как и многие не понимают разницу со скрам и продукта готового нет, но канбан приятней уху)
@@denispenshin4746что говорят в компании вообще редко имеет отношение к тому, что реально делают. После ряда собеседований и компаний сделал вывод, что по скраму/канбану работают все, просто потому, что без этого в их понимании работать невозможно. Но у каждого этот скрам не похож на соседский, но именно его они считают каноничным. Самый же каноничный скрам я видел в компании, которая его не использовала. Там не было модных досок, зато было всё остальное. Такой скорости выпуска фичей и выхода на mvp я больше нигде не видел. И уходили с работы по расписанию, за исключением совсем уж форс мажоров, но это было пару раз в год всего
Юмор - это инструмент с помощью которого мы пытаемся справиться с реальностью. Присказка "Лучше дочь проститутка - чем сын скрам мастер" лихо резюмирует засилие IT рынка безусыми agile консультантами. Я с Алекссем Пименовым не работал, про работу его не слышал. Но, с моей точки зрения, объяснено всё очень доходчиво. Мне понравилось. Было полезно. Спасибо!
Спасибо за гостя - очень правильный мужик. Думал, перевелись в РФ грамотные, образованные, эрудированные люди, но нет - есть еще полноценные Айтишники! Их слишком мало для большой страны, и потому она обречена... Но все равно приятно, что они есть. В 2000-м году, 20 лет занимаясь исключительно проектной деятельностью (начиная с разработки АСУ Госбанка СССР (!)), я вдруг узнал о существовании отдельной предметной области "Управление проектами", со своими стандартами и методологиями/методиками. Причем, различные "западные" подходы к разработке больших софтверных ИС я использовал с первых лет трудовой деятельности, когда они даже не переводились и не издавались у нас (напр., Метод нисходящего проектирования с использованием HIPO-диаграмм, CASE-технология). Надо признать, что советская промышленная разведка пусть с опозданием, но поставляла в закрытые госучреждения кое-какие технические и технологические достижения Запада. Поэтому у нас всегда раньше, чем даже в Академии наук, появлялись новые трансляторы, СУБД и т.п. Тогда же в 2000 г. я прочитал в интернете, что специальная комиссия при правительстве КНР обнародовала итоги своих исследований: народное хозяйство Китая испытывает дефицит в 20 000 профессиональных менеджеров проектов. Правительство Китая приняло срочную государственную программу подготовки проджект- менеджеров и их сертификации на степень PMP (Project Manager Profassional) по программе Project Management Institute (штаб-квартира в США, штат Пенсильвания). У меня нет сомнений, что эта программа была выполнена :). Результаты - на лицо. "Чтобы мыслить нестандартно, стандарты надо знать". Если бОльшую часть проф.деятельности вы занимаетесь проектной деятельностью (в любой роли-ипостаси), начните с прочтения стандарта де факто для УП - PMBoK от PMI (не ICB от IPMA). Тогда и в методологиях/методах/методиках начнете ориентироваться осмысленно. И многие другие интересные вещи могут открыться для вас, совершенно неожиданно (как для меня когда-то). P.S. Если честно, я узнал о профессиональном УП (о PMI и PMBoK) в ходе рабочей командировки в Дойчебанк. Три года мы безуспешно пытались реализовать проект создания ИС Национального Банка Украины на базе ERP-системы SAP R/3. И когда уже нависла угроза дискредитации коллектива и системы SAP R/3 (а че? у нас же это запросто), решили послать за опытом к немецким коллегам. Меня сделали руководителем делегации. Вернулся другим человеком. Оказалось, наши ребята и систему знали в сто раз лучше, и бизнес-процессы знали отлично (делали же реинжиниринг BPR и затем кастомизировали систему). А собака была зарыта в другом месте... Главная проблема - неправильная организация проекта и игнорирование требований методологии SAP ASAP в части вовлечения в проект ключевых сотрудников заказчика, начиная со спонсора проекта, владельцев бизнес-процессов, руководителей функциональных групп, ключевых пользователей, их обязательное поэтапное обучение на курсах вендора и т.д., с возложением на них ответственности и одновременным внедрением специальной системы мотивации, и т.д., и т.п. Я стал бороться за проект (не будучи его руководителем). В итоге меня назначили руководителем проекта (флаг вам в руки), и через 6 месяцев мы успешно перевели пилотный филиал банка на работу в новой системе. А дальше был роллаут.
Канбан - это инструмент, представляющий из себя упорядоченный список заданий. Он позволяет регулировать более быстрое выполнение проекта. Любой план представляет из себя гипотезы: 1) О том что за данный период времени должны быть сделаны конкретные работы; 2) О том что, конкретная работа займет конкретное время. В реальной жизни, как в материальном производстве, так и в ИТ-сфере конкретная работа может быть выполнена быстрее или медленнее, чем планировалось. Также может потребоваться отложить одно задание, чтобы приступить к другому. Канбан помогает внепланово делать планируемые задания и наоборот планово делать то, что было на данный момент не запланировано. Гибкое производство! Разумеется, чтобы Канбан работал лучше есть и другие инструменты, например по подготовке специалистов, позволяющие меньшим числом, не перенапрягаясь делать больше работ ;-)
Хм. Странно, что из видео вы упустили и другие моменты о Канбан-Методе 1. Социальные аспекты внедрения изменений 2. Смысл надо ли вообще применять канбан-метод, может и так всех устраивает? 3. Канбан это Метод. 4. Пробобалистическая оценка это небольшая часть канбан-метода 5. Упорядочивание заданий - слишком по разному можно понять. Может быть вы имели в виду управление потоком работ?
@@ThePavelPower Вероятно я многое упустил из того, что сказал Алексей или того, что он хотел сказать и как это выразил. Сила Lean в том, что объединяя субъективные мнения разных специалистов можно получить более объективную картину ситуации. Затем можно коллективно обработать информацию и коллективно принять подходящее для ситуации решение. В разных сферах Канбан может выглядеть и называться по разному - в том числе "чек-лист". Важно не только то, что в нем написано, а еще и то, что он является поводом для коллективных взаимодействий.
@@БорисБорисовичКондрабаев-Прозо не хотел бы вас расстраивать, но Lean - это скорее про производство, или например про выстраивание pipeline в DevOps. Но не про тот вид деятельности, где рабочим элементом является накопление знаний - непосредственно интеллектуальный труд с высокой вариабельностью и валатильностью. Само понятие канбан - это сигнал к вытягиванию. А Канбан-Метод - это метод благодаря которому можно строить Канбан-Системы (или вытягивающие системы). В рамки Канбан-Метода входят использование и применение как визуализации, работы с социумом, статистики, контекстного анализа, способы внедрения изменений, и другое. Возможно само по себе слово Канбан - часто путают с доской со стикерами или Lean подходами. Но это не так.
@@ThePavelPower Каждый имеет свое понимание о Lean. Кто то понимает его с точки зрения менеджмента количеств/цен, а кто то с точки зрения менеджмента качеств/ценностей. Про рамки Канбан полностью согласен.
Очень крутое интервью, спасибо за полезные советы! Всегда интересно послушать опыт специалиста, особенно по Kanban.Также используем Kanban (в Strive, онлайн гораздо удобнее, чем все это вести на физических досках) для управления задачами, и такие интервью помогают глубже понимать его возможности и ловушки. Здорово, когда есть возможность применить знания от профи!
Не понимаю тех, кто "ничего не понял". По моему, всё что нужно было объяснить, было объяснено и заблуждения развенчаны. Но пытаться переубедить свою команду, что канбан это не доска, не буду. Сначала книжки из видео почитаю. Алексей Пименов, если ты это читаешь, спасибо, тебе, ты крут! Борода, спасибо за ещё одно отличное видео!
- Рад приветствовать вас в нашем блокчейн-стартапе! - По телефону вы не говорили что вы в подвале работаете... - Это не подвал, это лофт! - А что за бомжи на входе клейнюха пиздят? - Это наша скрам-команда! Работаем по аджайлу!
Пример с применением Канбан на заводе (материальное производство) понятен, как он работает и в чем плюсы, что касается ИТ сферы, я не до конца поняла в чем преимущество Канбан и как пошагово он внедряется (кроме wip limits), если уже есть, к примеру, настроенный Скрам. Немного не хватает конкретики и структуры. Но в целом, было интересно послушать, спасибо!
Добре. Подход со снарядом Канбан-Метод начинается с изучением контекста и выяснением точек неудовлетворённости внешней и внутренней. Разъяснением того кто является клиентом, и что за сервис предоставляет "команда" своим клиентам, что является результатом. (Кстати не всегда в командах понимают кто клиент и что за сервис предоставляется) Потом определяются потоки типов работ и классы обслуживания, какие они в реальности существуют, а не какие заведены в вашей JIRA или каком ещё issue traker. На этом этапе сами разработчики часто удивляются тому, что не заметили слона. Потом изучаются возможности команды, такие как: пропускная способность, реальное время выполнения задач какого типа и класса с какой скоростью, как это соотносится с оценкой (привет Майку Кону который многим голову напудрил своей книгой про Agile оценки). Потом выясняются эффективность потока (не людей или команды) оценка эффективности потока даёт понимание на сколько можно ускорить получение результата простым способом - сокращение незавершенной работы. Потом определяется характер вариативности поставок - что даёт хорошо понять имеет ли вообще тратить время на оценки, например. Потом определяются естественные SLA по времени для команды по типам и классам задач, которые защищают команду от перегруза и ошибок оценки .... Если дальше интересно, то прочитайте про STATIK. После анализа понимается решение о плане изменений в зависимости от текущего организационного уровня команды и того уровня к которому нужно команду привести чтобы "команда" соответствовала своему предназначению или даже больше.
Пориимущество канбан заключается в здравом смысле - создавать такой вид процессов который соответствует контексту для получения нужного результата и динамики развития организации.
Говорить, что канбан не имеет никакого отношения к бережливке и аджайлу по меньшей мере не корректно. Это все равно, что говорить, что лев это совсем не тигр. Но лев и тигр, также как и кот это семейство кошачьих и они все объединены общими признаками. А в организации важно уметь находить оптимальную точку разделения и обобщения . Противопоставлять надо традиционный менеджмент использующий управление по целям и инерционный подход с передовым менеджментом, использующим гибкий подход. То есть парадигма в которой гибкость важнее плана. И к такому гибкому подходу вы можете смело причислять: Agile QRM Скрам. Lean (настоящий гибкий Лин, а не его интерпретация в РФ), производственный канбан и вытягиваюшая система. Канбан метод в проектном управлении. Теорию ограничений Голдратта. И даже менеджмент качества (настоящий TQM основанный на статистическом управлении процессами и контрольной карте Шухарта) Все эти методы, ориентированы на гибкость и скорость. Все они ориентированы на управление динамическими, стохастическими системами и перекликаются с кибернетикой и синергетикой. И стоят особняком к традиционному менеджменту. Показывают, как работать с неопределенностью, вместо того, чтобы бессмысленно молиться на ложно детерминированный план. Поэтому не имеет смысла говорить о том, как бенгальский тигр отличается от амурского. Лучше объясните людям, как тигр отличается от бегемота. Это гораздо важнее, так как правильно акцентирует внимание ищущего человека.
Спасибо за видос. Класная инфа. Гибкая система нужна в процессном управлении для непосед.Усидчивый чувак сможет к любым вещам привыкнуть, творческий нет. Ему рутина затылок чешит и нужно что-то делать лучше, иначе. В любой сфере есть проторенные дорожки. Когда айти полностью объединится с бизнессом(во всех масштабах) соединятся системы бизнес архитектур типа ТОГАФ, аналитик типа процессов типа BPMN, улучшений типа Канбан, проектных техник типа Agile. И будем мы жить в красивом утопическом обществе)))
Чё то я смотрел-смотрел этого дядьку, сколько он всего рассказал, но не понятно нихрена. Хотя я варюсь в теме. Очень много воды, максимально мало практических вопросов, как в итоге работать. Не понравился дядька, а вот канал отличный, спасибо за видосы.
Успех того или иного подхода действительно зависит от мышления, ведь далеко не каждый способен к гибкому анализу в рамках контекста. Очень часто деревянные манагеры подскакивают кабанчиком, лишь бы внедрить, не имея глубокого понимания, не желая развиваться и заниматься "калибровкой". Спасибо за интересный выпуск.
Имхо, ситуация сейчас на рынке (2022) примерно такая: СКРАМ - применяется в основном в айти и цифровизующихся телекомах-банках-тп компаниях - применяется для создания продуктов с нуля и до победы в "комплексном домене" по модели Кеневин (ruclips.net/video/rCLth07UAsA/видео.html) - выделенной роли "правильного" скрам-мастера, кто за все это безобразие отвечает в 98% российских компаниях - НЕТ. Обычно эту роль выполняет проджект, реже продакт или один из разработчиков (в обоих случаях будет "не очень", потому что не будет достаточных знаний и опыта) - Скрам все больше становится "просто инструментом" для проджекта/деливири-менеджера, одним из гаечных ключей" в его тулбоксе (также как у прогеров библиотека) - в 99% случаев внутри спринта используется канбан-доска. т.е. в реальности используются оба подхода, но сильно усеченные (не ставят цели спринта, не работают с WiP и тп) - в 80-90% случаев по скраму работают в Джире, т.к. там на лету создается "аджайл-проект", состоящий из роадмапа, бэклога разделенного на спринты и канба-доски для активного спринта. Все просто, понятно, легко въехать. Плюс в Джире хорошо сделан раздел с отчетами (капасити, бернапы и тп) КАНБАН - в 90% случаев подразумевается ПРОСТО РАБОТА со стикерами задач на доске - чаще всего - в Трелло, иногда подпроектами в Джире - WiP-лимиты используют только оооочень прошаренные проджекты/тимы))) - какую-то аналитику, свимлайны, гистограммы, петли обратной связи наверное кто-то использует, но после очень хорошей консалтерской работы))) - в общем - Канбан для народа - это трелло-доска со стикерами тасок, 3-5 колонками статусов, ассайненными исполнителями, чек-листами внутри тасок - через 3-6 месяцев юзания такого подхода - первая колонка с общим бэклогом продукта/проекта становится сборищем тотального отстоя на несколько сотен тасок и НИКТО не понимает "что с этим делать" ))) - кстати, последний трабл в Джире решили весьма красиво - в настройках проекта ставишь галочку и делаешь "бэклог проекта" ОТДЕЛЬНО, не внутри канбан доски, что еще больше приближает реализацию "типа канбан" к "типа скрам", т.к. изобщего бэклога надо отобрать приоритетные таски в бэклог канбан-доски (штоо???) и при этом постараться не запутаться где у тебя што)) ПРО БУДУЩЕЕ - очевидно, что НЕ большие компании (малый и средний бизнес) будут юзать непрофессиональные попсовые подходы, которые могут на лету и без заморочек решить главную потребность бизнеса - хоть как-то нормализовать и стандартизировать поток тасок от туду в дан. Если кто-то при этом сможет еще что-то делать с командой,ретро, осью, графиками и повышать производительность работы - честь и хвала такому народному гению) - большие компании все больше отходят от просто-скрам/канбана в сторону сложных, но видимо продуктивных Лессов, Сэйфов, Социо и Холократий. Такие временные и ресурсные подходы недоступны "обычным" компаниям ввиду их затратности (что обычно применимо к любой разнице в ресурсах биг компаниз и остальных) - примечательно, что например в Яндексе и Сбере почти вернулись к "классике" проджектов и продактов, и для обоих в требованиях скрам-канбан-аджайл подходы просто указываются как требованию к опыту ЧТО ТАМ - на рынке западных вакансий (ЕС и ЮК) довольно много вакансий именно отдельных специализаций скрам и канбан лидеров/мастеров/коучей, так что как раз "там" тема до сих пор живет и развивается.
Нескончаемый поток терминов и жаргонизмов, которыми он умело жонглирует, как любой нахватавшийся теоретик. В итоге ни о чем. Я не знаю в чем ценность этого видео, но я тупо слил время, а хотел разобраться в этих технологиях.
Мне вот интересна одна составляющая подобных методов. Иногда предполагается спрогнозировать трудозатраты и затраты времени для решение той или другой задачи. Вопрос ы том, что многие задачи имеют эксперементальный характер. Как прогнозировать затраты времени и ресурсов на их решения? В моём представлении оценить затраты на решение задачи можно только решив её и оценив по факту. Какие методы предусмотрены для подобных случаев?
@@avmletsplay4450 как тут Story Points поможет? Если ничего не известно о задаче, то как можно дать прогноз завершения? Обычно задачу пытаются сначала декомпозировать для того, чтобы понять какие типы работ команде уже знакомы, и на основании уже этих данных давать прогноз. С учётом того, что известно о возможностях самой команды. Может быть в команде нет какой-то компетенции для выполнения. Тогда оценка не релевантна.
Спасибо за контент! Пименов живая легенда нашей современности! Похвалить его - значит не сказать ничего) Чистой воды профессионал. Мечтал бы у него учиться
При просмотре словил большой инсайт, реально всю дорогу думаю что надо оценить задачки, накидать в спринт и смотреть как всё там шевелится или не шевелится. А надо думать наоборот, релизами и версиями. это у меня к 35 минуте такое. Но вот что за "вытягивание" я что-то к этому моменту так и не понял.
Интересный выпуск получился. В начале не хотел смотреть, т.к. меня больше интересуют интервью с программистами про конкретные языки программирования. А тут и гость интересный оказался, и тема зашла, как ни странно. :))
вообще не понял, что такое канбан. это соус, который ты добавляешь в любой процесс. а если серьезно, то я понял, что вот есть скрам, если не нравится жесткость рамок спринтов , и мало колонок состояний, и нельзя брать больше или меньше задач чем нужно, то используешь канбан, и можешь делать че хочешь. можешь добавлять новые колонки, можешь брать сколько хочешь задач, или только одну, я так и не понял, можешь выходить за рамки спринта, дольше делать, чем один спринт задачи, либо можешь переключиться на абсолютно новые задачи, которые приорити и не в спринте, и задеплоить посреди спринта, например. пока то, что я понял - это то, что канбан - это хаос. ну не в плохом смысле, а просто идея, что можно не следовать жестким практикам скрама, а делать че хочешь, и смотреть на результат, но все равно сохранять какие-то процессы. очень разманно, непонятно это определение)
В рассуждениях есть несколько непонятных моментов. 1. У вас фиксированное количество задач в работе, которые не имеют фиксированного временного окна как двухнедельный спринт. Какой смысл в фиксированном количестве, если вы не работаете над задачами последовательно, ведь вас съедят за переключение контекста в любой команде, это биологическое ограничение? 2. Если идет экономический рост снаружи компаний, то акцент на доставке фич и Kanban здесь лучше подходит, но если кризис - то компания бдит о бюджете, режет косты, увольняет, внедряет метрики для контроля расходов, режет или избавляется от малоиспользуемого функционала. Scrum здесь привлекательнее, менеджер лучше держится за место, пускай накапливая технический долг (качество трудно считать), но зато отчитываясь через метрики, где можно тыкать пальцем на графиках, успокаивая начальство. Какой смысл получив после среза затрат, сократив скрам-мастера и бизнес-аналитика(потому что неясно как мерять их эффективность в деньгах) и получив "у нас свой Scrum", если придется размазывать их обязанности по команде, теряя фокус над задачами, увеличив обратное делегирование и неэффективно используемое время работы экспертов?
За полтора часа из полезного узнал только что есть электричка Истра - Москва. Сложилось впечатление, что гость тренирует по книжкам, а не по боевому опыту - нет никаких примеров что же там может поломаться в скраме и как это может починить канбан, а на простые вопросы отсылает почитать книгу.
#КОНКУРС Если я правильно уловил мысль, то основная тема в том, чтобы понять что в текущем процессе управления разработкой не так и менять это, что в принципе разумно, хотя не понимаю почему здесь нужно специальное слово "Канбан", я бы назвал это здравым смыслом. Какие основные отличительные признаки канбана? Скажем занесли представителю заказчика откат чтобы он меньше придирался и добавили лимиты на колонки, таким образом на два вопроса ответили положительно - у нас все, применяется канбан? :) Так и не понял что отличает канбан от какого-нибудь другого способа улучшить качество сервиса и продукта.
Вначале поставил лайк. В момент, когда услышал о "статистике" для оценки временных затрат - отозвал. Серьезно? Возможно, если компания не меняет свой состав 3 года и всё это время делает лендинги на вордпрессе с уже готовыми шаблонами, у неё быстро накопятся данные для достоверной статистики. Экспериментов достаточно много и параметры практически не меняются. Но как только параметры хоть чуть "поплывут" по количеству и/или просто своим величинам, что совершено характерно для того, для чего и используется разработка итерациями с быстрой обратной связью (высокая неопределённость) - помашем этой "статистике" рукой. Чужая статистика тоже не особенно полезна. Теория сложных систем нас учит, - а разработка ПО - как раз такая,- что две сложные динамические системы, даже если они кажутся "похожими", при одном и том же внешнем воздействии дальше будут двигаться по разным траекториям своего фазового пространства. Ничего в прогнозировании затрат не придумали и не придумают. Даже будучи украшенными псевдоцифрами они остаются психологическим феноменом. В среднем и долгосрочном горизоните профакивались и всегда будут профакиваться)
Моё мнение что когда-то Agile работал но с ростом технологий и требованиям к разрабам это прямой путь к выгоранию. Не раз видел как производительность команды может упасть до 50% при переходе на scrum и это при очень хорошем скрум мастере. Agile работает только в очень идеальных условьях, надо просто взять лучшее из него и перейти на hybrid kanban. Давай что нибудь про выгорание, это достаточно неизвестная тема и многие узнают об этом когда уже поздно.
Классное интервью, было интересно слушать, хотя иногда терялась концентрация и приходилось перематывать. Но надо отметить, картина канбана в сознании прояснилась и многое встало на свои места) Спасибо обоим Алексеям и комментаторам, которые также делятся своими знаниями и опытом в комментариях, вас очень интересно читать!
Спасибо, Алексеи (оба). Данное видео появилось в идеальное время для меня. Я как раз начала замечать несовершенство скрамa на моих работах и, при поиске различной информации по улучшению, наткнулась на Канбан. Это действительно не так просто его понять и правильно применять, поскольку написано мало, весьма скомкано и поверхностно. Сейчас сяду читать книжки, что вы посоветовали. Кстати, не соглашусь с предыдущими комментариями, смею предположить, что для не интересующихся оптимизацией рабочих процессов людей, понимание данных процессов будет затруднительно.
Очень размыто с долгим уходом в ненужные детали, несколько раз пересматривал кусками т.к. терялась линия повествования. Сама база что с чем сравнивается смешанно подается на протяжении полутора часов. Дядя энергичный оратор, но он больше запутал чем объяснил, лучше забуду это и посмотрю в другом более структурированном месте, а то на собесе как-то стремно на такое опираться. Лайк за скиллы забазаривания.
Доски называют "канбан", потому что с японского [かんばん/Kanban] - переводится, как "доска")) потому мне тоже поломало мозг выражение "доски - это не канбан")) Оч интересное видео, спасибо!
Спасибо за цитаты. Записал две: 1-ая) на песню Аллы Борисовны "про фарш и котлеты"; 2-ая) от известного боксера "про раствор и осадок". #конкурс Дисклеймер: любые совпадения являются случайными, автор - буйный. :) На лужайке мирно щиплют траву коровки. На холме гордо высится бык Герман и его юный отпрыск из финала СССР. (Сын) - Вон, смотри, смотри, какая красивая! давай, а? (Сын) - А может вон ту... Ах какая! (Сын) - Или вот эту? Тоже хороша!! (Герман) - Не торопись. Сейчас мы медленно спустимся с горы и всех от`Kanban`им. P.S. "Упарывал" текст как мог, сори если что.
Познавательный выпуск, спасибо за труд! На мой вкус все же как-то многовато теории и мало примеров было в выпуске :) Хотелось бы больше конкретики, например для таких-то и таких-то проектов лучше использовать Канбан потому что... для таких - Скрам и тд
Скрам применяется в контексте организации работ для создания комплексных продуктов небольшой командой. В других условиях он не работает. Канбан-Метод применяют для улучшения тех процессов которые у вас есть, чтобы добиться улучшений и выхода на новый уровень. Так если, например,у вас перестал работать Скрам, то можно применить Канбан-Метод и улучшить Скрам, или найти другой способ работы
Интересно, а если человек имеет базовый опыт с процессом создания продукта в IT, но непосредственно не разбирается в технологиях программирования, тестирования, развертывания продукта и прочего. При этом, закончив курсы по методологиям SCRUM или Kanban, такого возьмут со стороны управлять процессом разработки? Т.е. опыта нет, но есть хорошая теоретическая база.
Опыта у меня с этими методами и нет представления. Я не разработчик. Но интересна тема. Я немного баловался для личных дел Trello. И там грубо говоря сделал 3 секции: список дел, в процессе, готово. Читал что надо ограничивать себя единовременно выполнением не более 3х задач. Немного не понял(хотя пока пересматривал ролик и читал литературу, начал понимать) про сигнал к работе. 29:00. Т.е. есть лимит на взятие 4 задач(Work(В) In(И) Progress(П) - лимит)), три уже взял и как бы есть один пустой слот для еще одной задачи. Сигналом для работы является один пустой слот из четырех в моем вип-лимите? Вроде верно. Т.е. не наличие карточки "сделай что-то" в секции "список задач", а место в моем вип-лимите. Могу взять еще задачу - вытягиваю карточку(канбан-метод), работа кипит и сделан проект будет в срок. Канбан это один из множества методов в рамках концепции бережливого производства. Если кратко agile-методология(совокупность методов) - это общее направление проворной разработки (или другого производства), а kanban(«подход баланса») и scrum(«подход структуры».)- уже ее методы(или скорее всего система методов - методика). Scrum и kanban - варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно. Главное сделали. Хехехе. Я прям чувствую как мышление меняется. Пишите свои мысли, поправляйте меня в ответ на этот комментарий. Я сейчас поставил на паузу и начал изучать. Я в шоке и в восторге. Лайк если заметил склейку после 28:20
На тему изи мани #конкурс Труд из обезъяны сделал человека. И надо ж было такому случиться, что именно он мой начальник! Ну, и я согласен с философией примения канбана, изложенноой Алексеем: тихой сапой добивайся нужных тебе результатов.
работаем в Сбере по аджайл, не сказал бы что эффективно используются ресурсы (разработчики, тестировщики, аналитики), но прозрачности больше, конечно, в плане кто чем занимается. Возможно канбан бы помог, но про канбан коучей у нас пока не слышал.
С начала и до самого конца не отпускало ощущение, что этот человек чего-то где-то нахватался, начитался, с практикой не сопоставил, но посчитал, что теперь он умнее всех и может учить. Типичный инфоциган с подвешенной тараторилкой.
Заклинаю тебя, я лучший коуч по канбану! По аджайлу и по доггистайлу. Ты будешь мне платить, работодатель! Потому что я черный пояс по скраму, а твой канбан я улучшал. Понятно...
#конкурс )) когда подаешься на вакансию ПМ (а ты вел проекты да только не в айти), многие компании пишут "опыт использования Agile, Scrum" , прошу обратить внимание на запятую:)) или "знание методологий Эджайл (скрам , канбан) " :))), и шлют тебе отказ, потому что у тебя типа нет опыта ведения ИТ проектов, но ведь у компании и нет понимания, что Эджайл - это не метод, а философия)), но объяснить это ребятам уже и не сможешь да и есть ли смысл?)) Вопрос от Чернышевского: так что делать?)
В вакансиях часто любят перечислить через запятую и обобщить те вещи, которые не стоят на одном уровне (не только про Agile). И ты думаешь hrы ли плохо передали инфу (что ещё пол беды) или сами менеджеры не понимают, что делают
#конкурс Скинул ссылку проджект менеджеру, что топил за скрам (потом за канбан) с привязкой во времени на фразе "Работает с высокомотивированными сотрудниками...". Лишен премии. Высокомотивировали. 😁
Долучайтесь в телеграм канал: t.me/agile_space В основному говоримо про Agile, Scrum, Soft Skills та Kanban. Тут ми публікуємо практичні кейси, поради, добірки, вакансії, події, усі новинки. Готові також поширити ваші напрацювання. Якщо Вам цікава така тема - welcome 🔥
Как будто ток-шоу: вроде и тема есть, и интересная, и рассказчик супер, но - вода, вода, вода... Реально, понятия Agile, scrum, kanban не раскрыто. Интервью ради интервью. Расстроен
Четкий выпуск! Намедни как раз смотрел запись с конференции 13th Agile Days в мае этого года. И тут БАЦ! Алексей у тебя на вью) Хорошая подача, отличные знания. Давно не находил ничего толкового по Kanban в рунете.
Он мне напомнил сэйлзтренеров "Я научу ваших продажников продавать. Надо создать правильный отдел продаж из правильных продажников..." Вроде бы интересно, но так и не объяснил, что канбан добавляет к скраму. Мастерски уклоняется от конкретного ответа
А можно тайминг где я уклонился, я может тогда хоть в комментарии конкретный ответ дам. Если говорить в контексте "канбан добавляет к скраму", то в первую очередь надо понять а что у вас не так? чем недоволен заказчик или команда?
@@pimenaus Согласен с предыдущим оратором. Вы говорили для тех, кто всё это и без Вас понимает. Кто понимал - согласился с Вами, кто не понимал - остался там же, где был. Весь Ваш текст построен по принципу "хорошо делай - хорошо будет". А на вопрос "что такое хорошо?" вы отвечаете, что ответ уникален для каждой ситуации. Всё верно, но абсолютно бесполезно с точки зрения предоставления информации слушателю. Это и называется - вода.
@@Шамиль-ю3н отличный ответ! Люблю такую дискуссию. вот смотрите, вы же сами понимаете, что не бывает универсальных решений (а их часто водогоны и продают: измени свое мышление, измени еще чего нибудь). Если нужен конкретный совет "что делать", то надо хорошо разобраться с ситуацией. Мы же не будем диарею лечить слабительным. Вот Канбан Метод в первую очередь - это инструмент анализа контекста, понимания того, что у вас творится, а потом уже подсказка того что с этим делать. Я просто не понимаю, как я мог отвечать по другому. Если вы обратитесь ко мне с проблемой, то я буду изучать ситуацию и даже прояснять - это у вас действительно проблема и может это симптом чего-то другого.
@@pimenaus вот опять (снова?) пять строчек "блаблабла" ... может, стоило просто рассказать несколько реальных случаев применения? уверен, так более доходчиво получилось бы.
Ахаха. Можно еще написать Scrum Buns, и тогда для практиков есть уже книга www.amazon.com/After-Scrum-Dahlia-Donovan-ebook/dp/B01DIF79W0/ref=sr_1_1?keywords=after+the+scrum&qid=1574447698&sr=8-1
разговор про скрам, эджайл, канбан 1. ни слова что такое спринт 2. ни слова что такое беклог 3. ни слова что такое сторипоинт 4. ни слова что такое покерное планирование и так далее вообще удивляет что столько разговаривали но так и не дали определения, не объяснили, что такое канбан. сказали только, что канбан это не доски, канбан это не то, это не се, так что это такое то?
И чё? Мне после этого коммента бежать новый видос снимать? Смысл от него? Если ты ленишься почитать про тему, и думаешь, что тебе ее за час вложат в голову - ты ошибаешься. Сделай лучше, скинь ссылку - я тебе скажу спасибо. Не можешь сделать лучше - не ной.
АйТиБорода я знаю что это, работал по скраму пару лет. я просто написал, почему мне не понравилось видео. что делать с реакцией подписчиков я не знаю, реши сам
После выпуска осталось больше вопросов чем ответов. Леша крутой, но как-то все бесструктурно было рассказано, не хватает конкретики, по пунктам и т.д в целом понял что это не agile, и просто метод или набор методов, надстройка для улучшения скрама, но хотелось бы меньше умных слов, а больше ясности.
Lex, в каком то выпуске смотрел, что там ребята сделали какой то тренажёр/сервис по слепой печате(там что то связанос "type"), теперь не могу вспомнить где это было. Не подскажешь что за сервис?)
Таймлайн для любимых подписчиков:
01:34 - Программирование и незаконченная аспирантура
05:49 - Приход в менеджмент через компьютерное зрение и установку камер
09:36 - Высшая Школа Экономики и MBA
10:37 - РЕКЛАМА
13:06 - Статьи на хабре и первые выступления
14:16 - Про ломку при уходе из программирования
16:13 - Менеджмент не благодарная наука
17:51 - Agile и альтернативы
24:12 - Канбан не про доски!
26:11 - мИФ ПРО ТАЙОНУ И КОНВЕЕР И БЕРЕЖЛИВОЕ ПРОИЗВОДСТВО
30:24 - О бережливом производстве
33:15 - Скрам или канбан
34:23 - Ради чего это нужно?
36:46 - "когда это будет сделано?"
38:38 - Статистические методы оценки
40:21 - Как проводить изменения
42:36 - Можно ли использовать канбан вместо скрама
48:52 - А чё разработчикам от этого канбана
53:33 - Скрам 2.0, скрамно, скрамбан
56:39 - Почему канбан НЕ МЕТОДОЛОГИЯ
01:00:13 - Как разработчику понять что на проекте канбан
01:07:25 - Что уйдет из скрама, если появится в проекте канбан
01:09:45 - Не берите канбан со старта проекта!
01:10:49 - Книги
01:12:45 - БЛИЦ
01:24:26 - КОНКУРС
АйТиБорода сможешь найти системного инженера, девопса, архитектора?
Изучи канал. Как минимум девопс уже был
akolchanov83 я здаров доддддд
Кратко о видео: кто понял тот понял, кто не понял, тот не понял
P.S Действительно согласен с комментариями что ни логических примеров, ни что такое agile, ни scrum, ни kanban не было сказано для обычных людей.
Спасибо за видео, ничего не понял.
Ничего нового. Пожалуйста 😎
Задавайте вопросы, постараюсь ответить
@@pimenaus Что использовать для маленьких команд(до 5 человек)?
@@miraclechina1301 а что делаете?
@@pimenaus , маленькая команда мобильных разработчиков
Может и вправду тяжело просто и понятно рассказать о Канбан, но обычно чем человек лучше разбирается в теме, тем проще и понятнее доносит информацию... Чувство, как будто в тебя воды влили нехило так.
Идёт середина видоса и я до сих пор ничего не понимаю... что такое канбан я хз.. типа все что улучшает - это и есть канбан. Такое чувство, что меня заставляют нанять коуча по канбану))
Ха-ха😂
А что хотелось бы понять? Может стоит разобрать на вашем примере?
Ответь себе (только честно), а знаешь ли ты, что такое ПРОЕКТ, сможешь ли дать одно из классических определений, сможешь ли объяснить, чем проектная деятельность отличается от операционной (функциональной)?
То-то и оно. Это русский мир, батенька :). Это генотип. Тупиковый проект Творца.
@@V.Zakomirnyi жестко ты прошелся. не надо было в космос лететь)
@@V.Zakomirnyiебать ты шиз, это вас так на незалежной промывают, что вам везде русский стр мерещится?
"Вы можете использовать канбан, чтобы улучшить ваш Скрам." "Использовать Канбан, не вместо Скрама, поверх!", "Канбан - способ, улучшить этот процесс", "Термина "Мы работаем по Канбан" - нет, как и термина "Мы внедрили канбан"".
"Контекст, в котором Скрам - перестал подходить, ты можешь использовать Канбан либо начали использовать по ошибке Скрам, где он не подходит - нужно использовать Канбан"
:)
Короткий точный пересказ всего интервью 👍
посмотрел видео про Скрам - все понял, плюс немного почитал стало многое ясно. Тут же...подумал, что я не догоняю, полез в комменты...фух, оказалось все со мной впорядке) спасибо комментам.
первое интервью которое я посмотрел и нихера не понял, причем у нас много таких разработчиков, кто нихера не понял)
А что вы хотели бы понять?
С какими вопросами/целями смотрели этот ролик?
А помоему всё понятно объяснил: Канбан - это не то что ты думал, Канбан - это то о чём ты думал не правильно :)))
аналогично ))
На habr очень хорошо написано про scrum vs kanban) Scrum- гибкий, kanban- ещё более гибкий. Scrum- для этапов создания продукта (долгий, трудоёмкий процесс, поэтому и задачи решаются довольно долго) kanban- вы уже зарелизили продукт, получаете фидбэки и фиксить и апдейтить надо буквально ежеминутно, что как раз и позволяет делать kanban) Ну как-то так это представляется лично мне)
я из вашего камента больше понял чем из всего ролика))
Хорошо сформулировано
Ну не зря переводчик, не зря🙈😁😁
Также для себя понял. Типа если в компании говорят, что работают по канбан, значит продукт хотя бы в mvp уже есть и его апгрейдят и баги убирают
Ну либо люди как и многие не понимают разницу со скрам и продукта готового нет, но канбан приятней уху)
@@denispenshin4746что говорят в компании вообще редко имеет отношение к тому, что реально делают. После ряда собеседований и компаний сделал вывод, что по скраму/канбану работают все, просто потому, что без этого в их понимании работать невозможно. Но у каждого этот скрам не похож на соседский, но именно его они считают каноничным. Самый же каноничный скрам я видел в компании, которая его не использовала. Там не было модных досок, зато было всё остальное. Такой скорости выпуска фичей и выхода на mvp я больше нигде не видел. И уходили с работы по расписанию, за исключением совсем уж форс мажоров, но это было пару раз в год всего
Юмор - это инструмент с помощью которого мы пытаемся справиться с реальностью. Присказка "Лучше дочь проститутка - чем сын скрам мастер" лихо резюмирует засилие IT рынка безусыми agile консультантами.
Я с Алекссем Пименовым не работал, про работу его не слышал. Но, с моей точки зрения, объяснено всё очень доходчиво. Мне понравилось. Было полезно. Спасибо!
Спасибо за гостя - очень правильный мужик. Думал, перевелись в РФ грамотные, образованные, эрудированные люди, но нет - есть еще полноценные Айтишники! Их слишком мало для большой страны, и потому она обречена... Но все равно приятно, что они есть.
В 2000-м году, 20 лет занимаясь исключительно проектной деятельностью (начиная с разработки АСУ Госбанка СССР (!)), я вдруг узнал о существовании отдельной предметной области "Управление проектами", со своими стандартами и методологиями/методиками. Причем, различные "западные" подходы к разработке больших софтверных ИС я использовал с первых лет трудовой деятельности, когда они даже не переводились и не издавались у нас (напр., Метод нисходящего проектирования с использованием HIPO-диаграмм, CASE-технология). Надо признать, что советская промышленная разведка пусть с опозданием, но поставляла в закрытые госучреждения кое-какие технические и технологические достижения Запада. Поэтому у нас всегда раньше, чем даже в Академии наук, появлялись новые трансляторы, СУБД и т.п.
Тогда же в 2000 г. я прочитал в интернете, что специальная комиссия при правительстве КНР обнародовала итоги своих исследований: народное хозяйство Китая испытывает дефицит в 20 000 профессиональных менеджеров проектов. Правительство Китая приняло срочную государственную программу подготовки проджект- менеджеров и их сертификации на степень PMP (Project Manager Profassional) по программе Project Management Institute (штаб-квартира в США, штат Пенсильвания). У меня нет сомнений, что эта программа была выполнена :). Результаты - на лицо.
"Чтобы мыслить нестандартно, стандарты надо знать". Если бОльшую часть проф.деятельности вы занимаетесь проектной деятельностью (в любой роли-ипостаси), начните с прочтения стандарта де факто для УП - PMBoK от PMI (не ICB от IPMA). Тогда и в методологиях/методах/методиках начнете ориентироваться осмысленно. И многие другие интересные вещи могут открыться для вас, совершенно неожиданно (как для меня когда-то).
P.S.
Если честно, я узнал о профессиональном УП (о PMI и PMBoK) в ходе рабочей командировки в Дойчебанк. Три года мы безуспешно пытались реализовать проект создания ИС Национального Банка Украины на базе ERP-системы SAP R/3. И когда уже нависла угроза дискредитации коллектива и системы SAP R/3 (а че? у нас же это запросто), решили послать за опытом к немецким коллегам. Меня сделали руководителем делегации. Вернулся другим человеком. Оказалось, наши ребята и систему знали в сто раз лучше, и бизнес-процессы знали отлично (делали же реинжиниринг BPR и затем кастомизировали систему). А собака была зарыта в другом месте... Главная проблема - неправильная организация проекта и игнорирование требований методологии SAP ASAP в части вовлечения в проект ключевых сотрудников заказчика, начиная со спонсора проекта, владельцев бизнес-процессов, руководителей функциональных групп, ключевых пользователей, их обязательное поэтапное обучение на курсах вендора и т.д., с возложением на них ответственности и одновременным внедрением специальной системы мотивации, и т.д., и т.п.
Я стал бороться за проект (не будучи его руководителем). В итоге меня назначили руководителем проекта (флаг вам в руки), и через 6 месяцев мы успешно перевели пилотный филиал банка на работу в новой системе. А дальше был роллаут.
Нормально в РФ айтишников - вон сколько оказывается уехало))
Осталось все равно дофига
Нормально у нас было с айтищниками, ты просто ватный шовинист
Канбан - это инструмент, представляющий из себя упорядоченный список заданий. Он позволяет регулировать более быстрое выполнение проекта. Любой план представляет из себя гипотезы: 1) О том что за данный период времени должны быть сделаны конкретные работы; 2) О том что, конкретная работа займет конкретное время.
В реальной жизни, как в материальном производстве, так и в ИТ-сфере конкретная работа может быть выполнена быстрее или медленнее, чем планировалось. Также может потребоваться отложить одно задание, чтобы приступить к другому.
Канбан помогает внепланово делать планируемые задания и наоборот планово делать то, что было на данный момент не запланировано. Гибкое производство!
Разумеется, чтобы Канбан работал лучше есть и другие инструменты, например по подготовке специалистов, позволяющие меньшим числом, не перенапрягаясь делать больше работ ;-)
Хм. Странно, что из видео вы упустили и другие моменты о Канбан-Методе
1. Социальные аспекты внедрения изменений
2. Смысл надо ли вообще применять канбан-метод, может и так всех устраивает?
3. Канбан это Метод.
4. Пробобалистическая оценка это небольшая часть канбан-метода
5. Упорядочивание заданий - слишком по разному можно понять. Может быть вы имели в виду управление потоком работ?
@@ThePavelPower Вероятно я многое упустил из того, что сказал Алексей или того, что он хотел сказать и как это выразил. Сила Lean в том, что объединяя субъективные мнения разных специалистов можно получить более объективную картину ситуации. Затем можно коллективно обработать информацию и коллективно принять подходящее для ситуации решение. В разных сферах Канбан может выглядеть и называться по разному - в том числе "чек-лист". Важно не только то, что в нем написано, а еще и то, что он является поводом для коллективных взаимодействий.
@@БорисБорисовичКондрабаев-Прозо не хотел бы вас расстраивать, но Lean - это скорее про производство, или например про выстраивание pipeline в DevOps.
Но не про тот вид деятельности, где рабочим элементом является накопление знаний - непосредственно интеллектуальный труд с высокой вариабельностью и валатильностью.
Само понятие канбан - это сигнал к вытягиванию.
А Канбан-Метод - это метод благодаря которому можно строить Канбан-Системы (или вытягивающие системы).
В рамки Канбан-Метода входят использование и применение как визуализации, работы с социумом, статистики, контекстного анализа, способы внедрения изменений, и другое.
Возможно само по себе слово Канбан - часто путают с доской со стикерами или Lean подходами. Но это не так.
@@ThePavelPower Каждый имеет свое понимание о Lean. Кто то понимает его с точки зрения менеджмента количеств/цен, а кто то с точки зрения менеджмента качеств/ценностей. Про рамки Канбан полностью согласен.
Самый чёткий комментарий
Очень крутое интервью, спасибо за полезные советы! Всегда интересно послушать опыт специалиста, особенно по Kanban.Также используем Kanban (в Strive, онлайн гораздо удобнее, чем все это вести на физических досках) для управления задачами, и такие интервью помогают глубже понимать его возможности и ловушки. Здорово, когда есть возможность применить знания от профи!
Как-то всё размыто, не хватает более четких примеров.
у всяких там коучей работа такая, воду гнать...
согалсен, конкретики не хватает
А конкретика за деньги.... секс для нищих не вариативен
а что конкретно вас интересует?
Что для вас такое "четкий пример"?
После интервью с этим коачем, проверь на месте ли золото, и не угнали ли коня :D А так лайк однозначно!
Ха-ха) всё на месте, Лёша даже не заметил пропажи 😅
Коучем быть зашкварно, это да. Сам себя не люблю называть кучем
@@pimenaus
Да лааадно вам)
Смузи начали пить, дорастём скоро, что и к психоаналитику будет сходить не стремно.
Не понимаю тех, кто "ничего не понял". По моему, всё что нужно было объяснить, было объяснено и заблуждения развенчаны. Но пытаться переубедить свою команду, что канбан это не доска, не буду. Сначала книжки из видео почитаю. Алексей Пименов, если ты это читаешь, спасибо, тебе, ты крут! Борода, спасибо за ещё одно отличное видео!
- Рад приветствовать вас в нашем блокчейн-стартапе!
- По телефону вы не говорили что вы в подвале работаете...
- Это не подвал, это лофт!
- А что за бомжи на входе клейнюха пиздят?
- Это наша скрам-команда! Работаем по аджайлу!
Намешал всего в кучу :)
Что такое канбан - так и осталось в тумане
vk.cc/9y8XCv
Пример с применением Канбан на заводе (материальное производство) понятен, как он работает и в чем плюсы, что касается ИТ сферы, я не до конца поняла в чем преимущество Канбан и как пошагово он внедряется (кроме wip limits), если уже есть, к примеру, настроенный Скрам. Немного не хватает конкретики и структуры. Но в целом, было интересно послушать, спасибо!
Добре.
Подход со снарядом Канбан-Метод начинается с изучением контекста и выяснением точек неудовлетворённости внешней и внутренней.
Разъяснением того кто является клиентом, и что за сервис предоставляет "команда" своим клиентам, что является результатом.
(Кстати не всегда в командах понимают кто клиент и что за сервис предоставляется)
Потом определяются потоки типов работ и классы обслуживания, какие они в реальности существуют, а не какие заведены в вашей JIRA или каком ещё issue traker. На этом этапе сами разработчики часто удивляются тому, что не заметили слона.
Потом изучаются возможности команды, такие как: пропускная способность, реальное время выполнения задач какого типа и класса с какой скоростью, как это соотносится с оценкой (привет Майку Кону который многим голову напудрил своей книгой про Agile оценки).
Потом выясняются эффективность потока (не людей или команды) оценка эффективности потока даёт понимание на сколько можно ускорить получение результата простым способом - сокращение незавершенной работы.
Потом определяется характер вариативности поставок - что даёт хорошо понять имеет ли вообще тратить время на оценки, например.
Потом определяются естественные SLA по времени для команды по типам и классам задач, которые защищают команду от перегруза и ошибок оценки
.... Если дальше интересно, то прочитайте про STATIK.
После анализа понимается решение о плане изменений в зависимости от текущего организационного уровня команды и того уровня к которому нужно команду привести чтобы "команда" соответствовала своему предназначению или даже больше.
*канбан не внедряется, а применяется к тому виду процессов который у вас уже есть, чтобы его улучшить.
Пориимущество канбан заключается в здравом смысле - создавать такой вид процессов который соответствует контексту для получения нужного результата и динамики развития организации.
Говорить, что канбан не имеет никакого отношения к бережливке и аджайлу по меньшей мере не корректно. Это все равно, что говорить, что лев это совсем не тигр. Но лев и тигр, также как и кот это семейство кошачьих и они все объединены общими признаками. А в организации важно уметь находить оптимальную точку разделения и обобщения .
Противопоставлять надо традиционный менеджмент использующий управление по целям и инерционный подход с передовым менеджментом, использующим гибкий подход. То есть парадигма в которой гибкость важнее плана.
И к такому гибкому подходу вы можете смело причислять:
Agile
QRM
Скрам.
Lean (настоящий гибкий Лин, а не его интерпретация в РФ), производственный канбан и вытягиваюшая система.
Канбан метод в проектном управлении.
Теорию ограничений Голдратта.
И даже менеджмент качества (настоящий TQM основанный на статистическом управлении процессами и контрольной карте Шухарта)
Все эти методы, ориентированы на гибкость и скорость. Все они ориентированы на управление динамическими, стохастическими системами и перекликаются с кибернетикой и синергетикой. И стоят особняком к традиционному менеджменту. Показывают, как работать с неопределенностью, вместо того, чтобы бессмысленно молиться на ложно детерминированный план.
Поэтому не имеет смысла говорить о том, как бенгальский тигр отличается от амурского. Лучше объясните людям, как тигр отличается от бегемота. Это гораздо важнее, так как правильно акцентирует внимание ищущего человека.
#конкурс благодаря видео понял, надо оставлять свой Chaos Driven Development только сверху накинуть канбан для привлекательности)
Отличное интервью, видно, что он не зря свой хлеб ест. Все по полочкам и ясно разложил. Спасибо тебе добрый проджект менеджер!
Спасибо!
Много читал и только сейчас начало складываться понимание как это работает и связано. Спасибо.
Kanban звучит как жанр в порно
Ееее😎
А я смотря на постер видео прочел "Все о... КАБАН"
Cum_ban Когда по окончании всех дел тебя банят на ресурсе для того чтобы не переусердствовал
Спасибо за видос. Класная инфа. Гибкая система нужна в процессном управлении для непосед.Усидчивый чувак сможет к любым вещам привыкнуть, творческий нет. Ему рутина затылок чешит и нужно что-то делать лучше, иначе. В любой сфере есть проторенные дорожки. Когда айти полностью объединится с бизнессом(во всех масштабах) соединятся системы бизнес архитектур типа ТОГАФ, аналитик типа процессов типа BPMN, улучшений типа Канбан, проектных техник типа Agile. И будем мы жить в красивом утопическом обществе)))
Чё то я смотрел-смотрел этого дядьку, сколько он всего рассказал, но не понятно нихрена. Хотя я варюсь в теме. Очень много воды, максимально мало практических вопросов, как в итоге работать. Не понравился дядька, а вот канал отличный, спасибо за видосы.
Ничего не понял. Лайкнул на всякий случай. Как будто всё понял и я типа как все.
Доход в 10 тонн зелени конечно удивляет.
Это самый топовый контент для меня! Спасибо большое! Алексей очень здраво и методологично мыслит.
Спасибо)
Спасибо!
Успех того или иного подхода действительно зависит от мышления, ведь далеко не каждый способен к гибкому анализу в рамках контекста. Очень часто деревянные манагеры подскакивают кабанчиком, лишь бы внедрить, не имея глубокого понимания, не желая развиваться и заниматься "калибровкой". Спасибо за интересный выпуск.
Я бы сказал, не каждый может системно думать. Что в Канбан-Методе без этого делать нечего
Качественно! прекрасное видео)
Имхо, ситуация сейчас на рынке (2022) примерно такая:
СКРАМ
- применяется в основном в айти и цифровизующихся телекомах-банках-тп компаниях
- применяется для создания продуктов с нуля и до победы в "комплексном домене" по модели Кеневин (ruclips.net/video/rCLth07UAsA/видео.html)
- выделенной роли "правильного" скрам-мастера, кто за все это безобразие отвечает в 98% российских компаниях - НЕТ. Обычно эту роль выполняет проджект, реже продакт или один из разработчиков (в обоих случаях будет "не очень", потому что не будет достаточных знаний и опыта)
- Скрам все больше становится "просто инструментом" для проджекта/деливири-менеджера, одним из гаечных ключей" в его тулбоксе (также как у прогеров библиотека)
- в 99% случаев внутри спринта используется канбан-доска. т.е. в реальности используются оба подхода, но сильно усеченные (не ставят цели спринта, не работают с WiP и тп)
- в 80-90% случаев по скраму работают в Джире, т.к. там на лету создается "аджайл-проект", состоящий из роадмапа, бэклога разделенного на спринты и канба-доски для активного спринта. Все просто, понятно, легко въехать. Плюс в Джире хорошо сделан раздел с отчетами (капасити, бернапы и тп)
КАНБАН
- в 90% случаев подразумевается ПРОСТО РАБОТА со стикерами задач на доске
- чаще всего - в Трелло, иногда подпроектами в Джире
- WiP-лимиты используют только оооочень прошаренные проджекты/тимы)))
- какую-то аналитику, свимлайны, гистограммы, петли обратной связи наверное кто-то использует, но после очень хорошей консалтерской работы)))
- в общем - Канбан для народа - это трелло-доска со стикерами тасок, 3-5 колонками статусов, ассайненными исполнителями, чек-листами внутри тасок
- через 3-6 месяцев юзания такого подхода - первая колонка с общим бэклогом продукта/проекта становится сборищем тотального отстоя на несколько сотен тасок и НИКТО не понимает "что с этим делать" )))
- кстати, последний трабл в Джире решили весьма красиво - в настройках проекта ставишь галочку и делаешь "бэклог проекта" ОТДЕЛЬНО, не внутри канбан доски, что еще больше приближает реализацию "типа канбан" к "типа скрам", т.к. изобщего бэклога надо отобрать приоритетные таски в бэклог канбан-доски (штоо???) и при этом постараться не запутаться где у тебя што))
ПРО БУДУЩЕЕ
- очевидно, что НЕ большие компании (малый и средний бизнес) будут юзать непрофессиональные попсовые подходы, которые могут на лету и без заморочек решить главную потребность бизнеса - хоть как-то нормализовать и стандартизировать поток тасок от туду в дан. Если кто-то при этом сможет еще что-то делать с командой,ретро, осью, графиками и повышать производительность работы - честь и хвала такому народному гению)
- большие компании все больше отходят от просто-скрам/канбана в сторону сложных, но видимо продуктивных Лессов, Сэйфов, Социо и Холократий. Такие временные и ресурсные подходы недоступны "обычным" компаниям ввиду их затратности (что обычно применимо к любой разнице в ресурсах биг компаниз и остальных)
- примечательно, что например в Яндексе и Сбере почти вернулись к "классике" проджектов и продактов, и для обоих в требованиях скрам-канбан-аджайл подходы просто указываются как требованию к опыту
ЧТО ТАМ
- на рынке западных вакансий (ЕС и ЮК) довольно много вакансий именно отдельных специализаций скрам и канбан лидеров/мастеров/коучей, так что как раз "там" тема до сих пор живет и развивается.
It's always helpful when u got people with full pack of different experience. Thanks!
Нескончаемый поток терминов и жаргонизмов, которыми он умело жонглирует, как любой нахватавшийся теоретик. В итоге ни о чем. Я не знаю в чем ценность этого видео, но я тупо слил время, а хотел разобраться в этих технологиях.
Довольно полезно, спасибо! Мы сами разбирались в этой теме (без мастера) благодаря таск-трекерам. Больше всего понравился аспро agile.
Алексей Пименов просто магнит внимания!
Теперь такой же видос про Scrum надо. А то слово "Scrum", мне кажется, упоминалось чаще чем канбан!
Скрам-хорошая вещь, я книжку прочитал...
Надеюсь, в видео про скрам мы таки узнаем, что такое канбан 😅
Мне вот интересна одна составляющая подобных методов. Иногда предполагается спрогнозировать трудозатраты и затраты времени для решение той или другой задачи. Вопрос ы том, что многие задачи имеют эксперементальный характер. Как прогнозировать затраты времени и ресурсов на их решения? В моём представлении оценить затраты на решение задачи можно только решив её и оценив по факту. Какие методы предусмотрены для подобных случаев?
Например статистика по задачам ввполненным
Story points
@@avmletsplay4450 как тут Story Points поможет?
Если ничего не известно о задаче, то как можно дать прогноз завершения?
Обычно задачу пытаются сначала декомпозировать для того, чтобы понять какие типы работ команде уже знакомы, и на основании уже этих данных давать прогноз. С учётом того, что известно о возможностях самой команды.
Может быть в команде нет какой-то компетенции для выполнения. Тогда оценка не релевантна.
Полтора часа ни о чем, ничего не понятно, можно же как-то структурировать информацию
Спасибо за выпуск 😊
А мне понравилось)
Спасибо, ребят!
Спасибо за контент! Пименов живая легенда нашей современности! Похвалить его - значит не сказать ничего) Чистой воды профессионал. Мечтал бы у него учиться
Чистой воды профессионал - сомнительный комплимент для профессионала 😊 или я не понял сарказма...
При просмотре словил большой инсайт, реально всю дорогу думаю что надо оценить задачки, накидать в спринт и смотреть как всё там шевелится или не шевелится. А надо думать наоборот, релизами и версиями. это у меня к 35 минуте такое. Но вот что за "вытягивание" я что-то к этому моменту так и не понял.
Интересный выпуск получился. В начале не хотел смотреть, т.к. меня больше интересуют интервью с программистами про конкретные языки программирования. А тут и гость интересный оказался, и тема зашла, как ни странно. :))
вообще не понял, что такое канбан. это соус, который ты добавляешь в любой процесс. а если серьезно, то я понял, что вот есть скрам, если не нравится жесткость рамок спринтов , и мало колонок состояний, и нельзя брать больше или меньше задач чем нужно, то используешь канбан, и можешь делать че хочешь. можешь добавлять новые колонки, можешь брать сколько хочешь задач, или только одну, я так и не понял, можешь выходить за рамки спринта, дольше делать, чем один спринт задачи, либо можешь переключиться на абсолютно новые задачи, которые приорити и не в спринте, и задеплоить посреди спринта, например. пока то, что я понял - это то, что канбан - это хаос. ну не в плохом смысле, а просто идея, что можно не следовать жестким практикам скрама, а делать че хочешь, и смотреть на результат, но все равно сохранять какие-то процессы. очень разманно, непонятно это определение)
доктор сказал привести дела в порядок, ведь у меня канбан
Классный гость! 🔥
Полезно. 👍
В рассуждениях есть несколько непонятных моментов.
1. У вас фиксированное количество задач в работе, которые не имеют фиксированного временного окна как двухнедельный спринт. Какой смысл в фиксированном количестве, если вы не работаете над задачами последовательно, ведь вас съедят за переключение контекста в любой команде, это биологическое ограничение?
2. Если идет экономический рост снаружи компаний, то акцент на доставке фич и Kanban здесь лучше подходит, но если кризис - то компания бдит о бюджете, режет косты, увольняет, внедряет метрики для контроля расходов, режет или избавляется от малоиспользуемого функционала. Scrum здесь привлекательнее, менеджер лучше держится за место, пускай накапливая технический долг (качество трудно считать), но зато отчитываясь через метрики, где можно тыкать пальцем на графиках, успокаивая начальство. Какой смысл получив после среза затрат, сократив скрам-мастера и бизнес-аналитика(потому что неясно как мерять их эффективность в деньгах) и получив "у нас свой Scrum", если придется размазывать их обязанности по команде, теряя фокус над задачами, увеличив обратное делегирование и неэффективно используемое время работы экспертов?
За полтора часа из полезного узнал только что есть электричка Истра - Москва.
Сложилось впечатление, что гость тренирует по книжкам, а не по боевому опыту - нет никаких примеров что же там может поломаться в скраме и как это может починить канбан, а на простые вопросы отсылает почитать книгу.
#КОНКУРС Если я правильно уловил мысль, то основная тема в том, чтобы понять что в текущем процессе управления разработкой не так и менять это, что в принципе разумно, хотя не понимаю почему здесь нужно специальное слово "Канбан", я бы назвал это здравым смыслом.
Какие основные отличительные признаки канбана? Скажем занесли представителю заказчика откат чтобы он меньше придирался и добавили лимиты на колонки, таким образом на два вопроса ответили положительно - у нас все, применяется канбан? :) Так и не понял что отличает канбан от какого-нибудь другого способа улучшить качество сервиса и продукта.
-1:07:36 важное условие чтобы Agile работал:
Команда высокомотивированных профессионалов, мерой труда которых является работающий продукт
Если у вас команда новичков, или середнячков, нанятых на небольшую зарплату, ни*уя ничего не будет работать
Вначале поставил лайк. В момент, когда услышал о "статистике" для оценки временных затрат - отозвал. Серьезно? Возможно, если компания не меняет свой состав 3 года и всё это время делает лендинги на вордпрессе с уже готовыми шаблонами, у неё быстро накопятся данные для достоверной статистики. Экспериментов достаточно много и параметры практически не меняются. Но как только параметры хоть чуть "поплывут" по количеству и/или просто своим величинам, что совершено характерно для того, для чего и используется разработка итерациями с быстрой обратной связью (высокая неопределённость) - помашем этой "статистике" рукой. Чужая статистика тоже не особенно полезна. Теория сложных систем нас учит, - а разработка ПО - как раз такая,- что две сложные динамические системы, даже если они кажутся "похожими", при одном и том же внешнем воздействии дальше будут двигаться по разным траекториям своего фазового пространства. Ничего в прогнозировании затрат не придумали и не придумают. Даже будучи украшенными псевдоцифрами они остаются психологическим феноменом. В среднем и долгосрочном горизоните профакивались и всегда будут профакиваться)
Я свою статистику получил уже через 2 недели. В чем сложность? Визуализировали, начали применять, статистику собирайте свою и анализируйте.
Моё мнение что когда-то Agile работал но с ростом технологий и требованиям к разрабам это прямой путь к выгоранию. Не раз видел как производительность команды может упасть до 50% при переходе на scrum и это при очень хорошем скрум мастере. Agile работает только в очень идеальных условьях, надо просто взять лучшее из него и перейти на hybrid kanban. Давай что нибудь про выгорание, это достаточно неизвестная тема и многие узнают об этом когда уже поздно.
Классное интервью, было интересно слушать, хотя иногда терялась концентрация и приходилось перематывать. Но надо отметить, картина канбана в сознании прояснилась и многое встало на свои места) Спасибо обоим Алексеям и комментаторам, которые также делятся своими знаниями и опытом в комментариях, вас очень интересно читать!
Спасибо, Алексеи (оба).
Данное видео появилось в идеальное время для меня. Я как раз начала замечать несовершенство скрамa на моих работах и, при поиске различной информации по улучшению, наткнулась на Канбан. Это действительно не так просто его понять и правильно применять, поскольку написано мало, весьма скомкано и поверхностно. Сейчас сяду читать книжки, что вы посоветовали. Кстати, не соглашусь с предыдущими комментариями, смею предположить, что для не интересующихся оптимизацией рабочих процессов людей, понимание данных процессов будет затруднительно.
На здоровье!
Очень размыто с долгим уходом в ненужные детали, несколько раз пересматривал кусками т.к. терялась линия повествования. Сама база что с чем сравнивается смешанно подается на протяжении полутора часов. Дядя энергичный оратор, но он больше запутал чем объяснил, лучше забуду это и посмотрю в другом более структурированном месте, а то на собесе как-то стремно на такое опираться. Лайк за скиллы забазаривания.
Алексей отлично все рассказал, как всегда 👍
Крутой дядька и очень интересное интервью! Очень жду байки)
Спасибо за краткий но полезный курс
О, читаю комменты и выдохнул - не один я не вдуплил тему:) Я старался, правда
Метод в науке, в общем - методика по использованию методик; Метод в программировании - функция класса ))))
Спасибо, Алексей. Очень крутой выпуск!
потрясающе !!!
Доски называют "канбан", потому что с японского [かんばん/Kanban] - переводится, как "доска")) потому мне тоже поломало мозг выражение "доски - это не канбан"))
Оч интересное видео, спасибо!
Спасибо за цитаты. Записал две:
1-ая) на песню Аллы Борисовны "про фарш и котлеты";
2-ая) от известного боксера "про раствор и осадок".
#конкурс
Дисклеймер: любые совпадения являются случайными, автор - буйный. :)
На лужайке мирно щиплют траву коровки. На холме гордо высится бык Герман и его юный отпрыск из финала СССР.
(Сын) - Вон, смотри, смотри, какая красивая! давай, а?
(Сын) - А может вон ту... Ах какая!
(Сын) - Или вот эту? Тоже хороша!!
(Герман) - Не торопись. Сейчас мы медленно спустимся с горы и всех от`Kanban`им.
P.S. "Упарывал" текст как мог, сори если что.
Познавательный выпуск, спасибо за труд! На мой вкус все же как-то многовато теории и мало примеров было в выпуске :) Хотелось бы больше конкретики, например для таких-то и таких-то проектов лучше использовать Канбан потому что... для таких - Скрам и тд
мысль как раз в том, что эти понятия друг друга не заменяют
Принято)
Скрам применяется в контексте организации работ для создания комплексных продуктов небольшой командой.
В других условиях он не работает.
Канбан-Метод применяют для улучшения тех процессов которые у вас есть, чтобы добиться улучшений и выхода на новый уровень.
Так если, например,у вас перестал работать Скрам, то можно применить Канбан-Метод и улучшить Скрам, или найти другой способ работы
Ловко описали людей, которые ценят свое время и не работают больше, чем положено ТК, как "немотивированных"
Интересно, а если человек имеет базовый опыт с процессом создания продукта в IT, но непосредственно не разбирается в технологиях программирования, тестирования, развертывания продукта и прочего. При этом, закончив курсы по методологиям SCRUM или Kanban, такого возьмут со стороны управлять процессом разработки? Т.е. опыта нет, но есть хорошая теоретическая база.
Опыта у меня с этими методами и нет представления. Я не разработчик. Но интересна тема. Я немного баловался для личных дел Trello. И там грубо говоря сделал 3 секции: список дел, в процессе, готово. Читал что надо ограничивать себя единовременно выполнением не более 3х задач.
Немного не понял(хотя пока пересматривал ролик и читал литературу, начал понимать) про сигнал к работе. 29:00. Т.е. есть лимит на взятие 4 задач(Work(В) In(И) Progress(П) - лимит)), три уже взял и как бы есть один пустой слот для еще одной задачи. Сигналом для работы является один пустой слот из четырех в моем вип-лимите? Вроде верно. Т.е. не наличие карточки "сделай что-то" в секции "список задач", а место в моем вип-лимите. Могу взять еще задачу - вытягиваю карточку(канбан-метод), работа кипит и сделан проект будет в срок. Канбан это один из множества методов в рамках концепции бережливого производства.
Если кратко agile-методология(совокупность методов) - это общее направление проворной разработки (или другого производства), а kanban(«подход баланса») и scrum(«подход структуры».)- уже ее методы(или скорее всего система методов - методика). Scrum и kanban - варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно. Главное сделали. Хехехе.
Я прям чувствую как мышление меняется. Пишите свои мысли, поправляйте меня в ответ на этот комментарий. Я сейчас поставил на паузу и начал изучать. Я в шоке и в восторге.
Лайк если заметил склейку после 28:20
Останется найти компанию, где эти методики внедрены или соблюдаются.
До видео - карточки на доске
После - карточки на до воске со свободным местом.
А и сходить поспать .
Очень интересно, спасибо!
Круто , интересно.
Хотел глянуть для общего развития. Не развился. Спасибо.
На тему изи мани
#конкурс
Труд из обезъяны сделал человека. И надо ж было такому случиться, что именно он мой начальник!
Ну, и я согласен с философией примения канбана, изложенноой Алексеем: тихой сапой добивайся нужных тебе результатов.
работаем в Сбере по аджайл, не сказал бы что эффективно используются ресурсы (разработчики, тестировщики, аналитики), но прозрачности больше, конечно, в плане кто чем занимается. Возможно канбан бы помог, но про канбан коучей у нас пока не слышал.
Viktor T не в сбере дело, а в людях балластах
У вас есть Рома Петров, он вроде канбан в Сбере двигает
С начала и до самого конца не отпускало ощущение, что этот человек чего-то где-то нахватался, начитался, с практикой не сопоставил, но посчитал, что теперь он умнее всех и может учить. Типичный инфоциган с подвешенной тараторилкой.
Очень скромный человек. :)))) Этим все и сказано.
Блин, пожалуйста, сними видос про то как создавать резюме программисту-джуну в разных сферах (веб, ПО, гейм...) было бы очень интересно посмотреть.
У джунов все резюме одинаковые
Можно написать " Готов работать за кофе и печеньки" с руками оторвут... но это не точно
@@itbeard Тогда я слишком далеко зашел... пора идти работать)
Это самое полезное видео по данной теме во всем просторе ютюба! Спасибо большое!
На здоровье!😊
Заклинаю тебя, я лучший коуч по канбану! По аджайлу и по доггистайлу. Ты будешь мне платить, работодатель! Потому что я черный пояс по скраму, а твой канбан я улучшал. Понятно...
О наконец-то
#конкурс )) когда подаешься на вакансию ПМ (а ты вел проекты да только не в айти), многие компании пишут "опыт использования Agile, Scrum" , прошу обратить внимание на запятую:)) или "знание методологий Эджайл (скрам , канбан) " :))), и шлют тебе отказ, потому что у тебя типа нет опыта ведения ИТ проектов, но ведь у компании и нет понимания, что Эджайл - это не метод, а философия)), но объяснить это ребятам уже и не сможешь да и есть ли смысл?)) Вопрос от Чернышевского: так что делать?)
А зачем вам такая компания то?
@@pimenaus разумеется не зачем:))) Кстати, спасибо за лекцию. )) Тоже кое-что отложила себе в голове. Разложила кое-что по полочкам.
В вакансиях часто любят перечислить через запятую и обобщить те вещи, которые не стоят на одном уровне (не только про Agile). И ты думаешь hrы ли плохо передали инфу (что ещё пол беды) или сами менеджеры не понимают, что делают
ку! ты победил в конкурсе :) Напиши мне в телеге @iamitbeard или в инсте @itbeard, расскажу что делать дальше ;)
@@itbeardКу! хорошо :))
Интересно прочесть доклад о внедрении метода в операционный бизнес
#конкурс
Скинул ссылку проджект менеджеру, что топил за скрам (потом за канбан) с привязкой во времени на фразе "Работает с высокомотивированными сотрудниками...". Лишен премии. Высокомотивировали. 😁
Долучайтесь в телеграм канал: t.me/agile_space
В основному говоримо про Agile, Scrum, Soft Skills та Kanban.
Тут ми публікуємо практичні кейси, поради, добірки, вакансії, події, усі новинки. Готові також поширити ваші напрацювання.
Якщо Вам цікава така тема - welcome 🔥
Вот уж про что не ожидал тут услышать, так это про Петруччи и Гилберта :)
Лекс, планируешь интервью с С++ разработчиком?
Как будто ток-шоу: вроде и тема есть, и интересная, и рассказчик супер, но - вода, вода, вода... Реально, понятия Agile, scrum, kanban не раскрыто. Интервью ради интервью. Расстроен
Четкий выпуск! Намедни как раз смотрел запись с конференции 13th Agile Days в мае этого года. И тут БАЦ! Алексей у тебя на вью)
Хорошая подача, отличные знания. Давно не находил ничего толкового по Kanban в рунете.
Гуд)
Он мне напомнил сэйлзтренеров "Я научу ваших продажников продавать. Надо создать правильный отдел продаж из правильных продажников..." Вроде бы интересно, но так и не объяснил, что канбан добавляет к скраму. Мастерски уклоняется от конкретного ответа
А можно тайминг где я уклонился, я может тогда хоть в комментарии конкретный ответ дам. Если говорить в контексте "канбан добавляет к скраму", то в первую очередь надо понять а что у вас не так? чем недоволен заказчик или команда?
@@pimenaus Согласен с предыдущим оратором. Вы говорили для тех, кто всё это и без Вас понимает. Кто понимал - согласился с Вами, кто не понимал - остался там же, где был. Весь Ваш текст построен по принципу "хорошо делай - хорошо будет". А на вопрос "что такое хорошо?" вы отвечаете, что ответ уникален для каждой ситуации. Всё верно, но абсолютно бесполезно с точки зрения предоставления информации слушателю. Это и называется - вода.
@@Шамиль-ю3н отличный ответ! Люблю такую дискуссию. вот смотрите, вы же сами понимаете, что не бывает универсальных решений (а их часто водогоны и продают: измени свое мышление, измени еще чего нибудь). Если нужен конкретный совет "что делать", то надо хорошо разобраться с ситуацией. Мы же не будем диарею лечить слабительным. Вот Канбан Метод в первую очередь - это инструмент анализа контекста, понимания того, что у вас творится, а потом уже подсказка того что с этим делать. Я просто не понимаю, как я мог отвечать по другому. Если вы обратитесь ко мне с проблемой, то я буду изучать ситуацию и даже прояснять - это у вас действительно проблема и может это симптом чего-то другого.
@@pimenaus вот опять (снова?) пять строчек "блаблабла" ... может, стоило просто рассказать несколько реальных случаев применения? уверен, так более доходчиво получилось бы.
@@silverbullet653 ruclips.net/video/GMxYc8olYhY/видео.html сойдет за пример? мои клиенты и мои студенты
Можно ссылку на курс? Спасибо
SkrumBun это вам не KunRum. Тюнинг продукту, а не продукт тюнингу) Большой лайк!
Спасибо)
Ахаха. Можно еще написать Scrum Buns, и тогда для практиков есть уже книга www.amazon.com/After-Scrum-Dahlia-Donovan-ebook/dp/B01DIF79W0/ref=sr_1_1?keywords=after+the+scrum&qid=1574447698&sr=8-1
разговор про скрам, эджайл, канбан
1. ни слова что такое спринт
2. ни слова что такое беклог
3. ни слова что такое сторипоинт
4. ни слова что такое покерное планирование и так далее
вообще удивляет что столько разговаривали но так и не дали определения, не объяснили, что такое канбан. сказали только, что канбан это не доски, канбан это не то, это не се, так что это такое то?
И чё? Мне после этого коммента бежать новый видос снимать? Смысл от него? Если ты ленишься почитать про тему, и думаешь, что тебе ее за час вложат в голову - ты ошибаешься. Сделай лучше, скинь ссылку - я тебе скажу спасибо. Не можешь сделать лучше - не ной.
АйТиБорода я знаю что это, работал по скраму пару лет. я просто написал, почему мне не понравилось видео. что делать с реакцией подписчиков я не знаю, реши сам
После выпуска осталось больше вопросов чем ответов. Леша крутой, но как-то все бесструктурно было рассказано, не хватает конкретики, по пунктам и т.д в целом понял что это не agile, и просто метод или набор методов, надстройка для улучшения скрама, но хотелось бы меньше умных слов, а больше ясности.
Лекс, получается по логике теперь стоит ожидать отдельное интервью о Скраме? :)
начинается скрамата
Нее, не стоит)
наконец-то дошло, кого мне напоминает сегодняшний гость: Евгения Леонова (советский актер) :D
Ага))) тоже ловил себя на мысли)
Моргалы выколю!😅😅
Даёшь интервью с Rust разработчиком!
Будем разбираться
Стоит ли щяс учить C# и каково его будущие ?
Стоит
Но сверху надо накатить канбан😁
Lex, в каком то выпуске смотрел, что там ребята сделали какой то тренажёр/сервис по слепой печате(там что то связанос "type"), теперь не могу вспомнить где это было. Не подскажешь что за сервис?)
Хм... Solo?
@@itbeard solotype?
Кто то говорил что этот проект выстрелил и он запущен во многих странах. Мне кажется что это не соло
Тут недавно только хелловорлд первый написал, а тут Kanban какой то. Поумнею потом посмотрю :D Но лукаса прожал!
Хоть так)
Аналогично