Прелесть микротиков в том, что они могут много за небольшие деньги. Плата за это — та самая необычность.
Как раз с этим не согласен.
По цене: MikroTik hAP lite 3300р (но раньше вроде бы подешевле был, в районе 2тр), Keenetic Lite 2400р.
По функционалу: понятно, что Keenetic попроще вроде бы, но очень много вещей быстрым накликиванием делается, а если не хватит вдруг (мне в Keenetic не хватает только кастомных записей в DNS), то можно поставить последний openwrt (еще не пробовал).
Возможно, на уровне организаций в MikroTik есть смысл, для дома никакого смысла нет.
Гляньте на unraid, как решение «из коробки» он мне очень понравился.
Да, смотрел. Отказался от него из-за этого видео: оно красиво на сайте, но на практике мне все же хотелось бы CasaOS, но только работающую.
Админить не обязательно с винды, есть веб-интерфейс и консоль.
У меня иногда слетали все доступы, а выделенного management интерфейса там нет. Давайте по чесноку: вы используете WinBox, когда делаете новые настройки, или исключительно веб-интерфейс/консоль?
А брать микротик для openwrt нет никакого смысла.
Согласен, это я уже просто не знаю что с ним делать.
Да, пробовал. В установке с мониторингом и распределенным хранилищем вентиляторы крутятся постоянно даже без полезной нагрузки (вроде бы и без этого проверял и все равно крутились -- детали про это есть у меня в видео). Из-за этого отказался от кубера дома.
Изначально думал, что тихие машинки подойдут, но по опыту эксплуатации ZyXEL NAS326 (там тоже тихий вентилятор) понял, что уже не могу с тихими, нужны именно бесшумные. Просто личное предпочтение.
В последнее время, когда можно оказаться внезапно релоцировавшимся, держать дома основной сервер... А что если домой не получится попасть в ближайшие полгода. А с собой забрать то, что можно взять с собой. У тут сервер где-то "там" и развернутым таким же облаком выручит
У меня был такой опыт, когда это еще не стало популярным). U59 реально маленький и довольно легкий -- я 3 штуки одной рукой беру, поэтому я бы их взял (в отличие от свичей/роутеров/больших проводов -- проще новые купить). Плюс, полгода -- не проблема, оно все нормально может работать.
Отдельно скажу, что при концепции DropBox и гит центральный сервер нужен, но не принципиален -- практически все данные есть на множестве клиентов. Если что, то на новом месте можно еще одну похожу машинку купить и перенастроить клиентов на этот новый сервер.
Да, сам по себе Raspberry pi 4 8G норм, у него проблема в цене. Просто сейчас машинки Beelink есть по <7тр со склада в России (т.е. быстрая и беспроблемная доставка) и по возможностям лучше. Там даже если надоест, то обратно ставишь Windows и отдаешь/продаешь.
3 проблемы почему в итоге не стал покупать Synology (от важного к менее важному):
Прочитал, что они не бесшумные. Мне нормально, если оно какое-то количество времени будет шуметь, но не постоянно. Изначально у меня такого требования не было, но потом понял, что некомфортно.
Сомневаюсь, что одной машинки хватит на домашние задачи + Gitea/Drone/SonarQube/Docker registry/...
Это не Open Source решение: вроде бы ушли от облачной зависимости, но, получается, как-то не до конца. Это не сильно критично, но все же.
Да, все облачные системы говорят, что хранят ваши данные зашифрованными
Я чаще видел, что данные при передаче шифруются. Особо не замечал, чтобы они говорили, что данные в зашифрованном виде лежат, хотя может и так.
А на внешние облака можно выгружать бэкапы в виде зашифрованных контейнеров
Да, облака в качестве стандартных услуг (типа S3 API, которое практически у всех доступно) вполне имеет смысл использовать. Тем более для бекапов это весьма дешево.
Что касается личного облака, я уже переделал два NAS Techus N4200, но пока так и не нашёл альтернативу с удобством того же DropBox. Если у кого есть мысли - пишите в ответе.
Может быть у меня требования ниже, но есть довольно много аналогов в которых тоже ставятся клиенты для синхронизации и есть мобильные клиенты -- SyncThing, NextCloud, Seafile, ... . Вот вопрос на ту же тему на Хабре с более подробными ответами -- https://qna.habr.com/q/440713
У меня базовые потребности к офису: что-то иногда делаю, но довольно простые таблички с обычными формулами, поэтому наверняка хватит. Если, вдруг, что-то сложное, то потенциально есть возможность использовать десктопные приложения.
Предполагается давать доступ не только себе, но и всей семье (свои папки, возможность шарить папки и расписания).
В общем, жить в обществе и быть независимым от общества - невозможно
Для меня облака -- это тупиковая ветвь развития, как и экономика аренды в целом. Раньше их не было и еще остались десктопные приложения. В будущем, скорее всего, массово не будет, т.к. и люди, и компании потихоньку осознают опасность и дороговизну аренды.
p.s. я недавно задумался, не поднять ли мне сервер свой, чтобы не платить за аренду чужого.... НО вопрос в стабильности и пропускной способности (а также постоянном айпи). Ну и настраивать надо
IP покупается у провайдера, у меня 50р/мес стоит, в личном кабинете сделал. По стабильности и пропускной способности: я подключался из заграницы домой по vpn и шло довольно много трафика -- никаких проблем не было, поэтому тут вполне уверен (конечно, зависит от вашего конкретного провайдера, но, скорее всего, проблем не будет). По поводу настраивать -- да, сейчас самое простое -- это купить NAS какой-нить дорогой -- там и NextCloud будет, и контейнеры можно запускать.
Да, смотрел, но в NextCloud этот функционал уже есть (и больше -- то же редактирование документов в вебе). Поэтому для простоты поддержки остановился на NextCloud пока что.
Там есть облачный редактор: https://nextcloud.com/office/ . На первый взгляд нормально работает, большого опыта пока что нет.
Все-таки основное -- это отсутствие зависимости от облачных провайдеров (когда это есть можно уже и стоимость сравнивать). Не хочется зависеть ни от Гугла, ни от МейлРу, т.к. как только эта зависимость становится более-менее сильной, то и стоимость резко вверх пойдет. Да и вообще начинают слишком много контролировать.
Про цену -- это скорее то, что домашнее облако не дороже, чем публичное в итоге.
Однако размышляя над теми же напряжениями скрама я в итоге пришел чуть к иным аспектам: - скрам мастер может быть, если нужен, но может и не быть если не нужен. может быть как full time роль или part time? как внешний или внутренний игрок? руководитель или зам или кто то из верхней команды если мы говорим про молекулярные команды на 100 чел? или внешний консультант если мы говорим про атомарные команды 5-10 чел.
- еще интересно провести аналогии с Канбан - где есть деливери менеджеры - отвечающие за снятие блокеров и помех на пути доставки ценности. на мой взгляд очень созвучно со скрам мастером. в этом случае роль конечно должна быть полноценная.
Если есть Скрам (т.е. в частности нет начальников отделов), то непонятно как получается без скрам-мастера: на основные события может он и не особо нужен, но проводить 1-1 и справляться с блокерами и другими конфликтами кто-то должен. Понятно, бывает, что один из разработчиков на себя это берет (и выполняет роль скрам-мастера, может быть даже не зная этого слова). Только это не системный подход: команда может "неожиданно" начать хуже работать, когда такой разработчик уйдет в другую команду или просто устанет выполнять дополнительную роль.
Работая с 20+ командами, я пришел к выводу что в этом мире не все всегда и везде, а кое что иногда и местами.
Согласен, что тут мы про теорию, а на практике по самым разным причинам разные вещи могут отличаться.
Например его аналог Социократия S3 - опенсорсная, сильно понятней для меня, но не так популярна потому что не так сильно рекламируется.
AM -- это определение термина Agile. Ни больше, ни меньше. Никаких книг определение не заменяет.
Agile -- это зонтичный бренд, а не какая-то конкретная методология, поэтому непосредственно Agile вообще не может быть применен. Можно только говорить является ли методология А Agile или нет.
По сути мы с вами говорим об одном и том же. Только само понятие (концепт) вам не нравится. Мне же кажется, что имеет смысл его растолковывать, если уж оно до сих пор употребляется.
Agile Manifesto был опубликован в 2001, в то время как гибкие методологии управления проектами уже существовали и применялись задолго до (тот же DSDM появился в 1994 году).
Тут вы полностью правы. В 2001 году появился зонтичный бренд Agile для уже существовавших методик. Как любой бренд они отстраивались от "классических" методов.
Похоже, Дядя Боб хорошо чувствовал запросы со стороны индустрии и был мастером трындетьформулировать ответы звучными тезисами (другое аналогичное творение с его участием это пресловутый SOLID).
И тут правы -- манифест крайне тяжело понимается.
Но воспринимать все это на серьезных щщах, искать какой-то сакральный смысл, фреймворк или руководство к действию - реально большая глупость.
Есть термин Agile. Судя по этому предложению для вас он ничего не обозначает. Я же предпринял попытку проинтерпретировать исходный манифест, чтобы было понятно о чем говорят люди. То, что они ни о чем не говорят -- не согласен. Идеально, если после прочтения статьи об Agile останется выжимка примерно как первый комментарий к этой статье. Остальное лишь пояснение как к этому пришли.
По вовлеченности: попробуйте сделать дома ремонт и не вникать в детали. В принципе, такое возможно, но тогда нужно нанимать отдельных людей, которые будут вникать. Конкретно в Скраме это все скрывается через абстракцию Владельца продукта и его команду (не путать со скрам-командой).
По мотивации: как раз про это и есть значительная часть Скрама. Ровно для этого выделяется скрам-мастер.
По ответственности: вы опять хотите назначить 1 ответственного человека за все. Так не работает Скрам. У скрам-мастера, команды и владельца продукта у каждого есть свои зоны ответственности. И это одна из основных проблем Скрама (что часто люди так или иначе все равно пытаются выделить 1 человека ответственного за все). Конкретно владелец продукта отвечает за приоритизацию задач (из всего массива были выбраны самые важные и достаточно мелкий, чтобы не тянули в себе неважные подзадачи). Откуда берутся задачи (анализ рынков, процессов и тп) -- это за пределами Скрама (или может быть отдельная скрам или не скрам команда аналитиков, например).
Я ни в коем разе не утверждаю, что Agile и/или Скрам справились с возложенной на них задачей. Я лишь утверждаю, что классические методологии не справились (и из-за этого появились популярные альтернативы). В частности, PMI чаще не работает, чем работает (и его сложность -- это его проблема, не нужно тут вдруг сущность людей отдельно рассматривать).
Что и как внедрять в конкретном случае -- даже чтобы это определить нужен не один день. Это вполне себе полноценная работа. Тут призываю как раз проводить довольно широкий анализ и рассматривать максимум доступных инструментов.
Тут мы говорим про то как формируются принципы Agile. Это не значит, что Agile применим для всего. Более того не значит, что Agile в итоге лучше традиционных методов. Это означает, что Agile мы начинаем с чистого листа (например, 16 страниц Скрам вместо огромной книги). И по необходимости что-то добавляем, но помня, что в целом PMBoK приводит к провалу проектов.
Если в каком-то случае PMBoK работает лучше Agile, то лучше его использовать, т.к. он позволяет гораздо легче подписывать контракты.
Да, я даже слово Скрам не использовал. Просто это часто используется совместно со Скрамом.
Никаких обязательств по срокам и бюджету команда не берет.
Команда берет обязательства на 1 спринт. На весь проект не берет.
Я бы это выразил по другому - в PMI или Prince2 есть (хотя и не всегда) обязательства по срокам - бюджету - объему работ. Есть инструменты контроля, есть способы коррекции. В Скраме может быть лимит бюджета, может не быть - Скраму всё равно, он никак не контролирует.
Мы тут забываем одну вещь: если бы PMI давал результат, то Agile движение не появилось бы вообще. Другими словами, из статистики мы знаем, что все эти инструменты, которые есть в классических методах в итоге не работают.
Я собственно поэтому и не считаю его методом управления проектом, что в нем нет очень многих инструментов, нужных для проекта. Ничего нет о предпроектной активности (анализ и выбор по фин показателям, сбор и анализ требований), нет планирования кроме как "на лету" на ближайший спринт, и очень очень грубо дальше, нет инструментов корреции по срокам, нет управление рисками (кроме опять таки все того же backlog refinement), нет управления стоимостью. Да можно просто открыть PMBoK и читать по главам - по сути кроме части процессов исполнения - ничего больше и нет.
Тут полностью согласен, но немного под другим углом. Абсолютно понятно, что 16 страниц Scrum не заменяют PMBoK. Это просто невозможно по размеру текстов. Но я на это смотрю как Angular (PMBoK) vs React (Scrum): да, он меньше, но под конкретные условия можно подобрать (написать) дополнительные инструкции. Понятно, что Scrumу присущи уникальные преимущества из-за которых его вообще рассматривают, но не об этом сейчас.
Только очень грубые оценки по burndown чартам, основываясь на эмпирическом замере velocity (термин "мощность" тут ближе всего, но большинство считает что это скорость, так что сорри за англицизм). И эта самая велосити нифига не прогнозируема
В Скраме нет определения как делать оценки. Хотите применяйте этот метод, хотите другой. Тут уже и так много текста, не буду про разные способы оценок -- про это есть отдельные книги.
Так вы по сути уже нарушили основные принципы Скрама - постоянные инспекция и адаптация. Какая же здесь адаптация? Мы занимаемся самоуспокоением - ну мы же работаем инкременты деливерим, если заказчик их не может или не хочет смотреть - его проблема. От нас пули улетели.
Ну, не совсем нарушил -- я как раз предлагал это делать внутри, даже если не удалось объяснить заказчику ценность. Понятно, что ситуация не идеальная, но это жизнь.
РО - единственный, кто отвечает за ценность продукта. Если это человек со стороны заказчика, значит очень повезло. Если с вашей стороны - он должен быть полностью погружен в бизнес заказчика, мне кажется.
В целом, хороший скрам-мастер будет и свою команду на это настраивать, но да, PO нужен и важен. От него скорее требуется не столько какие-то специальные навыки, сколько высокая заинтересованность в продукте и готовность на это тратить время. Я работал и по обычным контрактам, в успешных проектах это и там важнейший фактор. Просто в Scrum об этом говорится открыто и подчеркивается такая необходимость.
Не соглашусь, в классических подходах есть инструменты удержания проекта внутри треугольника. В Скраме нет. Я вот не совсем понял мысль про фиксацию времени и стоимости в Agile - это как и где, поясните? Каким образом Скрам контролирует попадание в дедлайны и бюджет? ... И эта самая велосити нифига не прогнозируема, и в Скраме нет никаких инструментов коррекции если понятно что не укладываемся. Переприоритизация элементов бэклога это в данном случае эрзац, а не инструмент коррекции.
Обычно Agile-контракт (внешний или внутренний) подписывают на время (дату), сумму и команду, описывают качество как в обычном проекте, функционал по разному (описывают больше или меньше), но на него не комитятся. Из-за этого опять же обычно так работают только внутренние команды. Если контракт внешний agile, то его чаще всего подписывают как обычно, но делают рамочным (опять же фиксируется дата окончания и сумма, а ТЗ/заказы выдаются помесячно). В любом случае, это уже получше, т.к. объем оцениваемых задач ниже и максимальная возможная ошибка пониже. Бывают и совсем обычные контракты, тогда уж использовать Скрам или нет -- отдельный вопрос, тут нужен внутренний продвинутый владелец продукта, чтобы все приемы классических подходов в себе абстрагировать.
То, что нет многого -- очевидно. Весь вопрос мешает ли Скрам классическим инструментам -- если нет, то вообще проблемы нет.
Основная мысль про фиксацию возвращает нас к пирамидке. Аксиома: чаще всего с применением всех классических и неклассических подходов в нее уложиться не получается (есть какая-то американская статистика по проектам и у каждого собственный опыт). Тогда нужно что-то двигать (описал ранее как обычно двигают). В Agile у нас такой порядок работ, чтобы все самое критичное было сделано сразу же (и как только что-то становится более критичным, сразу же этим и занимаемся, поэтому спринты по неделе -- длина спринтов зависит от необходимой скорости изменения задач). Т.е. мы останавливаемся там до куда успеваем, но не успели мы самые незначительные вещи. После этого уже заказчик смотрит что делать: устраивает его так или делаем новый этап (сразу или через какое-то время).
Как раз с этим не согласен.
По цене: MikroTik hAP lite 3300р (но раньше вроде бы подешевле был, в районе 2тр), Keenetic Lite 2400р.
По функционалу: понятно, что Keenetic попроще вроде бы, но очень много вещей быстрым накликиванием делается, а если не хватит вдруг (мне в Keenetic не хватает только кастомных записей в DNS), то можно поставить последний openwrt (еще не пробовал).
Возможно, на уровне организаций в MikroTik есть смысл, для дома никакого смысла нет.
Да, смотрел. Отказался от него из-за этого видео: оно красиво на сайте, но на практике мне все же хотелось бы CasaOS, но только работающую.
У меня иногда слетали все доступы, а выделенного management интерфейса там нет. Давайте по чесноку: вы используете WinBox, когда делаете новые настройки, или исключительно веб-интерфейс/консоль?
Согласен, это я уже просто не знаю что с ним делать.
Да, пробовал. В установке с мониторингом и распределенным хранилищем вентиляторы крутятся постоянно даже без полезной нагрузки (вроде бы и без этого проверял и все равно крутились -- детали про это есть у меня в видео). Из-за этого отказался от кубера дома.
Изначально думал, что тихие машинки подойдут, но по опыту эксплуатации ZyXEL NAS326 (там тоже тихий вентилятор) понял, что уже не могу с тихими, нужны именно бесшумные. Просто личное предпочтение.
У меня был такой опыт, когда это еще не стало популярным). U59 реально маленький и довольно легкий -- я 3 штуки одной рукой беру, поэтому я бы их взял (в отличие от свичей/роутеров/больших проводов -- проще новые купить). Плюс, полгода -- не проблема, оно все нормально может работать.
Отдельно скажу, что при концепции DropBox и гит центральный сервер нужен, но не принципиален -- практически все данные есть на множестве клиентов. Если что, то на новом месте можно еще одну похожу машинку купить и перенастроить клиентов на этот новый сервер.
Да, сам по себе Raspberry pi 4 8G норм, у него проблема в цене. Просто сейчас машинки Beelink есть по <7тр со склада в России (т.е. быстрая и беспроблемная доставка) и по возможностям лучше. Там даже если надоест, то обратно ставишь Windows и отдаешь/продаешь.
3 проблемы почему в итоге не стал покупать Synology (от важного к менее важному):
Прочитал, что они не бесшумные. Мне нормально, если оно какое-то количество времени будет шуметь, но не постоянно. Изначально у меня такого требования не было, но потом понял, что некомфортно.
Сомневаюсь, что одной машинки хватит на домашние задачи + Gitea/Drone/SonarQube/Docker registry/...
Это не Open Source решение: вроде бы ушли от облачной зависимости, но, получается, как-то не до конца. Это не сильно критично, но все же.
Я чаще видел, что данные при передаче шифруются. Особо не замечал, чтобы они говорили, что данные в зашифрованном виде лежат, хотя может и так.
Да, облака в качестве стандартных услуг (типа S3 API, которое практически у всех доступно) вполне имеет смысл использовать. Тем более для бекапов это весьма дешево.
Может быть у меня требования ниже, но есть довольно много аналогов в которых тоже ставятся клиенты для синхронизации и есть мобильные клиенты -- SyncThing, NextCloud, Seafile, ... . Вот вопрос на ту же тему на Хабре с более подробными ответами -- https://qna.habr.com/q/440713
У меня базовые потребности к офису: что-то иногда делаю, но довольно простые таблички с обычными формулами, поэтому наверняка хватит. Если, вдруг, что-то сложное, то потенциально есть возможность использовать десктопные приложения.
Предполагается давать доступ не только себе, но и всей семье (свои папки, возможность шарить папки и расписания).
Для меня облака -- это тупиковая ветвь развития, как и экономика аренды в целом. Раньше их не было и еще остались десктопные приложения. В будущем, скорее всего, массово не будет, т.к. и люди, и компании потихоньку осознают опасность и дороговизну аренды.
IP покупается у провайдера, у меня 50р/мес стоит, в личном кабинете сделал. По стабильности и пропускной способности: я подключался из заграницы домой по vpn и шло довольно много трафика -- никаких проблем не было, поэтому тут вполне уверен (конечно, зависит от вашего конкретного провайдера, но, скорее всего, проблем не будет). По поводу настраивать -- да, сейчас самое простое -- это купить NAS какой-нить дорогой -- там и NextCloud будет, и контейнеры можно запускать.
Да, смотрел, но в NextCloud этот функционал уже есть (и больше -- то же редактирование документов в вебе). Поэтому для простоты поддержки остановился на NextCloud пока что.
Про серверные стойки -- согласен. У меня, в итоге, скорее всего, будет 2 U59: один для домашних нужд, а второй для хобби (гит и все его cicd друзья).
Я так понял, что NextCloud -- это более популярный форк Owncloud, поэтому подробно не смотрел. Гляну, может действительно то, что нужно.
Там есть облачный редактор: https://nextcloud.com/office/ . На первый взгляд нормально работает, большого опыта пока что нет.
Все-таки основное -- это отсутствие зависимости от облачных провайдеров (когда это есть можно уже и стоимость сравнивать). Не хочется зависеть ни от Гугла, ни от МейлРу, т.к. как только эта зависимость становится более-менее сильной, то и стоимость резко вверх пойдет. Да и вообще начинают слишком много контролировать.
Про цену -- это скорее то, что домашнее облако не дороже, чем публичное в итоге.
Рад, что было интересно).
Если есть Скрам (т.е. в частности нет начальников отделов), то непонятно как получается без скрам-мастера: на основные события может он и не особо нужен, но проводить 1-1 и справляться с блокерами и другими конфликтами кто-то должен. Понятно, бывает, что один из разработчиков на себя это берет (и выполняет роль скрам-мастера, может быть даже не зная этого слова). Только это не системный подход: команда может "неожиданно" начать хуже работать, когда такой разработчик уйдет в другую команду или просто устанет выполнять дополнительную роль.
Согласен, что тут мы про теорию, а на практике по самым разным причинам разные вещи могут отличаться.
Спасибо, как-то это прошло мимо меня, почитаю.
AM -- это определение термина Agile. Ни больше, ни меньше. Никаких книг определение не заменяет.
Agile -- это зонтичный бренд, а не какая-то конкретная методология, поэтому непосредственно Agile вообще не может быть применен. Можно только говорить является ли методология А Agile или нет.
По сути мы с вами говорим об одном и том же. Только само понятие (концепт) вам не нравится. Мне же кажется, что имеет смысл его растолковывать, если уж оно до сих пор употребляется.
Тут вы полностью правы. В 2001 году появился зонтичный бренд Agile для уже существовавших методик. Как любой бренд они отстраивались от "классических" методов.
И тут правы -- манифест крайне тяжело понимается.
Есть термин Agile. Судя по этому предложению для вас он ничего не обозначает. Я же предпринял попытку проинтерпретировать исходный манифест, чтобы было понятно о чем говорят люди. То, что они ни о чем не говорят -- не согласен. Идеально, если после прочтения статьи об Agile останется выжимка примерно как первый комментарий к этой статье. Остальное лишь пояснение как к этому пришли.
По вовлеченности: попробуйте сделать дома ремонт и не вникать в детали. В принципе, такое возможно, но тогда нужно нанимать отдельных людей, которые будут вникать. Конкретно в Скраме это все скрывается через абстракцию Владельца продукта и его команду (не путать со скрам-командой).
По мотивации: как раз про это и есть значительная часть Скрама. Ровно для этого выделяется скрам-мастер.
По ответственности: вы опять хотите назначить 1 ответственного человека за все. Так не работает Скрам. У скрам-мастера, команды и владельца продукта у каждого есть свои зоны ответственности. И это одна из основных проблем Скрама (что часто люди так или иначе все равно пытаются выделить 1 человека ответственного за все). Конкретно владелец продукта отвечает за приоритизацию задач (из всего массива были выбраны самые важные и достаточно мелкий, чтобы не тянули в себе неважные подзадачи). Откуда берутся задачи (анализ рынков, процессов и тп) -- это за пределами Скрама (или может быть отдельная скрам или не скрам команда аналитиков, например).
Я ни в коем разе не утверждаю, что Agile и/или Скрам справились с возложенной на них задачей. Я лишь утверждаю, что классические методологии не справились (и из-за этого появились популярные альтернативы). В частности, PMI чаще не работает, чем работает (и его сложность -- это его проблема, не нужно тут вдруг сущность людей отдельно рассматривать).
Что и как внедрять в конкретном случае -- даже чтобы это определить нужен не один день. Это вполне себе полноценная работа. Тут призываю как раз проводить довольно широкий анализ и рассматривать максимум доступных инструментов.
Тут мы говорим про то как формируются принципы Agile. Это не значит, что Agile применим для всего. Более того не значит, что Agile в итоге лучше традиционных методов. Это означает, что Agile мы начинаем с чистого листа (например, 16 страниц Скрам вместо огромной книги). И по необходимости что-то добавляем, но помня, что в целом PMBoK приводит к провалу проектов.
Если в каком-то случае PMBoK работает лучше Agile, то лучше его использовать, т.к. он позволяет гораздо легче подписывать контракты.
Да, я даже слово Скрам не использовал. Просто это часто используется совместно со Скрамом.
Команда берет обязательства на 1 спринт. На весь проект не берет.
Мы тут забываем одну вещь: если бы PMI давал результат, то Agile движение не появилось бы вообще. Другими словами, из статистики мы знаем, что все эти инструменты, которые есть в классических методах в итоге не работают.
Постарался раскрыть эту мысль в отдельной статье: https://habr.com/ru/post/691800/
Тут полностью согласен, но немного под другим углом. Абсолютно понятно, что 16 страниц Scrum не заменяют PMBoK. Это просто невозможно по размеру текстов. Но я на это смотрю как Angular (PMBoK) vs React (Scrum): да, он меньше, но под конкретные условия можно подобрать (написать) дополнительные инструкции. Понятно, что Scrumу присущи уникальные преимущества из-за которых его вообще рассматривают, но не об этом сейчас.
В Скраме нет определения как делать оценки. Хотите применяйте этот метод, хотите другой. Тут уже и так много текста, не буду про разные способы оценок -- про это есть отдельные книги.
Ну, не совсем нарушил -- я как раз предлагал это делать внутри, даже если не удалось объяснить заказчику ценность. Понятно, что ситуация не идеальная, но это жизнь.
В целом, хороший скрам-мастер будет и свою команду на это настраивать, но да, PO нужен и важен. От него скорее требуется не столько какие-то специальные навыки, сколько высокая заинтересованность в продукте и готовность на это тратить время. Я работал и по обычным контрактам, в успешных проектах это и там важнейший фактор. Просто в Scrum об этом говорится открыто и подчеркивается такая необходимость.
Обычно Agile-контракт (внешний или внутренний) подписывают на время (дату), сумму и команду, описывают качество как в обычном проекте, функционал по разному (описывают больше или меньше), но на него не комитятся. Из-за этого опять же обычно так работают только внутренние команды. Если контракт внешний agile, то его чаще всего подписывают как обычно, но делают рамочным (опять же фиксируется дата окончания и сумма, а ТЗ/заказы выдаются помесячно). В любом случае, это уже получше, т.к. объем оцениваемых задач ниже и максимальная возможная ошибка пониже. Бывают и совсем обычные контракты, тогда уж использовать Скрам или нет -- отдельный вопрос, тут нужен внутренний продвинутый владелец продукта, чтобы все приемы классических подходов в себе абстрагировать.
То, что нет многого -- очевидно. Весь вопрос мешает ли Скрам классическим инструментам -- если нет, то вообще проблемы нет.
Основная мысль про фиксацию возвращает нас к пирамидке. Аксиома: чаще всего с применением всех классических и неклассических подходов в нее уложиться не получается (есть какая-то американская статистика по проектам и у каждого собственный опыт). Тогда нужно что-то двигать (описал ранее как обычно двигают). В Agile у нас такой порядок работ, чтобы все самое критичное было сделано сразу же (и как только что-то становится более критичным, сразу же этим и занимаемся, поэтому спринты по неделе -- длина спринтов зависит от необходимой скорости изменения задач). Т.е. мы останавливаемся там до куда успеваем, но не успели мы самые незначительные вещи. После этого уже заказчик смотрит что делать: устраивает его так или делаем новый этап (сразу или через какое-то время).