Исправлена проблема отображения popup-окон карточек задач и пожеланий.

Исправлена проблема видимости на форме требования пользовательского атрибута, заданного для типа требования.

Исправлена проблема входа в проект, название которого состоит только из цифр.

На форме редактирование профиля пользователя исправлено отображение подсказок для полей.

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

Исправлена проблема с названием бейзлайна, который был создан с указанием проекта.

Пользовательские истории сильны в определении функциональности продукта с точки зрения пользователя и клиента: каждая пользовательская история описывает единицу функциональности продукта, например, “Являясь провайдером приложения, я бы хотел зарегистрироваться в центре приложений, чтобы иметь возможность пользоваться его услугами”. Сосредоточив внимание на отдельной области функциональности продукта, история позволяет команде понять, внедрить и протестировать требование.

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

В Agile проектах мы ценим личное общение. Подобный вид обсуждения требований считается наиболее оптимальным, поскольку при нем можно собрать всю необходимую информацию, как вербальную, так и невербальную. Тем не менее, существуют моменты, когда даже эти слова могут быть неправильно истолкованы или, что более вероятно, плохо сохранены в вашей памяти.

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

В отличие от некоторых обсуждений, которые мы наблюдаем в сообществе разработчиков ПО, Agile разработка не является принятием Scrum или любого другого процесса, инструментария или методологии в качестве культа «карго», хотя мы, разумеется, следим за этим и считаем это проблемой. В основе гибкости (agility) лежит быстрое реагирование, обучение и достаточность. Гибкость отображается в надежности и качестве программного обеспечения. По определению, ненадежность и низкий уровень качества разработки препятствует и уменьшает ее гибкость. В манифесте указано, что “постоянное внимание, уделяемое техническому совершенству и качественному проектированию, увеличивает гибкость процесса”, предлагая архитектуре четкую роль в контексте Agile среды.