От одного из лекторов слышал, что большинство проектов работает по методологии HDD - hope driven development. Всё делается как придется, но с надеждой, что получится хорошо.
Бюрократия и иерархия - это всегда страшно, и всё это есть в любой организации, в любом бизнесе. Это нужно упорядочить - а это создаст новые процедуры, иерархии и бюрократию
Пришёл с работы, думал 5 минут ютуб проверить, попал на ваш канал и залип уже на 5 часов... Спасибо большое за ваш труд, Сергей, очень хорошие видео! :)
Очень интересное обсуждение методологий! Тоже порой думаем, какой подход эффективнее: гибкость Agile или структурированность Kanban. Для себя открыли сервис Strive, в онлайне работать проще и приятнее) В работе заметно, что чистый Agile встречается редко, а каждый проект подстраивает методологию под свои задачи. Особенно ценно услышать мнение, как выбрать подход, чтобы балансировать продуктивность и комфорт команды! Спасибо!
Как менеджер не в IT (пока ;) добавлю: для управления необходимо отталкиваться от задач и предмета вопроса, а не от названия методологии и её подбора. Например, для простых, одноступенчатых задач - определил, довёл исполнителю / команде, проверил. Для комплексных проектов - постоянный контроль, сверка, корректировка, запуск.
Сергей, спасибо за видео! Неплохо описан взгляд менеджера и инженера на все эти подходы. Не хочу показаться пуристом и не буду придираться к мелочам (рассказать точно до мелочей - это был бы серьезный вызов), хочу просто немного по верхам вас поправить. Смотрите, то что вы описывали касающееся выпуска MVP - это подход Lean Startup, у которого есть конкретный автор (Если не ошибаюсь Эрик Риз) и он не имеет никакого отношения к Lean Manufacturing придуманному на Тойоте. Так же как и Канбан Метод, который сейчас используют в IT тоже не имеет никакого отношения к Lean Manufacturing и используемому там Канбану. Здесь вопрос скорее в том, что как раз Lean Manufacturing не смогли применить к IT-разработке из за того, что есть очень сильная специфика. Lean Manufacturing сделан для материального мира, производства материальной продукции и производственных цепочек, которые требуют достаточно мало умственной работы (когнитивных навыков). Современный же Канбан Метод, который был придуман в конце 2000-х как раз в нашем любимом IT (зачатки этого подхода появились в Microsoft) и он придуман именно для процессов требующих большого количества когнитивной работы и выпуска нематериальных продуктов. Помимо того, что современный Канбан не имеет никакого отношения к Lean (а во многих вещах действует ровно наоборот) он не имеет никакого отношения к Agile, это подход который был придуман как альтернатива тем подходам, которые мы привыкли называть гибкими, чтобы избегать тех проблем, которые они вызывали при внедрении. Если будет интересно, то готов на эту тему пообщаться, можете меня в FB найти или в телеге, буду рад конструктивному диалогу
Все равно имеют и леан стартап к леану, и канбан связан с мануфактуринг. И мса от майкрософта к "выбирайте что то, что было ранее". Да они другие, и концепты переписаны, но они based on. Первое вообще где алжайл евангелисты ведь все это не методологии а аппроач. Водопада нет к целом кстати, во первых каскад, во второых автор описания каскада описал итерацию каскада🤔. Но как бы не корректирую, просто слова для определения приняты немного другие. В общем, та же каша что и везде. Что в аджайл аппрочах, что в каскадных итерациях.
Достаточно понятное объяснение методологий, спасибо. Очень интересно будет посмотреть ролик с вашим мнение по поводу плюсов и минусов этих методологий, почему от каких-то то уходят и другим приходят.
Таки, читал, правда, давно то было.. П.с. не вижу проблемы в том что с течением времени и в угоду современным тенденциям, то или иное слово - живет, меняется, и так дальше. Не удивился если бы сегодняшние программисты, штурмовали Зимний
На самом деле правильная организация разработки программного обеспечения была описана еще в 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 от заказчика, чтобы уточнить требования к системе (может быть даже изменившиеся) и вовремя ориентировать разработку в нужном направлении.
Знаю и работаем только по технологии ASAP - as soon as possible :) Понимаю, что это краткий экскурс в методики, но мне это нужно было, чтобы хотя бы общее представление иметь. В книгах довольно запутано пишется, имхо :)) Спасибо за видео!
На практике всё это просто не работает, а точнее - сильно снижает качество и эффективность работы, приводит к быстрому выгоранию и к конфликтам. Есть такой антипаттерн руководства - микроменеджмент. Так вот, скрам, аджаил и канбан очень быстро вырождаются в ту или иную форму микроменеджмента, партсобраний (дейли, викли, ретро, пленинг, груминг, хуюминг) и вот этого всего. Хуже всего с этим в крупных компаниях, с раздутой бюрократией и руководящим составом партийных работников а-ля СССР. Как раз сейчас ищу новую работу после более чем двух лет именно в таком корпоративном гадюшнике.
Советую записаться к ним в школу. Сэкономите кучу времени. Это не только к Foxminded относится. Языки, игра на гитаре, спорт. Хотите что-то быстро выучить/освоить - ищите ментора.
Как Вы правы.!.... Не существует "волшебной таблетки" на все случаи жизни.... Простота, новизна, чётко поставленные цели, большое желание работать, тесты + ЗДРАВЫЙ СМЫСЛ, который подсказывает как быстрее достичь нужный результат в конкретных ситуациях.
есть хороший пример от Арестовича. Хороший психолог может обладать только одной методологией, но добиваться результата. А плохой психолог может уметь во что угодно мастерски, но все равно не помогать. Конечно, тут на самом деле вопрос более сфокусированный, методологии разработки по-моему имеют вполне конкретные спектры применения, известные плюсы и минусы, и, банально, то что подходит в одном наборе задач, вредно в другом (например Эджайл - это нифига не решение для крупных проектов, умрешь его поддерживать потом). Да, я конкретно про Lean vs Agile, у них в принципах расхождения. По Lean - "плодить сущности" вредно. Agile - прямо говорит "делай как можешь, главное результат". Конечно, если их сложить (и дать приоритет Lean или Agile в зависимости от ситуации) - то да, идеальное решение.
Ну наверное еще принципиальное правило канбана это не впихивать не впихуемое. То есть предел на одноврменно выполняемые задачи. Если при обычном подходе это никого не волнует, то при канбане, руководитель должен спуститься вниз и вместо постановки новых задач помочь расширить ограничение потока.
Здравствуйте, вы упомянули работу программистов в паре, можете по-подробнее рассказать про это? Какие технологии для этого используются, как это осуществляется в современных компаниях (EE и мобильной разработки) и как это делать качественно и быстро?
Сходил на конференцию по Kanban,у. У нас это хайп сейчас) Но все понимают, что это не истина. Актуальны все методы, какой подойдёт вам, зависит от ваших кейсов и контекста. Сергей, как всегда спасибо за контент
Когда пишешь коммент, только прочитав название? Сергей и говорит, что Agile - это не методология, а общее название гибких методов, отвечающих одним принципам, описанных в манифесто.
Хороший у тебя канал, Сергей, а главное нужный. Да первыми заказчиками были военные, вторыми финансовые компании и банки, Советский Союз до этого не дошёл, потому и IT заглох в совке
В вакансии на trainee позицию java разработчика указано одно из требований "understanding of software development processes" , как это понимать и как на это отвечать на собесе ?
Весь этот ажайл чаще всего это работа в «долг». Это то во что оно вырождается. Когда нет плана но мы продолжаем занимать бабки компании хрен пойми под чего. Тут не вопрос «как хочет пизнес» а вопрос того что в людях бизнеса сегодня практически не осталось людей от бизнеса - там чиновники сидят. Клерки. А что им от жизни надо? Спихнуть ответсвенность, Вот и начинаются аджайл пляски. Пока бабло не кончится.
EvgeN и при чем тут встречи в конце спринта если речь идёт об ежедневных стендапах ? К чему это ты написал? И то написал хрень какую-то, нет встреч на которых обсуждаются статус целей спринта, проблемы и будущие задачи на одной встречи. Если не знаешь то не пиши ничего.
Там тебе дадут туториал, дадут пару часов объяснений и остальное ты будешь делать САМ. В универе то же самое. Пока ты отучишься где-либо, плевать где, выйдет сотня новых JS фреймворков и будешь уже и их изучать с нуля. Позволю себе погадать, что ты хочешь что-то выучить и начать карьеру интерна или джуна. Смотри вакансии, смотри, что популярно в той сфере кодинга, которая тебе нравится и начинай долбить эту сферу и конкретные инструменты. Заведи себе Гитхаб или Гитлаб аккаунт и лей туда свои проекты. Совершенствуйся в этом. Всё. Нет волшебной таблетки. Есть только желание, внутренний огонь. Вперёд, братан.
@@vlaih0 Я занимаюсь прокачиванием себя как программиста, достигнув определенного уровня, сложно придумать такие задания и такую мотивацию, дабы двигаться дальше + без образования очень неохотно берут за рубеж.
@@aleksandr3094 от 2 лет опыта рассматриваются. Если у тебя есть опыт работы, это ценнее диплома. Если тем более на Западе это не понимают, значит они немного долбанутые.
Отличное видео. Подскажите, если владелец проекта начинает его с нанятым разработчиком вдвоём. За всю it-часть отвечает разраб (в том числе работа с серверами, бэкапами, безопасность сайта). Каким образом владельцу сохранять полный контроль над проектом? Чтобы в случае желания продажи бизнеса владелец был уверенным, что он действительно владеет всем необходимым для этого. И не придётся ни о чем потом договариваться с нанятым разработчиком и зависеть от него в этом вопросе.
Сергей, мне кажется вы сильно упростили историю "водопадного" подхода к разработке. Термин "waterfall" в разработке ПО впервые ввел Винстон Ройс в 1970 году, и с тех пор этот термин получил распространение. Но Ройс применил его именно как пример плохого подхода к разработке, как пример того как нельзя делать. Он призывал как раз итеративно двигаться, каждый раз внося коррективы. Нельзя сказать что Пентагон использовал именно такую "последовательную" модель и она получила название waterfall.
Термин то он ввел, но ведь это только термин, реально так и работали, в основном конечно были военные заказы. И скорость изменений была очень низкая, этого вполне хватало для того времени. Опять же где-то в 70-х как раз стоимость разработки сравнялась со стоимостью оборудования, и потребовались какие-то изменения в принципах разработки.
@@MrVlMor ну я не совсем согласен с тем что "реально так и работали", хотя я лично в то время не девелопил конечно ) Судя по воспоминаниям, работали по разному, в том числе и достаточно гибко. Но если упростить картину, пусть будет так )
@@SigSauerArm Все госзаказы такие. Сначала надо смету составить и бюджет утвердить, а потом начать работу. А самые жирные проекты что тогда, что сейчас - от государства. На них и ориентировались в первую очередь, используя проверенные методики. Эксперименты - удел богатых компаний
Блин, я похоже пурист =). Lean говорит в т.ч. про управление персоналом, как и про многое другое. Просто нужно понимать что Lean это философия, нежели практические советы. Т.е. да, практики, да, примеры, но Lean это не про какую-то конкретную запись в "политиках компании", это выше уровнем. И - да, факт, Lean применим если не к любому товару то почти к любому (сложно найти контр-примеры). Т.е. с одной стороны, максимально применимая и широкая методология, но минимально конкретно описывающая какие-либо процессы. Хотя есть там всякие Gemba Walks, но они опять же - методологии с очень широкой применимостью, в них не описывается "увидел покрытый паутиной стол - выбрось его" =). А описывается процесс поиска неэффективностей и их решения в каком-то очень общем формате.
А вот теперь хотелось бы услышать подробней что конкретно подразумевается под термином "гибкий" в методологии Agile. Ушел гуглить. Так вот. Прочитав манифест ru.wikipedia.org/wiki/Agile_Manifesto - я сделал вывод что это не более чем шпаргалка для абсолютно любого человека или компании для того чтобы взаимодействие (заказчик - компания - команда - человек - продукт) устремлялись и улучшали взаимодействие во имя общих благ с целью получения продукта/результата. И на этом основании у меня возникает только два вопроса: 1. Мы знаем что Agile - это набор правил и ценностей, следуя которым мы идем к так называемому "успеху". Вопрос следующий: А разве когда-то было иначе (тоесть мы следовали иным правилам чтобы добиться этого же самого "успеха")? 2. Если учитывать методологию Agile - как то, что давно существующее еще до получения названия данного термина, но возможно еще не осознанное человеком, что же все таки подразумевается под термином "гибкость"?
@Volodymyr Volodymyr Тогда вот еще вопрос. В моей практике был момент, когда СЕО компании допустил студента в качестве архитектора некоего проекта. Тот же по своим соображениям слепил как умел, а после чего проект достался мне. Я конечно тоже не ас, но примерно целый месяц мы закрывали баги. Что в этом случае говорит "гибкость"? Как продвигаться, если жопа настигает? ))
Мне не понятно, если я как просто manual QA analyst, то какая от меня требуется agile методология, поясню, на собеседованиях меня спрашивают какие эджаил методологии вы используете🙈 логично что никакие, я просто QA но может я что то не так понимаю
@@SergeyNemchinskiyНеобычно слышать сочитание слов java и cms , хотелось бы узнать ваше мнение по этому поводу. Перспективны ли данные cms-ки,стоит ли их изучать ?
Силой мысли. Ты только подумал, а код уже готов. Правда и системные требования к такому коду возрастут. Для запуска блокнота понадобится xeon gold и баран 128гиг.
@@nowater756 Количество просмотров твоих псевдо-уроков говорит о том, что никто - это ты, и твои голимые уроки никому на свете не нужны. И почти под всеми твоими видео стоит всего один лайк, а это позволяет сделать вывод о том, что ты сам себя же и лайкаешь. Так что клоун здесь тоже ты. Обтекай.
Погодите! Поправьте меня но agile это не методология, а своего рода основы от которых методологии отталкиваются. Несколько догм которым надо следовать)
Получается ведь, что жёсткое формальное следование какой-либо из методологий Agile будет противоречить самому манифесту Agile, который ставит во главу гибкость, результат и здравый смысл.
Ещё раз, тест не показывает, что функция верна. Верификация/доказательство показывает, что функция верна. И обложенная типами программа гораздо лучше обложенной тестами.
@@drovoseg , или немного лучше чем ничего. Тут зависит от специфики софта, конечно. ООП, например, тупо не подразумевает создание по-настоящему надёжных программ.
@@БарометрАтмосферный А что в вашем понимании "по-настоящему надёжная программа"? Мне на ум приходит только Hello world, хотя и он может не сработать в определённых обстоятельствах :) Даже в НАСА код пишется и тестируется очень тщательно, но и там встречаются ошибки.
интересно, а выпуск полу-сырых игр с миллионом багов и голым каркасом - это тоже лин нагадил? :D Не знаю как остальные, а я за такой продукт никогда не плачу, до тех пор пока он не станет по "военному" готовым и завершенным. Хотя конечно можно сказать, что рынок и определяет среднее арифметическое мвп
МВП - это как раз термин из Лин. Скрам говорит просто про приращение функционала в каждой итерации. В лине нет итераций :) В общем, они просто друг друга дополняют
Я могу ошибаться, ибо работал в другой сфере, но методология вообще ничего не дает в большинстве случаев... Она сводится к тому что дает теоретические знания о том как что-то, где-то с конкретными людьми получилось сделать.... Другой вопрос что эти знания могут пригодиться, а могут так навредить что угробите команду... Всегда нужно применять то что работает вот тут, сейчас и конкретно с данными людьми.... Но чем больше у лидера рабочих инструментов и широта взглядов, тем эфыективннее будет работа команды... По сути все сводится к простой истине :"Анализируем - слабые стороны ликвидируем, сильные - усиливаем."... А вот как это делатб зависит от ситуации конкретной....
Почему-то вспомнился эксперимент компании Intel. Они хотели сделать упавление системой по голосу, но не знали, а надо ли вообще это человеку. Что понять вкладыватсья ли в разработку ПО для распознавания голоса и голосовых команд провели эксперимент : по одну сторону стенки был "якобы пользователь", которые выдавал голосовые команды, а по-другой другой человек, который слушал и выполнял. В конечном итоге выяснили: нафиг оно не надо. А сейчас? Сейчас голосовое управление очень даже нужно! Это на тему того , что пользователи сразу никогда не знают чего они на самом деле хотят. :)
Спасибо! Очень понятно и аргументированно. Дополнительный вопросик: как правильно организовать работу коллектива по разработке и внедрению софта? Я имею ввиду штатный состав, выражаясь языком советской канторы. Аналитики-программисты-тестироввщики- поддержка-... какое соотношение и распределение обязанностей по конкретным людям? Напрашивается аналитики отдельно, программисты отдельно. Но программисты часто жалуются на некачественную работу аналитиков (я не говорю, что аналитики виноваты) и начинается тыканье пальцами, походы и выяснения. Итд итп. Каков Ваш опыт и Ваши рекомендации? Спасибо!
Коротко Agile придумали погані керівники щоб виправдати чому у них хрін зрозумієш що відбувається. :D - Чого у тебе не організована робота підрозділів? - Та ні організована: просто по Agile.
@@dominuspiritus Не знаю можно ли по правилам это делать. Канал Селиховкина - ruclips.net/channel/UC31GPSNxlyH90YRDxH_wStw Если что-то нарушил, заранее прошу прощения )
Потому что у проекта есть определенное количество запланировнных ресурсов. Например бюджет в деньгах. И если взять график зависимости оставшихся ресурсов от прошедшего времени, то он напоминает водопад. Перед каждым дедлайном команда напрягается и получается отчетливый провал на графике. Похоже на пороги водопада.
Уважаемый Дмитрий, Вы умеете пользоваться MS Project? Знаете такой термин как «представление»? Найдите в представлении «Временная шкала» так называемый Вами «водопад» (images.app.goo.gl/i3gX29FXkJYAQ5Qa6)
Плохой перевод c английского "cascade" - на самом деле должно быть "каскадная разработка". Разумеется не "single drop waterfall" как например Kaieteur Falls. Переводчики не понимающие сути (или машинные переводчики) это еще тот прикол. Я встречал книгу в которой заказ (Sales Order) называли "порядком" и так всю книгу.
@@natty55555 , почему вообще появился термин "каскадная разработка"? Что там разработчики по каскаду скачут? Или кто-то табличное представление данных по другому не додумался назвать?
@@sdtester По этапам скачут: 1 Составление спецификаций. 2.Разработка. 3 Отладка. 4 Эксплуатация С любой ступеньки нельзя вернуться вверх, только вниз на следующую. В реальной разработке много раз приходится возвращаться на одну, две ступеньки вверх, а то и на самую первую (только она уже будет называться "Уточнение требований"). Певоначальные спецификации практически всегда приблизительны и не соответствуют тому что заказчик реально хочет. К счастью каждая последующая итерация занимает все меньше времени так что этот процесс сходящийся. И заказчик видит как система на его глазах принимает ту форму которую он (заказчик) реально хочет.
Напомнило лекцию О. Бендера о шахматах в Васюкинском клубе Четырёх Коней: "Одни из Вас играют хорошо, другие играют плохо, и никакие лекции не изменят этого соотношения сил". Это вот о том, что у одних руководителей методология работает, а у других нет. Смех смехом, но грамотное руководство разработчиками ещё важнее, чем, скажем, хороший тренер в сборной России по хоккею с шайбой.
Почти 17 минут не о чем. Те кто имел об этом какое-то представление, услышали мнение Немчинского. Мнение очень взвешенное и аккуратное, видимо, чтобы никого не обидеть. Те кто ничего не знал о методологиях, никакой полезной информации не получили.
Тут много восторженных комментов... но, как человек не в теме, утверждаю - видео ниочем. Ну может в среде менеджеров это офигенно информативное видео, но в сравнении с современными высокоплотными видео - это какая-то вода. Тут кто-то давно должен был написать что-то вроде "начало видео на 14:00". Я к тому, что в современном мире у людей оч. мало свободного времени для самообразования и расходовать его на воду от профессионалов крайне расточительно. Тем более, что формат ютуба позволяет сделать плотную насыщенную подачу материала без размазывания времени. Да и вообще, те же современные фильмы и сериалы на столько избавлены от воды, что остался только экшон - остальное безжалостно вырезано - в наше время сантабарбару ни кто не смог бы посмотреть.
От одного из лекторов слышал, что большинство проектов работает по методологии HDD - hope driven development. Всё делается как придется, но с надеждой, что получится хорошо.
И посмеялся и sad but true
Ну или spdd
🤣 so true
Бюрократия и иерархия - это всегда страшно, и всё это есть в любой организации, в любом бизнесе. Это нужно упорядочить - а это создаст новые процедуры, иерархии и бюрократию
Перфекцехуизм
Есть еще методологии "всего по чуть чуть" и "мы не знаем как мы работаем, но всем говорим что у нас все по скраму" =)))))))))
Вввайаваавапийпввпийавппвпваупйвамйавпввпввмппвапапввппв
❤️:-)
Пришёл с работы, думал 5 минут ютуб проверить, попал на ваш канал и залип уже на 5 часов... Спасибо большое за ваш труд, Сергей, очень хорошие видео! :)
О, шикарно!!! Это было интересно послушать!
спасибо!
Sergey Nemchinskiy Спасибо Вам
Как всегда, просто, ясно, доходчиво о сложных и многогранных вещах.
Сергей, спасибо.
Очень интересное обсуждение методологий! Тоже порой думаем, какой подход эффективнее: гибкость Agile или структурированность Kanban. Для себя открыли сервис Strive, в онлайне работать проще и приятнее) В работе заметно, что чистый Agile встречается редко, а каждый проект подстраивает методологию под свои задачи. Особенно ценно услышать мнение, как выбрать подход, чтобы балансировать продуктивность и комфорт команды! Спасибо!
Как менеджер не в IT (пока ;) добавлю: для управления необходимо отталкиваться от задач и предмета вопроса, а не от названия методологии и её подбора.
Например, для простых, одноступенчатых задач - определил, довёл исполнителю / команде, проверил.
Для комплексных проектов - постоянный контроль, сверка, корректировка, запуск.
Сергей, спасибо за видео! Неплохо описан взгляд менеджера и инженера на все эти подходы. Не хочу показаться пуристом и не буду придираться к мелочам (рассказать точно до мелочей - это был бы серьезный вызов), хочу просто немного по верхам вас поправить. Смотрите, то что вы описывали касающееся выпуска MVP - это подход Lean Startup, у которого есть конкретный автор (Если не ошибаюсь Эрик Риз) и он не имеет никакого отношения к Lean Manufacturing придуманному на Тойоте. Так же как и Канбан Метод, который сейчас используют в IT тоже не имеет никакого отношения к Lean Manufacturing и используемому там Канбану. Здесь вопрос скорее в том, что как раз Lean Manufacturing не смогли применить к IT-разработке из за того, что есть очень сильная специфика. Lean Manufacturing сделан для материального мира, производства материальной продукции и производственных цепочек, которые требуют достаточно мало умственной работы (когнитивных навыков). Современный же Канбан Метод, который был придуман в конце 2000-х как раз в нашем любимом IT (зачатки этого подхода появились в Microsoft) и он придуман именно для процессов требующих большого количества когнитивной работы и выпуска нематериальных продуктов. Помимо того, что современный Канбан не имеет никакого отношения к Lean (а во многих вещах действует ровно наоборот) он не имеет никакого отношения к Agile, это подход который был придуман как альтернатива тем подходам, которые мы привыкли называть гибкими, чтобы избегать тех проблем, которые они вызывали при внедрении. Если будет интересно, то готов на эту тему пообщаться, можете меня в FB найти или в телеге, буду рад конструктивному диалогу
спасибо за уточнение
Все равно имеют и леан стартап к леану, и канбан связан с мануфактуринг. И мса от майкрософта к "выбирайте что то, что было ранее". Да они другие, и концепты переписаны, но они based on.
Первое вообще где алжайл евангелисты ведь все это не методологии а аппроач.
Водопада нет к целом кстати, во первых каскад, во второых автор описания каскада описал итерацию каскада🤔. Но как бы не корректирую, просто слова для определения приняты немного другие.
В общем, та же каша что и везде. Что в аджайл аппрочах, что в каскадных итерациях.
Достаточно понятное объяснение методологий, спасибо.
Очень интересно будет посмотреть ролик с вашим мнение по поводу плюсов и минусов этих методологий, почему от каких-то то уходят и другим приходят.
они не взаимоисключающие :)
Вот хорошо сказал: у одних работает, у других нет. Независимо от метода все решает компетентность и работоспособность команды и руководителей.
Вот именно!!!
Аджайл и скрам это красивая обёртка для того, чтоб выжимать из разраба все соки
@Volodymyr Volodymyr А какая разница кем работать, если разговор идет о "методике" работы?
@Volodymyr Volodymyr здесь:)
Чтобы выжимать сроки достаточно требовать отчет каждый день, а agile нужен чтобы подстраиваться под изменения в тз с минимальными издержками
А программист не пролетарий? Такая же наемная персона, будь ты на галерах или во фрилансе, но конечно же в красивой упаковке ;)
Таки, читал, правда, давно то было..
П.с. не вижу проблемы в том что с течением времени и в угоду современным тенденциям, то или иное слово - живет, меняется, и так дальше. Не удивился если бы сегодняшние программисты, штурмовали Зимний
как начался разговор на менеджерскую тему - сразу как-то мутно стало... :) а за ролик спасибо
На самом деле правильная организация разработки программного обеспечения была описана еще в 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 от заказчика, чтобы уточнить требования к системе (может быть даже изменившиеся) и вовремя ориентировать разработку в нужном направлении.
Як завжди - на висоті ;) Дякую !
Вітаю, чудово, здоров'я, благословінь, миру.
Знаю и работаем только по технологии ASAP - as soon as possible :)
Понимаю, что это краткий экскурс в методики, но мне это нужно было, чтобы хотя бы общее представление иметь. В книгах довольно запутано пишется, имхо :))
Спасибо за видео!
кружечка зачетная и спасибо за видео
Спасибо сергей очень интересно и понятно для новичка!
На практике всё это просто не работает, а точнее - сильно снижает качество и эффективность работы, приводит к быстрому выгоранию и к конфликтам. Есть такой антипаттерн руководства - микроменеджмент. Так вот, скрам, аджаил и канбан очень быстро вырождаются в ту или иную форму микроменеджмента, партсобраний (дейли, викли, ретро, пленинг, груминг, хуюминг) и вот этого всего. Хуже всего с этим в крупных компаниях, с раздутой бюрократией и руководящим составом партийных работников а-ля СССР. Как раз сейчас ищу новую работу после более чем двух лет именно в таком корпоративном гадюшнике.
Спасибо. Доступно, без лишнего пафоса
Было бы интересно узнать, особенно новичкам правильную последовательность изучения технологий для Java разработчика. Спасибо за отличные видео)
Java, Hibernate/Spring.
Советую записаться к ним в школу. Сэкономите кучу времени.
Это не только к Foxminded относится. Языки, игра на гитаре, спорт. Хотите что-то быстро выучить/освоить - ищите ментора.
Java core, Servlet/JSP, и далее Hibernate, Spring
У меня есть статья про правильный порядок изучения dou.ua/lenta/articles/java-enterprise-guide/
@@the_leonik кому нахер нужен твой сервлет jsp?
Как Вы правы.!.... Не существует "волшебной таблетки" на все случаи жизни.... Простота, новизна, чётко поставленные цели, большое желание работать, тесты + ЗДРАВЫЙ СМЫСЛ, который подсказывает как быстрее достичь нужный результат в конкретных ситуациях.
есть хороший пример от Арестовича. Хороший психолог может обладать только одной методологией, но добиваться результата. А плохой психолог может уметь во что угодно мастерски, но все равно не помогать.
Конечно, тут на самом деле вопрос более сфокусированный, методологии разработки по-моему имеют вполне конкретные спектры применения, известные плюсы и минусы, и, банально, то что подходит в одном наборе задач, вредно в другом (например Эджайл - это нифига не решение для крупных проектов, умрешь его поддерживать потом).
Да, я конкретно про Lean vs Agile, у них в принципах расхождения. По Lean - "плодить сущности" вредно. Agile - прямо говорит "делай как можешь, главное результат". Конечно, если их сложить (и дать приоритет Lean или Agile в зависимости от ситуации) - то да, идеальное решение.
3.58 Ура, начало!
Да, в кратце хорошо прошёлся по основным моментам 👍
Хорошая тема поднята. Нужно продолжение! )
Задавайте вопросы
Ну наверное еще принципиальное правило канбана это не впихивать не впихуемое. То есть предел на одноврменно выполняемые задачи. Если при обычном подходе это никого не волнует, то при канбане, руководитель должен спуститься вниз и вместо постановки новых задач помочь расширить ограничение потока.
Спасибо за видео
Здравствуйте, вы упомянули работу программистов в паре, можете по-подробнее рассказать про это? Какие технологии для этого используются, как это осуществляется в современных компаниях (EE и мобильной разработки) и как это делать качественно и быстро?
Мы как раз с напарником работаем по большей части вдвоём, хотелось бы узнать все тонкости и лайфхаки
Сходил на конференцию по Kanban,у. У нас это хайп сейчас) Но все понимают, что это не истина. Актуальны все методы, какой подойдёт вам, зависит от ваших кейсов и контекста. Сергей, как всегда спасибо за контент
Вам спасибо
Все отлично, только Agile - не методология, а набор ценностей и принципов, которые утилизируются гибкими методологиями.
Когда пишешь коммент, только прочитав название? Сергей и говорит, что Agile - это не методология, а общее название гибких методов, отвечающих одним принципам, описанных в манифесто.
@@ЯрославВладимиров-д7х Ну и как это меняет ситуацию, если в названии всё же ошибка? :)
Mikail Davydov в названии вопрос и автор поясняет в чем ошибка такой формулировки
По-прежнему Сергей Немчинский, ураааа
Какие книги можете посоветовать по scrum и kanban?
Kanban in Action
если ты не руководитель то тебе эти методологии нахрен не нужны
@@алексавы-р5к руководителями не рождаются
Вот 10 минут слушаю ,полезной информации 0,5 😮
Спасибо. Очень внятно. Подписался.
Часто попадались на глаза названия этих методологий. Надеялся понять что это такое, но так и ничего не понял с видео.
И все эти методологии в итоге приходят к тому что необходимо каждый раз описать тз и сделать как военные потому что желания заказчика бесконечные
Хороший у тебя канал, Сергей, а главное нужный. Да первыми заказчиками были военные, вторыми финансовые компании и банки, Советский Союз до этого не дошёл, потому и IT заглох в совке
В вакансии на trainee позицию java разработчика указано одно из требований "understanding of software development processes" , как это понимать и как на это отвечать на собесе ?
Да, любят эту фразу)
Весь этот ажайл чаще всего это работа в «долг». Это то во что оно вырождается. Когда нет плана но мы продолжаем занимать бабки компании хрен пойми под чего. Тут не вопрос «как хочет пизнес» а вопрос того что в людях бизнеса сегодня практически не осталось людей от бизнеса - там чиновники сидят. Клерки. А что им от жизни надо? Спихнуть ответсвенность, Вот и начинаются аджайл пляски. Пока бабло не кончится.
шикарно, впервые слышу эти термины и я увидел общую кратину.
выжимка видоса: "скрам - показатель наращивания функционала", - самое главное
Слышал что Скрам также подразумевает Митинги ежеднывные в онлайне например по чатам заказчик/разработчик/руководитель разработки ?
Ежедневно? Очень короткие тим митинги, где участники делятся производственными новостями.
спринты обычно неделя, в конце каждого спринта встречи для обсуждения что что получилось, что мешает выполнить задачу + поставить дальнейшие задачи
обычно 2 недели
EvgeN и при чем тут встречи в конце спринта если речь идёт об ежедневных стендапах ? К чему это ты написал? И то написал хрень какую-то, нет встреч на которых обсуждаются статус целей спринта, проблемы и будущие задачи на одной встречи. Если не знаешь то не пиши ничего.
@@Muchitel я это и имел ввиду
Что вы думаете о School 21 и подобных заведениях, они лучше ВУЗов? И как на них смотрят работодатели?
Там тебе дадут туториал, дадут пару часов объяснений и остальное ты будешь делать САМ. В универе то же самое. Пока ты отучишься где-либо, плевать где, выйдет сотня новых JS фреймворков и будешь уже и их изучать с нуля.
Позволю себе погадать, что ты хочешь что-то выучить и начать карьеру интерна или джуна. Смотри вакансии, смотри, что популярно в той сфере кодинга, которая тебе нравится и начинай долбить эту сферу и конкретные инструменты.
Заведи себе Гитхаб или Гитлаб аккаунт и лей туда свои проекты. Совершенствуйся в этом.
Всё. Нет волшебной таблетки. Есть только желание, внутренний огонь.
Вперёд, братан.
@@vlaih0 не угадал, я мидл-джун без образования))
Но хочу получить.
@@aleksandr3094 зачем? Строгое требование твоего работодателя? Лучше прокачаться в своей технологии.
@@vlaih0 Я занимаюсь прокачиванием себя как программиста, достигнув определенного уровня, сложно придумать такие задания и такую мотивацию, дабы двигаться дальше + без образования очень неохотно берут за рубеж.
@@aleksandr3094 от 2 лет опыта рассматриваются. Если у тебя есть опыт работы, это ценнее диплома. Если тем более на Западе это не понимают, значит они немного долбанутые.
Здравствуйте! Ваше мнение - на сегодняшний день agile-коучи востребованы? И где этому учат?
Дякую за цікаву і достатньо повну відповідь.
Сергей, здравствуйте! А что у Вас за клава на столе? Сейчас хороших белых, полноформатных клав почти не найдешь.
Отличное видео. Подскажите, если владелец проекта начинает его с нанятым разработчиком вдвоём. За всю it-часть отвечает разраб (в том числе работа с серверами, бэкапами, безопасность сайта). Каким образом владельцу сохранять полный контроль над проектом? Чтобы в случае желания продажи бизнеса владелец был уверенным, что он действительно владеет всем необходимым для этого. И не придётся ни о чем потом договариваться с нанятым разработчиком и зависеть от него в этом вопросе.
Чорт побери так! Відсутність взаємовиключень це головна особливість, що ускладнює процес вивчення методологіїй.
Отличное видео
Що означає працювати в парі? Як це організовується?
Спасибо!
Впервые слышу о работе программистов в паре. Можете рассказать об этом подробнее?
Сниму видео. А пока можете погуглить pair programming
Сергей, мне кажется вы сильно упростили историю "водопадного" подхода к разработке. Термин "waterfall" в разработке ПО впервые ввел Винстон Ройс в 1970 году, и с тех пор этот термин получил распространение. Но Ройс применил его именно как пример плохого подхода к разработке, как пример того как нельзя делать. Он призывал как раз итеративно двигаться, каждый раз внося коррективы. Нельзя сказать что Пентагон использовал именно такую "последовательную" модель и она получила название waterfall.
Термин то он ввел, но ведь это только термин, реально так и работали, в основном конечно были военные заказы. И скорость изменений была очень низкая, этого вполне хватало для того времени. Опять же где-то в 70-х как раз стоимость разработки сравнялась со стоимостью оборудования, и потребовались какие-то изменения в принципах разработки.
@@MrVlMor ну я не совсем согласен с тем что "реально так и работали", хотя я лично в то время не девелопил конечно ) Судя по воспоминаниям, работали по разному, в том числе и достаточно гибко. Но если упростить картину, пусть будет так )
@@SigSauerArm Все госзаказы такие. Сначала надо смету составить и бюджет утвердить, а потом начать работу. А самые жирные проекты что тогда, что сейчас - от государства. На них и ориентировались в первую очередь, используя проверенные методики. Эксперименты - удел богатых компаний
Блин, я похоже пурист =).
Lean говорит в т.ч. про управление персоналом, как и про многое другое. Просто нужно понимать что Lean это философия, нежели практические советы. Т.е. да, практики, да, примеры, но Lean это не про какую-то конкретную запись в "политиках компании", это выше уровнем. И - да, факт, Lean применим если не к любому товару то почти к любому (сложно найти контр-примеры). Т.е. с одной стороны, максимально применимая и широкая методология, но минимально конкретно описывающая какие-либо процессы. Хотя есть там всякие Gemba Walks, но они опять же - методологии с очень широкой применимостью, в них не описывается "увидел покрытый паутиной стол - выбрось его" =). А описывается процесс поиска неэффективностей и их решения в каком-то очень общем формате.
Сергей, расскажите, наконец, о современных выдающихся Java-world технологиях, какой прогресс в этом деле?
я подумаю
Разработка через tdd окупается на больших проектах со временем. Исключает дальнейшие сюрпризы с доработками
А вот теперь хотелось бы услышать подробней что конкретно подразумевается под термином "гибкий" в методологии Agile. Ушел гуглить.
Так вот. Прочитав манифест ru.wikipedia.org/wiki/Agile_Manifesto - я сделал вывод что это не более чем шпаргалка для абсолютно любого человека или компании для того чтобы взаимодействие (заказчик - компания - команда - человек - продукт) устремлялись и улучшали взаимодействие во имя общих благ с целью получения продукта/результата. И на этом основании у меня возникает только два вопроса:
1. Мы знаем что Agile - это набор правил и ценностей, следуя которым мы идем к так называемому "успеху". Вопрос следующий: А разве когда-то было иначе (тоесть мы следовали иным правилам чтобы добиться этого же самого "успеха")?
2. Если учитывать методологию Agile - как то, что давно существующее еще до получения названия данного термина, но возможно еще не осознанное человеком, что же все таки подразумевается под термином "гибкость"?
@Volodymyr Volodymyr То есть раньше (до существования методологии Agile) реагирования не происходило или возможно они были медленными?
@Volodymyr Volodymyr Спасибо. Доходчиво объяснил)
@Volodymyr Volodymyr Тогда вот еще вопрос. В моей практике был момент, когда СЕО компании допустил студента в качестве архитектора некоего проекта. Тот же по своим соображениям слепил как умел, а после чего проект достался мне. Я конечно тоже не ас, но примерно целый месяц мы закрывали баги. Что в этом случае говорит "гибкость"? Как продвигаться, если жопа настигает? ))
Мне не понятно, если я как просто manual QA analyst, то какая от меня требуется agile методология, поясню, на собеседованиях меня спрашивают какие эджаил методологии вы используете🙈 логично что никакие, я просто QA но может я что то не так понимаю
В канбан методе тоже итерации есть. Называются каденции
Расскажите пожалуйста про Биг Дата ,базы данных, sap
про базы данных тут плейлист целый. про биг дата не расскажу. Не работал
Расскажите пожалуйста про cms на java .Hybris,Liferay,Alfresco
зачем и что рассказать?
@@SergeyNemchinskiyНеобычно слышать сочитание слов java и cms , хотелось бы узнать ваше мнение по этому поводу. Перспективны ли данные cms-ки,стоит ли их изучать ?
Как будет выглядеть процесс разработки ПО через 10-20 лет?
Силой мысли. Ты только подумал, а код уже готов. Правда и системные требования к такому коду возрастут. Для запуска блокнота понадобится xeon gold и баран 128гиг.
@@rasiyanin высрал? Доволен?
Monarch вероятно этот ответ и являлся целью заданного изначально вопроса... слабеет умом народ, к сожалению
Канбан-Метод - метод улучшения процессов. Говорят, что не только в Agile области модели cynefin может применяться.
*не только для complex систем
Обьясните, зачем бизнесу знать как у меня проект в Intellij выглядит? какая у него структура, реализация и тд
@@billy_bastiani ты дурак? причем тут деньги, мне платят за продукт, а не как у меня будет называться папка: "product", а не "mne poxyi"
@@nowater756
Дурак здесь ты, который не понимает как происходит разработка. Сиди уже, не позорься.
@@billy_bastiani нахуй ты что-то высераешь клоун?) ты же никто
@@nowater756
Количество просмотров твоих псевдо-уроков говорит о том, что никто - это ты, и твои голимые уроки никому на свете не нужны. И почти под всеми твоими видео стоит всего один лайк, а это позволяет сделать вывод о том, что ты сам себя же и лайкаешь. Так что клоун здесь тоже ты. Обтекай.
От архитектуры проекта напрямую могут зависеть сроки реализации фичи. Время - деньги. Деньги - бизнес.
Что можешь сказать по поводу JPA и Hibernate? Что из этого нужно учить, а что нет?
будет видео. уже запланировано
Здравствуйте, не могли бы пожалуйста осветить тему программирования логических контроллеров
нет. вообще ничего об этом не знаю
Погодите! Поправьте меня но agile это не методология, а своего рода основы от которых методологии отталкиваются. Несколько догм которым надо следовать)
Получается ведь, что жёсткое формальное следование какой-либо из методологий Agile будет противоречить самому манифесту Agile, который ставит во главу гибкость, результат и здравый смысл.
Ещё раз, тест не показывает, что функция верна. Верификация/доказательство показывает, что функция верна. И обложенная типами программа гораздо лучше обложенной тестами.
Ну зато тест может показать, что функция НЕ верна.
@@drovoseg , а может и НЕ показать.
Да, но это намного лучше чем ничего.
@@drovoseg , или немного лучше чем ничего. Тут зависит от специфики софта, конечно. ООП, например, тупо не подразумевает создание по-настоящему надёжных программ.
@@БарометрАтмосферный А что в вашем понимании "по-настоящему надёжная программа"?
Мне на ум приходит только Hello world, хотя и он может не сработать в определённых обстоятельствах :)
Даже в НАСА код пишется и тестируется очень тщательно, но и там встречаются ошибки.
Скрам это фреймворк, а не методология, вопрос с psm1😅
Ничего не понятно, но очень интересно
интересно, а выпуск полу-сырых игр с миллионом багов и голым каркасом - это тоже лин нагадил? :D Не знаю как остальные, а я за такой продукт никогда не плачу, до тех пор пока он не станет по "военному" готовым и завершенным.
Хотя конечно можно сказать, что рынок и определяет среднее арифметическое мвп
не понял из объяснения, в чем отличие Лин и Скрам - и там и там надо сначала сделать мвп и потом наращивать функционал...
МВП - это как раз термин из Лин. Скрам говорит просто про приращение функционала в каждой итерации. В лине нет итераций :) В общем, они просто друг друга дополняют
Я могу ошибаться, ибо работал в другой сфере, но методология вообще ничего не дает в большинстве случаев... Она сводится к тому что дает теоретические знания о том как что-то, где-то с конкретными людьми получилось сделать.... Другой вопрос что эти знания могут пригодиться, а могут так навредить что угробите команду... Всегда нужно применять то что работает вот тут, сейчас и конкретно с данными людьми.... Но чем больше у лидера рабочих инструментов и широта взглядов, тем эфыективннее будет работа команды... По сути все сводится к простой истине :"Анализируем - слабые стороны ликвидируем, сильные - усиливаем."... А вот как это делатб зависит от ситуации конкретной....
Почему-то вспомнился эксперимент компании Intel. Они хотели сделать упавление системой по голосу, но не знали, а надо ли вообще это человеку. Что понять вкладыватсья ли в разработку ПО для распознавания голоса и голосовых команд провели эксперимент : по одну сторону стенки был "якобы пользователь", которые выдавал голосовые команды, а по-другой другой человек, который слушал и выполнял. В конечном итоге выяснили: нафиг оно не надо. А сейчас? Сейчас голосовое управление очень даже нужно! Это на тему того , что пользователи сразу никогда не знают чего они на самом деле хотят. :)
Спасибо! Очень понятно и аргументированно. Дополнительный вопросик: как правильно организовать работу коллектива по разработке и внедрению софта? Я имею ввиду штатный состав, выражаясь языком советской канторы. Аналитики-программисты-тестироввщики- поддержка-... какое соотношение и распределение обязанностей по конкретным людям? Напрашивается аналитики отдельно, программисты отдельно. Но программисты часто жалуются на некачественную работу аналитиков (я не говорю, что аналитики виноваты) и начинается тыканье пальцами, походы и выяснения. Итд итп. Каков Ваш опыт и Ваши рекомендации? Спасибо!
Эм. это не на видео вопрос,а на тренинг. А точнее - учебную программу "проектный менеджмент"
@@SergeyNemchinskiy ну хотя бы в двух словах Ваше мнение или практика.
Я работаю в TDD. Норм идет
Разработчик с 20+ летним стажем, начал руководить с 2001, запись 2020. Т.е. опыт разработки до позиции руководителя 1+ лет?))
Добрый день, мы из России!
Круть!
Коротко Agile придумали погані керівники щоб виправдати чому у них хрін зрозумієш що відбувається. :D
- Чого у тебе не організована робота підрозділів?
- Та ні організована: просто по Agile.
нет, даже не близко
преимущества и недостатки раскажите
у Ивана Селиховкина на канале есть хорошее сравнение проектного управления (в классическом понимании PMI), SCRUM и Kanban.
@@SigSauerArm ссылку на канал, пожалуйста, предоставь
@@dominuspiritus Не знаю можно ли по правилам это делать. Канал Селиховкина - ruclips.net/channel/UC31GPSNxlyH90YRDxH_wStw
Если что-то нарушил, заранее прошу прощения )
Интересная у Вас логика - если последовательно, то «водопад» ;)))) , а почему не «вагончики»?
Вы можете объяснить что называли и почему «водопадом»?
Потому что у проекта есть определенное количество запланировнных ресурсов. Например бюджет в деньгах. И если взять график зависимости оставшихся ресурсов от прошедшего времени, то он напоминает водопад. Перед каждым дедлайном команда напрягается и получается отчетливый провал на графике. Похоже на пороги водопада.
Уважаемый Дмитрий, Вы умеете пользоваться MS Project? Знаете такой термин как «представление»? Найдите в представлении «Временная шкала» так называемый Вами «водопад» (images.app.goo.gl/i3gX29FXkJYAQ5Qa6)
Плохой перевод c английского "cascade" - на самом деле должно быть "каскадная разработка". Разумеется не "single drop waterfall" как например Kaieteur Falls.
Переводчики не понимающие сути (или машинные переводчики) это еще тот прикол. Я встречал книгу в которой заказ (Sales Order) называли "порядком" и так всю книгу.
@@natty55555 , почему вообще появился термин "каскадная разработка"? Что там разработчики по каскаду скачут? Или кто-то табличное представление данных по другому не додумался назвать?
@@sdtester По этапам скачут:
1 Составление спецификаций.
2.Разработка.
3 Отладка.
4 Эксплуатация
С любой ступеньки нельзя вернуться вверх, только вниз на следующую.
В реальной разработке много раз приходится возвращаться на одну, две ступеньки вверх, а то и на самую первую (только она уже будет называться "Уточнение требований").
Певоначальные спецификации практически всегда приблизительны и не соответствуют тому что заказчик реально хочет. К счастью каждая последующая итерация занимает все меньше времени так что этот процесс сходящийся. И заказчик видит как система на его глазах принимает ту форму которую он (заказчик) реально хочет.
Простым и понятным языком для чайников новичков ! КЛАСС
Методологии и методики - это разные вещи. Не надо их путать и использовать как синонимы.
Давайте о вебе/мобильной разработке на JS? Electron и все ребята
А у что вы скажите насчёт ИИ? Например, на чём пишут?
Напомнило лекцию О. Бендера о шахматах в Васюкинском клубе Четырёх Коней: "Одни из Вас играют хорошо, другие играют плохо, и никакие лекции не изменят этого соотношения сил". Это вот о том, что у одних руководителей методология работает, а у других нет. Смех смехом, но грамотное руководство разработчиками ещё важнее, чем, скажем, хороший тренер в сборной России по хоккею с шайбой.
XP применяется только в первый рабочий день ☝️
Какой/какие язык/языки прогамиирования нужен/нужны для разработки игр на windows/mac/playstation/Xbox etc.?
Вода-вода, конкретики 1%
если Agile , Scrum методологии, то через запятую, если Agile философия, тогда
Все первые методологии пришли из строительства. Вот где адам и ева.
По воду руководства программистами есть книга "Как пасти котов"...Кто читал?
Sevgen Berg Кот 😜
Описывается несколько типажей и как их сочетать. Книжка маленькая, читается легко
Налил воды, ничего по сути (
Обычное дело для таких, смотрите видео Гугда, там все твёрдо и четко
11:54 орнул, жиза 🤣🤣🤣
Почти 17 минут не о чем. Те кто имел об этом какое-то представление, услышали мнение Немчинского. Мнение очень взвешенное и аккуратное, видимо, чтобы никого не обидеть. Те кто ничего не знал о методологиях, никакой полезной информации не получили.
Тут много восторженных комментов... но, как человек не в теме, утверждаю - видео ниочем. Ну может в среде менеджеров это офигенно информативное видео, но в сравнении с современными высокоплотными видео - это какая-то вода. Тут кто-то давно должен был написать что-то вроде "начало видео на 14:00".
Я к тому, что в современном мире у людей оч. мало свободного времени для самообразования и расходовать его на воду от профессионалов крайне расточительно. Тем более, что формат ютуба позволяет сделать плотную насыщенную подачу материала без размазывания времени. Да и вообще, те же современные фильмы и сериалы на столько избавлены от воды, что остался только экшон - остальное безжалостно вырезано - в наше время сантабарбару ни кто не смог бы посмотреть.
Наиболее распространённая методологие - это ха, тьфу и в продакшн)