Гибкие методологии разработки по: Что такое Agile, зачем и где используется, разница Scrum и Kanban

Гибкая методология разработки ПО | GeekBrains

Что такое Agile и кому это нужно.

https://d2xzmw6cctk25h.cloudfront.net/post/1210/og_cover_image/7821d9d710832d18089c261711dd1ae1

В предыдущем тематическом посте мы рассмотрели 12 основных методологий программирования (и да, забыли Kanban). Самое время взглянуть на каждый из пунктов подробнее, познав суть, преимущества и недостатки, область применения. Начнем с одного из фундаментальных понятий — Agile-разработки.

Историческая справка

В 1970 году Уинстон Ройс опубликовал статью под названием «Управление разработкой больших программных систем» (Winston Royce, «Managing the Development of Large Software Systems»). В ней он жестко прошелся по традиционной каскадной модели, показав, что при неитерационной разработке качество продукта получается низкое, а цена каждой ошибки начального уровня велика. Кстати, именно Ройс впервые ввел понятие водопада для описания последовательного программирования.

В качестве альтернативы он привел гибкую модель разработки, когда продукт разрабатывается одновременно несколькими группами программистов, а объем определяется порядком итерации. Алгоритм такой: сначала планируется, создается и тестируются базовые возможности приложения, оно получает фидбэк от клиентов или руководства, после чего устраняются недостатки, добавляется функциональность, цикл повторяется вновь и так далее до бесконечности. В идеале каждая итерация должна занимать 2−4 недели, занятость программистов на всех этапах создания продукта должна быть равной.

Курица, яйцо и манифест

Идея гибкой разработки получила массу поклонников и, как следствие, ответвлений. Чтобы хоть как-то объединить их, в 2001 году свет увидел Agile Manifesto — идеологический набор правил разработки, что-то вроде «Цели и задачи в области качества» на предприятиях. Он содержит 4 идеи и 12 принципов, описанных в том числе на русском языке. Основа — регламентация приоритета между документами, инструментами и человеческими отношениями. В Agile ответ категоричен — люди и их желания первичны. Описанное в манифесте не является чем-то уникальным, подавляющее большинство моделей и методологий разработки основываются на том, что клиент всегда прав, а исполнитель должен иметь мотивацию и соответствующие условия труда. Однако именно здесь описанное стоит понимать буквально.

Основные этапы

Однако вернёмся к концепции гибкой разработки. Графически её можно представить следующим образом:

Важно помнить, что Agile — это общая концепция. Где-то под циклом понимается путь от анализа и планирования до выпуска, где-то это просто этап разработки, связанный с определённым уровнем сложности. Но везде есть 4 стадии:

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

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

Преимущества и недостатки

Начнём с плюсов:

1. Максимальная удовлетворённость клиента. У него есть постоянный контакт с разработчиками, его пожелания быстро находят отклик в проекте.
2. Благоприятная атмосфера в коллективе. Даже в случае разногласий эффективнее все решать словами.
3. Высокие цели. Постоянный фидбек предполагает внимание к мелочам, эргономике, соответствию трендам.
4. Безопасность. Множество итераций исключает существование ошибок, допущенных в самом начале.

Но есть и минусы:

1. Слабое внимание к документации. В случае возникновения претензий и конфликтных ситуаций аргументов в свою защиту у исполнителя просто не будет.
2. Проблемы с реализацией комплексных продуктов. Если в самом начале разработки были заложены ограничения — на поздних этапах исправлять их будет сложно.
3. Вероятность отказа клиентов в процессе разработки. Если у заказчика нет четкого понимания, что он хочет видеть на выходе — выполнять его требования очень сложно.
4. Влияние иерархии. Руководители принимают все решения, так как все процессы цикла реализуются параллельно. Важность рядовых программистов минимальна.

Agile-модель будет очень полезна начинающим компаниями и стартапам, когда необходимо привлекать клиентов и завоевывать авторитет. В крупных компаниях Agile в чистом виде применяется редко, лишь для отдельных проектов или отделов.

Что почитать

Отечественный и зарубежный рынок насыщен книгами по гибкой разработке, поэтому интересующимся не составит труда найти себе подходящее чтиво. Вот мой список ТОП-3:

1. «Постигая Agile. Ценности, принципы, методологии», Эндрю Стеллман, Дженнифер Грин. Издательство O’Reilly редко разочаровывает, эта книга — определённо не исключение. В ней вы узнаете и про общую концепцию, и подробнее про Scum, Kanban, XP и Lean.
2. «Гибкая разработка программ на Java и C++. Принципы, паттерны и методики», Роберт С. Мартин. Agile в прикладном применении.
3. «Пользовательские истории. Гибкая разработка программного обеспечения», Майк Кон. Истории правильного и неправильного применения гибкой разработки ПО, советы по внедрению конкретных методологий.

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

НОУ ИНТУИТ | Лекция | «Гибкие» (agile) методы разработки

Аннотация: Общее описание «гибких» методов разработки ПО. Extreme Programming: общее описание, основные принципы организации процесса. Scrum: общее описание, роли, практики.

Общее

«Гибкие» (agile) методы разработки ПО появились как альтернатива формальным и «тяжеловесным» методологиям, наподобие CMM и RUP. Талантливые программисты не желают превращения разработки ПО в рутину, хотят иметь максимум свобод и обещают взамен высокую эффективность. С другой стороны, практика показывает, что «тяжеловесные» методологии в значительном количестве случаев неэффективны. Основными положениями гибких методов, закрепленных в Agile Manifesto в 2007 году являются следующее¹:

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

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

Extreme Programming

Самым известным гибким методом является Extreme Programming (известное сокращенное название – XP). Он был создан талантливым специалистом в области программной инженерии Кентом Беком в результате его работы в 1996-1999 годах над системой контроля платежей компании «Крайслер».

Модель процесса по XP выглядит как частая последовательность выпусков (releases) продукта, столь частых, сколь это возможно. Но при этом обязательно, чтобы в выпуск входила новая целиковая функциональность. Ниже перечислены основные принципы организации процесса по XP.

1. Планирование (Planning Game), основанное на принципе, что разработка ПО является диалогом между возможностями и желаниями, при этом изменятся и то и другое.
2. Простой дизайн (Simple Design) – против избыточного проектирования.
3. Метафора (Metaphor) – суть проекта должна умещаться в 1-2 емких фразах или в некотором образе.
4. Рефакторинг (Refactoring) – процесс постоянного улучшения (упрощения) структуры ПО, необходимый в связи с добавлением новой функциональности.
5. Парное программирование (Pair Programming) – один программирует, другой думает над подходом в целом, о новых тестах, об упрощении структуры программы и т.д.
6. Коллективное владение кодом (Collective Ownership).
7. Участие заказчика в разработке (On-site Customer) – представитель заказчика входит в команду разработчика.
8. Создание и использование стандартов кодирования (Coding Standards) в проекте – при написании кода (создаются и) используются стандарты на имена идентификаторов, составление комментариев и т.д.
9. Тестирование – разработчики сами тестируют свое ПО, перемежая этот процесс с разработкой. При этом рекомендуется создавать тесты до того, как будет реализована соответствующая функциональность. Заказчик создает функциональные тесты.
10. Непрерывная интеграция. Сама разработка представляется как последовательность выпусков.
11. 40-часовая рабочая неделя.

Однако в полном объеме XP не была использована даже ее авторами и является, скорее, философией. Кроме того, известны и внедряются отдельные практики XP, как, например, парное программирование, коллективное владение кодом, и, конечно же, рефакторинг кода. Идея простого, неизбыточного дизайна проекта также оказала значительное влияние на мир разработчиков ПО.

Более практичным «гибким» методом разработки является Scrum.

Scrum

История. В 1986 японские специалисты Hirotaka Takeuchi и Ikujiro Nonaka опубликовали сообщение о новом подходе к разработке новых сервисов и продуктов (не обязательно программных). Основу подхода составляла сплоченная работа небольшой универсальной команды, которая разрабатывает проект на всех фазах. Приводилась аналогия из регби, где вся команда двигается к воротам противника как единое целое, передавая (пасуя) мяч своим игрокам как вперед, так и назад. В начале 90-х годов данный подход стал применяться в программной индустрии и обрел название Scrum (термин из регби, означающий — схватка), в 1995 году Jeff Sutherland и Ken Schwaber представили описание этого подхода на OOPSLA ’95 – одной из самых авторитетных конференций в области программирования. С тех пор метод активно используется в индустрии и многократно описан в литературе. Scrum активно используется также в России.

Общее описание. Метод Scrum позволяет гибко разрабатывать проекты небольшими командами (7 человек плюс/минус 2) в ситуации изменяющихся требований. При этом процесс разработки итеративен и предоставляет большую свободу команде. Кроме того, метод очень прост – легко изучается и применяется на практике. Его схема изображена на
рис.
11.1.

Рис.
11.1.

Вначале создаются требования ко всему продукту. Потом из них выбираются самые актуальные и создается план на следующую итерацию. В течение итерации планы не меняются (этим достигается относительная стабильность разработки), а сама итерация длится 2-4 недели. Она заканчивается созданием работоспособной версии продукта (рабочий продукт), которую можно предъявить заказчику, запустить и продемонстрировать, пусть и с минимальными функциональными возможностями. После этого результаты обсуждаются и требования к продукту корректируются. Это удобно делать, имея после каждой итерации продукт, который уже можно как-то использовать, показывать и обсуждать. Далее происходит планирование новой итерации и все повторяется.

Внутри итерации проектом полностью занимается команда. Она является плоской, никаких ролей Scrum не определяет. Синхронизация с менеджментом и заказчиком происходит после окончания итерации. Итерация может быть прервана лишь в особых случаях.

Роли. В Scrum есть всего три вида ролей.

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

Scrum-мастера (Scrum Master) обеспечивает максимальную работоспособность и продуктивную работу команды – как выполнение Scrum-процесса, так и решение хозяйственных и административных задач. В частности, его задачей является ограждение команды от всех воздействий извне во время итерации.

Scrum-команда (Scrum Team) – группа, состоящая из пяти–девяти самостоятельных, инициативных программистов. Первой задачей команды является постановка для итерации реально достижимых и приоритетных для проекта в целом задач (на основе Project Backlog и при активном участии владельца продукта и Scrum-мастера). Второй задачей является выполнение этой задачи во что бы то ни стало, в отведенные сроки и с заявленным качеством. Важно, что команда сама участвует в постановке задачи и сама же ее выполняет. Здесь сочетается свобода и ответственность, подобно тому, как это организовано в MSF. Здесь же «просвечивает» дисциплина обязательств.

Практики. В Scrum определены следующие практики.

Sprint Planning Meeting. Проводится в начале каждого Sprint. Сначала Produсt Owner, Scrum-мастер, команда, а также представители заказчика и пр. заинтересованные лица определяют, какие требования из Project Backlog наиболее приоритетные и их следует реализовывать в рамках данного Sprint. Формируется Sprint Backlog. Далее Scrum-мастер и Scrum-команда определяют то, как именно будут достигнуты определенные выше цели из Sprint Backlog. Для каждого элемента Sprint Backlog определяется список задач и оценивается их трудоемкость.

Daily Scrum Meeting – пятнадцатиминутное каждодневное совещание, целью которого является достичь понимания того, что произошло со времени предыдущего совещания, скорректировать рабочий план сообразно реалиям сегодняшнего дня и обозначить пути решения существующих проблем. Каждый участник Scrum-команды отвечает на три вопроса: что я сделал со времени предыдущей встречи, мои проблемы, что я буду делать до следующей встречи? В этом совещании может принимать участие любое заинтересованное лицо, но только участники Scrum-команды имеют право принимать решения. Правило обосновано тем, что они давали обязательство реализовать цель итерации, и только это дает уверенность в том, что она будет достигнута. На них лежит ответственность за их собственные слова, и, если кто-то со стороны вмешивается и принимает решения за них, тем самым он снимает ответственность за результат с участников команды. Такие встречи поддерживают дисциплину обязательств
в Scrum-команде, способствуют удержанию фокуса на целях итерации, помогают решать проблемы «в зародыше». Обычно такие совещания проводятся стоя, в течение 15-20 минут.

Sprint Review Meeting. Проводится в конце каждого Sprint. Сначала Scrum-команда демонстрирует Product Owner сделанную в течение Sprint работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных представителей заказчика. Product Owner определяет, какие требования из Sprint Backlog были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в Sprint Backlog для следующей итерации. Во второй части митинга производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда анализирует в последнем Sprint положительные и отрицательные моменты совместной работы, делает выводы и принимает важные для дальнейшей работы решения. Scrum-команда также ищет пути для увеличения эффективности дальнейшей работы. Затем цикл повторяется.

Рис.
11.2.

Как разработать “проект-огонь” с методологией Agile?

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

Что такое Agile?

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

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

Термин впервые употребили в 2001 году в США в штате Юта во время собрания 17 разработчиков, которые обсуждали свои идеи и программные подходы. Совокупность ценностей и принципов, предложенных ими, легла в основу Манифеста гибкой методологии разработки.

Что такое методология Agile в разработке программного обеспечения? 12 принципов Манифеста методологии

Как пользоваться Agile?

Цикл разработки состоит из 6 гибких этапов. Некоторые из них могут протекать параллельно. На словах распределение этапов может показаться непростым, поэтому процесс Agile-разработки визуализируют, используя, например, диаграммы Ганта.

6 этапов Agile-разработки:

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

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

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

• Внедрение, кодирование и развитие. А также создание и начальное тестирование основных функций.

• Тестирование. Специалисты проверяют код, чтобы убедиться, что продукт соответствует потребностям клиента. Этот этап включает в себя тестирование модулей, интеграций и систем.

• Выпуск. После всех видов тестирования, продукт передается заказчику.

Что такое гибкая методология разработки?

Инструменты Agile сконцентрированы на гибкости и усовершенствовании. Здесь мы объединили несколько основных преимуществ методологии Agile.

Как это работает? 6 ключевых преимуществ Agile для менеджеров проектов:

1. Приспособиться к изменениям в ходе реализации проекта с более короткими циклами планирования не составляет труда. Вы всегда можете уточнить и изменить приоритеты по отстающим вопросам. Также позволить команде вносить изменения в проект.
2. Конечная цель может быть невидимой. Методология Agile может быть полезна для проектов с неопределенными конечными целями.
3. Высокое качество и быстрые стандарты доставки. Из-за разбивки проекта на итерации, команды могут быть сфокусированы на разработке и тестировании.
4. Сильное взаимодействие команды. Методология обеспечивает прямое взаимодействие. Люди могут работать вместе и совместно брать на себя ответственность.
5. Клиенты могут работать в тесном сотрудничестве с командой. Они могут внести свой реальный вклад и оказать воздействие на продукт.
6. Постоянное улучшение. Проекты на основе метода Agile подразумевают обратную связь от пользователей и членов команды.

Читайте также: Критерии успешности проекта.

5 главных недостатков метода

Гибкость методологии довольно высока, но иногда происходят некоторые заминки. Вот некоторые недостатки гибкого метода программной разработки:

1. Процесс планирования может быть менее конкретным. Иногда бывает трудно определить конкретную дату поставки. Некоторые элементы, запланированные к реализации, могут не быть завершены в срок. Это происходит потому, что менеджеры часто вносят изменения приоритетов при решении текущих задач.
2. Команда должна знать все детали и факты. Как правило, команды Agile-проектов небольшие, и их участники должны быть «подкованы» в разных областях.
3. Время для развития. Успешное Agile-движение происходит тогда, когда команда полностью посвящена проекту.
4. Команды часто забывают о документации. Лучше всего найти баланс между бумажными вопросами и личными встречами.
5. Конечный продукт может сильно отличаться от того, что было изначально задумано. Вы можете добавлять новые итерации, поскольку метод подразумевает гибкость.

Основные обязанности менеджера Agile-проектов:

• Поддержание всех активностей и ценностей в проектной команде.
• Устранение помех и препятствий.
• Проведение и модерирование всех совещаний.
• Обсуждая путей преодоления препятствий.
• Работа с приоритетами, усиление отстающих вопросов в рамках процессов.
• Мотивирование. Руководители проектов должны быть основными мотиваторами для своих команд.

Читайте также: О методе критического пути (critical path method) и иерархической структуре управления.

Сравнение гибких методологий

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

Список методов Agile:

XP (Extreme Programming)

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

Экстремальное программирование названо так потому, что преимущественные элементы традиционной практики разработки программного обеспечения подняты на «экстремальный» уровень.

FDD (Feature driven development)

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

ASD (Adaptive system development)

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

Kanban

Название метода происходит от японского слова, которое означает «визуальные карты или бильборд». Это наглядная основа внедрения Agile, которая способствует мелким и непрерывным изменениям в существующей системе проекта.

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

Crystal Clear

Crystal Clear – еще один пример методологии Agile. Он чаще всего используется командами из 6- 8 разработчиков. Crystal Clear преимущественно сфокусирован на людях, а не на процессах.

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

Scrum

Scrum лучше всего отражает функции Agile-управления. Спринты длятся 1-2 недели и позволяют командам поставлять программное обеспечение на регулярной основе.

Scrum-разработка: участники процесса

В управлении проектами с помощью Scrum обязанности распределены между владельцем продукта, Scrum-мастером и командой.

• Владельцы продукта несут ответственность за все бизнес-вопросы проекта. Они имеют право принимать решения о продукте и могут сбалансировать все приоритеты.

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

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

5 ресурсов для работы с Agile-проектами

JIRA

Одна из классических систем для решения задач и управления проектами онлайн. Задачи в JIRA состоят из названия, типа, темы, приоритетности, содержания и компонентов.

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

HP Agile Manager

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

GanttPRO

Сервис, основанный на использовании онлайн диаграмм Ганта, помогает создавать объемные проектные планы за короткое время и позволяет качественно руководить ими. Менеджеры могут делиться полученными графиками и экспортировать их в отчеты, бизнес-планы и презентации.

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

Basecamp

Сервис, известный аж с 2004 года, постоянно подвергается обновлениям и инновационным правкам. Разработчики Basecamp постоянно выпускают виджеты и плагины для интеграции, предоставляют доступ к API, поддерживают мобильные клиенты.

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

Bipulse

Сервис для планирования и управления проектами позволяет предсказывать сроки завершения проекта на основе Agile-метрик, рассчитывать календарное расписание критической цепи, интегрироваться с популярными трекерами задач и многое другое.

Пример работы с проектом в JIRA:

Пример работы с проектом в GanttPRO:

А вы использовали методологию Agile в своей работе?

Что вы можете сказать о результатах вашего проекта?

Получился ли тот самый “огонь”?!

О (гибких) методологиях / Хабр

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

Плохих и хороших методологий не существует. Существуют подходящие, и не подходящие.

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

Перед тем, как внедрять методологию нужно составить список причин, почему эта методология не подойдет. В светском мире это называется “оценка рисков”.

Все споры о том, нужна ли документация или нет, нужен ли PM или нет и т.д. бессмысленны без рассмотрения конкретной команды/заказчика/условий.

В agile методологий есть один очень существенный недостаток — коллективная ответственность (т.е. её полное отсутствие на практике).

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

«Чистых» внедрений тех или иных методологий в реале практически не существует.

Agile — это как HTML5 на мобилках. На словах круто, но все педалят нативные приложения.

Есть мнение, что те, кто не любит agile — просто не умеют его готовить (внедрять). Ок.

Два самых эпических внедрения скрама моей практике: 1) внедрение в research & development проекте (R&D — это когда любая оценка задачи неточна чуть более чем полностью) в команде из одного человека 2) внедрение скрама в команде, которую еще не набрали. В обеих случаях проекты завершились эпическим фейлом.

Нужно ли изучать различные методологии? — Да. Нужно ли применять одну методологию? — Нет.

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

Методологии — ничто, люди — всё.

Ну и качестве завершения анекдот в тему: — Здравствуйте! Перепишите на меня свою компанию. — Что!? — Ой, извините, не с того начал. Вы используете Agile?

Спасибо за внимание!

НОУ ИНТУИТ | Лекция | Гибкие технологии разработки ПО

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

Презентацию к данной лекции Вы можете скачать здесь.

Цель лекции:

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

Введение

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

При использовании гибких методологий минимизация рисков осуществляется путём сведения разработки к серии коротких циклов, называемых итерациями, продолжительностью 2 -3 недели. Итерация представляет собой набор задач, запланированных на выполнение в определенный период времени. В каждой итерации создается работоспособный вариант программной системы, в которой реализуются наиболее приоритетные (для данной итерации) требования заказчика. На каждой итерации выполняются все задачи, необходимые для создания работоспособного программного обеспечения: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что текущий программный продукт готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов требований к программному продукту, возможно, вносит коррективы в разработку системы.

Принципы и значение гибкой разработки

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

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

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

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

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

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

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

Оперативное реагирование на изменения важнее следования плану. Способность реагирования на изменения во многом определяет успех программного проекта. В процессе создания программного продукта очень часто изменяются требования заказчика. Заказчики очень часто точно не знают, чего хотят, до тех пор, пока не увидят работающее программное обеспечение. Гибкие методологии ищут обратную связь от заказчиков в процессе создания программного продукта. Оперативное реагирование на изменения необходимо для создания продукта, который удовлетворит заказчика и обеспечит ценность для бизнеса.

Постулаты гибкой разработки поддерживаются 12 принципами [11]. В конкретных методологиях гибкой разработки определены процессы и правила, которые в большей или меньшей степени соответствуют этим принципам. Гибкие методологии создания программных продуктов основываются на следующих принципах[12]:

1. Высшим приоритетом считать удовлетворение пожеланий заказчика посредством поставки полезного программного обеспечения в сжатые сроки с последующим непрерывным обновлением. Гибкие методики подразумевают быструю поставку начальной версии и частые обновления. Целью команды является поставка работоспособной версии с течение нескольких недель с момента начала проекта. В дальнейшем программные системы с постепенно расширяющейся функциональностью должны поставляться каждые несколько недель. Заказчик может начать промышленную эксплуатацию системы, если посчитает, она достаточно функциональна. Также заказчик может просто ознакомиться с текущей версией программного обеспечения, предоставить свой отзыв с замечаниями.
2. Не игнорировать изменение требований, пусть даже на поздних этапах разработки. Гибкие процессы позволяют учитывать изменения для обеспечения конкурентных преимуществ заказчика. Команды, использующие гибкие методики, стремятся сделать структуру программы качественной, с минимальным влиянием изменений на систему в целом.
3. Поставлять новые работающие версии ПО часто, с интервалом от одной недели до двух месяцев, отдавая предпочтение меньшим срокам. При этом ставится цель поставить программу, удовлетворяющую потребностям пользователя, с минимумом сопроводительной документации.
4. Заказчики и разработчики должны работать совместно на протяжении всего проекта. Считается, что для успешного проекта заказчики, разработчики и все заинтересованные лица должны общаться часто и по многу для целенаправленного совершенствования программного продукта.
5. Проекты должны воплощать в жизнь целеустремленные люди. Создавайте команде проекта нормальные условия работы, обеспечьте необходимую поддержку и верьте, что члены команды доведут дело до конца.
6. Самый эффективный и продуктивный метод передачи информации команде разработчиков и обмена мнениями внутри неё — разговор лицом к лицу. В гибких проектах основной способ коммуникации — простое человеческое общение. Письменные документы создаются и обновляются постепенно по мере разработки ПО и только в случае необходимости.
7. Работающая программа — основной показатель прогресса в проекте. О приближении гибкого проекта к завершению судят по тому, насколько имеющаяся в данный момент программа отвечает требованиям заказчика.
8. Гибкие процессы способствуют долгосрочной разработке. Заказчики, разработчики и пользователи должны быть в состоянии поддерживать неизменный темп сколь угодно долго.
9. Непрестанное внимание к техническому совершенству и качественному проектированию повышает отдачу от гибких технологий. Члены гибкой команды стремятся создавать качественный код, регулярно проводя рефакторинг.
10. Простота — искусство достигать большего, делая меньше. Члены команды решают текущие задачи максимально просто и качественно. Если в будущем возникнет какая-либо проблема, то в качественный код имеется возможность внести изменения без больших затрат.
11. Самые лучшие архитектуры, требования и проекты выдают самоорганизующиеся команды. В гибких командах задачи поручаются не отдельным членам, а команде в целом. Команда сама решает, как лучше всего реализовать требования заказчика. Члены команды совместно работают над всеми аспектами проекта. Каждому участнику разрешено вносить свой вклад в общее дело. Нет такого члена команды, который единолично отвечал бы за архитектуру, требования или тесты.
12. Команда должна регулярно задумываться над тем, как стать ещё более эффективной, а затем соответственно корректировать и подстраивать свое поведение. Гибкая команда постоянно корректирует свою организацию, правила, соглашения и взаимоотношения.

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

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

Ключевые термины

Краткие итоги

Гибкая методология разработки программного обеспечения ориентирована на использование итеративного подхода, при котором программный продукт создается постепенно. Программный продукт создается за несколько итераций, включающих реализацию определенного набора требований. Итерации имеют длительность 2 -3 недели. Результатом итерации является промежуточный вариант работоспособного программного обеспечения. Для методологии гибкой разработки декларированы ключевые постулаты и принципы. Принципам гибкой разработки ПО, в определенной степени, соответствуют ряд методологий.

Набор для практики

Вопросы

1. Поясните понятие «гибкая методология разработки программного обеспечения».
2. Какие компетенции необходимы для команды разработчиков, использующих гибкие методологии.
3. Как управляют рисками в гибких методологиях разработки ПО?
4. Какие задачи выполняются на итерациях в методологии гибкой разработки?
5. Назовите ключевые ценности методологий гибкой разработки ПО.
6. Назовите основные принципы гибкой разработки ПО.
7. Какие существуют методологии, которые соответствуют принципам гибкой разработки ПО?
8. Поясните, как в гибком подходе относятся к документированию и выпуску работоспособного кода.
9. Поясните, как должно быть организовано взаимодействие с заказчиком в гибком подходе к разработке ПО.
10. Поясните, как относятся к изменениям в гибком подходе к разработке ПО.

Упражнения

1. Проведите анализ возможностей методологии AgileUnifiedProcess.
2. Проведите анализ возможностей методологии AgileDataMethod.
3. Проведите анализ возможностей методологии Featuredrivendevelopment.

Бесплатная электронная книга по гибким методологиям разработки / Хабр

Хабравчане, позвольте вам представить мой небольшой и скромный труд (чуть больше 100 страниц) по гибким методологиям разработки. Электронная книга доступна бесплатно для скачивания со следующих сервисов в PDF:

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

Содержание

• Предисловие
• Agile-методологии
• Scrum – гибкий управленческий фреймворк
• Управление продуктом
• Управление командой
• Управление контрактами
• Управление рисками
• Инженерные практики
• Контроль и обеспечение качества
• Анализ требований
• Масштабирование Agile
• Бережливое производство
• Как внедрить Agile за 14 недель
• Гибкие компании-аутсорсеры
• Консалтинг-компании и независимые тренеры

Благодарности

Спасибо всем, кто помогал в работе над данными материалами, в том числе по плану внедрению Agile: Евграшин Тимофей, Гармаш Максим, Ковязин Егор, Козлов Илья, Колосова Ксения, Лукьянчикова Наталья, Паньшин Дмитрий, Подурец Михаил, Рогачев Сергей, Свердлов Андрей, Сорокин Евгений, Сурикова Ирина, Тарасенко Анна, Уразбаев Асхат, Шабакаева Лия.
Особую благодарность также выражаю многочисленным рок и хард-рок группам, без которых создание этой книги было бы невозможно.,

На всякий случай

Эта книга не претендует на звание «единого и непогрешимого» источника знаний по гибким методологиям, потому что они постоянно развиваются: появляются новые подходы, дорабатываются старые и расширяются сферы применения.
Также на этих страницах отражено исключительно моё мнение и понимание гибких методологий, не связанное с моими нынешними или будущими работодателями или сообществами, в которых я состою. Тем не менее, не отрицаю их сильного влияния на меня.
Если у вас есть конструктивные замечания/предложения по данной книге с удовольствием приму их к сведению. Если замечания еще и грамотно оформлены, готов включить их в виде цитат.
Мои контакты указаны в книге, ну а троллить предлагаю в комментариях 🙂

Рецензии

Топ-5 инструментов управления Agile-проектами / Блог компании DataArt / Хабр

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Agile-манифест

Испытывают ли разработчики ПО необходимость в инструментах для управления проектом? Могут ли такие инструменты помочь в написании качественного продукта?

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

Идеальный рабочий процесс.

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

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

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

Эффективность и качество разработки зависят от целого ряда факторов:

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

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

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

Обзор

Сейчас на рынке представлено более ста решений по управлению проектами, у каждого есть сильные и слабые стороны. Эта статья — обзор самых популярных инструментов управления Agile-проектами по версии опроса, проведенного среди коллег в DataArt.

В опросе участвовали 39 человек из 32 проектов, их роли распределились следующим образом:

Роли респондентов.

Среди инструментов управления Agile-проектами самыми популярными стали:

• Jira
• TFS
• Version One
• Rally
• Spreadsheet

VersionOne

URL: www.versionone.com
Ключевые особенности VersionOne

• управление Agile Portfolio;
• репортинг и аналитика;
• планирование и роадмаппинг продукта;
• планирование и роадмаппинг релиза;
• планирование спринта;
• управление процессом тестирования;
• открытый API для интеграции.

Краткий обзор VersionOne

Универсальный инструмент управления проектами и командами любого размера. VersionOne считаются пионерами в производстве ПО для управления Agile-продуктами. По сей день они остаются компанией, всецело преданной философии Aglie.

Тарифы VersionOne
www.versionone.com/pricing_and_editions

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

Преимущества использования

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

Скриншоты

JIRA

Ключевые особенности JIRA

• Контроль проекта.
• Agile, Scrum, Kanban.
• Планирование проекта.
• Учет ошибок (Issue Tracking).
• Возможность интеграции с кодом.
• Служба техподдержки.
• Доступность с мобильных девайсов.
• Возможность кастомизации рабочего процесса.
• Составление отчетности.
• Аутентификация через LDAP и Active Directory.
• Система учета ошибок (Bug Tracking).
• Интеграция с Git.
• 1000+ всевозможных дополнений, расширений, плагинов.
• Email-уведомления.
• Возможность самостоятельно определять и изменять вычислительные потребности (On Demand).
• Бесплатна для Open source-проектов.

Краткий обзор JIRA

Тысячи команд выбрали JIRA, чтобы организовать процесс, распределять работу и отслеживать деятельность команды. Используя стационарный или мобильный интерфейс, JIRA помогает команде выполнять работу.

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

Отслеживание проекта: JIRA позволяет централизованно управлять всеми проектами, не теряя из виду общую картину.

Разработка ПО

После системы контроля версий JIRA — самое важное приложение в для команды разработчиков, поскольку позволяет достаточно легко адаптироваться к использованию scrum и Kanban.

Рабочий процесс

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

Работа внутри команды

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

Сбор ошибок

С JIRA Service Desk команда получает современный гибкий сервис поддержки, который способен оптимально организовать запросы от клиентов.

Детали

Тарифы JIRA
www.atlassian.com/software/jira/agile

Облако

Сервер

Механизм ценообразования: подписка.
Бесплатная пробная версия: доступна.

Преимущества использования:

Agile в масштабе

Scrum и Kanban повышают вероятность успеха проекта. JIRA интегрируется с GitHub, чтобы связать дефекты с соответствующими исправлениями.

Движок для создания рабочего процесса.

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

Пользовательский опыт

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

Гибкие панели мониторинга (Dashboards)

Создавайте свой личный JIRA дашборд, позволяющий в удобном для вас виде отслеживать состояние проекта, создавать пользовательские отчеты.

Мощный инструмент поиска и отчетности

Используйте JIRA’s Query Language (JQL) с автозаполнения для создания расширенных запросов. Такие запросы позволяют отслеживать статус проекта, включать необходимые метрики в отчеты, отслеживать прогресс команды.

Варианты развертывания

Доступны инсталлеры под Windows и Linux для решения OnPremise. Есть возможность начать с JIRA OnDemand а позже перейти на OnPremise.

Интеграция

Получите больше от JIRA с гибким REST и Java API — плюс более 600 плагинов и дополнений в Atlassian Marketplace, чтобы соединиться с приложениями и инструментами, которые вы используете каждый день.

Скриншоты

Rally Software

Ключевые особенности Rally Software

• Гибкая ценовая политика.
• Дополнения и расширения Rally Apps.

Краткий обзор Rally Software

Rally Software — инструмент управления проектами, которая использует Agile- и lean-методы, чтобы помочь предприятиям в разработке ПО. С акцентом на Aglie-методологии, ралли помогает предприятиям всех размеров постепенно внедрять полезные практики, позволяющие сокращать циклы разработки и улучшать сотрудничать в распределенных командах.

Под влиянием Agile и Lean принципов, Rally представляет первое решение для управления Agile-портфолио, которое позволяет:

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

Скриншоты

Тарифы Rally Software

Механизм ценообразования: Фримиум, подписка

 
FREE for up to 10 users

Преимущества использования

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

TFS

Ключевые особенности

• Система контроля версий.
• Agile-планирование.
• Управление тест-кейсами.
• Репортинг.

Управлять репозиториями, выстраивать процессы, инфраструктуру тестирования и развертывания, получать статус и репортинг — все это легко с Team Foundation Server, инструментом управления жизненным циклом приложения в Visual Studio. Оно позволяет всем заинтересованным сторонам участвовать разработке, используя единое решение. Используйте TFS, чтобы управлять разнородными проектами и командами.

Система контроля версий

Поддержка централизованной (Team Foundation Version Control) или распределенной (Git) системы в Team Foundation Server дает команде возможность гибко использовать технологию контроля версий, которая лучше подходит для нее.

Agile-планирование и взаимодействие

Адаптируйте Agile-практики в подходящем вам темпе, используя шаблоны для Scrum, Agile или CMMI®. Можно скачать шаблоны процессов или создать собственные. Все участники проекта вовлекаются в рабочий процесс с помощью Kanban-досок и постоянно получают друг от друга обратную связь.

Билды

TFS помогает выявить ошибки и проблемы с качеством продукта на ранней стадии. Настройка непрерывной интеграции (continuous integration) с запуском интеграционных тестов повышает уверенность в качестве билдов.

А еще TFS позволяет получить информацию о статусе последней сборки и на домашней странице проекта, и через Visual Studio.

Веб интерфейс для управления тест-кейсами

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

Отчетность

Механизм репортинга в Team Foundation Server 2013 отслеживает различные виды работ, чтобы создавать отчеты на основе текущего состояния. А шаблоны для получения информации можно брать готовые или составлять самим.

TFS Цена

 
Ценовая политика: подписка, бесплатная 90-дневная версия.

Скриншоты

Google Docs

Особенности

• Бэклог и диаграмма сгорания продукта.
• Бэклог и диаграмма сгорания для спринта.
• Бэклог для сдерживающих факторов.
• Burndown chart, team velocity.

Специально созданные Scrum-темплейты помогают управлять небольшим проектом. Самое главное достоинство решения — простота: не требуется никакой дополнительной инсталяции и настройки. Google Docs — отличный выбор для распределенных команд.

Скриншоты

Цена Google Docs
Ценовая модель: бесплатно (1 Гб дискового пространства).

Заключение

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

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

У рассмотренных продуктов (кроме Google Docs) есть бесплатная пробная версия. За это время команда может проверить инструмент в действии на реальном проекте и посмотреть, насколько инструмент помогает в решении вопросов разработки и планирования.

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

Microsoft TFS не отстает от конкурентов. Преимущества продукта особенно ощутимы, когда команда уже использует другие решения от Microsoft.

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

Google Docs — удобный инструмент для небольших команд со сравнительно простыми процессами. Основное преимущество (кроме бесплатности) — легкость в использовании и интуитивно понятные интерфейс.

Надеюсь, обзор был полезен и поможет выбрать правильный инструмент.

Автор: Евгений Толбаков.

Обзор наиболее популярных методологий разработки программного обеспечения

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

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

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

1. Гибкость

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

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

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

Индивидуальные agile-методологии включают Scrum и Kanban.

2. Скрам

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

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

В Scrum-методологии стартовым документом является так называемый product backlog — список пожеланий к результатам. Его оценивают по важности, а иногда и по сложности. В период реализации проекта бэклог продукта может быть изменен командой scrum.

3. Канбан

Как и описанный выше Scrum, Kanban является одним из возможных способов реализации гибкой (Agile) методологии разработки программного обеспечения.Его задача — сбалансировать разных специалистов внутри команды и эффективно распределить между ними работу.

Бизнес-процесс разделен не на универсальные спринты, а на этапы выполнения конкретных задач: «Запланировано», «Разработано», «Протестировано», «Завершено» и т. Д. Канбан-подход был разработан, чтобы помочь использовать доступные ресурсы в самый эффективный способ, быстро находить возникающие проблемы и решать их в короткие сроки.

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

Канбан менее строг, чем Scrum — время спринтов там не ограничено, нет ролей, кроме product owner-а.

4. Водопад

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

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

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

5. Постное

Модель Lean Software Development — один из типов гибких методологий разработки программного обеспечения.В процессе работы разработчики выделяют основные и второстепенные элементы проекта. Главные имеют большую ценность, а из второстепенных достается больше всего.

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

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

Принципы бережливого производства:

• Снижение убытков. Чтобы не платить больше и не тратить время зря, разработчики анализируют проект перед началом работы и оставляют только основные функции.
• Качество постройки. Разработчик тестирует проект, вносит правки и устраняет ошибки на каждом этапе.
• Быстрая отчетность. Обратная связь очень важна для эффективной работы разработчика, поэтому он своевременно предоставляет заказчику подробную информацию.
• Общая оптимизация системы.Система оптимизируется не по отдельным процессам, а целиком.

Сводка

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

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

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

.

Объяснение 13 методологий разработки программного обеспечения

Этот пост был первоначально опубликован 26 апреля 2019 г. и последний раз обновлялся 14 сентября 2020 г.

Какими бы сложными ни были создание и приоритезация отставания по продукту, выбор методологии разработки программного обеспечения, которую вы собираетесь использовать для решения этой проблемы, может быть сложнее. Хотя каждая методология гарантирует, что программное обеспечение соответствует его требованиям, каждая имеет свой уникальный набор плюсов и минусов. Чтобы помочь вам сделать выбор, мы создали исчерпывающее руководство по наиболее популярным методологиям разработки программного обеспечения на сегодняшний день.Давайте нырнем!

Модель водопада

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

Источник: tutorialspoint.com

Плюсы:

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

Минусы:

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

Методология прототипа

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

Источник: tryqa.com

Плюсы:

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

Минусы:

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

Методология гибкой разработки программного обеспечения

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

Источник: financesonline.com

Плюсы:

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

Минусы:

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

Быстрая разработка приложений (RAD)

Цель состоит в том, чтобы обеспечить более быстрые и качественные результаты, чем вы могли бы достичь с помощью любого из других вариантов.Это связано с методологией Agile-разработки, поскольку в ней упор делается на работающее программное обеспечение и отзывы пользователей в пользу планирования. Короче говоря, это меньше разговоров, больше тестирования.

Источник: kissflow.com

Плюсы:

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

Минусы:

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

Методология разработки моделей динамических систем

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

Источник: acodez.in

Плюсы:

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

Минусы:

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

Модель спирали

Эта модель ориентирована на раннее выявление рисков. Разработчики начинают с изучения потенциальных проблем на раннем этапе, когда проект все еще невелик. Затем они оценивают риски, связанные с развитием проекта, и составляют планы либо оставить проект в том виде, как он есть, либо решить проблемы, а затем перейти к следующей итерации «спирали».

Источник: geeksforgeeks.org

Плюсы:

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

Минусы:

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

Методология экстремального программирования

Методология экстремального программирования (также известная как методология XP) используется, когда командам разработчиков необходимо создавать программное обеспечение в нестабильной среде, например, когда требования клиентов быстро меняются. Он включает частые «выпуски» в короткие циклы разработки и «контрольные точки», во время которых они могут добавлять новые требования клиентов.

Источник: airbrake.io

Плюсы:

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

Минусы:

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

Разработка на основе функций (FDD)

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

Источник: Hangoutagile

Плюсы:

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

Минусы:

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

Методология совместной разработки приложений

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

Источник: www.velvetech.com

Плюсы:

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

Минусы:

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

Методология бережливого развития

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

Источник: toolsqa.com

Плюсы:

• Повышенная эффективность ускоряет разработку и снижает общую стоимость проекта.
• Более быстрая разработка означает, что команда разработчиков может предоставить больше функциональности за более короткий период.
• Команда разработчиков имеет больше полномочий в принятии решений, что расширяет возможности людей и помогает мотивации и, следовательно, прогрессу. Бережливый подход следует гибкому принципу «Найдите хороших людей и позвольте им делать свою работу.”

Минусы:

• Успех зависит от дисциплины, приверженности и технических способностей команды. Может потребоваться дополнительное обучение, чтобы убедиться, что команда работает на должном уровне.
• Эта методология требует от бизнес-аналитика проверки правильности документации и ее понимания всеми участниками.
• Слишком большая гибкость разработчика может привести к недостаточной концентрации внимания, что, в свою очередь, может повредить рабочий процесс всего проекта. Вот где действительно может помочь хорошее программное обеспечение для управления проектами.

Методология рационального унифицированного процесса (RUP)

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

Источник: testbytes.net

Плюсы:

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

Минусы:

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

Методология разработки Scrum

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

Источник: stackify.com

Плюсы:

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

Минусы:

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

Методология развертывания DevOps

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

Источник: softwaretestinghelp.com

Плюсы:

• Время от разработки до выхода на рынок значительно сократилось
• Меньше ошибок или сбоев в процессе, что делает его эффективным и точным
• Большая часть процесса автоматизирована, что помогает ускорить процесс и позволяет членам команды, работающим над проектом, более целенаправленно использовать свое рабочее время

Минусы:

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

Заключительные мысли

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

Опробовать некоторые из этих методологий на пробной основе для одних проще, чем для других, поэтому убедитесь, что вы готовы и можете совершать, проверять и изменять при необходимости. Со временем вы обнаружите, какая методология (или их сочетание!) Работает для вашей команды.

Сотрудничайте и воплощайте свои проекты в жизнь с помощью Backlog

Джорджина Гатри

Джорджина — перемещенная британка, в настоящее время работающая во Франции в качестве внештатного копирайтера. Прежде чем переехать в более солнечный климат, она работала писателем в агентстве B2B в Бристоле, Англия, где она также родилась. В свободное время любит старые фильмы и готовит (плохо).

.

8 популярных методологий разработки программного обеспечения

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

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

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

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

Есть Lean, Agile, Scrum, Kanban, Waterfall и все, что между ними. Но какая методология лучше всего подходит для вашей организации и вашей продуктовой группы? Это руководство поможет вам в этом.

Готовы приступить к созданию улучшенных дорожных карт? Ознакомьтесь с нашим подробным руководством здесь .

Выбор фреймворка для разработки

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

Прежде чем рассматривать идею перехода вашей организации на какую-либо из этих методологий, обязательно оцените следующее:

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

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

Совместимость инструментов и методологий: Оцените имеющиеся инструменты на уровне продукта и проверьте, будут ли они хорошо работать с выбранной вами структурой. Готовы ли вы и ваша команда отказаться от них ради чего-то, что лучше соответствует методологии?

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

1. Он должен приносить максимальную пользу пользователям, не усложняя работу групп разработчиков и разработчиков продукта.
2. Он должен хорошо соответствовать бизнес-целям, операциям и продуктам организации
3. Он должен устранить ограничения, риски, бесполезную трату ресурсов и в целом улучшить процесс разработки продукта.Это означает более быстрое время вывода продукта на рынок, более высокую удовлетворенность пользователей и более широкие возможности команд разработчиков.

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

1. Бережливое развитие

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

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

1. Более глубокое понимание потребностей пользователей. Сделайте их приоритетными, когда пришло время составить документ с требованиями

2. Уменьшите количество отходов. Это включает узкие места и утечку ресурсов.Если ваши пользователи не будут за это платить, это будет пустой тратой вашего времени, денег и командных усилий. Бережливое производство выделяет следующие три типа устранения отходов:

• Muda: Удаление частей процесса, которые не добавляют ценности для клиента (прямо или косвенно)
• Mura: Устранение отклонений на уровне операций для обеспечения наиболее быстрых и плавных процессов
• Мури: Устранение перегрузки. Таким образом, команды становятся менее напряженными и более продуктивными, когда они работают в удобном темпе.

3.Всегда проверять (ABV): Для этого используйте первый принцип. Используйте отзывы пользователей и исследования, чтобы повторять и проверять идеи, и делайте это постоянно.

4. Повышение видимости и прозрачности данных: Создавайте базы знаний и репозитории, чтобы их могли видеть команды и заинтересованные стороны. Поделитесь результатами проверочных экспериментов, чтобы каждый мог извлечь из них уроки.

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

Преимущества бережливой разработки

• Устранение отходов ведет к оптимизации процесса разработки продукта, что снижает утечку ресурсов.Lean может помочь организациям сэкономить на самых важных ресурсах на бизнес-уровне: времени, деньгах и усилиях
• Это может помочь продуктовым командам лучше понять, что клиенты ищут в продукте, сосредоточившись на наблюдении за их поведением, глубоко сочувствуя проблемам, которые они пытаются решить, и превращая обратную связь в практические эксперименты.
• Это ускоряет процесс обучения, а затем ускоряет процесс предоставления функций.
• Повышает продуктивность команды за счет устранения расточительных методов работы
• Легко масштабируется

Недостатки бережливой разработки

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

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

2. Схватка

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

На

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

Официальное руководство по Scrum описывает набор ценностей, лежащих в основе Scrum:

1. Приверженность достижению целей высокого уровня и командного уровня
2. Смелость решать любую проблему, какой бы сложной она ни была
3. Сосредоточьтесь на работе, определенной во время спринта
4. Открытость с заинтересованными сторонами о проблемах, с которыми сталкивается команда

Когда эти ценности внедряются всеми, столпы, составляющие методологию Scrum, воплощаются в жизнь.Эти три столпа:

1. Прозрачность. Обеспечение прозрачности продукта, бизнес-целей и целей организации, а также того, как каждый член команды отвечает за их выполнение
2. Осмотр. Частые проверки, чтобы убедиться, что текущие усилия команды согласованы с целями продукта, бизнеса и организации
3. Адаптация. Внесение изменений как можно скорее при обнаружении этих недостатков в процессе

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

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

Преимущества Scrum

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

Недостатки Scrum

• Оценка ресурсов. Из-за отсутствия полного представления о процессе разработки продукта трудно точно оценить, сколько времени, денег и усилий команды потратят.
• Лучше всего подходит для небольших команд и динамичных проектов. Крупные организации все еще могут внедрять Scrum, но им нужна строгая и целеустремленная структура, которая помогает им в этом, как SAFe и LeSS
• Нет жестких сроков. Из-за этого сложно сказать, когда будет выпущено обновление или выпуск.
• Требуется высококвалифицированная команда. И если команда плохо разбирается в том, как использовать ценности и практики Scrum, организация должна инвестировать в инициативы по обучению.

Ознакомьтесь с нашей библиотекой 35+ шаблонов дорожных карт . Получите доступ к ним бесплатно, подписавшись на пробную версию Roadmunk.

3. Канбан

Kanban, как и Scrum, представляет собой еще одну гибкую среду, которая ориентирована на ранние непрерывные выпуски и создание высокоэффективных групп разработчиков продуктов. В отличие от Scrum, у Kanban нет предопределенных ролей и событий, он гибок, когда дело доходит до внесения изменений, и полагается на непрерывную доставку в течение ограниченных по времени спринтов.

Для Канбана нет определенного набора правил, только несколько общих принципов:

1. Визуализируйте рабочий процесс. В частности, повседневные задачи каждого в контексте работы друг друга
2. Ограничить незавершенное производство (WIP). Это помогает устранить узкие места и не дает командам работать над слишком большим количеством задач одновременно
3. Улучшение рабочего процесса. Переход к следующему элементу в очереди, как только текущая задача завершена

Что касается артефактов, Канбан использует доску, предназначенную для визуализации работы, выполняемой на каждом этапе процесса разработки продукта.Инициативы разделены на три столбца: To Do, In Progress, Complete.

Идеально для: Небольших продуктовых команд, которые хотели бы более стабильный и последовательный вывод результатов без масштабной реструктуризации и обучения команды

Преимущества Канбана

• Помогает определить нехватку времени и ресурсов. Это достигается за счет наглядного отображения всех задач (с помощью доски канбан) и оптимизации незавершенной работы (WIP), чтобы команды всегда работали над приоритетными задачами.
• Быстрая непрерывная доставка. Это позволяет производственным группам вносить изменения там, где это необходимо, на основе постоянных отзывов пользователей. Это создает среду, в которой команды чувствуют, что работают над инициативами, которые действительно нужны пользователям.
• Команды считают, что у них больше контроля над процессом. Работа в команде не диктуется каким-то одним лидером. Он выбран с использованием вытягивающей системы, в которой параметры для определения приоритетов инициатив ясны и понятны.
• Гибкость и универсальность. Поскольку канбан не определяет временные рамки, когда должна быть выполнена работа, есть место для приоритетов и требований, которые можно изменить на основе постоянной обратной связи с пользователями.

Недостатки Канбана

• Слишком много задач. Если задач слишком много, это может создать узкое место, из-за которого команды не смогут двигаться вперед, пока эти задачи не будут выполнены.
• Неправильное управление доской канбан. Требуется постоянный мониторинг, чтобы убедиться, что он всегда в курсе событий и не беспорядок.
• Отсутствие временных рамок Канбан полагается на оптимизированные рабочие процессы для реализации любой инициативы.Это означает, что невозможно установить крайние сроки или сроки доставки.
• Внедрение нового инструмента. В крупных организациях и корпоративных компаниях с множеством команд и инициатив внедрение инструментов Канбан может быть затруднительным.

4. Экстремальное программирование (XP)

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

Цели использования XP — улучшить техническую сторону процесса разработки продукта с помощью набора инженерных практик. Но прежде чем мы перейдем к тому, что на самом деле представляют собой эти практики, вот основные ценности, на которые опирается XP:

1. Связь. Улучшение каналов связи между пользователями и членами команды. Нет необходимости в обширной и тщательной документации, вместо этого для обмена знаниями необходимы личные обсуждения.
2. Простота. Простой дизайн и простое кодирование помогают каждому сэкономить ресурсы (время, затраты, усилия) в долгосрочной перспективе.
3. Обратная связь. Создание высоко функциональных циклов обратной связи между командой разработчиков и пользователями, а затем немедленное реагирование на эту обратную связь и внесение изменений там, где это необходимо.
4. Мужество. Переход с установленной среды разработки на XP может быть пугающим. XP требует, чтобы команды разработчиков имели смелость оценивать и подвергать сомнению свои процессы, результаты и были готовы брать на себя любые новые изменения и обязанности
5. Респект. Каждый должен уважать своих коллег, потребности и ожидания пользователей. Все работают вместе, чтобы принять и сформулировать обратную связь с целью определения лучших решений.

Способ, которым XP помогает командам достичь этих основных ценностей, заключается в определении набора процессов и практик разработки, которые охватывают четыре столпа:

1. Обратная связь: Постоянная и понятная обратная связь, которую команды могут быстро применить. В эту категорию входят четыре принципа: парное программирование, игра-планирование, разработка через тестирование и практика под названием Whole Team

.

2. Непрерывные процессы: Постоянное улучшение кода, итеративная разработка и работа над небольшими инкрементными выпусками, которые происходят в короткие циклы
3. Общее понимание кода: Использование максимально простого дизайна, использование стандартизованных форматов для стиля и формата кодирования и коллективное владение кодом
4. Оптимальные условия работы для инженеров: Поскольку XP требует высокого уровня эффективности и качества продукции, важно, чтобы разработчики всегда работали с максимальной отдачей.Ограничивая работу 40 часами в неделю, команды могут предотвратить выгорание.

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

Идеально для: Небольших команд с высоким уровнем участия клиентов. Команды должны уметь адаптироваться к меняющимся требованиям, возникающим из-за наличия высокоприоритетных каналов связи с пользователями.

Преимущества экстремального программирования

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

Недостатки экстремального программирования

• Это очень технично. Из-за строгого и предписывающего характера XP и ее большого внимания к управлению разработкой программного обеспечения она не так доступна, как бережливая разработка, scrum и kanban.
• Нет гибкости. XP использует набор обязательных практик (см. Перечисленные выше методы), таких как непрерывная интеграция, разработка через тестирование и парное программирование. Команды должны придерживаться этих правил, чтобы называть свою работу XP
• Слишком кодоцентричен. В XP не уделяется первоочередного внимания дизайну, и его принципы и методы почти полностью связаны с кодированием программного обеспечения.
• Это требует высокофункциональных команд. Из-за отсутствия иерархии и управления команды разработчиков должны быть высокоэффективными, целенаправленными и вовлеченными.

5. Разработка с использованием функций (FDD)

Эта гибкая методология представляет собой среду итеративной и инкрементной разработки, которая лучше всего работает с большими группами разработчиков программного обеспечения. Он заимствует некоторые гибкие элементы из Scrum и Extreme Programming, такие как улучшенное командное взаимодействие, видимое отслеживание прогресса, оптимизация и расстановка приоритетов на основе потребностей пользователей, а также разработка и тестирование функций в короткие итерации. Некоторые даже говорят, что FDD — это просто Scrum / XP в большом масштабе.

Методология разбита на 5 важных процессов

1. Разработка общей модели: Участники домена и разработчики создают исходную объектную модель под руководством человека с соответствующим опытом
2. Составьте список функций: Используя информацию из шага 1, составьте список функций, которые можно выполнить за две недели
3. План по функциям: На этом этапе командам необходимо построить функции в порядке приоритета, зависимостей и доступности ресурсов
4. Дизайн по функции: Выбранная функция затем разрабатывается под руководством главного программиста, который также определяет приоритеты и тех, кто должен участвовать
5. Построено по функциям: После завершения обзора проекта команда приступает к созданию пользовательских интерфейсов и прототипов функций

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

Преимущества разработки, управляемой функциями

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

Недостатки разработки, основанной на функциях

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

.

• Слишком просто создавать функции, которые «приятно иметь», а не функции, отвечающие реальным потребностям.

Другие популярные методологии разработки программного обеспечения

6. Быстрая разработка приложений (RAD)

Rapid Application Development (RAD) — это среда, которая уделяет приоритетное внимание быстрому созданию прототипов, быстрым и итеративным выпускам указанных прототипов и быстрой обратной связи на длительных этапах циклов разработки и тестирования.Фреймворк RAD также уделяет большое внимание минимизации времени, затрачиваемого на планирование, и максимизации обратной связи с пользователями на этапе прототипа.

Он состоит из четырех определенных этапов или фаз:

• Требования к планированию: На этом этапе разработчики и дизайнеры определяют требования к работе и получают одобрение заинтересованных сторон
• Пользовательский дизайн: Используя итерации прототипа, пользователи тесно сотрудничают с командой разработчиков, чтобы убедиться, что то, что они создают, соответствует их потребностям.
• Rapid Construction: Утвержденные прототипы из этапа 2 затем превращаются в функциональные рабочие модели.Пользовательский дизайн и быстрое строительство повторяются столько раз, сколько необходимо, и пока команда не найдет наилучшее возможное решение.
• Преобразование: Этап реализации. На этом этапе происходит полномасштабное тестирование и обучение.

7. Методология модели разработки динамических систем (DSDM)

DSDM — это итеративная методология, работающая под эгидой гибкой разработки. Его главная цель — согласовать все усилия и инициативы со стратегическими целями организации и обеспечить реальные преимущества, которые окажут наибольшее влияние на бизнес.Как и RAD, он использует итеративный, поэтапный подход к созданию программного обеспечения. И, как и RAD, он использует те же четыре фазы разработки: технико-экономическое обоснование и бизнес-исследование, функциональную модель и итерацию прототипа, проектирование и сборку, а также внедрение.

Основное различие между RAD и DSDM состоит в том, что DSM использует более формальные отчеты и отчеты о требованиях. Восемь принципов методологии DSDM:

1. Ориентация на потребности бизнеса
2. Доставить вовремя
3. Сотрудничать
4. Никогда не поступайтесь качеством
5. Построить постепенно за счет твердого фундамента
6. Итеративная разработка
7. Общайтесь постоянно и четко
8. Продемонстрировать контроль

8.Модель спирали

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

Спирали состоят из четырех различных квадрантов:

1. Определение и планирование требований: Сюда входит определение доступности ресурсов (время, усилия, затраты) и понимание системных требований
2. Анализ рисков: Оцените все доступные решения и оцените их потенциальные риски, такие как смещение затрат и времени.Затем разрабатывается стратегия снижения риска.
3. Разработка и тестирование: Написание, тестирование и развертывание происходит
4. Обзор и план: На этом этапе пользователи участвуют в тестировании решения и предоставлении обратной связи. Затем команды принимают эти отзывы и планируют следующую спираль

Начните создавать красивые + совместные дорожные карты с Roadmunk. Подпишитесь на бесплатную пробную версию здесь.

.

10 лучших методологий разработки программного обеспечения для внедрения проектов SE

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

1 | Гибкая разработка программного обеспечения

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

Основные принципы гибкой разработки программного обеспечения приведены ниже:

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

Преимущества

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

Недостатки

1. Трудно оценить трудоемкость крупных программных проектов на начальных этапах жизненного цикла разработки программного обеспечения.
2. Он создает меньше документации из-за того, что разработка больше ориентирована на код.

2 | Тестирование черного ящика

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

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

Преимущества

1. Эффективно для больших и сложных приложений.
2. Дефекты можно выявить на ранней стадии тестирования.

Недостатки

1. Невозможно идентифицировать все входы.
2. Тестовые наборы просто сложно разработать без четких спецификаций.

3 | Прототипирование модели

Эту модель можно назвать одной из самых популярных моделей SDLC (Software Development Life Cycle), в которой прототип строится, тестируется, а при необходимости дорабатывается. Эта модель работает лучше всего, когда требования к проекту известны заранее.

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

Преимущества

1. Уточнение ведет к удовлетворению новых требований.
2. Гибкий дизайн.

Недостатки

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

4 | Модель быстрой разработки приложений

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

Преимущества

1. Начальные проверки возникают быстро.
2. Отзывы клиентов приветствуются.

Недостатки

1. Сильно зависит от навыков моделирования.
2. Неприменимо к более дешевым проектам.

5 | Модель спирали

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

Преимущества

1. Эффективен для крупных и сложных проектов.
2. Превосходная модель разработки благодаря анализу рисков и управлению рисками на каждом этапе.

Недостатки

1. Достаточно дорого и не подходит для более дешевых проектов.
2. Оценка времени затруднена.

6 | Тестирование белого ящика

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

Смотрите также

Преимущества

1. Этот метод легко автоматизировать.
2. Помогает в оптимизации кода.

Недостатки

1. Стоимость высока и представляет собой сложный метод.
2. Требует много времени для больших приложений.

7 | Методология экстремального программирования

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

Преимущества

1. Обеспечивает большую управляемость в рамках процедуры моделирования.
2. Ориентация в основном на вовлечение клиентов и предоставление качественного программного обеспечения.

Недостатки

1. Возможности и будущие результаты неизвестны.
2. Эффективность прямо пропорциональна вовлеченности людей.

8 | Методология совместной разработки приложений

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

Преимущества

1. Большой объем ценной информации за более короткий период времени.
2. Немедленно устраните разногласия с помощью подходящей помощи.

Недостатки

1. Требуется много времени на планирование и составление графика.
2. Необходимость в высококвалифицированных специалистах, которых сложно найти.

9 | Методология разработки Scrum

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

Преимущества

1. Рабочая группа отвечает за принятие решений.
2. Это слегка контролируемый метод с постоянным обновлением.

Недостатки

1. Этот метод не подходит для сложных и крупных проектов.
2. Требуется высококвалифицированная команда.

10 | Методология разработки модели динамической системы

Это гибкая методология разработки программного обеспечения, которая является итеративной и инкрементной и в значительной степени основана на методологии быстрой разработки приложений (RAD).Метод обеспечивает четырехэтапную структуру, которая состоит из реализации, итерации проектирования и сборки, итерации прототипа, технико-экономического обоснования и бизнес-исследования.

Преимущества

1. Легкий доступ для конечных пользователей.
2. Быстрая поставка функциональности.

Недостатки

1. Внедрение экономически выгодно.
2. Сложно для небольших организаций.

Если вам понравилась эта история, присоединяйтесь к нашему сообществу Telegram.

Кроме того, вы можете написать для нас и стать одним из 500+ экспертов, которые написали статьи на AIM. Поделитесь своими номинациями здесь.

Амбика Чоудхури

Технический журналист, который любит писать о машинном обучении и искусственном интеллекте. Любитель музыки, сочинения и обучения чему-то нестандартному. Контакты: [email protected]

.