Сторипоинт часто используется в Agile-разработке как инструмента для оценки задач. Изначально сторипоинты задумывались как мера ценности, которую команда доставляет клиенту, а не просто как аналог человеко-часов. Однако на практике их часто используют для измерения объема работы, что приводит к искажению их смысла. Предлагаю вернуться к изначальной идее сторипоинтов, оценивая не просто усилия, а ценность, которую команда создает для клиента. Но как в этом случае формировать бэклог, оценивать задачи с учетом технической сложности, объема работы и рисков, а также как распределять время команды между основными и вспомогательными активностями? Читаем дальше…

В рамках agile-трансформации часто за кадром остается вопрос информационной безопасности. В традиционных подходах этим обычно занимается специализированный отдел, который анализирует техническое задание, включает в него требования ИБ, изучает созданное программное обеспечение, пытаясь найти в нем уязвимости и взломать его. Однако при переходе на командо-ориентированный подход с быстрой реакцией на изменения и быстрой поставкой, эти активности могут быть забыты. До первого инцидента ИБ, приводящего к серьёзным потерям, которые в современном мире случаются всё чаще. После этого вспоминают об ИБ, но мало кто понимает, как совместить её с гибкими подходами.
Данная статья, перевод которой я выкладываю, даёт общее понимание о месте ИБ в agile-фреймворке SAFe и о том, как обеспечить гибкость не в ущерб безопасности.

Пользовательская история — настолько привычный термин, что уже как-будто и не требуется объяснения, что это такое. Но работа с командами постоянно заставляет вернуться на грешную землю и осознать, что не настолько это понятный инструмент, чтобы им все могли пользоваться.
Данная статья представляет собой перевод статьи об историях из SAFe. Но насколько бы полным не был оригинал, он все-равно вызывает вопросы у разработчиков. Поэтому я дал свои коментарии, что же все-таки такое — история.