Итеративная и инкрементальная разработка проектов

Введение

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

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

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

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

Высокое внимание уделяется отладке и тестированию – как отдельных компонент, так и всей информационной системы в целом

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

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

Требования к информационным системам требовательно формализуются и закрепляются в техническом задании

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

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

2. «V-Model»

Унаследовала структуру «шаг за шагом» от каскадной модели

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

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

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

Когда использовать V-модель?

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

6. «Iterative Model» (итеративная или итерационная модель)

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

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

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

Когда оптимально использовать итеративную модель?

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

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

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

Модель быстрой разработки приложений включает следующие фазы:

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

Когда используется RAD-модель?

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

Инкрементная модель жизненного цикла

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

Рис. 5. Инкрементная модель жизненного цикла

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

С точки зрения структуры жизненного цикла модель называют итеративной (говоря о процессе). С точки зрения развития продукта – инкрементной (имеется ввиду наращивания функциональности продукта). Инкремент – приращение, увеличение (например, в языке программирование – увеличение значения переменной на 1).

Для каждого инкремента выполняется:

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

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

Сам подход является однократным, т.е. мы весь наш проект делаем за один большой этап, имея в виду требования, но весь проект делится на инкременты, это небольшие версии продуктов, для которых заранее определена функциональность. Т.е. мы говорим, что у нас вся длительная разработка состоит, например, из 5 фаз. На первом этапе получим однопользовательскую версию, на втором инкременте (фазе) мы получим версию, которая поддерживает много пользователей, на третьем инкременте у нас появится поддержка веб-интерфейсов, а на четвертом какое-нибудь протоколирование и так далее. Т.е. хоть требования у нас все равно задаются только один раз, но на выходе у нас появляется несколько инкрементов. Различия между инкрементной и итеративной (спиральной) моделями показана на рисунке 6.

Рис. 6. Иллюстрация различий между инкрементной и итеративной (спиральной) моделями

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

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

Недостатки инкрементной модели:

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

Как мы адресный склад внедряли на КА 2

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

Поступила нам задачка по переводу оптового склада с ТиС 7.7 на 1С:КА. Нужно организовать: адресный склад и учет товаров по партиям.
Бизнес-процесс достаточно стандартный: это прием заказ от покупателя, объединение заказов под отгрузку, сборка заказов на складе и загрузка все этого в авто, с последующим оформлением реализации и всех печатных документов. Схема вроде стандартная и поддерживается в типовом решении КА2, но не все так просто, как кажется в начале…

«Agile Model» (гибкая методология разработки)

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

В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

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

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

Когда использовать Agile?

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

Самый быстрый способ получить эффект от автоматизации производства в 1С:ERP

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

V модель — разработка через тестирование

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

V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе проекта ставятся следующие задачи:• Минимизация рисков: V-образная модель делает проект более прозрачным и повышает качество контроля проекта путём стандартизации промежуточных целей и описания соответствующих им результатов и ответственных лиц. Это позволяет выявлять отклонения и риски в проекте на ранних стадиях и улучшает качество управления проектов, уменьшая риски.• Повышение и гарантии качества: V-Model —стандартизованная модель разработки, что позволяет добиться от проекта результатов желаемого качества. Промежуточные результаты могут быть проверены на ранних стадиях. Универсальное документирование облегчает читаемость, понятность и проверяемость.• Уменьшение общей стоимости проекта: ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты.• Повышение качества коммуникации между участниками проекта: универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта. Таким образом, уменьшаются неточности в понимании между пользователем, покупателем, поставщиком и разработчиком.

Иерархия IT-систем и выбор программного обеспечения для организации труда Промо

IT-системы плотно вошли в нашу жизнь. Мощные и сложные программные продукты используются в самых разных сферах

При этом многие забывают, что появились IT-системы не просто так, как программные продукты, которые нужно продавать и внедрять, а как инструменты организации и автоматизации труда.И очень важно помнить при выборе и внедрении IT-систем, что первичен здесь — труд, а не программное решение. Я не единожды сталкивался с тем, что люди выбирали программу просто потому, что: “она понравилась”

В результате появляются попытки “натянуть” процессное производство, например, работу молокозавода, на ERP-систему, предназначенную для дискретного производства (сборка изделий). 

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

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

Особенности каскадной модели:

— высокий уровень формализации процессов;— большое количество документации;— жесткая последовательность этапов жизненного цикла без возможности возврата на предыдущий этап.Минусы:• Waterfall-проект должен постоянно иметь актуальную документацию. Обязательная актуализация проектной документации. Избыточная документация.• Очень не гибкая методология.• Может создать ошибочное впечатление о работе над проектом (например, фраза «45% выполнено» не несёт за собой никакой полезной информации, а является всего лишь инструментов для менеджера проекта).• У заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы.• У пользователя нет возможности привыкать к продукту постепенно.• Все требования должны быть известны в начале жизненного цикла проекта.• Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выбьется из графиков.• Отсутствует возможность учесть переделку, весь проект делается за один раз.Плюсы:• Высокая прозрачность разработки и фаз проекта.• Чёткая последовательность.• Стабильность требований.• Строгий контроль менеджмента проекта.• Облегчает работу по составлению плана проекта и сбора команды проекта.• Хорошо определяет процедуру по контролю качества.

Современные СЭД: курс на упрощенчество и подмена понятий

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

Соответствующие и нерелевантные затраты

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

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

Наиболее типичные ошибки при оценке работ в проектах 1С

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке.
Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, — то вам будет полезно понять методы оценки работ.
Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет».
Типичные ошибки распределю по классам.

Право на ошибку

Что такое ошибка? Это когда что-то сделано неправильно или неидеально. Человек — не идеальное существо, все мы с вами делаем ошибки. Но у ошибок есть цена — последствия и затраты на их исправление (несколько иной угол зрения представлен в статье «Почему ошибаются программисты? Часть 1/2»). Вряд ли кто-то будет спорить, что ошибка бригады интенсивной терапии, спасающей жизнь человека в реанимации, имеет цену выше, чем грамматическая ошибка школьника в первом классе, который только учится писать. Детство — волшебное время, время недорогих ошибок, которые помогают быстро учиться и получать опыт.

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

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

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

«Водоворот» или каскадная модель с промежуточным контролем

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

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

Что такое итеративный процесс?

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

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

А что же такое неитеративный процесс? 

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

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

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

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

Есть ли разница между инкрементным и итеративным подходом? 

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

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

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

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

Попробовать управлять проектами с помощью Asana

Пять шагов итеративного процесса

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

1. Составление плана и требований

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

2. Анализ и проектирование

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

3. Реализация

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

4. Тестирование

После получения первой итерации производится её тестирование наиболее подходящим способом. Например, если вы работаете над улучшением веб-страницы, вам следует произвести A/B-тестирование относительно текущей версии веб-страницы. Если вы создаёте новый продукт или функцию, можно протестировать удобство их использования на потенциальных клиентах. 

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

Читать: Что представляет из себя схема «планирование, исполнение, проверка и принятие необходимых мер» (PDCA)?

5. Рассмотрение и оценка результата 

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

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

Классический подход

Давайте вспомним основные принципы классического и гибкого подходов. Классический проектный подход (еще называют «каскадная модель», «водопадная модель») заключается в том, что вы последовательно реализуете этапы проекта. Например, планирование, разработку, тестирование и поставку результатов работ Заказчику. Присутствует вертикаль управления — Руководителю проекта делегированы полномочия, он управляет командой и ресурсами, отчитывается Заказчику и Куратору (Спонсору) проекта. Руководитель проекта составляет план проекта, который утверждается Заказчиком, и команда действует согласно ему. Только в конце проекта готовый продукт передается Заказчику.

«Бескомпьютерная» автоматизация Промо

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

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

Канбаном часто называют всю систему организации производства Toyota Motor Company, считая его почти синонимом данной системы. Это не совсем точно. Канбан — только один из элементов Toyota Production System (TPS). Канбан как инструмент предложил один из создателей TPS — Таичи Оно. Хотя он утверждает, что придумал его вместе с рабочими для упрощения управления на местах.

Модель на основе разработки прототипа

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

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

• Прояснить неясные требования (прототип UI).
• Выбрать одно из ряда концептуальных решений (реализация сценариев).
• Проанализировать осуществимость проекта.

Классификация прототипов:

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

Вкратце можно выразить суть моделей разработки ПО таблицей 1.3.

Таблица 1.3.— Сравнение моделей разработки ПО

Что в итоге

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

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

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

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

Удачи в проектах!