Вся статья написана на основе реальной практики в компании- без всякого лукавства. Кто хочет развиваться- тому помощь оказывается. Я же конкретные примеры приводил в статье.
В разделе "Зачем нужен ИПР" написано о том, что нередко ИПР в разных компаниях часто вырождается в "обязаловку", и далее по всему тексту я постоянно делаю акцент на ненавязчивости и добровольности процесса.
У вас описана классика scrum. Напомню, что согласно отцам-основателям методологии (тот же Сазерленд), достижение цели scrum- постоянное повышение производительности- осуществляется улучшением коммуникации внутри команды. Это избавляет от «серых зон», вносящих неопределенность в разработку и, в итоге, в неопределенность со сроками. Но вы указали, что у вас команды 3-7 человек. Это очень компактные команды, в них априори не существует проблем с коммуникацией. Пара-тройка разрабов всегда могут сами за кофе на кухне обсудить вопросы и выбрать техническое решение. Это самый тесный, самый эффективный способ коммуникации. Scrum им для этого не нужен. Почитайте Сазерленда- scrum начинается от 50 человек в команде. Когда коммуникации ослабляются и одна часть команды не знает, что делает другая. Все эти митинги, демо, ретро нацелены именно на то, чтобы команда не разваливалась на отдельные слабосвязанные группы.
На мой взгляд, в вашем случае эффективней будет отказаться от ретро, демо, планирования спринтов. Попробуйте в рамках одной команды провести такой эксперимент в течение полугода: ежедневные летучки и через 2 недели выкладывание в релиз того, что успели. Думаю, вы увидите, что производительность команды возрастёт. Agile-методологии на то и гибкие, что допускают любые отклонения от классической реализации.
О, спасибо, прикольная вещь. Можно, например, так зашивать на сборочном сервере в код ключи доступа к каким-то ресурсам или маркировать бинарники отдаваемые пользователю.
Вы упоминаете, что переписывать тяжело и поэтому останетесь на Легаси. Из личного опыта рекомендую не бояться этого. Как правило, "не так страшен черт, как его малюют". А поддержка неудачных или устаревших решений будет вас все сильнее тяготить.
Расскажите, пожалуйста, о вашем стеке используемых решений. Например, как делаете логирование (кибана, грейлог или свое решение)?
Вся статья написана на основе реальной практики в компании- без всякого лукавства. Кто хочет развиваться- тому помощь оказывается. Я же конкретные примеры приводил в статье.
В разделе "Зачем нужен ИПР" написано о том, что нередко ИПР в разных компаниях часто вырождается в "обязаловку", и далее по всему тексту я постоянно делаю акцент на ненавязчивости и добровольности процесса.
Это не должно быть "обязаловкой". В разделе "Зачем нужен ИПР" об этом говорится.
Как сложилась терминология в компании, так и написал. Приношу извинения, если это сбивает с толку.
На мой взгляд, в вашем случае эффективней будет отказаться от ретро, демо, планирования спринтов. Попробуйте в рамках одной команды провести такой эксперимент в течение полугода: ежедневные летучки и через 2 недели выкладывание в релиз того, что успели. Думаю, вы увидите, что производительность команды возрастёт. Agile-методологии на то и гибкие, что допускают любые отклонения от классической реализации.
О, спасибо, прикольная вещь. Можно, например, так зашивать на сборочном сервере в код ключи доступа к каким-то ресурсам или маркировать бинарники отдаваемые пользователю.
Вы упоминаете, что переписывать тяжело и поэтому останетесь на Легаси. Из личного опыта рекомендую не бояться этого. Как правило, "не так страшен черт, как его малюют". А поддержка неудачных или устаревших решений будет вас все сильнее тяготить.
Расскажите, пожалуйста, о вашем стеке используемых решений. Например, как делаете логирование (кибана, грейлог или свое решение)?