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