Как минимум, издание было другое (подарочное издание малым тиражом, коричневая обложка с золотыми буквами, год 2001, или скорее, 2000), авторов не помню...
Но суть не в конкретной книге, а с Вашей мыслью согласен: методика была разработана еще в прошлом веке (причем даже не в самом конце), но большинство помнят только водопад и сравнивают скрам только с ним.
Анемичная модель, это, вообще, не про ООП, более-менее то же самое можно на Си (без плюсов) со структурами реализовать. Подозреваю, что ее и придумали сишники, которых насильно пересадили на Джаву
Тысячи круд ресурсов в системе не связанных между собой? Это не сложная, а просто объемная система. Даже сложно представить, для чего она может понадобиться?
Не просто так в SQL появились транзакции, люди давно поняли, что простым крудом сложную логику не реализуешь )
Со щитом получилось недопонимание между мной и электриком на фоне моего желания иметь фишки умного дома и нашего обоюдного на тот момент незнания, как этот умный дом можно реализовать + до меня дошло, что в первоначальном варианте щит будет торчать в прихожей на виду (я почему-то думал, что его полностью "утопят" в стену).
Нуууу. Недавно делал ремонт в квартире. Если бы все делали водопадом, я сейчас был бы намного менее доволен ) Понятно, что несущие стены не переносили, но, например:
1) одну межкомнатную перегородку наращивали на 50 см по сравнению с планом силами электрика-многостаночника и штукатура уже после отъезда каменщика
2) так же, уже после начала первичной прокладки электропроводки, пришлось входную дверь немного сдвинуть для организации электрощита в другом месте (сразу размеры щита неправильно посчитали)
2) розеток добавили в комнатах 4 штуки (сейчас понимаю, что надо было 6) уже после черновой штукатурки, 1 перенесли
3) робот пылесос за время ремонта получил возможность подключения к воде и канализации, поэтому, был перенесен из комнаты в прихожую (к стояку) с добавлением и там розетки + ответвления по сантехнике и соответствующая перепланировка мебели
Давным-давно, году в 2001м примерно, начальница давала мне почитать толстый том по управлению проектами. Точное название и авторов, естественно, не помню. Но помню, что там описывалась методика спиральной разработки. Мне кажется, для большого проекта она лучше и водопада, и скрама
Так в этом и смысл Скрама - сделать подвал с гаражом и сдать их заказчику. Если вдруг окажется, что у того джип не пролезает в ворота, переделать ДО того, как начали строить этажи.
Мне чистый Скрам (даже и с месячными спринтами) для крупных проектов кажется очень сомнительным приемом - все же для полноценного проектирования сложной системы надо ее более-менее видеть целиком (без деталей, но общие границы и контексты), а что увидит аналитик за неделю? Да он банально не успеет опросить всех нужных специалистов заказчика. Тут логично делать первые спринты только на стратегическую аналитику и проектирование архитектуры (чтобы аналитик с заказчиком не напридумывали нереализуемого), потом спринт более детальной архитектуры и только потом реализация блоков системы при помощи классической модели скрама. А между несколькими релизами вставлять еще спринт аналитики и архитектуры.
Первое проект, второе - циклический процесс. Проект имеет начало и конец (получение готового продукта), процесс (на некотором временном промежутке) начала и конца не имеет и выдает продукт постоянно. В скраме разбили большой проект на кусочки с получением какой-то части конечного продукта в конце каждого спринта. Смысл в том что "за время пути собачка могла подрасти". Т.е. пока продукт реализуется по методологии водопада, требования заказчика и физический мир могут измениться. Или аналитики ошиблись, но понятно это становится только при начале эксплуатации программы. Скрам позволяет корректировать цели и методики не после получения конечного продукта, а по пути, после реализации некоторого еще не полного, но уже полезного заказчику ПО.
Занятно, похоже на гибрид property и mixin. Для чего сделано именно так, мне не очень понятно, но я питоном не так давно начал интересоваться и не по своей воле...
Просмотрел по диагонали, могу ошибаться, но разве очередность событий не важна? Несколько воркеров с FOR UPDATE SKIP LOCKEDмогут нарушить очередность и сломать консистентность данных
Тут когда собственники бизнес делят — легко могут зайти с «группой поддержки» и физически выгнать всех с территории предприятия, еще и побив подвернувшихся под руку.
Вот! А говорите, никаких рисков в ИТ нет! Историю с группой поддержки я проходил на личном опыте (без побития). Везде есть риски, разные. Понимаю, новые впечатления в кино взорвали вам эмоциональную сферу. Да, безусловно, на съемках много сложнопредсказуемых факторов и часто факторы более "материальные" чем в ИТ, но зачем же сразу принижать свою профессиональную область? Если у вас в фирме процессы за годы так отлажены, что риски почти исключены, это ваша заслуга, а не жизнь в ИТ такая простая ).
Как вы себе представляете возросшую "клиентоориентированность и гибкость" в B2B?
Я? Я работаю в большой отечественной компании и автоматизирую процессы коллег инфраструктурщиков. Всегда стараюсь вникнуть в предметную область и понять потребность внутреннего заказчика. Не написать код строго по бизнес-требованиям и даже ТЗ, а решить проблему, с которой заказчик пришел. Заказчик (а иногда и наш собственный аналитик) может (имеет полное право) не знать всех возможностей и ограничений системы, придумывает решение по своему предыдущему опыту, что часто не оптимально. Иногда могу предложить использовать что-то из недавно освоенного отделом вместо того, что представлялось коллегам, иногда вижу и помогаю исправить логические нестыковки в бизнес-требованиях, иногда вынужден признавать, что какая-то идея заказчика на текущий момент слишком ресурсоемка, не окупит усилий, и либо конструктивно донести эту мысль до заказчика, с переносом задачи в бэклог на отдаленное будущее, когда появятся свободные ресурсы, либо предложить упрощенную альтернативу но сейчас. А иногда, если образовалось пол часа свободного времени, могу не заказанную небольшую фичу прикрутить, если вижу, что людям пригодится.
Но что я? Для меня общение с внутренним клиентом, приятный бонус (люблю ощущать, что моими продуктами пользуются, что они приносят людям пользу) или производственная необходимость (если штатный аналитик перегружен), не прописанные в должностных обязанностях.
Вы перечислили варианты решения проблем с минимальным, но совсем не нулевым отклонением от графика. Замена тим-лида в процессе стартовавшей разработки это потеря не одного дня (найти замену, ввести в курс проекта, познакомить с командой и распределением задач). История с аналитиком может оказаться совсем не простой, если сотрудник подрядчика не открыто противостоит, а тихо саботирует (выдает не все данные), что может выясниться только на этапе пилотирования. Или на каком-то этапе аналитик с представителем заказчика (а то и с самим заказчиком) окончательно разругаются и придется заменять аналитика (это случай из реальной жизни).
Вопрос практики проектирования, такого рода переделки «всех экранов» характерны для юных падаванов, пока еще остро желающих «переписать все».
Согласен, не очень удачный пример. Шаблоны, разбиение экранов на блоки и виджеты решают вопрос. Хуже, если окажется, что на каждом экране функционал требует какие-то свои специфические данные, которые надо тащить из репозитория через все слои. Впрочем, забудем этот пример, я его из головы взял.
До пандемии да, а теперь идет скорее откат к основам, поскольку вся эта "гибкость и клиенториентированность" сжирает ресурсы.
Не могу судить о состоянии рынка заказной разработки ПО, но есть нейросети, которые жрут гораздо больше ресурсов. Тем не менее, все крупные игроки (включая SAP) в них вцепились, и, если реализуется хотя бы десятая часть задуманного, клиентоориентированность и гибкость возрастут на порядок.
В процессе разработки заболевает/увольняется тим-лид
Аналитик не может найти общего языка с сотрудником, назначенным курировать проект со стороны заказчика, и ТЗ либо пишется очень медленно, либо с ошибками непонимания, которые потребуют переработки ПО на стадии тестирования с заказчиком
Обстановка на рынке меняется и оказывается очень важным добавить в приложение кнопку издавания трех зеленых свистков вверх, причем добавить так, что придется немного переработать все экраны приложения и половину DTO.
SAP, на сколько я помню (хотя сейчас могу уже соврать - лет двадцать прошло с тех пор как я интересовался мировым рынком MRP/ERP/CRM и прочих КИС), закупали во многом потому, что это авторитетно (лидер рынка, BAAN тогда уже сдал позиции, а Оракл был только СУБД), максимально функционально, есть у других крупных отечественных фирм и можно немалый бюджет освоить. Внедряли с большим скрипом, отставанием по срокам, и что принципиально - с большой кастомизацией под отечественные условия.
Слышал про случаи, когда SAP был явно избыточен, но его все равно, мучительно внедряли.
Кто помельче и хотел подешевле, брали Аксапту и тоже внедряли не без проблем.
А у отечественных производителей как не было в нулевых, так, похоже, и нет КИС для больших корпораций с сотнями тысяч сотрудников. Более того, с тех пор некоторые представители среднеразмерных систем вымерли, после того, как 1С научилась таки в нормальный клиент-сервер, а не так, что при работе пары десятков пользователей все тормозило нещадно.
Если на предприятии внедрен SAP сильно вряд ли меня подпустят к тем бизнес-процессам, но, если зовут автоматизировать другой участок, где еще нет автоматизации, то что мешает мне, посмотрев свежим взглядом и систематизировав предлагать бизнесу оптимизации? Не навязывать, как пытались в SAP в девяностые, а предлагать для дискуссии. Идея о том, что аналитик из какого-нибудь SAP/BAAN лучше основателя бизнеса знает, как у того должны работать процессы, кажется несколько устаревшей - сейчас заметная часть мира живет в постоянных изменениях чтобы не проиграть конкуренцию. И SAP это поняли, в рекламе новых продуктов упоминается гибкость и адаптируемость к индивидуальным особенностям конкретного бизнеса.
25 лет практики это очень много, поэтому нет уже никаких рисков при оценке.
Я про риски не в смысле дать неправильную оценку, а в смысле неопределенных факторов влияющих на реализацию, тех проблемах, которые могут случиться, а могут и нет, от которых в значительной степени зависит вилка по ресурсам.
Оптимальную по сравнению с чем?
С другими вариантами реализациями по совокупности факторов. Предложить где-то оптимизировать безнес-процессы, но учитывать, что заказчик, если это не новый владелец, в этом всем варится и может знать какие-то факторы, делающие наши оптимизации не работающими.
При моем опыте сколь-нибудь серьезной ошибки в оценке быть уже не может )
Т.е. вы риски явно не учитываете, включаете интуицию?
Сейчас снова сорву покровы: в подавляющем большинстве случаев заказчик не знает, не представляет и не догадывается.
Поэтому и нужны вы — профессионал, который подскажет, расскажет, объяснит и посчитает.
Помню, такой подход был в моде в начале нулевых. Как раз у SAP практически девизом шла мысль: мы уже автоматизировали туеву хучу фирм и лучше всех знаем, как должны строиться бизнес-процессы. Потом, правда, по доходившим до меня слухам, оказалось, что на нашей территории их немецкие бизнес-процессы не работают... И пришлось уже "почти внедренные" системы серьезно допиливать для совмещения с реальностью.
Но и "клиент всегда прав" не работает. Предпочитаю золотую середину - клиент, вероятно, знает свой бизнес (если сам построил или много лет в деле, конечно), но не знает в автоматизацию и, вероятно, не всегда строит процессы оптимально. Мое дело выяснить смысл бизнес-процессов и предложить оптимальную реализацию.
Неважно что я предпочитаю, когда есть правила отрасли и давно известная градация бюджетов.
Но для себя-то вы учитываете риски? Чтобы не переборщить с занижением или предложить дополнительное обследование-аналитику.
Например, риск того, что заказчик сам толком не знает свои бизнес-процессы и разрабатываемое ПО, после написания по ТЗ заказчика, придется долго и муторно дорабатывать напильником?
Похоже, что его, хотя я такой фамилии не помню ) Сейчас понимаю, что уже и деталей самой методологии не помнил...
Как минимум, издание было другое (подарочное издание малым тиражом, коричневая обложка с золотыми буквами, год 2001, или скорее, 2000), авторов не помню...
Но суть не в конкретной книге, а с Вашей мыслью согласен: методика была разработана еще в прошлом веке (причем даже не в самом конце), но большинство помнят только водопад и сравнивают скрам только с ним.
Анемичная модель, это, вообще, не про ООП, более-менее то же самое можно на Си (без плюсов) со структурами реализовать. Подозреваю, что ее и придумали сишники, которых насильно пересадили на Джаву
Тысячи круд ресурсов в системе не связанных между собой? Это не сложная, а просто объемная система. Даже сложно представить, для чего она может понадобиться?
Не просто так в SQL появились транзакции, люди давно поняли, что простым крудом сложную логику не реализуешь )
Со щитом получилось недопонимание между мной и электриком на фоне моего желания иметь фишки умного дома и нашего обоюдного на тот момент незнания, как этот умный дом можно реализовать + до меня дошло, что в первоначальном варианте щит будет торчать в прихожей на виду (я почему-то думал, что его полностью "утопят" в стену).
Нуууу. Недавно делал ремонт в квартире. Если бы все делали водопадом, я сейчас был бы намного менее доволен ) Понятно, что несущие стены не переносили, но, например:
1) одну межкомнатную перегородку наращивали на 50 см по сравнению с планом силами электрика-многостаночника и штукатура уже после отъезда каменщика
2) так же, уже после начала первичной прокладки электропроводки, пришлось входную дверь немного сдвинуть для организации электрощита в другом месте (сразу размеры щита неправильно посчитали)
2) розеток добавили в комнатах 4 штуки (сейчас понимаю, что надо было 6) уже после черновой штукатурки, 1 перенесли
3) робот пылесос за время ремонта получил возможность подключения к воде и канализации, поэтому, был перенесен из комнаты в прихожую (к стояку) с добавлением и там розетки + ответвления по сантехнике и соответствующая перепланировка мебели
А по поводу этажей, Вы не поверите, но есть в Москве примеры домов, когда на хрущевские 5 этажей наращивали сверху еще 4!!! https://vm.ru/moscow/206479-hrushevke-narastili-etazhej-unikalnaya-strojka-pozvolit-uvelichit-imeyushiesya-v-starom-dome-kvartiry-i-poluchit-novye
Давным-давно, году в 2001м примерно, начальница давала мне почитать толстый том по управлению проектами. Точное название и авторов, естественно, не помню. Но помню, что там описывалась методика спиральной разработки. Мне кажется, для большого проекта она лучше и водопада, и скрама
Так в этом и смысл Скрама - сделать подвал с гаражом и сдать их заказчику. Если вдруг окажется, что у того джип не пролезает в ворота, переделать ДО того, как начали строить этажи.
Вот только, редко кому нужен гараж без дома.
Мне чистый Скрам (даже и с месячными спринтами) для крупных проектов кажется очень сомнительным приемом - все же для полноценного проектирования сложной системы надо ее более-менее видеть целиком (без деталей, но общие границы и контексты), а что увидит аналитик за неделю? Да он банально не успеет опросить всех нужных специалистов заказчика. Тут логично делать первые спринты только на стратегическую аналитику и проектирование архитектуры (чтобы аналитик с заказчиком не напридумывали нереализуемого), потом спринт более детальной архитектуры и только потом реализация блоков системы при помощи классической модели скрама. А между несколькими релизами вставлять еще спринт аналитики и архитектуры.
Первое проект, второе - циклический процесс. Проект имеет начало и конец (получение готового продукта), процесс (на некотором временном промежутке) начала и конца не имеет и выдает продукт постоянно. В скраме разбили большой проект на кусочки с получением какой-то части конечного продукта в конце каждого спринта. Смысл в том что "за время пути собачка могла подрасти". Т.е. пока продукт реализуется по методологии водопада, требования заказчика и физический мир могут измениться. Или аналитики ошиблись, но понятно это становится только при начале эксплуатации программы. Скрам позволяет корректировать цели и методики не после получения конечного продукта, а по пути, после реализации некоторого еще не полного, но уже полезного заказчику ПО.
Похоже на замену программирования терпеливым воспитанием исполнительного и старательного дебила... (((
Переименование класса во все проекте и замену сигнатур IntelliJ неплохо делает без всякого ИИ, не тратя на это кучу электричества.
Занятно, похоже на гибрид property и mixin. Для чего сделано именно так, мне не очень понятно, но я питоном не так давно начал интересоваться и не по своей воле...
Выглядит так, что питонисту надо обязательно знать Си ) А некоторые "ускорения" как "Давайте сделаем Си с синтаксисом Питона".
Просмотрел по диагонали, могу ошибаться, но разве очередность событий не важна? Несколько воркеров с
FOR UPDATE SKIP LOCKEDмогут нарушить очередность и сломать консистентность данныхВот! А говорите, никаких рисков в ИТ нет! Историю с группой поддержки я проходил на личном опыте (без побития). Везде есть риски, разные. Понимаю, новые впечатления в кино взорвали вам эмоциональную сферу. Да, безусловно, на съемках много сложнопредсказуемых факторов и часто факторы более "материальные" чем в ИТ, но зачем же сразу принижать свою профессиональную область? Если у вас в фирме процессы за годы так отлажены, что риски почти исключены, это ваша заслуга, а не жизнь в ИТ такая простая ).
Я? Я работаю в большой отечественной компании и автоматизирую процессы коллег инфраструктурщиков. Всегда стараюсь вникнуть в предметную область и понять потребность внутреннего заказчика. Не написать код строго по бизнес-требованиям и даже ТЗ, а решить проблему, с которой заказчик пришел. Заказчик (а иногда и наш собственный аналитик) может (имеет полное право) не знать всех возможностей и ограничений системы, придумывает решение по своему предыдущему опыту, что часто не оптимально. Иногда могу предложить использовать что-то из недавно освоенного отделом вместо того, что представлялось коллегам, иногда вижу и помогаю исправить логические нестыковки в бизнес-требованиях, иногда вынужден признавать, что какая-то идея заказчика на текущий момент слишком ресурсоемка, не окупит усилий, и либо конструктивно донести эту мысль до заказчика, с переносом задачи в бэклог на отдаленное будущее, когда появятся свободные ресурсы, либо предложить упрощенную альтернативу но сейчас. А иногда, если образовалось пол часа свободного времени, могу не заказанную небольшую фичу прикрутить, если вижу, что людям пригодится.
Но что я? Для меня общение с внутренним клиентом, приятный бонус (люблю ощущать, что моими продуктами пользуются, что они приносят людям пользу) или производственная необходимость (если штатный аналитик перегружен), не прописанные в должностных обязанностях.
Вот в интернете немало статей написано специалистами в этой области: https://yandex.ru/search/?clid=11450072&text=клиентоориентированность+в+B2B&l10n=ru&lr=213 )))
Вы перечислили варианты решения проблем с минимальным, но совсем не нулевым отклонением от графика. Замена тим-лида в процессе стартовавшей разработки это потеря не одного дня (найти замену, ввести в курс проекта, познакомить с командой и распределением задач). История с аналитиком может оказаться совсем не простой, если сотрудник подрядчика не открыто противостоит, а тихо саботирует (выдает не все данные), что может выясниться только на этапе пилотирования. Или на каком-то этапе аналитик с представителем заказчика (а то и с самим заказчиком) окончательно разругаются и придется заменять аналитика (это случай из реальной жизни).
Согласен, не очень удачный пример. Шаблоны, разбиение экранов на блоки и виджеты решают вопрос. Хуже, если окажется, что на каждом экране функционал требует какие-то свои специфические данные, которые надо тащить из репозитория через все слои. Впрочем, забудем этот пример, я его из головы взял.
Не могу судить о состоянии рынка заказной разработки ПО, но есть нейросети, которые жрут гораздо больше ресурсов. Тем не менее, все крупные игроки (включая SAP) в них вцепились, и, если реализуется хотя бы десятая часть задуманного, клиентоориентированность и гибкость возрастут на порядок.
Что мешает неопределенным факторам повториться?
В процессе разработки заболевает/увольняется тим-лид
Аналитик не может найти общего языка с сотрудником, назначенным курировать проект со стороны заказчика, и ТЗ либо пишется очень медленно, либо с ошибками непонимания, которые потребуют переработки ПО на стадии тестирования с заказчиком
Обстановка на рынке меняется и оказывается очень важным добавить в приложение кнопку издавания трех зеленых свистков вверх, причем добавить так, что придется немного переработать все экраны приложения и половину DTO.
SAP, на сколько я помню (хотя сейчас могу уже соврать - лет двадцать прошло с тех пор как я интересовался мировым рынком MRP/ERP/CRM и прочих КИС), закупали во многом потому, что это авторитетно (лидер рынка, BAAN тогда уже сдал позиции, а Оракл был только СУБД), максимально функционально, есть у других крупных отечественных фирм и можно немалый бюджет освоить. Внедряли с большим скрипом, отставанием по срокам, и что принципиально - с большой кастомизацией под отечественные условия.
Слышал про случаи, когда SAP был явно избыточен, но его все равно, мучительно внедряли.
Кто помельче и хотел подешевле, брали Аксапту и тоже внедряли не без проблем.
А у отечественных производителей как не было в нулевых, так, похоже, и нет КИС для больших корпораций с сотнями тысяч сотрудников. Более того, с тех пор некоторые представители среднеразмерных систем вымерли, после того, как 1С научилась таки в нормальный клиент-сервер, а не так, что при работе пары десятков пользователей все тормозило нещадно.
Если на предприятии внедрен SAP сильно вряд ли меня подпустят к тем бизнес-процессам, но, если зовут автоматизировать другой участок, где еще нет автоматизации, то что мешает мне, посмотрев свежим взглядом и систематизировав предлагать бизнесу оптимизации? Не навязывать, как пытались в SAP в девяностые, а предлагать для дискуссии. Идея о том, что аналитик из какого-нибудь SAP/BAAN лучше основателя бизнеса знает, как у того должны работать процессы, кажется несколько устаревшей - сейчас заметная часть мира живет в постоянных изменениях чтобы не проиграть конкуренцию. И SAP это поняли, в рекламе новых продуктов упоминается гибкость и адаптируемость к индивидуальным особенностям конкретного бизнеса.
Я про риски не в смысле дать неправильную оценку, а в смысле неопределенных факторов влияющих на реализацию, тех проблемах, которые могут случиться, а могут и нет, от которых в значительной степени зависит вилка по ресурсам.
С другими вариантами реализациями по совокупности факторов. Предложить где-то оптимизировать безнес-процессы, но учитывать, что заказчик, если это не новый владелец, в этом всем варится и может знать какие-то факторы, делающие наши оптимизации не работающими.
Т.е. вы риски явно не учитываете, включаете интуицию?
Помню, такой подход был в моде в начале нулевых. Как раз у SAP практически девизом шла мысль: мы уже автоматизировали туеву хучу фирм и лучше всех знаем, как должны строиться бизнес-процессы. Потом, правда, по доходившим до меня слухам, оказалось, что на нашей территории их немецкие бизнес-процессы не работают... И пришлось уже "почти внедренные" системы серьезно допиливать для совмещения с реальностью.
Но и "клиент всегда прав" не работает. Предпочитаю золотую середину - клиент, вероятно, знает свой бизнес (если сам построил или много лет в деле, конечно), но не знает в автоматизацию и, вероятно, не всегда строит процессы оптимально. Мое дело выяснить смысл бизнес-процессов и предложить оптимальную реализацию.
Но для себя-то вы учитываете риски? Чтобы не переборщить с занижением или предложить дополнительное обследование-аналитику.
Например, риск того, что заказчик сам толком не знает свои бизнес-процессы и разрабатываемое ПО, после написания по ТЗ заказчика, придется долго и муторно дорабатывать напильником?