Управление проектами

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

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

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

Extreme Programming, экстремальное программирование, также известное как XP — это методология разработки программного обеспечения, которая относится к гибким (agile) и подчеркивает важность удовлетворения потребностей клиентов посредством непрерывной поставки высококачественного программного обеспечения.

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

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

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

​Ежедневно мы отвечаем на этот вопрос и не один раз. Очень часто это первый вопрос позвонившего клиента. Мы понимаем, что клиенты устали слушать, что всё зависит от сложности разработки этого самого сайта.

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

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

Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку». Невозможно сделать разработку сайта одновременно и быстрой, и дешевой, и индивидуальной, и качественной.

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

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

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

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

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

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

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

​Давайте рассмотрим «иллюзорные» гарантии, которые вроде как присутствуют в том или ином виде, но на самом деле их нет.

Гарантии в IT‑услугах встречаются не так уж и редко: это и гарантии качества в разработке, и SLA в поддержке, и гарантии трафика или позиций в продвижении. Но тем не менее, понимаются эти гарантии не всегда правильно.