41. AgileCleanroom Цель: качество продукта Методика: фокусирование на предупреждении дефектов, а не на их устранении. Идея состоит в том, чтобы потратить время на анализ, проверку, обеспечение качества кода/алгоритмов во время разработки, а не следовать методу «code and fix».
50. суть - создание прототипа для уточнения требований заказчика, затем доведение прототипа до состояния готового продуктаНедостатки: Очень тяжело привести проект к завершающей фазе Проект сложно планировать и финансировать В результате можно не получить ничего, кроме прототипа системы
67. AgileRational Unified Process - ход работ определяется целями проекта, выраженными в виде use cases - основой является архитектура результирующей программной системы - разработки основана на планируемых и управляемых итерациях
85. 3. Agile семейство гибких методологий разработки Характеристики: минимизация рисков разработка на базе коротких циклов (итераций) упор на общение в команде
86. 3.1. Ценности Agile личности и их взаимодействия; работающее программное обеспечение; сотрудничество с заказчиком; реакция на изменения.
87. 3.2. ПринципыAgile 1. удовлетворение клиента; 2. приветствие изменения требований; 3. частая поставка рабочего ПО; 4. ежедневное общение заказчика с разработчиками; 5. мотивированные личности, обеспеченные нужными условиями работы, поддержкой и доверием; 6. рекомендуемый метод передачи информации — личный разговор, лицом к лицу; 7. работающее ПО — лучший измеритель прогресса; 8. спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп работы;
88. 3.2. ПринципыAgile 9. улучшение технического мастерства и удобный дизайн; 10. простота и искусство не делать лишней работы; 11. самоорганизованная команда; 12. Частая адаптация к изменяющимся обстоятельствам.
90. 4. Методики семействаAgile 4.2. Agile Unified Process (AUP) -это упрощённая версия RUP (Rational Unified Process)
91. 4. Методики семействаAgile 4.3. Agile Data - это набор стратегий которые IT профессионалы используют для того чтобы эффективно взаимодействовать в плане использования данных в программных системах
92.
93. 4. Методики семействаAgile 4.6.Бережливая разработкаПО Принципы: Исключение затрат. Затратами считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение. Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком. Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
94. 4. Методики семействаAgile 4.6.Бережливая разработкаПО Принципы: Предельно быстрая доставка заказчику. Короткие итерации. Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий. Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг. Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, действовать мало, промахиваться быстро; учиться стремительно».
100. 4. Методики семействаAgile 4.7. Scrum: Daily Scrum Происходит каждый день начинается точно вовремя; ограничен 15-ю минутами; проводится в одном и том же месте Вопросы Daily Scrum : Что сделано с момента предыдущего митинга до текущего? Что будет сделано с момента текущего митинга до следующего? Какие проблемы мешают достижению целей спринта?
101. 4. Методики семействаAgile 4.7. Scrum: Demo Meeting ограничен 4-мя часами происходит в конце итерации демонстрируется инкремент функциональности продукта привлекается максимальное количество зрителей. все члены команды участвуют в демонстрации
102. 4. Методики семействаAgile 4.7. Scrum: Retrospective Meeting ограничен 1—3-мя часами. все члены команды рассказывают своё отношение к ходу прошедшего спринта; что было сделано хорошо в прошедшем спринте? что надо улучшить или не допускать в следующем? выполняют улучшение процесса разработки
103. Завершение Главное - не нужно хватать список методик и бежать к менеджеру с криками «Давайте работать по этим методикам» ))) Каждый программист – сам себе микро-менеджер, так как когда мы получаем задачу, то нам приходится решать, как её выполнять ))) Поэтому, прочитав об этих методиках, можно выделить лучшее для себя и изменить стратегию своей работы )) Менеджер будет рад )))