Анализ и оценка методов разработки программного обеспечения (Agile) — тест 1

Crystal-проекты должны соответствовать 3 основным показателям:

быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.
совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.
«осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.

Подробно семейство методологий описано в книге Алистера «Crystal Clear: A Human-Powered Methodology for Small Teams».

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

Основа гибкой методологии — разбиение проектов на маленькие рабочие кусочки, называемые пользовательскими историями. Согласно приоритетности задачи решают в рамках коротких двухнедельных циклов (итераций).

В начале команда изучает реальность разработки приложения и область применения. дальше работа делится на три взаимосвязанных цикла:

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

Feature driven development (fdd)

Методология, которая появилась даже раньше, чем «Манифест гибкой разработки ПО«.

12 принципов, которые составляют agile methodology, можно поделить на 4 главные идеи:

Приоритет людей и общения над инструментами и процессами;
Приоритет работающего продукта над полной документацией;
Приоритет сотрудничества с заказчиков над утверждением контракта;
Приоритет готовности меняться над следованием первоначально созданному плану.

Agile data method (adm)

ADM — набор итеративных методик гибкой разработки программного обеспечения, которые делают упор на формирование требования и решений по проекту через сотрудничество отдельных команд. Как и AUP, это не самоценная методика.

Agile modeling — набор ценностей, принципов и практик для моделирования программного обеспечения.

AM используют как составляющую полноценной методики разработки ПО — например, экстремального программирования или Rapid Application Development.

Agile показатели

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

Dynamic software development method (dsdm)

Над разработкой DSDM трудился не один человек и даже не команда, а консорциум из 17 английских компаний. DSDM, как и экстремальное программирование, используется преимущественно для создания программного обеспечения.

Essential unified process (essup)

Разработка шведского учёного Ивара Якобсона, созданная для улучшения Rational Unified Process.

Essup оперирует понятием практики, в которые входят:

сценарий использования — описание поведения системы.
итерационная разработка — создание рабочих кусков кода короткими циклами в несколько недель.
командные практики — направленные на сплочение команды и повышение её эффективности.
процессуальные практики — например, «Думай глобально, начинай с малого» или «Вовлекайте стейкхолдеров в бизнес-процессы».

Все практики в том или ином виде встречаются в методологиях RUP, CMMI и гибкой методике разработки.

Feature driven development состоит из таких цикличных этапов:

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

Getting real (gr)

Эффективная для стартапов и начинающих команд методология, которая предлагает по максимуму использовать особенности небольших проектов и компаний: мобильность, гибкость, поиск новых решений, отсутствие жёсткой запутанной иерархии и т.д. Джейсон Фрид и Давид Ханссон, основатели компании 37signals (теперь — Basecamp), определили Getting Real как систему для решения реальных задач: максимально простую, понятную и функциональную.

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

возможностей
опций и настроек
структуры компании
встреч
обещаний.

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

Lean software development

Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат.

Автор методики, скотт амблер, выделил следующие ключевые позиции agile unified process:

Ваша команда знает, что делает;
Простота превыше всего.
Соответствие принципам гибкой методологии разработки.
Сфокусированность на ценных для проекта активностях.
Независимость в выборе инструментов.
Индивидуальная настройка AUP под нужды конкретного проекта.

Анализ и оценка методов разработки программного обеспечения (agile) — тест 1

Главная / Менеджмент /
Анализ и оценка методов разработки программного обеспечения (Agile) / Тест 1

Гибкие материалы: Гибка листового металла, цена, услуга, гибка листа, купить в Тамбове | МеталлЭнергоХолдинг

В набор входят следующие 7 принципов:

избавление от потерь — всё, что не прибавляет ценности продукту для конечного потребителя.
постоянное обучение — непрерывное развитие команды увеличивает возможности эффективного выполнения задач.
принятие решения так поздно, как только можно — приоритет не спонтанным решениям, а продуманным, разработанным на основе полученных знаний.
быстрая доставка — по сути основа итеративной модели.
усиление команды — один из принципов «Манифеста…» гласит, что люди и взаимодействие важнее процессов и инструментов. Проектная команда — основа успешного завершения задач.
целостность и качество — нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от багов.
видение цельной картины — разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и стратегии разрабатываемого ПО.

В скрам есть 4 ключевых элемента:

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

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

Вердикт

С гибкой методологией разработки программного обеспечения небольшие проектные команды добиваются максимальной эффективности. Agile реализуется через другие гибкие методы: Scrum, XP, Lean и т.п.

Её невозможно реализовать с наскока, неопытной командой, за короткий отрезок времени, но внедрение Agile улучшит взаимодействие между IT и бизнесом, ускорит выход продукта на рынок, повысит ценность продукта для конечного пользователя.

Гибкая процессная методология agile ответы на тесты интуит

Ретроспектива — это

(1) Социальная технология, система управления, в которой полномочия и ответственность за принятие решений распределяются по самоорганизующимся единицам, вместо управленческой иерархии

(2) Коллективное обсуждение задачи или проблемы с целью выработки единой оценки по ее решению

(3) Согласование объема работ, которые нужно выполнить для того, чтобы владелец продукта на ближайшем демо был удовлетворен ценностью от реализованного командой инкремента

(4) Собрание, которое проводит проектная команда в конце каждой итерации, чтобы обсудить, чему мы научились, как команда и строить планы на следующие итерации, основываясь на извлечённых уроках

Инженерия требований представляет собой

(1) Графические инструменты моделирования бизнес-процессов, а также текстовые и табличные редакторы, в которых моделируются или описываются бизнес-процессы

(2) Поток, последовательно проходящих фаз анализа требований, проектирования, реализации, тестирования, интеграции и поддержки

(3) Социальную технологию, систему управления, в которой полномочия и ответственность за принятие решений распределяются по самоорганизующимся единицам, вместо управленческой иерархии

(4) Набор техник, методов и принципов связанных друг с другом

Для большинства проектов хватит 4 направлений метрик:

Производительность — сюда относятся Velocity и WIP. Первая подойдёт не для всех проектов, так как идет измеряются количество выполненных задач в итерацию, а они неравнозначны. Метрика Work-in-Progress определяет лимит задач на разных стадиях: и чем он выше, тем хуже;
Прогнозирование — метрика capacity: определение количества идеальных часов, доступных в следующем спринте. Соответственно, можно понять, сколько времени есть на работу, насколько эффективно выполнение задач и как спланировать количество задач для спринта;
Качество — например, индекс стабильности требований, который рассчитывается по формуле = (Общее количество оригинальных бизнес-требований Число требований, которые поменялись к этому времени Число добавленных требований Число убранных требований) / (общее число оригинальных требований). С помощью метрики определяется количество времени, затраченное на переделывание задач;
Ценности — в каждом случае просчитывается индивидуально, зависимо от формата проекта. Например, стартап AirBnb в качестве метрики, определяющую конечную ценность продукта для пользователей, выбрала количество загруженных фотографий высокого качества. С их увеличением пропорционально росло и количество потребителей.

К метрикам применимы те же правила, что и к другим Agile-инструментам.

Жесткие и гибкие методологии разработки |

Материал позаимствован с лекций Скопина И.Н.

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

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

Гибкие материалы: Электричество — вики по игре ARK: Survival Evolved

Таблица. Сопоставление жесткой и быстрой стратегий в методологиях программирования:

Жесткие методологии	Быстрые методологии
Ориентация на предсказуемые процессы разработки программного обеспечения с четко обозначенными целями	Осознание того, что процессы разработки программного обеспечения в принципе непредсказуемы
Распознавание ситуаций и применение готовых методов	Распознавание ситуаций и конструирование методов для работы в них
Планирование, в котором определяются этапы с объемом работ, ресурсами, сроками и уровнем качества работ	Соблюдение баланса между параметрами проекта: объем работ, ресурсы, сроки и уровень качества работ
Заказчик — внешний по отношению к проекту субъект, влияющий на разработку только через предоставление ресурсов и контроль результатов, в том числе по поэтапным срокам выполнения проекта	Заказчик (его представитель) — член команды разработчиков, наделенный правом влиять на разработку; его главной целью является отслеживание актуальности решаемых задач
Ролевое разделение труда работников проекта	Совместная деятельность сотрудников и деперсонифицированная ответственность
Дисциплина и подчинение	Самодисциплина и сотрудничество
Обезличенный процесс, исполнители которого определяются только по квалификационным требованиям	Процесс, максимально учитывающий личностные качества исполнителей

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

Методы присутствующие в agile:

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

Метод успешно применяют такие компании как Microsoft, Yahoo, Siemens Healthcare, а проектный менеджер в Amazon даже описал кейс внедрения Scrum на основе полученного опыта.

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

Минусы:

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

Приложения

Для ведения проектов с Agile подходят далеко не все сервисы или программы для проектного менеджмента, ведь у каждого есть своя специфика.

Если ваш бизнес относится к маркетинг и рекламным, дизайнерским, seo или digital агентствам, то saas-сервис Worksection можно применить для работы всей команды целиком. Нас рекомендуют COXO Digital, Royal ® Advertising и Prozorro.

Вот пара лайфхаков, чтобы настроить Agile в Worksection:

Миф № 1: agile подойдет для всех проектов.

Самое упорное заблуждение. Ни один метод Agile не добавит сам по себе ценности продукту и не смотивирует команду.

Гибкие материалы: Agile: 5 плюсов и 5 минусов - skademy.by

Миф № 2: agile против документации.

Гибкая методология разработки не против документации, она против документации как самоцели. А вот при выборе документации как средства коммуникации Agile действительно отдаёт приоритет живому общению.

Миф № 3: agile и планирование несовместимы.

Опровержением этого мифа служат дневные планирования с 10-минутными стэндапами, итерационное планирование каждые две недели, спринт-встречи и т.д.

Миф № 4: agile требует много переделывания (re-work).

В гибкой методологии разработки ПО переделывание проявляется в двух формах: переделывание требований (пользователи понимают, что им действительно нужно) и программного обеспечения (команды разработчиков находят улучшенные способы написать и спроектировать приложение).

Независимая от инструментов методология разработки по без жесткой структуры, которая содержит такие практики:

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

Нет единственно верной или нужной вашему проекту метрики.

Их нужно постоянно пересматривать, отбрасывать устаревшие и добавлять новые по мере необходимости. Она должна быть понятна и доступна всей всей команде, не превращаться в самоцель. Метрика ради метрики — плохое решение.

Он применим исключительно в сфере разработки по, и строится вокруг 4 процессов:

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

Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet.

Особая роль отводится участия конечного потребителя (пользователя) в процессе разработки. помимо этого принципа, к базовым относятся:

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

DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.

Плюсы:

вовлечение стейкхолдеров — у команды появляется больше возможностей понять желания клиента. А ранняя и частая доставка ПО усиливает доверие стейкхолдеров к проектной команде и еще глубже вовлекает в проект.
ранняя и предсказуемая доставка — модель разработки через итерации (короткие промежутки от 1 до 6 недель) дает гибкость, ускоряет выпуск релиза продукта.
фокусирование на бизнес-ценности — коллаборация с клиентом обеспечивает понимание командой того, как сделать продукт максимально ценным для потребителя.
непрекращающееся улучшение качества — тестирование во время каждой итерации, деление финального билда на отдельные куски рабочего кода позволяют улучшать и справляться с ошибками ПО до выхода финального продукта.

Принципы agile modeling таковы:

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

Разрушители мифов: agile

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

Суть agile data method определяется шестью положениями:

Данные — основа создания любого приложения.
Проблемы с проектом — их можно обнаружить только при чётком понимании цели и концепции проекта.
Рабочие группы — помимо непосредственной команды разработчиков есть enterprise groups, которые поддерживают другие рабочие группы.
Уникальность — нет идеальной методики, под каждый проект нужно комбинировать инструменты с разных методологий.
Работа в команде — совместная работа гораздо эффективнее, чем поодиночке.
«Сладкое пятно» — поиск оптимального решения проблемы («сладкого пятна»), избегая крайностей.

Хоть в fdd тоже применяется итерационная модель разработки, от agile она отличается в следующем:

больше внимания предварительному моделированию
повышенная (по сравнению с Agile) важность построения отчётности и графиков
нацелено на корпоративную разработку.