Методологии SCRUM, Agile, Kanban и т.д. с точки зрения руководителя и разработчика
Добрый день! Хотелось бы в следующем видео услышать ваше мнение про всякие методологии разработки, типа SCRUM, Agile и т.д. Какую методологию предпочли бы вы как руководитель и как разработчик? Действительно ли они повышают продуктивность команды? Стоит ли изучать этот вопрос разработчику?
Какими критериями руководствуются при выборе методологии разработки. В частности Кабан и Agile. Сюда же преимущества и недостатки данных методологий.
От Скрам мастера слышал следующее, что Agile в чистом виде не используется не в одном проекте. Согласны ли вы с этим утверждением и если да, то почему так выходит?
Курсы JAVA - bit.ly/2o4pkep
Курсы C#/.NET - bit.ly/2VXVaGf
Курсы ANDROID С НУЛЯ - bit.ly/33LtxTt
Курсы Automation QA (Java) - bit.ly/32BiU5A
Курсы FRONT-END - bit.ly/2qpvN4e
Курсы UI/UX дизайна - bit.ly/2p26LI5
Курсы WordPress Developer - bit.ly/31yDHW7
Сайт Foxminded: bit.ly/2P5LRm5
Foxminded в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
Мой Telegram: t.me/nemchinskiyOnBusiness
Мой блог: www.nemchinsky.me
Есть еще методологии "всего по чуть чуть" и "мы не знаем как мы работаем, но всем говорим что у нас все по скраму" =)))))))))
Вввайаваавапийпввпийавппвпваупйвамйавпввпввмппвапапввппв
❤️:-)
От одного из лекторов слышал, что большинство проектов работает по методологии HDD - hope driven development. Всё делается как придется, но с надеждой, что получится хорошо.
И посмеялся и sad but true
Ну или spdd
🤣 so true
Бюрократия и иерархия - это всегда страшно, и всё это есть в любой организации, в любом бизнесе. Это нужно упорядочить - а это создаст новые процедуры, иерархии и бюрократию
Перфекцехуизм
Пришёл с работы, думал 5 минут ютуб проверить, попал на ваш канал и залип уже на 5 часов... Спасибо большое за ваш труд, Сергей, очень хорошие видео! :)
Как всегда, просто, ясно, доходчиво о сложных и многогранных вещах. Сергей, спасибо.
Спасибо сергей очень интересно и понятно для новичка!
Як завжди - на висоті ;) Дякую !
Спасибо. Доступно, без лишнего пафоса
Хорошая тема поднята. Нужно продолжение! )
Задавайте вопросы
Спасибо. Очень внятно. Подписался.
О, шикарно!!! Это было интересно послушать!
спасибо!
Sergey Nemchinskiy Спасибо Вам
Достаточно понятное объяснение методологий, спасибо. Очень интересно будет посмотреть ролик с вашим мнение по поводу плюсов и минусов этих методологий, почему от каких-то то уходят и другим приходят.
они не взаимоисключающие :)
Да, в кратце хорошо прошёлся по основным моментам 👍
Дякую за цікаву і достатньо повну відповідь.
Спасибо за видео
Как менеджер не в IT (пока ;) добавлю: для управления необходимо отталкиваться от задач и предмета вопроса, а не от названия методологии и её подбора. Например, для простых, одноступенчатых задач - определил, довёл исполнителю / команде, проверил. Для комплексных проектов - постоянный контроль, сверка, корректировка, запуск.
как начался разговор на менеджерскую тему - сразу как-то мутно стало... :) а за ролик спасибо
шикарно, впервые слышу эти термины и я увидел общую кратину.
Знаю и работаем только по технологии ASAP - as soon as possible :) Понимаю, что это краткий экскурс в методики, но мне это нужно было, чтобы хотя бы общее представление иметь. В книгах довольно запутано пишется, имхо :)) Спасибо за видео!
кружечка зачетная и спасибо за видео
Отличное видео
Спасибо!
3.58 Ура, начало!
Сергей, здравствуйте! А что у Вас за клава на столе? Сейчас хороших белых, полноформатных клав почти не найдешь.
Сергей, спасибо за видео! Неплохо описан взгляд менеджера и инженера на все эти подходы. Не хочу показаться пуристом и не буду придираться к мелочам (рассказать точно до мелочей - это был бы серьезный вызов), хочу просто немного по верхам вас поправить. Смотрите, то что вы описывали касающееся выпуска MVP - это подход Lean Startup, у которого есть конкретный автор (Если не ошибаюсь Эрик Риз) и он не имеет никакого отношения к Lean Manufacturing придуманному на Тойоте. Так же как и Канбан Метод, который сейчас используют в IT тоже не имеет никакого отношения к Lean Manufacturing и используемому там Канбану. Здесь вопрос скорее в том, что как раз Lean Manufacturing не смогли применить к IT-разработке из за того, что есть очень сильная специфика. Lean Manufacturing сделан для материального мира, производства материальной продукции и производственных цепочек, которые требуют достаточно мало умственной работы (когнитивных навыков). Современный же Канбан Метод, который был придуман в конце 2000-х как раз в нашем любимом IT (зачатки этого подхода появились в Microsoft) и он придуман именно для процессов требующих большого количества когнитивной работы и выпуска нематериальных продуктов. Помимо того, что современный Канбан не имеет никакого отношения к Lean (а во многих вещах действует ровно наоборот) он не имеет никакого отношения к Agile, это подход который был придуман как альтернатива тем подходам, которые мы привыкли называть гибкими, чтобы избегать тех проблем, которые они вызывали при внедрении. Если будет интересно, то готов на эту тему пообщаться, можете меня в FB найти или в телеге, буду рад конструктивному диалогу
спасибо за уточнение
Все равно имеют и леан стартап к леану, и канбан связан с мануфактуринг. И мса от майкрософта к "выбирайте что то, что было ранее". Да они другие, и концепты переписаны, но они based on. Первое вообще где алжайл евангелисты ведь все это не методологии а аппроач. Водопада нет к целом кстати, во первых каскад, во второых автор описания каскада описал итерацию каскада🤔. Но как бы не корректирую, просто слова для определения приняты немного другие. В общем, та же каша что и везде. Что в аджайл аппрочах, что в каскадных итерациях.
Здравствуйте, вы упомянули работу программистов в паре, можете по-подробнее рассказать про это? Какие технологии для этого используются, как это осуществляется в современных компаниях (EE и мобильной разработки) и как это делать качественно и быстро?
Мы как раз с напарником работаем по большей части вдвоём, хотелось бы узнать все тонкости и лайфхаки
Аджайл и скрам это красивая обёртка для того, чтоб выжимать из разраба все соки
@Volodymyr Volodymyr А какая разница кем работать, если разговор идет о "методике" работы?
@Volodymyr Volodymyr здесь:)
Чтобы выжимать сроки достаточно требовать отчет каждый день, а agile нужен чтобы подстраиваться под изменения в тз с минимальными издержками
А программист не пролетарий? Такая же наемная персона, будь ты на галерах или во фрилансе, но конечно же в красивой упаковке ;)
Таки, читал, правда, давно то было.. П.с. не вижу проблемы в том что с течением времени и в угоду современным тенденциям, то или иное слово - живет, меняется, и так дальше. Не удивился если бы сегодняшние программисты, штурмовали Зимний
Круть!
Как Вы правы.!.... Не существует "волшебной таблетки" на все случаи жизни.... Простота, новизна, чётко поставленные цели, большое желание работать, тесты + ЗДРАВЫЙ СМЫСЛ, который подсказывает как быстрее достичь нужный результат в конкретных ситуациях.
Здравствуйте! Ваше мнение - на сегодняшний день agile-коучи востребованы? И где этому учат?
Вітаю, чудово, здоров'я, благословінь, миру.
Отличное видео. Подскажите, если владелец проекта начинает его с нанятым разработчиком вдвоём. За всю it-часть отвечает разраб (в том числе работа с серверами, бэкапами, безопасность сайта). Каким образом владельцу сохранять полный контроль над проектом? Чтобы в случае желания продажи бизнеса владелец был уверенным, что он действительно владеет всем необходимым для этого. И не придётся ни о чем потом договариваться с нанятым разработчиком и зависеть от него в этом вопросе.
выжимка видоса: "скрам - показатель наращивания функционала", - самое главное
Было бы интересно узнать, особенно новичкам правильную последовательность изучения технологий для Java разработчика. Спасибо за отличные видео)
Java, Hibernate/Spring.
Советую записаться к ним в школу. Сэкономите кучу времени. Это не только к Foxminded относится. Языки, игра на гитаре, спорт. Хотите что-то быстро выучить/освоить - ищите ментора.
Java core, Servlet/JSP, и далее Hibernate, Spring
У меня есть статья про правильный порядок изучения dou.ua/lenta/articles/java-enterprise-guide/
@@the_leonik кому нахер нужен твой сервлет jsp?
Часто попадались на глаза названия этих методологий. Надеялся понять что это такое, но так и ничего не понял с видео.
Вот хорошо сказал: у одних работает, у других нет. Независимо от метода все решает компетентность и работоспособность команды и руководителей.
Вот именно!!!
Сходил на конференцию по Kanban,у. У нас это хайп сейчас) Но все понимают, что это не истина. Актуальны все методы, какой подойдёт вам, зависит от ваших кейсов и контекста. Сергей, как всегда спасибо за контент
Вам спасибо
Получается ведь, что жёсткое формальное следование какой-либо из методологий Agile будет противоречить самому манифесту Agile, который ставит во главу гибкость, результат и здравый смысл.
Здравствуйте, не могли бы пожалуйста осветить тему программирования логических контроллеров
нет. вообще ничего об этом не знаю
Що означає працювати в парі? Як це організовується?
Мне не понятно, если я как просто manual QA analyst, то какая от меня требуется agile методология, поясню, на собеседованиях меня спрашивают какие эджаил методологии вы используете🙈 логично что никакие, я просто QA но может я что то не так понимаю
Какие книги можете посоветовать по scrum и kanban?
Kanban in Action
если ты не руководитель то тебе эти методологии нахрен не нужны
@@user-cx8kh4sb2i руководителями не рождаются
Ничего не понятно, но очень интересно
Впервые слышу о работе программистов в паре. Можете рассказать об этом подробнее?
Сниму видео. А пока можете погуглить pair programming
И все эти методологии в итоге приходят к тому что необходимо каждый раз описать тз и сделать как военные потому что желания заказчика бесконечные
Расскажите пожалуйста про Биг Дата ,базы данных, sap
про базы данных тут плейлист целый. про биг дата не расскажу. Не работал
Что можешь сказать по поводу JPA и Hibernate? Что из этого нужно учить, а что нет?
будет видео. уже запланировано
В вакансии на trainee позицию java разработчика указано одно из требований "understanding of software development processes" , как это понимать и как на это отвечать на собесе ?
Да, любят эту фразу)
Простым и понятным языком для чайников новичков ! КЛАСС
На самом деле правильная организация разработки программного обеспечения была описана еще в 1982г - в книге Fox, J. M. (1982). Software and its Development. Englewood Cliffs, N.J.: Prentice-Hall. (Дж. Фокс "Программное обеспечение и его разработка" - arbinada.com/en/node/57 ). И это еще задолго до того как появился сам термин agile (проворное) программирование. А так называемые agile технологии это просто спекуляции на тех идеях (присвоение тех идей), наукообразные и загадочные названия (для маркетинга), плюс еще сомнительные экзотические довески - "парное программирование", "экстремальное программирование", и т п. которые закономерно отмерли. Я однажды попал в коллектив, руководитель которого был адептом agile методов - это был просто дурдом, где каждый стремился спихнуть с себя ответсnвенность и подставить другого и где подпольно ходила методичка "Как выживать на провальном проекте" (книга Эдварда Йордона «Путь камикадзе»). На самом деле реально эффективное программирование, требует вдумчивости и соответственно требует времени на обдумывание, продумывание декомпозиции разработки на этапы и разные другие детали. Часто противопостовляемая (для контраста - опять же маркетинг!) аджайл методам упомянутая здесь технология , называемая "водопад" (на самом деле, я думаю, это термин, неверно переведенный с английского и не отражающий сути - правильно должно быть как "каскад" или "каскадная технология" или просто "последовательная разработка"). Этот неэффективный и нежизнеспособный метод организации разработки, иногда случающийся на заре становления программирования, действительно имел место и иногда имеет место и в наши дни. Возможно к нему склонны военные, хотя я не думаю что только они - скорее это общечеловеческая некомпетентность, которой всегда хватало. Давно признанно что разработка software это итеративный процесс и это было открыто еще в 70-80гг. Более того многие подобные идеи использовались еще до возникновения программирования. Например, в строительстве гидроэлектростанций - станцию запускали в несколько этапов, уже после первого этапа, еще до окончания строительства, она уже начинала давать ток и приносить прибыль. В несколько этапов запускают космические аппараты к далеким телам солнечной системы - сначала грубый запуск в нужном направлении, потом при первом приближении - анализ местоположения, цикл ориентации и корректировка траектории, при следующем приближении - итерацию повторяют. И так может быть несколько раз. Также стараются поступать и в программировании - как можно скорее запустить первую упрощенную версию системы, чтобы не только начать получать первую полезную отдачу от системы, но и ЧТО БОЛЕЕ ВАЖНО - получить feedback от заказчика, чтобы уточнить требования к системе (может быть даже изменившиеся) и вовремя ориентировать разработку в нужном направлении.
Расскажите пожалуйста про cms на java .Hybris,Liferay,Alfresco
зачем и что рассказать?
@@SergeyNemchinskiyНеобычно слышать сочитание слов java и cms , хотелось бы узнать ваше мнение по этому поводу. Перспективны ли данные cms-ки,стоит ли их изучать ?
Разработка через tdd окупается на больших проектах со временем. Исключает дальнейшие сюрпризы с доработками
Сергей, расскажите, наконец, о современных выдающихся Java-world технологиях, какой прогресс в этом деле?
я подумаю
В канбан методе тоже итерации есть. Называются каденции
По-прежнему Сергей Немчинский, ураааа
Что вы думаете о School 21 и подобных заведениях, они лучше ВУЗов? И как на них смотрят работодатели?
Там тебе дадут туториал, дадут пару часов объяснений и остальное ты будешь делать САМ. В универе то же самое. Пока ты отучишься где-либо, плевать где, выйдет сотня новых JS фреймворков и будешь уже и их изучать с нуля. Позволю себе погадать, что ты хочешь что-то выучить и начать карьеру интерна или джуна. Смотри вакансии, смотри, что популярно в той сфере кодинга, которая тебе нравится и начинай долбить эту сферу и конкретные инструменты. Заведи себе Гитхаб или Гитлаб аккаунт и лей туда свои проекты. Совершенствуйся в этом. Всё. Нет волшебной таблетки. Есть только желание, внутренний огонь. Вперёд, братан.
@@vlaih0 не угадал, я мидл-джун без образования)) Но хочу получить.
@@aleksandr3094 зачем? Строгое требование твоего работодателя? Лучше прокачаться в своей технологии.
@@vlaih0 Я занимаюсь прокачиванием себя как программиста, достигнув определенного уровня, сложно придумать такие задания и такую мотивацию, дабы двигаться дальше + без образования очень неохотно берут за рубеж.
@@aleksandr3094 от 2 лет опыта рассматриваются. Если у тебя есть опыт работы, это ценнее диплома. Если тем более на Западе это не понимают, значит они немного долбанутые.
Спасибо! Очень понятно и аргументированно. Дополнительный вопросик: как правильно организовать работу коллектива по разработке и внедрению софта? Я имею ввиду штатный состав, выражаясь языком советской канторы. Аналитики-программисты-тестироввщики- поддержка-... какое соотношение и распределение обязанностей по конкретным людям? Напрашивается аналитики отдельно, программисты отдельно. Но программисты часто жалуются на некачественную работу аналитиков (я не говорю, что аналитики виноваты) и начинается тыканье пальцами, походы и выяснения. Итд итп. Каков Ваш опыт и Ваши рекомендации? Спасибо!
Эм. это не на видео вопрос,а на тренинг. А точнее - учебную программу "проектный менеджмент"
@@SergeyNemchinskiy ну хотя бы в двух словах Ваше мнение или практика.
11:54 орнул, жиза 🤣🤣🤣
Все отлично, только Agile - не методология, а набор ценностей и принципов, которые утилизируются гибкими методологиями.
Когда пишешь коммент, только прочитав название? Сергей и говорит, что Agile - это не методология, а общее название гибких методов, отвечающих одним принципам, описанных в манифесто.
@@user-mh4jq8rr7i Ну и как это меняет ситуацию, если в названии всё же ошибка? :)
Mikail Davydov в названии вопрос и автор поясняет в чем ошибка такой формулировки
Слышал что Скрам также подразумевает Митинги ежеднывные в онлайне например по чатам заказчик/разработчик/руководитель разработки ?
Ежедневно? Очень короткие тим митинги, где участники делятся производственными новостями.
спринты обычно неделя, в конце каждого спринта встречи для обсуждения что что получилось, что мешает выполнить задачу + поставить дальнейшие задачи
обычно 2 недели
EvgeN и при чем тут встречи в конце спринта если речь идёт об ежедневных стендапах ? К чему это ты написал? И то написал хрень какую-то, нет встреч на которых обсуждаются статус целей спринта, проблемы и будущие задачи на одной встречи. Если не знаешь то не пиши ничего.
@@Muchitel я это и имел ввиду
Чорт побери так! Відсутність взаємовиключень це головна особливість, що ускладнює процес вивчення методологіїй.
Разработчик с 20+ летним стажем, начал руководить с 2001, запись 2020. Т.е. опыт разработки до позиции руководителя 1+ лет?))
Давайте о вебе/мобильной разработке на JS? Electron и все ребята
Почему-то вспомнился эксперимент компании Intel. Они хотели сделать упавление системой по голосу, но не знали, а надо ли вообще это человеку. Что понять вкладыватсья ли в разработку ПО для распознавания голоса и голосовых команд провели эксперимент : по одну сторону стенки был "якобы пользователь", которые выдавал голосовые команды, а по-другой другой человек, который слушал и выполнял. В конечном итоге выяснили: нафиг оно не надо. А сейчас? Сейчас голосовое управление очень даже нужно! Это на тему того , что пользователи сразу никогда не знают чего они на самом деле хотят. :)
интересно, а выпуск полу-сырых игр с миллионом багов и голым каркасом - это тоже лин нагадил? :D Не знаю как остальные, а я за такой продукт никогда не плачу, до тех пор пока он не станет по "военному" готовым и завершенным. Хотя конечно можно сказать, что рынок и определяет среднее арифметическое мвп
Как будет выглядеть процесс разработки ПО через 10-20 лет?
Силой мысли. Ты только подумал, а код уже готов. Правда и системные требования к такому коду возрастут. Для запуска блокнота понадобится xeon gold и баран 128гиг.
@@rasiyanin высрал? Доволен?
Monarch вероятно этот ответ и являлся целью заданного изначально вопроса... слабеет умом народ, к сожалению
Канбан-Метод - метод улучшения процессов. Говорят, что не только в Agile области модели cynefin может применяться.
*не только для complex систем
Хороший у тебя канал, Сергей, а главное нужный. Да первыми заказчиками были военные, вторыми финансовые компании и банки, Советский Союз до этого не дошёл, потому и IT заглох в совке
не понял из объяснения, в чем отличие Лин и Скрам - и там и там надо сначала сделать мвп и потом наращивать функционал...
МВП - это как раз термин из Лин. Скрам говорит просто про приращение функционала в каждой итерации. В лине нет итераций :) В общем, они просто друг друга дополняют
Сергей, мне кажется вы сильно упростили историю "водопадного" подхода к разработке. Термин "waterfall" в разработке ПО впервые ввел Винстон Ройс в 1970 году, и с тех пор этот термин получил распространение. Но Ройс применил его именно как пример плохого подхода к разработке, как пример того как нельзя делать. Он призывал как раз итеративно двигаться, каждый раз внося коррективы. Нельзя сказать что Пентагон использовал именно такую "последовательную" модель и она получила название waterfall.
Термин то он ввел, но ведь это только термин, реально так и работали, в основном конечно были военные заказы. И скорость изменений была очень низкая, этого вполне хватало для того времени. Опять же где-то в 70-х как раз стоимость разработки сравнялась со стоимостью оборудования, и потребовались какие-то изменения в принципах разработки.
@@MrVlMor ну я не совсем согласен с тем что "реально так и работали", хотя я лично в то время не девелопил конечно ) Судя по воспоминаниям, работали по разному, в том числе и достаточно гибко. Но если упростить картину, пусть будет так )
@@SigSauerArm Все госзаказы такие. Сначала надо смету составить и бюджет утвердить, а потом начать работу. А самые жирные проекты что тогда, что сейчас - от государства. На них и ориентировались в первую очередь, используя проверенные методики. Эксперименты - удел богатых компаний
Погодите! Поправьте меня но agile это не методология, а своего рода основы от которых методологии отталкиваются. Несколько догм которым надо следовать)
Вот 10 минут слушаю ,полезной информации 0,5 😮
Я работаю в TDD. Норм идет
Обьясните, зачем бизнесу знать как у меня проект в Intellij выглядит? какая у него структура, реализация и тд
@@billy_bastiani ты дурак? причем тут деньги, мне платят за продукт, а не как у меня будет называться папка: "product", а не "mne poxyi"
@@nowater756 Дурак здесь ты, который не понимает как происходит разработка. Сиди уже, не позорься.
@@billy_bastiani нахуй ты что-то высераешь клоун?) ты же никто
@@nowater756 Количество просмотров твоих псевдо-уроков говорит о том, что никто - это ты, и твои голимые уроки никому на свете не нужны. И почти под всеми твоими видео стоит всего один лайк, а это позволяет сделать вывод о том, что ты сам себя же и лайкаешь. Так что клоун здесь тоже ты. Обтекай.
От архитектуры проекта напрямую могут зависеть сроки реализации фичи. Время - деньги. Деньги - бизнес.
есть хороший пример от Арестовича. Хороший психолог может обладать только одной методологией, но добиваться результата. А плохой психолог может уметь во что угодно мастерски, но все равно не помогать. Конечно, тут на самом деле вопрос более сфокусированный, методологии разработки по-моему имеют вполне конкретные спектры применения, известные плюсы и минусы, и, банально, то что подходит в одном наборе задач, вредно в другом (например Эджайл - это нифига не решение для крупных проектов, умрешь его поддерживать потом). Да, я конкретно про Lean vs Agile, у них в принципах расхождения. По Lean - "плодить сущности" вредно. Agile - прямо говорит "делай как можешь, главное результат". Конечно, если их сложить (и дать приоритет Lean или Agile в зависимости от ситуации) - то да, идеальное решение.
Какой/какие язык/языки прогамиирования нужен/нужны для разработки игр на windows/mac/playstation/Xbox etc.?
XP применяется только в первый рабочий день ☝️
Интересная у Вас логика - если последовательно, то «водопад» ;)))) , а почему не «вагончики»? Вы можете объяснить что называли и почему «водопадом»?
Потому что у проекта есть определенное количество запланировнных ресурсов. Например бюджет в деньгах. И если взять график зависимости оставшихся ресурсов от прошедшего времени, то он напоминает водопад. Перед каждым дедлайном команда напрягается и получается отчетливый провал на графике. Похоже на пороги водопада.
Уважаемый Дмитрий, Вы умеете пользоваться MS Project? Знаете такой термин как «представление»? Найдите в представлении «Временная шкала» так называемый Вами «водопад» (images.app.goo.gl/i3gX29FXkJYAQ5Qa6)
Плохой перевод c английского "cascade" - на самом деле должно быть "каскадная разработка". Разумеется не "single drop waterfall" как например Kaieteur Falls. Переводчики не понимающие сути (или машинные переводчики) это еще тот прикол. Я встречал книгу в которой заказ (Sales Order) называли "порядком" и так всю книгу.
@@natty55555 , почему вообще появился термин "каскадная разработка"? Что там разработчики по каскаду скачут? Или кто-то табличное представление данных по другому не додумался назвать?
@@sdtester По этапам скачут: 1 Составление спецификаций. 2.Разработка. 3 Отладка. 4 Эксплуатация С любой ступеньки нельзя вернуться вверх, только вниз на следующую. В реальной разработке много раз приходится возвращаться на одну, две ступеньки вверх, а то и на самую первую (только она уже будет называться "Уточнение требований"). Певоначальные спецификации практически всегда приблизительны и не соответствуют тому что заказчик реально хочет. К счастью каждая последующая итерация занимает все меньше времени так что этот процесс сходящийся. И заказчик видит как система на его глазах принимает ту форму которую он (заказчик) реально хочет.
А у что вы скажите насчёт ИИ? Например, на чём пишут?
Блин, я похоже пурист =). Lean говорит в т.ч. про управление персоналом, как и про многое другое. Просто нужно понимать что Lean это философия, нежели практические советы. Т.е. да, практики, да, примеры, но Lean это не про какую-то конкретную запись в "политиках компании", это выше уровнем. И - да, факт, Lean применим если не к любому товару то почти к любому (сложно найти контр-примеры). Т.е. с одной стороны, максимально применимая и широкая методология, но минимально конкретно описывающая какие-либо процессы. Хотя есть там всякие Gemba Walks, но они опять же - методологии с очень широкой применимостью, в них не описывается "увидел покрытый паутиной стол - выбрось его" =). А описывается процесс поиска неэффективностей и их решения в каком-то очень общем формате.
преимущества и недостатки раскажите
у Ивана Селиховкина на канале есть хорошее сравнение проектного управления (в классическом понимании PMI), SCRUM и Kanban.
@@SigSauerArm ссылку на канал, пожалуйста, предоставь
@@wizaral Не знаю можно ли по правилам это делать. Канал Селиховкина - kzhead.info/tools/31GPSNxlyH90YRDxH_wStw.html Если что-то нарушил, заранее прошу прощения )
Я могу ошибаться, ибо работал в другой сфере, но методология вообще ничего не дает в большинстве случаев... Она сводится к тому что дает теоретические знания о том как что-то, где-то с конкретными людьми получилось сделать.... Другой вопрос что эти знания могут пригодиться, а могут так навредить что угробите команду... Всегда нужно применять то что работает вот тут, сейчас и конкретно с данными людьми.... Но чем больше у лидера рабочих инструментов и широта взглядов, тем эфыективннее будет работа команды... По сути все сводится к простой истине :"Анализируем - слабые стороны ликвидируем, сильные - усиливаем."... А вот как это делатб зависит от ситуации конкретной....
если Agile , Scrum методологии, то через запятую, если Agile философия, тогда
Коротко Agile придумали погані керівники щоб виправдати чому у них хрін зрозумієш що відбувається. :D - Чого у тебе не організована робота підрозділів? - Та ні організована: просто по Agile.
нет, даже не близко
Напомнило лекцию О. Бендера о шахматах в Васюкинском клубе Четырёх Коней: "Одни из Вас играют хорошо, другие играют плохо, и никакие лекции не изменят этого соотношения сил". Это вот о том, что у одних руководителей методология работает, а у других нет. Смех смехом, но грамотное руководство разработчиками ещё важнее, чем, скажем, хороший тренер в сборной России по хоккею с шайбой.
А вот теперь хотелось бы услышать подробней что конкретно подразумевается под термином "гибкий" в методологии Agile. Ушел гуглить. Так вот. Прочитав манифест ru.wikipedia.org/wiki/Agile_Manifesto - я сделал вывод что это не более чем шпаргалка для абсолютно любого человека или компании для того чтобы взаимодействие (заказчик - компания - команда - человек - продукт) устремлялись и улучшали взаимодействие во имя общих благ с целью получения продукта/результата. И на этом основании у меня возникает только два вопроса: 1. Мы знаем что Agile - это набор правил и ценностей, следуя которым мы идем к так называемому "успеху". Вопрос следующий: А разве когда-то было иначе (тоесть мы следовали иным правилам чтобы добиться этого же самого "успеха")? 2. Если учитывать методологию Agile - как то, что давно существующее еще до получения названия данного термина, но возможно еще не осознанное человеком, что же все таки подразумевается под термином "гибкость"?
@Volodymyr Volodymyr То есть раньше (до существования методологии Agile) реагирования не происходило или возможно они были медленными?
@Volodymyr Volodymyr Спасибо. Доходчиво объяснил)
@Volodymyr Volodymyr Тогда вот еще вопрос. В моей практике был момент, когда СЕО компании допустил студента в качестве архитектора некоего проекта. Тот же по своим соображениям слепил как умел, а после чего проект достался мне. Я конечно тоже не ас, но примерно целый месяц мы закрывали баги. Что в этом случае говорит "гибкость"? Как продвигаться, если жопа настигает? ))
Спасибо, грамотная лекция. Говорю как программист с 17и летнем стажем, и 7и летнем стажем тимлидства
Ещё раз, тест не показывает, что функция верна. Верификация/доказательство показывает, что функция верна. И обложенная типами программа гораздо лучше обложенной тестами.
Ну зато тест может показать, что функция НЕ верна.
@@drovoseg , а может и НЕ показать.
Да, но это намного лучше чем ничего.
@@drovoseg , или немного лучше чем ничего. Тут зависит от специфики софта, конечно. ООП, например, тупо не подразумевает создание по-настоящему надёжных программ.
@@user-tf5bs6de6z А что в вашем понимании "по-настоящему надёжная программа"? Мне на ум приходит только Hello world, хотя и он может не сработать в определённых обстоятельствах :) Даже в НАСА код пишется и тестируется очень тщательно, но и там встречаются ошибки.
Весь этот ажайл чаще всего это работа в «долг». Это то во что оно вырождается. Когда нет плана но мы продолжаем занимать бабки компании хрен пойми под чего. Тут не вопрос «как хочет пизнес» а вопрос того что в людях бизнеса сегодня практически не осталось людей от бизнеса - там чиновники сидят. Клерки. А что им от жизни надо? Спихнуть ответсвенность, Вот и начинаются аджайл пляски. Пока бабло не кончится.
По воду руководства программистами есть книга "Как пасти котов"...Кто читал?
Sevgen Berg Кот 😜
Описывается несколько типажей и как их сочетать. Книжка маленькая, читается легко
Так и не услышал разницу метедологий
Agile - filosofija
Методологии и методики - это разные вещи. Не надо их путать и использовать как синонимы.
Все первые методологии пришли из строительства. Вот где адам и ева.
Скрам это фреймворк, а не методология, вопрос с psm1😅
Добрый день, мы из России!
kzhead.info/sun/pquvfM6QiquuiIU/bejne.html - тут развели разговоров про канбан почти на час. Его вынесли из эджайла и сказали, что это инструмент улучшения того, что есть и его нужно использовать когда скрам уже не работает. Интересно узнать ваше мнение, Сергей, про эту точку зрения. Вы практик в бизнесе, а там практик со стороны консалтинга)) П.С. я больше доверяю реальной практике из бизнеса, а не всяким экспертам и коучам))
Огромная холиварная тема, даже не полезу. Я высказал свое мнение в этом видео
@@SergeyNemchinskiy, ок, в любом случае спасибо)
Вода-вода, конкретики 1%
Метадонологии
Почти 17 минут не о чем. Те кто имел об этом какое-то представление, услышали мнение Немчинского. Мнение очень взвешенное и аккуратное, видимо, чтобы никого не обидеть. Те кто ничего не знал о методологиях, никакой полезной информации не получили.
хой