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 у нас такой порядок работ, чтобы все самое критичное было сделано сразу же (и как только что-то становится более критичным, сразу же этим и занимаемся, поэтому спринты по неделе -- длина спринтов зависит от необходимой скорости изменения задач). Т.е. мы останавливаемся там до куда успеваем, но не успели мы самые незначительные вещи. После этого уже заказчик смотрит что делать: устраивает его так или делаем новый этап (сразу или через какое-то время).
Было бы с PMI все было хорошо, то не было бы и ITIL/ITSM, и Agile/Scrum. Просто везде свое. И, конечно, тут панацеи нет, нужно смотреть что за задача и окружение, а уж после под это подбирать решение.
Для определенности, буду писать только об ИТ-проектах.
В этом случае вся разработка инкрементальна, а вот ценность может быть бинарна (когда подписали акт, например).
Скрам, прежде всего, это организационный фреймворк. Просто невозможно говорить о Скраме, когда у вас нет скрам-мастера, команды и владельца продукта как отдельных людей. Это уже просто не Скрам (повторение любых артефактов или собраний ничего от Скрама не даст -- все они были и до Скрама, может быть под другими названиями).
Да, Скрам делался для продуктов. Вполне возможно использовать его и для достаточно длинных контрактов (особенно если команда уже была сформирована и до конкретного контракта).
Немного о проектном треугольнике: время, стоимость, функционал и качество. В классических проектах небольшая группа экспертов это все оценивает, затем контрактом фиксирует. При этом возникают проблемы при реализации, на то он и проект, а не процесс. Тогда чем-то нужно жертвовать. В классических проектах начинают смотреть в контракт и жертвуют недоописанными вещами (качество и функционал), при адекватных заказчиках увеличивают стоимость (change request), иногда еще жертвуют своей прибыльностью (увеличивают время). Agile (не только скрам) же говорит, что мы фиксируем стоимость и время, о качестве тоже договариваемся (но можем поменять по желанию заказчика), а функционал делаем с самого критичного до самого некритичного (и предполагаем, что на горизонте в полгода-год к нам еще придет бизнес и скажет, что приоритеты теперь другие).
Понятно, что у заказчика всегда есть подозрение, что люди не будут работать, поэтому это проще достигается с внутренними командами.
А роль Скрама здесь -- это как раз мотивировать команду и прозрачно показать весь процесс заказчику.
Теперь немного комментариев по тексту:
Scrum - это не метод управления проектами
Метод управления, но не всеми вариантами проектов, есть ограничения (минимальные размеры проекта прежде всего).
Скрам не умеет контролировать попадание в "проектный" треугольник Time - Budget - Scope, фактически он фокусируется только на удовлетворенности заказчика.
Умеет. Точнее никто не умеет, всегда чем-то жертвуют.
Вывод - Скрам хорошо подходит для разработки новых продуктов в области программного обеспечения. И очень ограниченно подходит для аутсорсинговых проектов, тем более не софтверных.
Если проект достаточно длинный (от полугода со стабильной командой), то, по моему опыту, Скрам вполне применим. При этом о том, что он практикуется заказчику вообще нет особой нужды знать -- это внутренний способ работы аутсорсера.
Scrum ничего не знает о дедлайнах или фиксированном бюджете
Как раз наоборот: у Скрама всегда фиксированный дедлайн и бюджет. При этом в самом Скраме совсем не описано как оценивать сложность/длительность задач, это можно делать как и без Скрама делаете. Скрам лишь позволяет выстроить процесс постепенного приблежения к цели с максимальной отдачей за единицу затрат в любой момент времени.
Поэтому даже если внешне это может выглядеть как Скрам, по сути таковым оно часто не является, если нет ценного, полезного инкремента в каждом спринте.
Похоже на передергивание. Понятно, что в самом начале, когда мы добавили, например, только авторизацию, продукт еще нельзя использовать конечными пользователями, но так же и нельзя сказать, что в спринте ничего ценного не добавили. Ценное -- добавили, заказчику -- показали, а выпускать текущий артефакт на пользователей заказик решает сам -- когда, на какую группу и тп. Другими словами под ценным мы понимаем видимое продвижение к цели продукта, а не возможность продукта сразу же быть использованным, тк да, бывают ситуации, когда это невозможно.
Вывод - перед началом проекта нужно проверять, возможно ли поставлять инкрементами что-то полезное заказчику и получать с этого обратную связь для коррекции работ.
Обратную связь всегда возможно получать. Если даже нет, то это особо ничего не меняет -- лишь добавляет дополнительный этап опытно-промышленной эксплуатации, когда заказчик бужет уже смотреть. При этом Скрам команда с самого начала все так же итеративно поставляет сборки, которые могут быть продемонстрированы заказчику, чтобы показать, что прогресс идет, или отданы отдельной команде тестирования (если уж заказчик не хочет смотреть промежуточные этапы).
Scrum - командный подход
Вывод - Скрам требует наличия сплоченной самоорганизованной команды. Нужно заранее продумать, есть ли она, или как её планируется создать.
Тут полностью согласен. Только сформулирую по-другому: нужно заранее понимать необходимость формирования команды (и это и есть основная задача скрам-мастера) и должно быть достаточное количество времени и стабильность команды, чтобы это имело смысл. Иначе нужно использовать не Скрам, а что-то другое.
Scrum опирается на кросс-функциональную команду
Вывод - Перед началом проекта проверить действительно ли кросс-функциональна команда, либо найти способ обойти это (напр. замена QA автотестами, вовлеченность команды в планирование с PO – аналитик не нужен).
Немного не так. Не обязательно, чтобы все отделы работали по Скраму (или все команды по контракту работали по Скраму). Например, IT обычно по Скраму не работают. Не обязательно, чтобы каждый член команды все мог (хотя это и мечта и традиционных руководителей проектов). Важно, чтобы задачи, который попадают в команду, могли бы быть решены этой командой. Например, дизайнеров можно вывести из Скрам-команды в команду владельца продукта, если они, в основном, будут нужны эпизодами. Аналитики и QA могут быть как внутри, так и снаружи -- опять же зависит скорее от кол-ва часов, которые они тратят на этот проект.
В Scrum достаточно высокие накладные расходы на "церемонии"
Вывод - Скрам поощряет работу короткими спринтами для быстрой адаптации к меняющимся требованиям, но слишком короткие спринты (одна - две недели) влекут за собой достаточно высокие накладные расходы на церемонии Скрам.
Есть такая проблема, но она разделяется на:
- дейли так или иначе обычно есть всегда, вполне понятно как их контролировать по времени
- демо позволяют получить обратную связь от заказчика и далее правильнее принимать тысячи мелких решений, которые программист делает чуть ли ни ежедневно, так что вполне себе окупаются
- ретро призваны повысить эффективность уже со следующего спринта -- т.е. окупаются моментально или проводятся как-то не так
- бэклог груминг -- тут сложнее всего контролировать время. Например, иногда на груминг берут не всех людей из команды, если это скорее совещание с аналитиками и дизайнерами по первоначальным уточнениям от разработчиков. Опять же на уровне ТЗ (когда еще нет кода) проще всего исправить проблемы (например, найти нестыковку с другим функционалом) и тут нужна вся команда (и тогда это окупается), но сами задачи уже должны быть достаточно хорошо проработаны.
Scrum не масштабируется на большие команды, и не умеет управлять паралельными потоками связанных работ
Вывод - при работе нескольких команд над одним продуктом Скрам как таковой уже не подходит, применяются другие подходы - SAFe, LeSS.
В целом -- да, но нельзя прям сказать, что другие. Скрам обычно остается на нижнем уровне и появляются надстройки для управления многими скрам-командами. Тут еще часто появляются микросервисы, чтобы отделить команду от команды.
Сторонники Scrum скупы на критику
Вывод - придется во всем разбираться самому, на помощь со стороны сильно не надейтесь.
Ну, и у нас есть подобные профессионалы. Есть книги, конференции, тот же Хабр, но да, если в вашей компании нет опыта, то нужно его нарабатывать. И сначала на не самом критичном проекте. А лучше найти человека в штат с опытом.
Scrum побуждает к привлечению внешних специалистов - Скрам-мастеров и Agile коучей
Вывод - у Agile коуча всегда много вопросов и нет ответов.
Мое искреннее мнение -- скрам-мастер не может быть внешним, это основа Скрама.
Нужен коуч или нет и в каком формате -- все решают сами, тут ничего нового.
Высокие требования в Scrum к Владельцу Продукта (Product Owner)
Скрам не предусматривает достаточный по времени этап сбора и анализа требований. Откуда они возьмутся, как правильно оценить их взаимосвязь, влияние на бизнес, выставить приоритет - ответов Скрам не даёт.
Вывод - без толкового Владельца продукта процесс не полетит. А найти такового очень непросто.
Не согласен. Как раз в традиционном подходе заказчик изначально все подписывает и получает, что подписал. Или платить кучу денег за дополнительные соглашения. Agile (даже не Скрам) позволяет заказчику уточнять задачу по мере увеличения понимания. Не обязательно запускать Скрам с момента подписания контракта или запуска нового продукта -- какое-то время до начала разработки может проводиться первоначальный анализ, прототипы дизайна и UI, это никак не противоречит Скраму, тк скрывается за абстракцией владельца продукта, а скрам-команда либо еще не начала работать, либо занимается какими-то заранее известными задачами (пишет интеграции с другими системами, например).
Резюмируем сказанное
Понятно, что резюме тоже другое. Для длительных проектов или продуктов Скрам вполне себе подходит, но нужно четко понимать роль скрам-мастера, иначе это просто не Скрам.
PS: Большое спасибо автору за статью, тему поднимать надо и рассуждать об этом тоже полезно всем.
В целом, можно представить себе схему когда у нас есть "монолит", который состоит из кучи библиотек (вместо отдельных сервисов).
Все-таки наличие таких библиотек необходимо (с какого-то размера), чтобы команды могли независимо делать эксперименты (если нет множества разных команд с разными целями и сроками, то и микросервисы, и библиотеки не нужны особо).
Таким образом, мы уходим от сетевых задержек. Какие при этом могут быть минусы?
- необходимость возможности старта всей системы на одном сервере: если используются локальные кеши, то такое не всегда возможно - увеличенное время сборки, но при этом вся система стартует локально (что удобно для разработчиков) - необходимо для одного запроса для снижения задержек использовать больше cpu/памяти/сети, чем есть на одном сервере - вроде бы в таком случаем масштабирование проще, но когда есть совсем разные разпросы, то оно не эффективно (например, один запрос требует кучу данных в памяти, а другой запрос cpu, а третий по сути аркестрирует вызовы к базам) - при большом количестве серверов и экспериментов придется довольно часто передеплоивать все, что, как ни крути, приводит к какому-то простою серверов и потенциальным ошибкам при обновлении
Т.е. да, в каких-то областях возможно не переходить на обычные микросервисы, а еще какое-то время оставаться на библиотечных микросервисах, но это каждый раз надо смотреть по месту. И, конечно, если у вас все и так хорошо без микросервисов, то не нужно их внедрять просто чтобы были.
Какая-то непонятная пропаганда. Почему, например, Россия не попала в сравнение? Я знаю довольно много обычных российских программистов, которые уже обеспечили себе старость и счастливых детей. Думаю, и во многих других странах у них все более чем хорошо.
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 у нас такой порядок работ, чтобы все самое критичное было сделано сразу же (и как только что-то становится более критичным, сразу же этим и занимаемся, поэтому спринты по неделе -- длина спринтов зависит от необходимой скорости изменения задач). Т.е. мы останавливаемся там до куда успеваем, но не успели мы самые незначительные вещи. После этого уже заказчик смотрит что делать: устраивает его так или делаем новый этап (сразу или через какое-то время).
Было бы с PMI все было хорошо, то не было бы и ITIL/ITSM, и Agile/Scrum. Просто везде свое. И, конечно, тут панацеи нет, нужно смотреть что за задача и окружение, а уж после под это подбирать решение.
Для определенности, буду писать только об ИТ-проектах.
В этом случае вся разработка инкрементальна, а вот ценность может быть бинарна (когда подписали акт, например).
Скрам, прежде всего, это организационный фреймворк. Просто невозможно говорить о Скраме, когда у вас нет скрам-мастера, команды и владельца продукта как отдельных людей. Это уже просто не Скрам (повторение любых артефактов или собраний ничего от Скрама не даст -- все они были и до Скрама, может быть под другими названиями).
Да, Скрам делался для продуктов. Вполне возможно использовать его и для достаточно длинных контрактов (особенно если команда уже была сформирована и до конкретного контракта).
Немного о проектном треугольнике: время, стоимость, функционал и качество. В классических проектах небольшая группа экспертов это все оценивает, затем контрактом фиксирует. При этом возникают проблемы при реализации, на то он и проект, а не процесс. Тогда чем-то нужно жертвовать. В классических проектах начинают смотреть в контракт и жертвуют недоописанными вещами (качество и функционал), при адекватных заказчиках увеличивают стоимость (change request), иногда еще жертвуют своей прибыльностью (увеличивают время). Agile (не только скрам) же говорит, что мы фиксируем стоимость и время, о качестве тоже договариваемся (но можем поменять по желанию заказчика), а функционал делаем с самого критичного до самого некритичного (и предполагаем, что на горизонте в полгода-год к нам еще придет бизнес и скажет, что приоритеты теперь другие).
Понятно, что у заказчика всегда есть подозрение, что люди не будут работать, поэтому это проще достигается с внутренними командами.
А роль Скрама здесь -- это как раз мотивировать команду и прозрачно показать весь процесс заказчику.
Теперь немного комментариев по тексту:
Метод управления, но не всеми вариантами проектов, есть ограничения (минимальные размеры проекта прежде всего).
Умеет. Точнее никто не умеет, всегда чем-то жертвуют.
Если проект достаточно длинный (от полугода со стабильной командой), то, по моему опыту, Скрам вполне применим. При этом о том, что он практикуется заказчику вообще нет особой нужды знать -- это внутренний способ работы аутсорсера.
Как раз наоборот: у Скрама всегда фиксированный дедлайн и бюджет. При этом в самом Скраме совсем не описано как оценивать сложность/длительность задач, это можно делать как и без Скрама делаете. Скрам лишь позволяет выстроить процесс постепенного приблежения к цели с максимальной отдачей за единицу затрат в любой момент времени.
Похоже на передергивание. Понятно, что в самом начале, когда мы добавили, например, только авторизацию, продукт еще нельзя использовать конечными пользователями, но так же и нельзя сказать, что в спринте ничего ценного не добавили. Ценное -- добавили, заказчику -- показали, а выпускать текущий артефакт на пользователей заказик решает сам -- когда, на какую группу и тп. Другими словами под ценным мы понимаем видимое продвижение к цели продукта, а не возможность продукта сразу же быть использованным, тк да, бывают ситуации, когда это невозможно.
Обратную связь всегда возможно получать. Если даже нет, то это особо ничего не меняет -- лишь добавляет дополнительный этап опытно-промышленной эксплуатации, когда заказчик бужет уже смотреть. При этом Скрам команда с самого начала все так же итеративно поставляет сборки, которые могут быть продемонстрированы заказчику, чтобы показать, что прогресс идет, или отданы отдельной команде тестирования (если уж заказчик не хочет смотреть промежуточные этапы).
Тут полностью согласен. Только сформулирую по-другому: нужно заранее понимать необходимость формирования команды (и это и есть основная задача скрам-мастера) и должно быть достаточное количество времени и стабильность команды, чтобы это имело смысл. Иначе нужно использовать не Скрам, а что-то другое.
Немного не так. Не обязательно, чтобы все отделы работали по Скраму (или все команды по контракту работали по Скраму). Например, IT обычно по Скраму не работают. Не обязательно, чтобы каждый член команды все мог (хотя это и мечта и традиционных руководителей проектов). Важно, чтобы задачи, который попадают в команду, могли бы быть решены этой командой. Например, дизайнеров можно вывести из Скрам-команды в команду владельца продукта, если они, в основном, будут нужны эпизодами. Аналитики и QA могут быть как внутри, так и снаружи -- опять же зависит скорее от кол-ва часов, которые они тратят на этот проект.
Есть такая проблема, но она разделяется на:
- дейли так или иначе обычно есть всегда, вполне понятно как их контролировать по времени
- демо позволяют получить обратную связь от заказчика и далее правильнее принимать тысячи мелких решений, которые программист делает чуть ли ни ежедневно, так что вполне себе окупаются
- ретро призваны повысить эффективность уже со следующего спринта -- т.е. окупаются моментально или проводятся как-то не так
- бэклог груминг -- тут сложнее всего контролировать время. Например, иногда на груминг берут не всех людей из команды, если это скорее совещание с аналитиками и дизайнерами по первоначальным уточнениям от разработчиков. Опять же на уровне ТЗ (когда еще нет кода) проще всего исправить проблемы (например, найти нестыковку с другим функционалом) и тут нужна вся команда (и тогда это окупается), но сами задачи уже должны быть достаточно хорошо проработаны.
В целом -- да, но нельзя прям сказать, что другие. Скрам обычно остается на нижнем уровне и появляются надстройки для управления многими скрам-командами. Тут еще часто появляются микросервисы, чтобы отделить команду от команды.
Ну, и у нас есть подобные профессионалы. Есть книги, конференции, тот же Хабр, но да, если в вашей компании нет опыта, то нужно его нарабатывать. И сначала на не самом критичном проекте. А лучше найти человека в штат с опытом.
Мое искреннее мнение -- скрам-мастер не может быть внешним, это основа Скрама.
Нужен коуч или нет и в каком формате -- все решают сами, тут ничего нового.
Не согласен. Как раз в традиционном подходе заказчик изначально все подписывает и получает, что подписал. Или платить кучу денег за дополнительные соглашения. Agile (даже не Скрам) позволяет заказчику уточнять задачу по мере увеличения понимания. Не обязательно запускать Скрам с момента подписания контракта или запуска нового продукта -- какое-то время до начала разработки может проводиться первоначальный анализ, прототипы дизайна и UI, это никак не противоречит Скраму, тк скрывается за абстракцией владельца продукта, а скрам-команда либо еще не начала работать, либо занимается какими-то заранее известными задачами (пишет интеграции с другими системами, например).
Понятно, что резюме тоже другое. Для длительных проектов или продуктов Скрам вполне себе подходит, но нужно четко понимать роль скрам-мастера, иначе это просто не Скрам.
PS: Большое спасибо автору за статью, тему поднимать надо и рассуждать об этом тоже полезно всем.
В целом, можно представить себе схему когда у нас есть "монолит", который состоит из кучи библиотек (вместо отдельных сервисов).
Все-таки наличие таких библиотек необходимо (с какого-то размера), чтобы команды могли независимо делать эксперименты (если нет множества разных команд с разными целями и сроками, то и микросервисы, и библиотеки не нужны особо).
Таким образом, мы уходим от сетевых задержек. Какие при этом могут быть минусы?
- необходимость возможности старта всей системы на одном сервере: если используются локальные кеши, то такое не всегда возможно
- увеличенное время сборки, но при этом вся система стартует локально (что удобно для разработчиков)
- необходимо для одного запроса для снижения задержек использовать больше cpu/памяти/сети, чем есть на одном сервере
- вроде бы в таком случаем масштабирование проще, но когда есть совсем разные разпросы, то оно не эффективно (например, один запрос требует кучу данных в памяти, а другой запрос cpu, а третий по сути аркестрирует вызовы к базам)
- при большом количестве серверов и экспериментов придется довольно часто передеплоивать все, что, как ни крути, приводит к какому-то простою серверов и потенциальным ошибкам при обновлении
Т.е. да, в каких-то областях возможно не переходить на обычные микросервисы, а еще какое-то время оставаться на библиотечных микросервисах, но это каждый раз надо смотреть по месту. И, конечно, если у вас все и так хорошо без микросервисов, то не нужно их внедрять просто чтобы были.
Плохо, как ни крути, это монополия (Яндекс.Еда + Delivery Club).
Какая-то непонятная пропаганда. Почему, например, Россия не попала в сравнение? Я знаю довольно много обычных российских программистов, которые уже обеспечили себе старость и счастливых детей. Думаю, и во многих других странах у них все более чем хорошо.