Приложения

Итоги

• превосходство живого общения над технологиями и инструментарием;

• превосходство действующего продукта над пакетом документов;

• превосходство работы с клиентами над подписанием договора;

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

• Product Backlog — перечень проектных правил;

• Sprint Backlog — перечень условий, которые необходимо реализовать в ближайший спринт;

• Sprint Goal — задача спринта;

• Sprint Burndown Chart — график, обновляемый в зависимости от темпа достижения целей. По нему удобно отслеживать развитие и уровень движения группы в разработке продукта.

• кодирование — по единым командным стандартам создания;

• тестирование — тесты составляются разработчиками до создания кода, который будут проверять;

• создание плана — планировать следует не только финальную стадию, но и промежуточные итерации;

• слушание — как членов команды, так и потребителей. На данном этапе проясняются проблемные моменты, определяются задачи и ценностные ориентиры.

• рабочий код доставляется оперативно — формирование идеи поэлементного принципа разработки Agile;

• совершенствование через самоанализ — обновленная версия программы становится более усовершенствованной, основываясь на информации о предшествующей;

• высокоэффективная взаимосвязь— новая разработка Алистера, метафора коммуникативного процесса и обмена материалами между членами команды разработки программ в одном помещении.

• обновленные рабочие версии продукта выпускаются довольно часто;

• разработчики принимают решения автономно;

• ПО тестируется на протяжении всего периода работы.

• DSDM подразделяется на версии, обновляемые вместе с развитием технологий, выхода новых пожеланий к разрабатываемым программам. Сегодня последней версией является DSDM Atern, которую выпустили в 2007 году, но и предшествующая, появившаяся в 2003 году, также используется.

• этап функциональной модели — разработка аналитических документов и прототипов;

• этап создания проектов и конструкций — система приводится в состояние, способное к работе;

• этап реализации — действие системы.

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

• Разработка общей модели — представление будущего продукта, основываясь на предварительной информации.
• Написание списка свойств — аналогичный продукт backlog в методологии скрам.
• Создание плана по свойствам — оценивание трудности свойств каждым участником рабочей группы.
• Создание методики по каждому свойству в отдельности — техническое оформление и последующая реализация — заключительный этап, на котором свойство отправляется в программу, и после этого цикл начинается снова.

• нужно избавиться от потерь — всего, что не добавляет ценности продукту для потребителей;

• непрерывное обучение — члены команды всегда должны совершенствовать свои навыки для повышения эффективного достижения целей;

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

• оперативная доставка — фундамент поэтапной модели;

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

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

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

• должна быть постоянная взаимосвязь между проектными стейкхолдерами;

• нужно стремиться создать самое понятное из возможных решений, которое будет применимо ко всем требованиям;

• нужно непрерывно получать обратную связь;

• важно нести ответственность и без страха отвечать за принятые решения; необходимо понимать, что абсолютно все знать невозможно.

• команда хорошо ориентируется в своей работе;
• самые лучше решения – понятные всем;
• продукт должен быть гибким;
• необходима фокусировка на важных для продукта моментах;
• самостоятельность в подборе используемых техник;
• индивидуальная перестройка AUP под каждый отдельный проект.

• Информация — фундамент разработки любого приложения.

• Сложности с продуктом — они становятся заметны, только когда есть четкое видение задач и концепции проекта.

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

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

• Командная работа — коллективное взаимодействие принесет больше положительного эффекта, чем одиночная разработка.

• «Сладкое пятно» — нужно искать подходящее решение проблемы, не доходя до крайних мер.

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

• возможность измерить темп работы группы разработчиков;
• встречи с членами команды проводятся каждый день, ретроспективы – после завершения каждого этапа;
• применяется концепция маленьких шагов и ранних тестов с применением чеклистов;
• используется методика гибкого моделирования (AMDD).

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

• Производительность — сюда входят Velocity и WIP. Velocity будет подходящей не для всех программ, так как происходит измерение числа решенных задач за один этап, а их значимость различная.

• Метрика Work-in-Progress занимается определением лимита задач на разных этапах. Чем выше лимит, тем хуже для проекта.

• Создание прогнозов — метрика capacity: она определяет число идеальных часов, которые будут доступны в следующем спринте. То есть, можно точно знать, сколько часов еще имеется для выполнения работы, насколько эффективно решаются поставленные задачи и как установить подходящее число задач для одного спринта.

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

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

• привлечение стейкхолдеров — так рабочая группа быстрее понимает, что необходимо потребителям. А ранняя и частая доставка ПО улучшает доверительные отношения стейкхолдеров и разработчиков и глубже привлекает их в проект;

• оперативная и ожидаемая доставка — поэтапная модель разработки делает продукт более гибким, ускоряет темпы выпуска тестовой версии;

• фокусировка на бизнес-ценности — коллаборация с пользователями позволяет разработчикам понять, что именно нужно потребителям;

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

• высокие требования к разработчикам и пользователям — важна взаимосвязь рабочей группы и потребителей для создания действительно качественного продукта. Многообразие методик в Agile для внедрения требует опытных членов группы;

• нельзя использовать для аутсорса и проектов, где взаимодействие участников происходит только в режиме онлайн;

• риск никогда не создать итоговую версию программы — этот недостаток возникает из-за того, что продукт все время совершенствуется и обновляется;

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

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