Десятина — это 10%. Налоги: НДФЛ — 19.5 %. ЕСВ — 22%. Военный сбор 1.5%. С каждого товара и услуги — 20% НДС. Ещё есть налоги на: недвижимость, акцизные товары включая топливо и т.д. И да — кто такие корупционеры?

присвойте переменной с типом List переменную типа List

Не может быть, поддержку односвязных списков ввели в синтаксис! Я где то слышал что в LISP-е так тоже можно ru.wikipedia.org/wiki/Лисп :) Наверное у Scala подсмотрели. Groovy тоже видимо ворует идеи docs.groovy-lang.org/...​ing-with-collections.html И Haskell www.haskell.org/tutorial/goodies.html

Он ничего не потеряет, если продукт провалится в продажах по какой-либо причине.

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

Так ведь специальный человек есть — Scrum master «хозяин толкучки» o_O.

Первое. Никто индивидуально тикетов не «закрывает». User story — пишут, уточняют требования, оценивают, разрабатывают, тестируют, разворачивают и т.д. конкретный флоу зависит от команды и проекта. Посему каждая тикет это результат командной работы. Аналогично как в футболе, бейсболе, волейболе и прочих командных видах спорта. Вся команда или выигрывает или проигрывает — и никому не интересно если «Роналду» забил гол при счёте в 1-10. Второе — планирование как раз и применяется чтобы знать какие задачи будут в спине. Скарам как раз и запрещает (в теории по крайней мере) изменять список задач в спринте. Если стало ясно что то что делается в спринт — вдруг больше не нужно — спринт досрочно закрывается и начинается новый.

Ну это в том числе и означает — что если коллега застрял над чем то в ходе спринта — то команда ему поможет, а не станет потирать руки радуюсь что у кого то случилось горе.

Что вы несёте ? В скраме как не где персональная ответственность за зделанное — причем как сделанное лично, так и результат работы команды в целом. Более того скрам стимулирует от команды достижение результатов.

«Автоматически» — это вы о процессе по которому работают люди. Тут нет автоматики. Работать начнет — но это будет стоить существенных усилий и нервов. Далеко не все захотят в самом деле работать по такому процессу, не все захотят смирится с фактом что проект скорее всего займет существенно больший срок и бюджет чем планировалось. Что придется отказаться от части функциональности, придется ставить приоритеты, и нельзя будет ставить всему максимальный приоритет и т.д. В общем нет пока процессов организации труда которые работают сами по себе.

Выполнять процедуры так же как и на тренингах. Ввести DoD, DoR, создать список пользователей системы и шаблоны пользовательских историй. Не брать неподготовленные (не отвечающие DoR и DoD критериям) user story в спринт. Ввести planing и estimation poker либо на всю команду если она без специализации (например frontend, backend) либо 3Amigo. Вести статистику, вычислять Velocity и Capacity, не брать в спринт работы больше чем физически можно выполнить. Проводить daily stand up не по тикетам — а по людям, где каждый отвечает на три вопроса — что он делал, что сделал и что будет делать. Следить за временем — максимум 4-ре минуты, останавливать если обсуждение идёт слишком долго и созывать 3Amigo по прицендентам. Проводить ретроспективы, записывать action point-ы и назначать ответственных за их исполнение. По идее все. Из практики: ещё на DoD, DoR и планингах — где вы говорите «нет эта история не определена и мы ее не можем оценить» или «вот эти истории в спринт взять не можем, потому что физически не сможем закончить такой спринт» — вот тут вы и увидите как заказчик «не против».

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

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

Это все про engagement (вовлечённость). Разного рода исследователями замечено — если людям нравится то что они делают то работают с результатом намного выше среднего — что крайне позитивно влияет на прибыль компании. Правда совсем не обязательно сотрудников :)

С Носа Дуа можно работать и удаленно. Проверено на практике ещё до карантина, когда надо было одного нашего тестировщика срочно вернуть из отпуска. Две недели фигачил по удалёнке.

Не однаразово чув від HR-рів що клієнта знайти важче ніж співробітника, куме.

Scrum Master — конечно видит работающий

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

Да всё понятно же стало — все будет хаджуме !

Вы в другом топике кажется писали про приход к компании «пушного зверя» если у нее начались проблемы с финансами ? Чем проект в этом случае отличается ?

scrumguides.org/...​-guide.html#product-owner The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. — ключевое is accountable — подотчетный. Смотрим толковый словарь — slovar.cc/rus/tolk/82317.html
1. Выдаваемый с условием последующего отчета о расходовании ( о деньгах ) .
2.Обязанный отчитываться ( в своей работе, действиях, расходовании средств и т.п. )

Надеюсь убедил, Product Owner — в Scrum человек прямо ответственный за финансирование. Если в каком то проекте — это не так, значит роли в нем определены не правильно. Скорее всего там и вообще Fragile со «спиралью». О чем и все статья.

а финансы тут при чем??

«Хліб усьому голова». Возможно вы опишите как можно отвечать за достижение целей проекта (согласно PM Book временного мероприятия для достижения результата) — не имея рычагов управления? Если цели проекта — это продукт, вот вам и ответ кто принимает решения в процессе. Даже при строительстве Беламор-каналла или Колизея — зеков и рабов кормить нужно было, аналогично организовывать конвоиров и надзирателей. Не считая логистики с производством и доставкой строй материалов и всего необходимого. Так что все намного проще чем кажется «No money, no honey», и просто из практики — до того как подключается человек принимающий финансовые решения никакие вопросы не решаются. Scrum Muster — вообще другие вопросы призван решить в гибком процессе, а конкретно посредник балансирующий интересы сторон (Свиней и Куриц), известную проблему продавца и покупателя — " Покупать — дорого, продавать — дешево". Это осуществляется через введение процесса — т.е. рядя стандартных процедур (практик). Как то — постановка целей, оценка сложностей и объемов работ, выявление и управление рисков , контроль исполнения и т.д. Скрам мастер следит чтобы все процессы применялись и исполнялись.

Product Owner — он и есть лицо финансово отвечающее за проект и достижение им целей. Тоесть управляющий — manager. Реально такой человек (лицо принимающее решение) есть всегда. В общем — кто платит тот и главный как обычно. Есть правда ситуации когда в команде есть — Product Owner — но это на поверку бизнес аналист, контрагент и т.п. — тоесть человек который никаких финансовых вопросов полномочий решать не имеет. Тогда как настоящий менеджер — якобы «супервайзит».