в scrum я как свинья в апельсинах, погуглил эту технологию и выяснил что она подразумевает наличие "Product Owner" человека от бизнеса который обладает компитенциями в том предмете которое внедряется.Вопрос, это означает что человек от бизнеса должен досканально знать ERP + предметные области? Те человек от бизнеса рулит всем и выступает мозгом проекта? или я не прав?

А спросить у франя стыдно что ли?

А франч по-человечьи изъясняться не соизволил?

(0) Ещё есть люди, которые не знают что такое scrum?

в классическом виде да, но так как у нас 1с-франь-внедрение-подписанные акты, то продактовнером будет самый головастый внедренец от франя. а вы не свинка, вы кура.

Слово 314159ц  для тебя что-то обозначает?

(0) не прав. продук оунер не должен знать все досканально.
Он должен знать что нужно буизнесу и в каком порядке/приоритете

(1) честно да... ожидал увидеть реацию как в (3) ну не в открытую конечно...

упд. (4) попутал овнера с мастером.

(6) те все же это человек от бизнеса?

(4) то что кура которую скоро ощипывать будут это и так понятно)))

Скрам открыл, что нужен человек от компании для определения целей проекта?

Это означает что внедрять Вам будут до тех пор, пока не закончатся деньги у компании...

(0) Беги оттуда.

(9) Не обязательно, но который говорит с бизнесом и понимает что тому нужно от продукта и как вы к этому двигаетесь.

А значит это, что будут спринты, и вы каждую неделю-две будете подписывать результаты для актов, чтобы когда они спрыгнут - вам всё пришлось оплатить. Короткие итерации - путь к успеху.

(12) или задачи от "Product Owner"

(0) Спросите у них, может все закончится на канбан-доске.

(7) Да уже Первобит всем уши прожужжал, что они по скраму работают...

(7) Автор методики SCRUM — Джефф Сазерленд, в прошлом военный лётчик, который воевал против советских людей во Вьетнаме, поливал джунгли химикатами "агент оранж"

https://tproger.ru/devnull/piece-technical-debt/
"Менеджер уходит, Скрам-мастер сдвигает сооружение, сделанное разработчиком, в угол комнаты и начинает рисовать графики."

(0) "Те человек от бизнеса рулит всем и выступает мозгом проекта? или я не прав?" - ты неправильно все понял. Читай еще раз.

(12) ну если у Вас деньги в компании нескончаемы то пока не закончатся задачи "Product Owner"....

Упс.. (21) к (15)

(14) сприны меня тоже напрягают... мне более понятно когда одна большая задача делится на менее большие , а те на еще меньше итд, а не так генерация спринов по ходу работы... (18) да это я уже тоже прочитал, но после встречи

(23) "спринты"

(0) В моей практике такие фразы от франчей означают, что сроки нереальные, и нет времени на проработку архитектуры и функциональности всего решения сразу, но программистов надо загрузить как можно раньше. И, поэтому, функционал будут сдавать кусками, поэтапно, а не весь сразу. На тестирование будете принимать не логически завершенный кусок (подсистема, или БП, или что там у вас), а то, что успеют за спринт. И потом будут ходить и говорить: "ну что, не протестировали? из-за вас сроки срываются".

(0) Вообще, примерно так:
Продакт оунер - главный ключевой пользователь, следит за формулировкой и приоритетами задач со стороны бизнеса;
РП - примерно равно бизнес-аналитик (ходит в костюме, хорош собой), тусит в основном с продакт оунером и с бизнесом; следит, чтобы команда попала в срок и в результат в конце проекта;
Скрам-мастер - примерно равно тим-лид (прыщавый парень или некрасивая девушка из ИТ); следит, чтобы команда попала в срок и в результат в конце каждого спринта (2-4 недели);
Ты - крайний за всё.

(26) Нет РП в классическом скраме :)

(27) есть :)

(19)Штука добротная, немного напоминает черного толкиниста.

(28) Значит это неправильный, нечистый скрам :))

(26) да этого и боюсь... от Продакт оунера все стартует,ошибка на его этапе (постановка) и остальное летит всё к чертям...

В результате внедрения УПП у вас есть укрупнённые и детальные схемы процессов. Можете использовать их для получения схемы "Как есть" и как Базис для модели "Как будет".

(26) Утверждение "Ты - крайний за всё." неверно, за всё отвечает команда, SCRUM предполагает коллективную отвественность.

(31) но кто-то же со стороны бизнеса должен понимать что вообще нужно.
Это и есть оунер

(0)это не 1Сник в бухгалтерии - Это бухгалтер в 1С-овской.

(0) А вам не все равно по каким методикам внедрение? Надо с исполнителя спрашивать за результат, а не за методики.

(36) Но оплата-то в процессе, а до результата еще ого-го )

(36) Для этого и сделана методика агиле

Мне, как заказчику, было бы вообще на методику положить. Внедрение должно быть законченным. Если по этапам, то каждый этап закончен. Ну и критерии законченности чтобы были однозначными. А сам процесс хоть волею Божею, хоть "сами не поняли как получилось".

(38) эджайл

(39) Так заказчику и так положить. Это исполнитель страхуется, чтоб с него не спрашивали "за результат" )

(0) срам - подразумевает что в вашей банде будет срам-мастер. Сам по себе срам-мастер не бывает без эжайла-гуру, который научит вас по стори-теллингу спринтам, фичам и прочему дерьму. Там еще есть ретроп-перспективный анал-айзинг и другие интересные игры.

(39) А зря, ибо разные технологии подразумевают разную ответственность

(43) Вау! Есть современная технология, предусматривающая ответственность???

(39) Так СКРАМ не предполагает что внедрение будет законченным, и ответа когда оно будет закончено не даст, ответ будет что вот такой то спринт будет завершен к такому то моменту и не более

(44) ХЗ, я работаю по своей, где есть и результат, и невозможность заказчика слиться с оплаты

(45) Что б тебя так врачи лечили. :) Внедрение или закончено или нет. Что значит закончено - прописывается однозначно без толкований. Все остальное развод.

(46) "невозможность заказчика слиться с оплаты" // Это обеспечивается чем-то помимо "юридической" ответственности (бумажного договора)?

Авансом 100% наверно это достигается

(49) У меня не 100% аванс ;-)

(0) Отвечаю - планирования проекта нет, бюджета проекта нет, сроков проекта нет, управления рисками перекладывается на заказчика. Методология SCRUM умными забугорными словами пудрит мозг заказчику, изображая видимость управления проектом с условиях полного хаоса.

В простонародье - собрались раз в неделю, определили приоритетные задачи (или уточнили ход имеющихся) на ближайшую неделю и пошли делать. И считаем, что проектом мы управляем.

Это конечно слишком грубое и примитивное описание, но адекватно отражающее картину.

(50) а как тогда ты не даешь слиться?

(23) Спринты полезная вещь. Один из главных элементов спринта - это обратная связь с бизнесом(заказчика).

Чем они напрягают? Если смотреть с точки зрения разбиения на более мелкие задачи, то в грубом смысле это оно и есть.

(52) Пади результат работы не передает без оплаты. Все на своих площадках сначала пилит-показывает-сдает.

(54) а тестируют как?

(53) Угу.

К пуговицам претензии есть? (с)

(55) Какие проблемы?

(51) Почему такое мнение сложилось о скраме как о методологии, которая только мешает нормальному развитию дел?

(54) Это геморрой
(52) Слитие одного этапа не слитие проекта, а так у меня нет незавершенных проектов ;-)

(58) скрам очень хорош на развитии продукта, именно продукта.
в проектной деятельности применение не очевидно

http://catalog.mista.ru/public/949714/
http://catalog.mista.ru/public/951073/

если у вас установлены сроки и зафиксирован бюджет - то по скраму вы попадете - как уже отмечалось как кур в ощип.

Скрам имхо имеет смысл внедрять если команда разработчиков внутри вашей конторы.

или когда внедрение будет делаться по принципу "ползучей автоматизации".

по большому счету как франи будут вам внедрять - абсолютно похрен. вам нужен измеримый и работающий результат.

будут делать скрамом - тогда в спринты выставлять и принимать только и исключительно законченные (мини)участки автоматизации. имеющие САМОСТОЯТЕЛЬНУЮ ЦЕННОСТЬ, которые можно УЖЕ ЭКСПЛУАТИРОВАТЬ. если спринтом что-то, что не может вами быть оценено как законченная функциональность и нельзя ее запустит в продакшен это маленький участоячтек готовой функциональности  - посылать нахрен.

как-то так
имхо

(60) Хорошо сказал, парой фраз. Именно по такому случаю применялся у меня скрам "на стадии развития продукта".
Продукт рос огромными темпами, нам нельзя было опаздывать. Делали так, как Злопчинский скинул - "сначала самокат, потом велосипед, а потом машина".

У нас уже на стадии "самокат" бизнес получал пользу и отдачу полученного решения.

(58) Она не мешает и не помогает. Она просто создает видимость, что кто-то чем-то управляет, когда все катится на самотек.

(0) Это не про "Product Owner", а в первую очередь смысл СКРАМА в разбивании процесса разработки на равные короткие промежутки времени, за которые будет что-то сделано и отдано заказчику.

(65) Прозвучало в классическом русском стиле:
"Что-то сделано"... "и отдано заказчику".

это значит что придется каждый день созваниваться отчитываться каждому участнику внедрения придется это делать - совместная конференция + часовая конференция раз в неделю.

При этом задачи обсуждаются и закладываются на целую неделю. И оцениваются. Потом через неделю другая порция задачек.

(67) Угу. Причем никто не знает, укладываемся мы в срок и бюджет, или нет. На горизонте в неделю только к концу проекта возникнут смутные подозрения, что что-то пошло не так.

(68) Быстрее

Или общие вехи никто по Скраму не проговаривает?

(70) Бессмысленно их проговаривать. Критическим путем нужно управлять.

(58) Сбербанк не признается, но они доказали неработоспособность этой методологии вне бизнес-инкубаторов.

(72) Любая теха не работает без понимания специфики ее применения

скрам для ERP, на мой взгляд сложноприменим. Как например, разработка архитектуры системы коррелирует со скрам?

Если использовать "пользовательские истории", то вы скорее всего к концу проекта получите красивые и удобные пользовательские формы и не работающую единую систему.

(74) Разработка нет, доработка внедренного-вполне

>внедрение ERP по методологии SCRUM. Что это для нас означает?

для вас это означает, что вы будете платить за процесс, а не за результат

(30) Какой есть :)

(0) а ты там кто?

(78) программист 1с со стороны заказчика, роли в проекте пока не обозначены

(0) Они не в состоянии написать ТЗ и сделать предпроектное.))
Будут на лету крылья к самолету прикручивать))))

(80) Да просто делали проект на подобном предприятии, будут пытаться на это натянуть :))

По скраму в какой момент наступает опытно промышленная эксплуатация? Когда заказчик говорит, а давайка запустимся?

(79)т.е. никто,
расслабься и займись изучением документации на учетную систему, договорись о красивых комментариях в коде и доступе к хранилищу

(82) Сначала запустим на складе приёмку, потом отгрузку...

Идеальный проект, с точки зрения денег ;-)

(82)  так же, как при любом другом внедрении
после приемо-сдаточных испытания

А потом для расчета себестоимости надо все ключи заново переформировать  и нзп закрыть, и еще на 1,5 года

(86) Я там тебе отписался в личку

(85) отнюдь
через месяц скрам-мастер оказывается крайним, нет очередного бэклога и очередной спрайт за его счет

(87) Внедренцы уже будут окучивать следующую жертву, а с ключами благодарные пользователи заставят заниматься топискстартера.

(89) ТОгда взяли не скрам мастера, а скрам джуниора ;-)

(89) Смотря как составлен договор и как все протоколируется.
Текущий проект, не ERP, мы могли закрыть еще в августе, был готов по функционалу, но заказчик постоянно хочет рюшечки, а рюшечки, не оговоренные на этапе ТЗ - платные.
И вот уже который спринт - украшательства.

(88) а домен какой почтовый ?
у меня тишина =)

(91) скам-мастер

(92) ТЗ на внедрение ERP требует полного обследования и со скрамом не дружит

(95) Согласен. Но у нас не ЕРП.
А из заказчика креакл так и прет.

(93) front

(89) Скрам-мастер должен фасилитировать, а не бэклог заполнять :))

(97) list, посмотри почту от 29.08 + КП нужно выслать Костег-у, а не мне =)

(98) в пофиг чем он будет заполнять бэклог, ТЗ нет, обследования нет, ФТ ЦФО противоречат друг другу и унаследованным данным

(99) Отписал ;-)

(101) ОК =)
знатно початились

Когда мы не в состоянии охватить проект целиком, то делаем его маленькими шажками, в надежде, что к чему-нибудь придем. А если не придем - ничего страшного, бабло всё равно получаем по этапам.
Это и есть скрам?

(103) Не...

(104) Та не, всё верно :)

(105) Слишком просто, на этом методологии не построишь.

(106) А речь и не о постройке методологии. Скрамы-аджайлы вообще не очень-то к проектам внедрения применимы, зато для получения бабла за процесс подходят как ничто другое.

(107) Не... без методологии бабла не дадут.

(103) Да, оно самое :)

(108) "Нельзя недооценивать предсказуемость тупизны" ©

Судя по всему, заказчик сам толком не понимает, чего хочет, а при таком подходе внедрятору гораздо удобнее доить заказчика "спринтами", чем по полгода с методистом наводить порядок в бизнес-процессах.

http://scrumblackbook.pmlead.ru/ScrumBlackBook.pdf

ой, уже было)

(0) теперь ваш п.здец по проекту будет твориться по этой методологии.

теперь вместо того что-бы орать что у вас бардак на проекте, будете кричать - у нас аджайл!

(110) так наведение порядка тоже может быть спринтом.
не где не сказано. что спринт - это ндцать строк кода

Раньше говорили - что нужен сильный РП со  стороны бизнеса, теперь говорят что нужен скрам мастер.
по сути ничего не поменялось

(116) Чего только не скажут, лишь бы самим не работать и только откаты пилить да вопросики обкашливать.

(117) но это никак не отменяет необходимость грамотного рп со стороны заказчика.
это же практически 80% успеха

Какой ужас

(118) Не бывает никакого "РП со стороны заказчика". У корабля один капитан, у проекта один руководитель. Со стороны заказчика могут быть координатор проекта, член команды проекта, эксперт и т.п. "функционалы". Но у проекта всегда один руководитель.

(120) В твоих терминах-координатор

(121) В терминах PMI, а не в моих :)

(0) Прикольно у вас там))). У нас проще будет. Первоначально сделаем цикл производства, пару месяцев учет в двух базах УПП и ЕРП, потом переход на типовой ЕРП, а потом уже доработку под нашу специфику.

(120) скрум называет такого человека от заказчика "продукт овнер"

(124) Думаю что не совсем. Скорее Product Owner ближе к спонсору проекта в PMI. Т.е. это функционер, отвечающий за реализацию бизнес-результатов проекта.

(125) спонсор и куратор - это же одно и тоже
https://pmpractice.ru/knowledgebase/managment/keypoints/participants/

(125) Спонсор - это владелец бюджета, проектом этот человек не управляет.

(127) На грабли аналогий наступали многие люди :) Казалось бы бытовое определение спонсора можно расширить и на проектный менеджмент, ан нет - тут нас ждем множество рифов.

Спонсор — лицо, предоставляющее ресурсы и поддержку для проекта и ответственное за достижение успеха. Спонсор содействует проекту от первоначальной концепции до его закрытия. Спонсор возглавляет проект на
протяжении процессов инициации до получения формальной авторизации и играет важную роль в разработке
первоначального содержания и устава. Спонсор может участвовать в одобрении изменений в содержании проекта, проведении анализа после окончания фазы и принятие решений «продолжить/прекратить» в случае выхода рисков за рамки. Спонсор обеспечивает плавный переход поставляемых результатов проекта в сферу деятельности организации заказчика после закрытия проекта.

Грубо говоря спонсор - это тот, кому позарез необходимо успешное завершение проекта. И это обычно не заказчик, хотя они могут быть в одном лице (или даже группе лиц).

(126) Я не говорил о кураторе. Я говорил о координаторе.

вот еще http://catalog.mista.ru/public/951098/
внутри статьи - ссылки на полезные материалы.

(68)как не узнает то? вы же каждый день проводите онлайн планерку и если кто из участником провалился, сразу это становится ясно. Плюс нужно отслеживать как продвигается выполнение задач взятых на неделю у каждого участника.

(128) Как сертифицированный PMP я какбе немного в курсе за терминологию PMBoK.
Спонсор - это в конечном случае владелец бюджета.