Создание веб-сайта. курс молодого бойца

Agile или Гибкий подход

Об истории применения и развития гибких подходов можно почитать в нашей статье «Неизвестная история Agile»

Напомним ключевое:

Еще с 30-х годов XX века практики и теоретики менеджмента искали пути повышения эффективности работы и избавления от потерь. Появился цикл Деминга (PDCA), бережливые методы производства в Тойоте, понимание негативного влияния простоев, перепроизводства, неравномерной работы, перегрузки сотрудников, накопления запасов и др.

В 1986 году опубликована статья японских исследователей Икуджиро Нонака и Хиротака Такеучи «New New Product Development Game», в которой иллюстрировались потери времени и информации при передаче продукта последовательно от проектировщика разработчику, от разработчика тестировщику и так далее. Авторы статьи рекомендовали специалистам последующих стадий включаться в работу раньше, даже если продукт еще не полностью разработан, чтобы сэкономить время на создание продукта. По сути, предлагается кроссфункциональная команда.

В 1993 году Джефф Сазерленд и Кен Швабер предложили фреймворк Scrum, который базируется на самоорганизации небольшой команды, содержит короткие итерации разработки (спринты), по результатам каждого спринта заказчик получает работоспособную и улучшенную версию продукта.

Рассмотрим более подробно, как поставляется продукт в Agile. Начнем с инкрементального подхода – это быстрое создание продукта с ограниченным, но работающим функционалом. Такой подход позволяет быстро проверять и корректировать гипотезы относительно создаваемого продукта и быстро корректировать направления дальнейшей разработки. Например, если Заказчик просит у нас портрет «Моны Лизы», мы делим холст целиком на участки, и каждый участок создаем последовательно. Такой формат не предполагает доработок уже созданных фрагментов, но каждый фрагмент является целостным и его уже можно показывать заказчику, не дожидаясь окончания проекта.

Инкрементальный подход

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

Итеративный подход

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

Итеративно-инкрементальный подход

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

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

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

Модели жизненного цикла

Модель жизненного цикла программного обеспечения характеризует подход команды к разработке ПП. Она отражает акценты и приоритеты во всём процессе изготовления программы, а самое главное, порядок следования этапов создания программных продуктов.

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

Каскадная (водопадная) модель

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

V-образная модель разработки

По рисунку можно проследить, что в V-образной модели имеется возможность вернуться на некоторые этапы разработки и уточнить нужные требования.

Модель прототипирования

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

Модель быстрой разработки (RAD-модель)

RAD-модель (rapid application development — быстрая разработка приложений) ориентирована в первую очередь на быстроту и удобство программирования. Команда делает акцент именно на разработке, а большая часть работы по составлению требований и описанию пользователей возлагается на заказчика.

Итерационная модель

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

Спиральная модель

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

Гибкие методологии

Гибкие методологии (Agile) олицетворяют современные подходы к разработке ПО. Они используются обычно в небольших командах разработчиков. Среди них такие модели жизненного цикла программного продукта, как Scrum, DSDM, XP, FDD и другие. Вы можете посмотреть видео про одну из гибких методологий: экстремальное программирование.

Поделиться в соц. сетях:

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II Промо

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

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

16.11.2014   
28688   
raiml   

46
   

Раздел 6 «Порядок контроля и приемки системы» /п. 2.8 ГОСТ 34.602-89/

1. Испытания делятся на следующие виды:

• Предварительные.
• Опытная эксплуатация.
• Приемочные.

2. Предварительные (а частично и приемочные) испытания в свою очередь делятся на:

• Автономные (без интеграции со смежными системами).
• Комплексные (в комплексе со смежными системами).

1. Предварительные автономные испытания частей системы.2. Предварительные автономные испытания системы в целом.3. Предварительные комплексные испытания.4. Опытная эксплуатация.5. Приемочные испытания.

• Для предварительных и приемочных испытаний это «Программа и методика предварительных (приемочных) испытаний». Указания для составления документа содержатся сразу в двух стандартах. Вкратце — в ГОСТ 34.603-92 (п. 2.2.2 и 4.1) и более подробно — в РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
• Для опытной эксплуатации предусматривается документ «Программа опытной эксплуатации», содержание которого приводится в п. 3.1 ГОСТ 34.003-90. Также следует прописать использование «Журнала опытной эксплуатации» (см. п. 3.2 ГОСТ 34.603-92), в который будут заноситься недостатки и результаты их устранения.

9.2. Подраздел 6.2. «Общие требования к приемке работ по стадиям» /п. 2.8.2 ГОСТ 34.602-89/

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

Разновидность методологий гибкой разработки

Agile Modeling (AM)

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

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

Принципы Agile Modeling таковы:

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

Agile Unified Process (AUP)

AUP — упрощённая версия другой методологии разработки ПО — Rational Unified Process (RUP). С 2012 года её заменили на Disciplined Agile Delivery (DAD), но кое-где AUP еще встречается.

Автор методики, Скотт Амблер, выделил следующие ключевые позиции Agile Unified Process:

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

Agile Data Method (ADM)

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

Суть Agile Data Method определяется шестью положениями:

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

Essential Unified Process (EssUP)

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

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

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

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

Getting Real (GR)

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

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

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

OpenUP (OUP)

Практики реализуются на основе четырех принципов:

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

Law of Demeter (LOD) — Закон Деметры

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

1. Классы должны быть самостоятельными
2. Нужно стараться сократить количество связей между различными классами
3. Классы должны быть выстроены иерархически

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

Благодаря соблюдению данного принципа приложения становится более гибким и понятным.

Принципы разработки ПО — Заключение

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

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

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

17.06.2016   
40053   
raiml   

37
   

Разница в том, что делаем

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

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

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

We have to be predictable — сказал мне один топ-менеджер Electronic Arts, и это — чистая правда. Каждый день опоздания с выпуском игры может стоить вам десятки миллионов упущенной прибыли или уходящего впустую маркетингового бюджета.
Совмещение несовместимого — неопределенности результата с его предсказуемостью — накладывает отпечаток на производственный процесс.

Классический цикл производства вплоть до запуска игрового проекта выглядит таким образом: Idea Generation, Pre-production, Production, Finaling. Эти стадии отличаются составом команды, артефактами и даже подходом к управлению. Если на этапе Pre-production вполне уместна гибкая разработка, то на этапе Production лучше использовать классические методологии.

Основной принцип — раннее прототипирование. Все, что вызывает вопросы, должно быть реализовано как можно раньше. Это заметно снижает цену ошибки. При этом понятие «раннее прототипирование» надо рассматривать достаточно широко. К примеру, делаем игру типа Diablo. В игре есть риск — получить неинтересную боевку. Для того, чтобы оценить эту самую интересность, надо очень много вложиться в production — надо, чтобы был готов персонаж, чтобы были готовы враги (желательно несколько разных), чтобы была настроена обратная связь — визуальные и звуковые эффекты, чтобы был сделан HUD, чтобы была сделана система ревардов. Причем все это должно быть сделано на уровне качества, близкому к финальному, иначе в комплексе не оценить. Поэтому «раннее прототипирование» — это и alpha-beta-версии, и soft launch. 

Проблемы

Организация процесса

Наиболее типовую в России модель процесса производства программного обеспечения можно охарактеризовать следующим образом: «Каждый разработчик выбирает тот или иной метод или технику для создания программ в соответствии с собственными привычками и пристрастиями. Практически полное отсутствие четкой ответственности за выполнение тех или иных функций. Качество программного обеспечения является случайной величиной и напрямую зависит от способностей отдельных сотрудников компании. Практически все зависит от инициативы и деловых качеств нескольких личностей». Эта формулировка практически полностью соответствует 1 уровню CMM под названием «начальный». По некоторым источником, 2 года назад доля фирм-производителей программного обеспечения, использующих эту модель, составляла свыше 70%.

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

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

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

Требования и итеративность

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

Фаулер пишет: «В процессе производства программного обеспечения все зависит от требований. Если вы не можете добиться устойчивости требований, вы не сможете создать предсказуемый план». Как же быть? С одной стороны требования должны быть устойчивыми, а с другой они будут неизбежно меняться в ходе проекта.

Ключ ко всему – итеративный процесс производства.

Критика

Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.

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

Agile показатели

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

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

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

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

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

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

Раздел 9 «Источники разработки» /п. 2.11 ГОСТ 34.602-89/

• Материалы с описанием аналогов (прототипов) разрабатываемой системы.
• Материалы, описывающие общую идею системы. Нередко данные документы составляют на предпроектных стадиях и именно на них обычно содержатся ссылки в разделе «Характеристики объекта автоматизации».
• Материалы по разработке проекта: перечень используемых ГОСТов серии 34, используемые стандарты по проектному управлению.
• Материалы, связанные с осуществлением основного процесса: перечень законов, стандартов, внутренних регламентов и приказов, устанавливающие правила осуществления автоматизируемых процессов.
• Материалы и стандарты, содержащие требования к общей и информационной безопасности.