Отцы основатели создали свой манифест в котором написали:

1. Люди и их взаимодействие важнее процессов и инструментов;
2. Готовый продукт важнее документации по нему;
3. Сотрудничество с заказчиком важнее жестких контрактных ограничений;
4. Реакция на изменения важнее следования плану.

Для чего создавался скрам?

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

Кстати, возможный прирост производительности обещают целых 300-400% :)

За счет чего прирост производительности?

Во главе угла — Команда, которая берет себе (сама) что-то в бэклог-спринта но в соответствии с заранее обозначенными целями Product Owner-ом (из бэклога продукта) и выполняет создавая очередной инкремент продукта (новую функциональность — User Story), используя для этого все ресурсы команды.

Команда должна быть самодостаточна и многофункциональна, т. е. включает в себя специалистов всех необходимых технологий, чтобы никого не ждать

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

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

Качественная коммуникация внутри команды и общая нацеленность на результат очень важны!

Скрам — это гибкая методика, задача — это не план, задача — может меняться по ходу спринта, даже на поздних этапах реализации. Важен конечный результат — итерация продукта.

Необходимо выбирать такую продолжительность спринта, что бы на выходе появлялась фича/субпродукт (User Story) который можно будет пощупать и решить стоит ли его пилить дальше и каким он будет в будущем.

Для синхронизации работы команды нужны ежедневные скрам-митинги (не более 15 мин), на которых каждый член команды должен ответить на три простых вопроса:

1. Что ты сделал вчера, чтобы помочь команде завершить спринт?
2. Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?
3. Какие препятствия встают на пути команды?

По окончанию спринта проводится Демонстрация и Ретроспектива.

Цитаты:

«Наилучшую продуктивность показывают команды, которые не используют оценки. Чем чаще вы спрашиваете вашу команду об оценках, тем сильнее вы замедляете ее работу. Если вашей команде приходится оценивать вообще всю свою работу, то это замедление достигает максимума. Сначала люди тратят время на первоначальные оценки, потом они обсуждают, почему оценки не сбылись и что же теперь делать дальше (обычное решение — потребовать новых оценок), а потом требования меняются, и вуаля — нужно оценить, как изменение требований повлияло на оценки. А еще команде приходится иметь дело с техническим долгом, накопленным в многочисленных попытках уложиться в собственные оценки, что замедляет проект в долгосрочной перспективе.»

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

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

Оценка задач

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

При этом в оценку усилий следует заложить все факторы, которые могут повлиять на нее:

1. Объем требуемой работы;
2. Техническую сложность задачи;
3. Возможные риски и неопределенность в требованиях;

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

Относительность оценки

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

Замена часов на абстрактные баллы

Так мы снимаем с оценивающего необходимость оценивать задачу в часах. Вместо этого он оценивает ее в баллах (Story Point), таким образом мы убираем противоречия в восприятии оценки разработчиком и менеджером. Более того, теперь отвлекающие факторы и форс-мажорные обстоятельства никак не повлияют на оценку, ведь они не меняют усилия, требующиеся для решения задачи!

Для оценки задач можно использовать любую шкалу. Самой распространенной являются числа Фибоначчи, это понятные числовые значения к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.

Для оценки задач можно использовать любую шкалу. Самой распространенной являются числа Фибоначчи, это понятные числовые значения к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.

Тем не менее некоторые команды используют альтернативную шкалу оценки. Самые распространенные это оценка в майках и собаках, когда сложность задачи указывается в размере майки (S, M, L, XL) или в породе собаки (Чихуахуа, Мопс, Дог). Таким образом команды еще больше абстрагируются от численного представления оценки, которое в некоторых случаях так и подмывает перевести в оценку временную.

Одна из самых больших ошибок, которые можно допустить при оценке задач — сделать ее самостоятельно и не спросить мнения членов команды. Люди — самый важный ресурс оценки. Они могут увидеть то, что не видите Вы.

Покер-планирование (Planning poker)

консенсусная относительная оценка задач (историй пользователей) командой. Этот вид оценки не входит в классический Scrum, но является паттерном для оценки User Story.

Покер-планирование проводится следующим образом:

Каждому участнику раздается колода карт с числовыми весами для оценки требований.

Начинается обсуждение и оценка очередной истории пользователя: она зачитывается, команда задает вопросы владельцу продукта, выясняет детали, если это необходимо.

Каждый член команды делает свою оценку, кладя карту рубашкой вверх.

После того, как все члены команды сделали оценку — все карты переворачиваются и оценки сверяются.

Если оценки всех участников одинаковы — консенсусная оценка заносится в беклог, в противном случае начинается повторное обсуждение и проводится второй раунд.

Планирование проекта

Часто у руководителя проекта возникает вопрос: “Как перевести Story Point в часы?”. Короткий ответ на этот вопрос: “Никак”. Что действительно важно, так это сколько Story Point команда разработки может “закрыть” за спринт. Собирая данные о скорости команды можно получить достаточно точные данные для долгосрочного планирования проекта.

Считаем историческую скорость (velocity) разработки команды в Story Point-ах за спринт. Если состав команды не менять (а его лучше не менять), то цифра со временем станет достаточно стабильной.

Оцениваем предстоящий объем работ в тех же Story Point-ах.

Делим предстоящий объем на историческую скорость — получаем количество спринтов, за которое объем предположительно будет выполнен.

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

Подходы:

«Fix Time and Budget, Flex Scope» — Запускайте вовремя и согласно смете
Лёгкий способ начать вовремя и уложиться в бюджет: фиксируйте время и бюджет. Никогда не отдавайте больше времени или денег проблеме, умерьте пыл.

Бытует миф: мы можем начать вовремя, уложившись в бюджет и реализуя всё предполагаемое. Это практически никогда не выходит, но когда так происходит, от этого страдает качество.

Если вы не укладываетесь в отведённые время и бюджет, не увеличивайте их. Вместо этого сократите возможности. Время добавить их чуть позже будет всегда.

«Движение #NoEstimates» — Безоценочная разработка.
Мы организуем процесс разработки так, чтобы максимально эффективно проводить задачи от этапа идеи до выкатки в прод и при этом сохранять высокое внутреннее качество. Организовывать процесс предлагают по Kanban с отслеживанием метрик обработки потока и особым вниманием к улучшению процесса доставки новых фич. Преждевременные оценки считаются вредными, оценка и грумминг бэклога — потеря времени

«Scrumban»
Чтобы внедрить Scrumban, не получится отказаться от Scrum с его итерациями. Нужно полностью овладеть и Scrum, и Kanban. Таким образом, неверно думать, что это более лёгкий фреймворк, где-то между двумя большими братьями.

Ключевые отличия двух самых распространенных в данный момент:

1) utf8mb4_unicode_ci (Unicode 4.0) — основан на официальных правилах Unicode для универсальной сортировки и сравнения, что обеспечивает точную сортировку на широком спектре языков.

2) utf8mb4_general_ci — представляет собой упрощенный набор правил сортировки, цель которого — работать как можно лучше, используя множество сокращений, предназначенных для повышения скорости. Он не соответствует правилам Юникода и приведет к нежелательной сортировке или сравнению в некоторых ситуациях, например, при использовании определенных языков или символов.

На современных серверах это повышение производительности будет практически незначительным. Он был разработан в то время, когда серверы имели крошечную долю производительности ЦП современных компьютеров

Для тех, кто все еще задается этим вопросом в 2020 году или позже, есть более новые варианты, которые могут быть лучше, чем оба из них. Например, utf8mb4_0900_ai_ci.

utf8mb4_ru_0900_ai_ci — стандарт Unicode 9.0 (новые языки и новые эмодзи).

_ci — это сортировка и сравнение без учета регистра

_bin — Бинарные сопоставления специально предназначены для игнорирования культурных правил и работы на уровне байтов

Для бинарных сопоставлений обновленная кодировка — utf8mb4_0900_bin Разница между utf8mb4_0900_bin и utf8mb4_bin может быть заметна в реализации:

Преобразование регистра (основанная на более новой версии Unicode, скорее всего, имеет больше определений сопоставления)

Конечный пробел (utf8mb4_binигнорирует конечные пробелы, utf8mb4_0900_bin не игнорирует их)

Сортировка (у utf8mb4_0900_bin порядок сортировки такой же, как у utf8mb4_bin, но намного быстрее)

Пример 1:

CREATE DATABASE `dummydb` DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_bin;

CREATE TABLE `dummy` (`key` VARCHAR(255) NOT NULL UNIQUE);

INSERT INTO `dummy` (`key`) VALUES (’one’);
INSERT INTO `dummy` (`key`) VALUES (’one ’);
INSERT INTO `dummy` (`key`) VALUES (’One’);
INSERT INTO `dummy` (`key`) VALUES (’öne’);

SELECT * FROM `dummy`;
На втором инсерте ожидается ошибка, остальные строки успешно вставятся. Для кодировки utf8mb4_bin это уникальные значения: one, One, öne

Пример 2:

CREATE DATABASE `dummydb` DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_ru_0900_ai_ci;

CREATE TABLE `dummy` (`key` VARCHAR(255) NOT NULL UNIQUE);

INSERT INTO `dummy` (`key`) VALUES (’one’);
INSERT INTO `dummy` (`key`) VALUES (’one ’);
INSERT INTO `dummy` (`key`) VALUES (’One’);
INSERT INTO `dummy` (`key`) VALUES (’öne’);

SELECT * FROM `dummy`;
На третьем и четвертом инсерте ожидается ошибка, первые, две строки успешно вставятся. Для кодировки utf8mb4_ru_0900_ai_ci это НЕ уникальные значения: one, One, öne

Рекомендации:

1) utf8mb4_0900_bin

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

2) utf8mb4_ru_0900_ai_ci

Если это текстовые данные по которым подразумевается поиск или сортировка , поиск будет производится без учета регистра, с учетом языковых особенностей (например будут найдены и Е и Ё при поиске по одной из них).

Slim называют микро-фреймворком ввиду своей простоты и легкости.
Пробую его в api сервисе, пока все устраивает.
Многие счиатют, что он как раз для этого и заточен.
Здорово, что можно очень быстро развернуть приложение, не замусоренное лишним функционалом,
подключаешь сам всё, что нужно и такое знакомое по другим фреймворкам:
Eloquent ORM, Monolog, Twig и т. д. и т. п.

Я решил протестировать у себя этот самый блог-движок Эгея (Aegea).
Первое мнение — это очень минималистичный интерфейс.
Выглядит красиво, но как этим управлять не понятно.
Надо поплясать с бубном чтобы все настроить.
Сперва не подгружались картинки.
Чтобы разобраться пришлось изучать код.
Нашел кое-какие настройки, можно переопределять содержимое из system/default/config.php в user/config.php.
Но проблема оказалась в том что php был голый — без нужных расширений, а требуются curl и gd.