StepEv

С точки зрения SCRUM не надо спрашивать аналитика за сколько он сделает задачи. Планирование в Скраме устроено совершенно по другому. Прочитайте внимательно Scrum Guide. Если что-то не понятно, спрашивайте в профильных сообществах в facebook, telegram.

Посмотрите как эти проблемы предлагают решать современные масштабируемые фреймворки - Nexus, LESS, SAFe. Для лучшего понимания любого из них стоит сначала разобраться с тем как работает Scrum в рамках одной команды, в чём особенности и выгода самоуправляемых команд, как их строить, как при этом обеспечивать качество. Путь долгий, серебрянной пули нет.

Том ДеМарко, Тимоти Листер, "Вальсируя с медведями" объясняет почему нет и что с этим сделать. Как один из примеров.

Ещё полезно задавать вопрос "А зачем?". Точно ли вашим зазказчикам нужны 100% гарантии? Или хватит 90% или даже 85%? Такие Service Level Agreements давать можно.

В нашей области нельзя давать обещаний, можно давать прогнозы. Где-то, где у вас стабильная система и накопленно достаточно данных, можно давать достаточно точные прогнозы используя достаточно простые методы. Но часто система не стабильна в той или иной степени. И не всегда с этим можно что-то сделать. Чем точнее нужен прогноз, тем дороже его давать.

Этой теме уделяет большое внимание Kanban метод.

Канбан метод даёт ответы на этот вопрос, когда объясняет как строить канбан систему. В рамках ответа на вопрос это, извините, сложно рассказать. Но могу подсказать куда копать - https://kanbanguide.ru/category/s-chego-nachat/

Начните с раздеов"С чего начать", "Визуализация", "STATIK". Чтобы меньше собрать граблей и шишек, рекомендую курс Kanban System Design.

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

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

Рекомендую книгу "Применение UML 2.0 и паттернов проектирования" Крейга Лармана. По идее, после прочтения вопросов не должно остаться. Ну, можно потом заполировать вот этой книгой https://habr.com/ru/post/140284/

https://github.com/swagger-api/swagger-codegen/wik...

Есть кучка сервисов, которые автоматически сделают то же самое без необходимости развёртывать у себя:
https://swaggerhub.com
https://apiblueprint.org/tools.html
https://getsandbox.com/
https://www.getpostman.com/docs/postman/mock_serve...

Добавлю Ларман, Применение UML и шаблонов проектирования

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

В дополнение к Макконнелу и Мартину - Дейв Томас и Энди Хант, Pragmatic Programmer (и др. в серии Pragmatic)

расширение friGate использует metabar для предложения более дешёвых товаров с яндекс марткета

Jira. Вроде всё, кроме sms нотификаций.

Что бы процесс проходил безболезненно, подтягивание develop в feature-branch лучше делать так:

git pull --rebase origin develop (в feature branch)
git push origin feature-brunch --force

То же самое cделать перед merge в develop.

Взламываем шифры с Python

ну или, например, вот

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

Краткие формы — везде. Подписан на рассылки с сайтов типа thesrverside, techtarget и т.п. Отдельно подписка на блоги любимых авторов типа Фаулера, Якобсона.

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

Но в любом случае я склонен присоединиться к предыдущему оратору — технология message queue это то, что доктор прописал.

Подробностей на сайте есть, например
habrahabr.ru/post/44907 (с продолжением) и habrahabr.ru/post/165981/

moedelo.org
или
www.b-kontur.ru

Первой пользовался сам, в целом нормально.

Что тут думать? Wordpress. Можно подписаться на обновления и на RSS и по почте. Способы трансляции в соцсети гуглятся без проблем, например, wordpress.org/support/topic/how-to-auto-post-to-facebook-twitter-and-google-fans-pages
Для СМС тоже можно что-то найти или дописать.

Trello плюс гуглодоки.