Учебно-методическое пособие «УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ» для самостоятельной внеаудиторной работы студентов по дисциплине «Управление проектами»

Здравствуйте, дорогой друг!
Перед вами методическое пособие, предназначенное для помощи вам в освоении дисциплины «Управление проектами». Вы не знаете что это такое? Внимательно изучите изложенный здесь материал, и у вас появится четкое представление об изучаемом предмете. Вы познакомитесь с основными понятия и методологиями и получите возможность перейти к их практическому освоению.
Современный рынок – это сложный механизм технологических, организационных и финансовых мероприятий. Сегодня невозможно успешно создавать ни один мало-мальски успешный проект без учета самых разнообразных факторов: спроса на проектируемый продукт, сложности его создания, наличия инвестиций, наличия всевозможных рисков. Рынок постоянно, ежедневно изменяется, в зависимости от спроса растут и падают цены, появляются новые и уходят старые поставщики ресурсов, рождаются новые и отмирают устаревшие технологии, производители аналогичных ресурсов сходятся в неумолимой конкурентной борьбе. И этот процесс с течением времени имеет тенденцию только усугубляться.
Именно поэтому во второй половине XX века появилась дисциплина, получившая название управления проектами. Эта дисциплина изучает, находит закономерности и стремится объединить в единое целое аспекты самой разнообразной деятельности, имеющей отношение к реализации любого проекта:
· постановку целей;
· анализ и планирование задач;
· подбор штата сотрудников;
· организацию взаимодействия между всеми направлениями и участниками процесса;
· управление исполнением работ;
· применение инноваций;
· мониторинг прогресса реализации проекта;
· корректировку отклонений в работе;
· связь с потребителем конечного продукта.
Такой подход позволяет более рационально управлять инвестициями проекта, наиболее эффективно оптимизировать имеющиеся ресурсы, управлять исполнением плана, избегать конфликтных ситуаций в команде, накапливать и применять опыт предыдущих проектов, учитывать и снижать проектные риски.
Сегодня существует множество самых разнообразных методологий (технологий) управления проектами. Каждая из этих методологий дает высокие результаты в одной или нескольких сферах деятельности, при этом оказываясь совершенно неэффективной в других. Это связано с конкретными особенностями производства товаров и услуг в различных сферах деятельности. Организация процесса выплавки стали, к примеру, в корне отличается от процесса приготовления пищи или постановки театральной пьесы. Но и то, и другое, и третье – это проекты, которые должны быть организованы самым оптимальным образом, чтобы приносить не убытки, а доход.
Это касается и разработки программного обеспечения. Далее мы будем рассматривать принципы управления проектами именно применительно к разработке ПО.
Управление проектами – это область деятельности, направленная на определение и достижение четких целей проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками. Это определение из Википедии.
Если же рассматривать управление проектами в более узком смысле, то можно сказать, что управление проектами - это использование знаний, навыков и опыта для реализации проектов в установленный срок, в рамках имеющегося бюджета и с минимальными потерями по вине непредвиденных обстоятельств (рисков). В самом деле, чем больше у руководителя и проектной команды накоплено опыта, тем выше вероятность быстрого и качественного выполнения каждого нового подобного проекта. Можно сказать, что у команды нарабатывается определенный шаблон. Чем ниже вероятность наступления проектных рисков – тем больше возможностей для более рационального использования ресурсов и времени? А следовательно – для завершения проекта в срок и без убытков.
О проектных рисках следует упомянуть отдельно. Проектный риск– это наступление некоторых непредвиденных обстоятельств, по вине которых нарушается запланированное течение событий. В результате этого приходится принимать какие-то экстренные меры для возврата проекта в запланированное русло.
Риски могут быть самыми разнообразными – от падения метеорита на строящийся дом до обвала цен на фондовой бирже. Поскольку подавляющее большинство успешных проектов реализуются лишь хорошо сработанными командами, то болезнь или уход из проекта любого из ее членов, также приведет к сбоям в работе и риску не уложиться в отведенные сроки.
Таким образом, можно утверждать, что последствия любых, каких бы то ни было рисков всегда одни и те же: невозможность реализовать проект согласно плану и в установленный срок. В итоге такие проекты начинают требовать либо дополнительных денежных вложений, либо дополнительного времени на реализацию.
И то и другое одинаково неприемлемо, поскольку ресурс времени в конкурентных рыночных условиях прямо пропорционален денежному ресурсу. Если проект, оплаченный заказчиком, не будет реализован в установленный им же срок, то велика вероятность, что этой задержкой немедленно воспользуются конкуренты и выпустят свой аналог продукта. Заказчик окажется уже не первым на рынке и потеряет большую часть прибыли. Любая задержка в реализации проекта равносильна потере денег. Кроме того, заказчик никогда не станет вкладывать дополнительные средства в проект, который, как выясняется, не может быть исполнен в срок по вине разработчиков – заказчику это просто не выгодно. Поэтому в данном случае проигравшей стороной окажутся разработчики, не сумевшие организовать реализацию проекта без потерь. Переделывать некачественную работу им придется бесплатно.
Применительно к программному обеспечению риски могут возникать на разных этапах разработки (эти этапы мы рассмотрим ниже). Риски могут носить самый разнообразный характер: недостаточная квалификация программистов и аналитиков, низкий уровень организации работы, выбывание одного или нескольких членов команды, неисправность оборудования, случайные сторонние факторы и т.п. Например, если заказчик программного продукта не является специалистом в IT-сфере (а так зачастую и бывает), то при уточнении требований проекта он может оставить без внимания некоторые вещи, которые ему кажутся очевидными. Но эти вещи могут быть неизвестны разработчикам и в результате будет создан проект, который не будет достаточно точно соответствовать потребностям заказчика. Понадобится корректировка проекта, а это – дополнительные расходы. Возможна ситуация несвоевременной поставки или поломки оборудования и тогда снова наступает проектный риск, заставляющий сдвигать срок завершения проекта. Может заболеть или уволиться один из ключевых сотрудников проектной команды – и проект снова начнет лихорадить, поскольку обязанности бывшего сотрудника придется срочно распределять между оставшимися, либо срочно искать ему замену.
Последствия таких рисков всегда самые печальные: выработка ресурса времени и средств, а значит – невозможность завершить проект в срок и в рамках указанного бюджета. А это – незапланированные финансовые потери, что в рыночных условиях совершенно недопустимо.
В таких сложных условиях невольно напрашивается вопрос: как же организовать разработку и реализацию сложного программного продукта без потерь? Жизнь не стоит на месте, рынок ежедневно и даже ежечасно меняется. Как же предусмотреть и избежать заранее то, что, возможно, случится завтра, но сегодня это еще никому не известно? Как избежать всевозможных случайных ошибок?
Ответ есть: изучать и применять методологии управления проектами, главная цель которых – снижение рисков и исполнение проекта в срок, с надлежащим качеством и в рамках запланированного бюджета. Рисками можно и нужно управлять.
Разработка программного обеспечения предполагает комплекс действий по анализу, планированию, разработке, тестированию и внедрению программных продуктов. Здесь не подойдет методология строгого крупномасштабного планирования (каскадная методология, которая будет рассмотрена ниже), когда сначала пишется план разработки, а потом все части программного продукта разрабатываются поэтапно согласно этому плану. Рынок информационных технологий постоянно и стремительно обновляется. И вполне вероятно, что пока новое ПО будет разрабатываться согласно плану, то оно станет уже просто неактуальным. Конкуренты выпустят более продуктивные аналоги. Поэтому при разработке ПО решающую роль играет связь с заказчиком, который держит под контролем ситуацию на IT-рынке и при изменении рыночных требований сразу же вносит корректировку в требования к будущему программному продукту.
Разработка программного обеспечения требует скоординированной работы сразу нескольких специалистов. Поэтому современные программные продукты обычно создаются командами разработчиков. Основная производственная сила при разработке ПО – это интеллект. Другой важный фактор – это заинтересованность каждого интеллектуала – специалиста команды – в конечном результате. Поэтому вся команда должна быть заинтересована в скорейшей качественной реализации проектов.
У каждого члена команды есть своя строго определенная роль, которая тесно связана с ролями других участников. Именно в таком тесном и точном исполнении ролей всеми членами команды и кроется успешная разработка качественного программного продукта. В небольших командах один специалист может совмещать сразу несколько ролей.
Разработка программного продукта происходит за короткие временные интервалы, после каждого из которых заказчику выдается небольшой, но законченный, работающий, отлаженный и протестированный кусочек будущего программного комплекса. Этот кусочек сразу же может быть использован для практической работы. При этом, если разработанный элемент успел стать неактуальным, или не устраивает заказчика, он будет переделан с минимальными потерями, поскольку времени и труда на него было затрачено достаточно немного. Но такое случается редко – ведь заказчик постоянно находится в курсе разработки и заранее проверяет актуальность и целесообразность каждого его этапа.
Каждый временной интервал (итерация) делится на строго определенные этапы. В общем виде они представляют собой анализ и постановку задачи, разработку алгоритмов, кодирование, отладку, тестирование, внедрение элемента ПО. Но поскольку времени на все эти вещи предоставлено немного, то команда IT-проекта должна действовать очень слаженно и согласованно – а именно такой подход и позволяет работать быстро и продуктивно. Ежедневно разработчики собираются вместе и обсуждают, что было сделано каждым их них за предыдущий день, что предстоит сделать сегодня и что не удалось. Все вместе они ищут причины вчерашних неудач и меры их скорейшего устранения.
Вот так, шаг за шагом, маленькими быстрыми приращениями большого продукта создаются современные программные комплексы. А координирует работу всей команды главный менеджер проекта.
Внимательно рассмотрите схему.
СХЕМА РАБОЧЕЙ ГРУППЫ ДЛЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Кого вы видите? Человечков не так уж много: Заказчик, Аналитик, Тестировщик, UI-тестировщик, Backend-разработчик, Frontend-разработчик и Дизайнер.
Начинается все с Заказчика.
Заказчик
Представьте себе, что у некоторого предпринимателя (или организации) появляется желание завести у себя некоторый программный продукт (программный комплекс, информационную систему или интернет-сайт), который, как предполагается, принесет его бизнесу определенные выгоды и преимущества. От желаемого ПО его отделяет только одно препятствие: сам он не умеет разрабатывать программные продукты и на рынке готового ПО нет именно того, что ему нужно.
Тогда он обращается к IT-специалистам и становится Заказчиком программного продукта. И первым из команды IT-специалистов, с кем приходится иметь дело Заказчику, становится Аналитик.
Аналитик (или системный аналитик) – это специалист по разработке технического задания. В его задачу входит анализ и формализация требований проекта в течение всего его жизненного цикла. Аналитик должен собрать как можно больше исходной информации о будущем проекте. При этом Заказчик сам часто не представляет до конца, в полном объеме, какой именно продукт он хочет получить на выходе. Обычно он ограничивается только общими требованиями. Он ожидает конкретизации своего заказа от разработчиков как от специалистов в данной области. Поэтому Аналитик должен обладать не только специальными профессиональными знаниями, но и развитыми навыками общения. Он должен стать связующим звеном, мостиком, между Заказчиком и командой разработчиков.
Чтобы точно установить цели проекта и для Заказчика, и для разработчиков, Аналитик должен уметь очень точно выделить предметную область будущего проекта и задачи в этой предметной области.
Этап аналитики в проекте является самым важным из всех этапов, поскольку ошибки системного анализа, выявленные на более поздних этапах, сделают ненужной всю работу, уже проделанную на данной итерации другими членами команды, и ее придется начинать с самого начала. И, само собой разумеется, что никто не станет оплачивать переделку напрасно выполненной работы – весь коллектив разработчиков останется без зарплаты. Поэтому ошибки аналитики в проекте являются самыми «дорогими» по масштабу последствий. Их появление в проекте недопустимо.
После определения предметной области, системный аналитик составляет ряд рабочих документов:
· Функциональные сценарии – это сценарии, которые описывают логику работы всей системы в целом. Чем сложнее система, тем строже должна соблюдаться последовательность взаимосвязанных процессов-сценариев. Сценарии отдельных процессов, выстроенные в строгой логической взаимосвязи, позволяют описать действие всей системы в динамике. Функциональные сценарии от Аналитика отправляются к Bаckend-разработчику и Тестировщику.
· Пользовательские сценарии – это сценарии взаимодействия системы с теми людьми, которые будут ее непосредственно использовать – Администратором, Модератором, Оператором (пользователем). Пользовательские сценарии - это сценарии того, что пользователь будет видеть на экране и того, как система будет реагировать на его действия. Пользовательские сценарии Аналитик передает Frontend-разработчику и Дизайнеру.
· Прототипы – модели финального продукта для проведения тестирования и уточнения. За время разработки проекта создается несколько версий прототипов, позволяющих отслеживать усовершенствования продукта. Прототипы Аналитик передает Дизайнеру.
После передачи сценариев и прототипов следующим разработчикам участие Аналитика в проекте не заканчивается. Фактически он продолжает держать в голове весь проект и его задача – сохранить целостную «картинку» даже при самых глобальных изменениях требований. Поскольку разработка ПО происходит в условиях поэтапного уточнения конечных требований, то их постоянное изменение - процесс естественный. Поэтому Аналитик должен постоянно отслеживать изменения и в соответствии с ними корректировать все части системы.Вack-end (задняя, изнаночная сторона) – это обобщенное название программно-аппаратной части информационной системы. Работа этой части программы не видна пользователю – она скрыта от него на внутреннем уровне. Сюда относятся базы данных, компоненты обработки хранящейся в них информации, а также вся программная логика. Вack-end является аппаратно-зависимым представлением. Если речь идет о веб-разработке, то под бекендом понимают работу серверной части сетевой информационной системы (в отличие от фронтенда – программного обеспечения клиентской стороны ).
Соответственно, backend-разработчик – это специалист, отвечающий за функциональную реализацию архитектуры системы в целом. Bekender должен уметь проектировать базы данных, выстраивать между ними связи, управлять логикой взаимодействия между компонентами системы. Он должен перенаправлять на обработку получаемые от пользователя данные и возвращать полученный результат. Для этого Bekend-разработчику необходимы знания по основам frontend-разработки, чтобы понимать в каком виде к нему придут входные данные и в каком виде их следует потом возвращать в интерфейс.
Результат работы backend-разработчика – АPI-наборы (application programming interface), которые Bekender передает Тестировщику.
Тестировщик – это специалист, выясняющий насколько разработанная система работоспособна и отказоустойчива. Основная задача тестировщика – выявить возможные ошибки при работе с программным обеспечением. Тестировщик словно встает на место пользователя и начинает давать системе задания для решения. Реакция системы должна точно соответствовать функциональным сценариям, переданным Тестировщику Аналитиком. Для качественной проверки системы Тестровщик разрабатывает специальные тесты, заставляющие все части системы работать в стандартных и нестандартных режимах, которые могут возникнуть после передачи ее в эксплуатацию. Тестировщик разрабатывает специальные позитивные и негативные сценарии. Позитивные сценарии отражают всё то, что было заложено в функциональных сценариях. Негативные сценарии должны охватывать все ситуации, которые в функциональных сценариях не рассматривались. Для этого Тестировщику просто необходимы навыки аналитика. Для успешной работы Тестировщик должен не просто владеть языком программирования, но и в некоторых случаях он должен владеть им даже лучше, чем разработчики. Качество тестирования самым радикальным образом влияет на качество конечного программного продукта.
Все выявленные несоответствия функциональным требованиям Тестировщик тщательно документирует и возвращает backend-специалисту. Так происходит до тех пор, пока Тестировщик не даст «добро» на продолжение разработки не передаст протестированные API Frontend-разработчику. Это означает, что максимально возможное количество ошибок в наборах API выявлено и устранено.
Дизайнер – это «узкий» специалист. Его предназначение в команде – продумывать все тонкости интерфейса будущей системы. Именно Дизайнер принимает окончательно решение о том, каким образом будут происходить изменения на экране пользователя. Он продумывает цветовые решения, форму и положение курсора и указателя мыши в различных режимах, размеры, расположение и свойства всплывающих окон, внешний вид средств навигации и представления данных в отчетах и выкладках.
В результате его работы появляются на свет так называемые исходники дизайна – эскизы всех возможных режимов работы интерфейса. Эти эскизы Дизайнер передает Frontend-разработчику, который осуществляет на их основе реализацию пользовательского интерфейса.
Front-end (передняя, лицевая сторона) – эта та часть информационной системы, которая находится в непосредственном контакте с пользователем. Frontend-разработчик соответственно – это специалист по разработке пользовательского интерфейса. Именно он выстраивает связи между внутренней логикой системы, заключенной в API-наборах, и действиями пользователя.
Его задача сделать систему дружественной и понятной пользователю, и при этом удовлетворяющей всем его требованиям. Он разрабатывает машинно-независимые представления интерфейса, которые в дальнейшем будут соединены с API и составят единую информационную систему. Когда речь идет о разработке веб-сайта, то под front-end принято понимать его клиентскую часть.
Frontend-разработчик обычно хорошо владеет кодом разработки API и серверной разработки. Это требование вытекает из необходимости понимать все особенности API, созданных на предыдущем этапе.
Frontend-разработчик получает от Аналитика пользовательские сценарии, на основе которых разрабатывает программные модули, отвечающие за логику действий пользователя. От Дизайнера он получает исходники дизайна, которые будут положены в основу внешнего вида будущего интерфейса, от Тестировщика – протестированные API-наборы. Итогом работы frontend-специалиста является так называемая alpha-версия информационной системы, которая передается на проверку UI-Тестировщику – специалисту по тестированию интерфейсов.
UI-Тестировщик проверяет работоспособность интерфейса в разных режимах и составляет список выявленных ошибочных ситуаций в поведении системы. Этот список UI-Тестировщик передает обратно Frontend-разработчику для исправления ошибок.
UI-Тестировщик (UserInterface) – это в широком смысле специалист по эргономике. В его задачи входит тестирование интерфейса alpha-версии системы на удобство ее использования и на соответствие своему назначению.
Несмотря на кажущуюся малозначимость такой работы, UI-тестирование имеет огромное значение в разработке качественной информационной системы. Удобство использования всех ее возможностей и инструментов позволяет эксплуатировать систему с максимальной производительностью – и наоборот, мелкие неудобства будут вызывать у пользователя чувство раздражения и снижать эффективность работы ПО в целом. Ведь каждый из нас на собственном опыте знает, как утомительно и даже непросто бывает разобраться в функционале программного продукта с непонятным, плохо продуманным интерфейсом.
Например, если вы не можете на сайте быстро и легко зарегистрироваться, если вам приходится проходить длинную (иногда – некорректно работающую) процедуру регистрации, то, скорее всего, вам вряд ли захочется иметь дело с этим сайтом в дальнейшем. Вы не станете звонить по телефонам, указанным в контактах, а скорее всего, просто навсегда покинете такой сайт (разве что, информация, открытая на нем только для зарегистрированных пользователей будет вам уж крайне необходима). Если при работе с базой данных вам приходится каждый раз проходить различные меню глубокой вложенности, или подтверждать каждое свое действие нажатием специальной кнопки, (причем только с помощью мыши), то это будет сильно утомлять вас и отнимать изрядное количество рабочего времени, которое можно было бы использовать более продуктивно. Выявить и обозначить все подобные недостатки в интерфейсе пользователя как раз и является задачей UI-тестировщика.
Все кнопки, ссылки и инструменты должны быть удобно расположены, они должны обеспечивать быструю и удобную смену экранов, должны однозначно идентифицироваться пользователем. Все элементы интерфейса должны отвечать принятым стандартам, должны адаптироваться к различным разрешениям экрана и аппаратному обеспечению. Цветовые решения должны быть сбалансированными и не утомлять зрение. Если речь идет о сайте, то обязательным требованием является кроссбраузерность. Ну и, разумеется, в интерфейсе недопустимы грамматические ошибки и неточности.
Все возникшие проблемы UI-Тестировщик документирует и возвращает на доработку frontend-специалисту. Когда в процессе UI-тестирования не будет выявлено ни одной проблемы со стороны пользовательского интерфейса, то система в виде beta-версии передается в эксплуатацию Заказчику.
Не стоит думать, что с передачей заказчику beta-версии программного обеспечения, работа команды на этом заканчивается. Ничего подобного. Утверждение, что каждая найденная в программе последняя ошибка на самом деле является предпоследней, имеет под собой глубокий смысл. Обычно, несмотря на тщательное тестирование на этапах разработки, с началом эксплуатации обнаруживаются скрытые более или менее серьезные неполадки в работе системы. А это сильно снижает репутацию компании-разработчика ПО, если эта компания не позаботится об их устранении.
Еще один важный момент внедрения нового ПО и адаптация его к целям заказчика – это обучение работе с данным продуктом персонала, которому предстоит его эксплуатировать. Даже если разработчики уже внедряли подобные проекты, то это было в других организациях и с другими людьми. Поэтому всегда важно помнить об уникальности каждого нового проекта. Клиент является экспертом в своей проблемной области, но не в вашей. Поэтому нужно говорить с ним не на языке, понятном IT-специалисту, а на его предметном языке, показывать ему не возможности API, а возможности, например, быстрого резервного копирования данных или получения статистики.
Отсюда вытекает необходимость сопровождения эксплуатации ПО в течении определенного, иногда достаточно длительного, времени. Появляющиеся за это время у пользователей вопросы и проблемы оперативно объясняются, анализируются и корректируются. В результате такого сопровождения у клиента повышается уровень владения программным продуктом, доверие к нему, атакжеулучшается качество программного продукта, качественно возрастает репутация компании-разработчика. А это, в свою очередь, отражается на количестве новых заказов.
Как мы уже говорили выше, риск при управлении проектом – это совокупность некоторых потенциально возможных событий в условиях высокой неопределенности, которые могут повлиять на реализацию проекта. Под неопределенностью мы понимаем возможность отклонения результата как в отрицательную (негативный риск), так и в положительную сторону (позитивный риск). Это значит, что по вине наступления риска проект может лишиться части ресурсов, либо получить их с избытком. Проще говоря, риск – это проблема, которая может наступить, а может и не наступить. Проблема – это наступивший риск. Негативные риски несут угрозу успешной реализации проекта, и поэтому под управлением рисками будем подразумевать управление именно негативными рисками.
Риски могут быть предсказуемыми (известными) и непредсказуемыми (неизвестными). Известными рисками будем считать те, о возможности свершения и последствиях которых мы знаем заранее из надежных источников. Такие риски можно однозначно идентифицировать и на этапе планирования предусмотреть меры реагирования на них. Например, на случай отключения электроэнергии можно использовать источники бесперебойного питания, либо аварийную схему энергоподачи. На случай возможной болезни одного из сотрудников можно предусмотреть потенциальную замену.
Предсказуемые риски – это риски, формирующиеся из прошлого опыта. Непредсказуемые риски предусмотреть и спланировать нельзя, поскольку о них заранее ничего не известно. Все риски могут как произойти, так и не произойти.
Однако большинство рисков являются все-таки известными, если углубиться в их изучение. А это значит, что можно предусмотреть большинство возможных рисков и заложить в проект часть ресурсов, времени и мер, направленных на минимизацию последствий рисков (в случае их наступления). А это позволит успешно реализовать проект.
Управление рисками – это процесс изучения любых рисков и формирование мер реагирования на них, а также профилактика рисков, чтобы снизить вероятность неблагоприятного воздействия на результат проекта и минимизировать возможные потери.
Применительно к проектам разработки программного обеспечения наступление риска может:
· снизить качество конечного продукта;
· повысить стоимость проекта;
· задержать, или вовсе сорвать,
завершение проекта.
Во избежание или снижение последствий негативных рисков при разработке ПО в недалеком прошлом применялись эвристические методы, основанные на накопленном опыте руководителей проектов. Однако с усложнением и удорожанием проектов такой подход перестал быть эффективным. Знаний одного, или нескольких, людей, пусть даже и очень обширных, уже оказывается не достаточно для принятия верных управленческих решений. Особенно это актуально для сферы IT-разработки, где высока степень неопределенности требований. Здесь требования к программному продукту обычно заранее полностью не известны и уточняются по мере разработки продукта и изменения ситуации на рынке, а это сильно повышает степень риска.
Как уже говорилось выше, самыми «дорогим» является риск ошибок, связанных с аналитикой. Неверно поставленные цели приведут к неверным результатам и как следствию – потерянным времени и деньгам.
Другой важный риск - отсутствие инвестиций, если заказчик по какой-либо причине не оплачивает вовремя выполненную работу. Может возникнуть риск с выбыванием из команды одного или нескольких сотрудников – тогда команде придется перестраивать всю работу над проектом.
Решением данных проблем при разработке программного обеспечения стали так называемые гибкие методологии управления, основанные на принципах agile-манифеста (эти принципы будут рассмотрены ниже). В таких методологиях цели проекта разбиваются на множество конкретных задач, каждая из которых после реализации представляет собой небольшую, но вполне законченную функционально реализованную часть основного продукта, а попросту говоря – работающую подзадачу. На разработку этой подзадачи отводится небольшой отрезок времени (итерация, спринт), за который эта подзадача должна быть спланирована, реализована, протестирована и передана заказчику. Заказчик принимает работу, внедряет ее у себя, добавляя к комплексу уже внедренных таких же небольших подзадач из этого же проекта –и начинает ею пользоваться. Затем он сообщает разработчикам свое мнение относительно новой внедренной подзадачи: насколько она соответствует своему назначению, насколько улучшает производительность труда, насколько эргономична. После такой рефлексии заказчик и разработчики вместе вносят изменения в беклог (требования к оставшейся части проекта). Аналитик в соответствии с изменившимися требованиями перестраивает общую «картинку» программного комплекса, устанавливает новые приоритеты между задачами – и команда приступает к реализации нового функционала, который будет стоять первым в списке. Более приоритетными считаются самые важные задачи проекта.
Чтобы уложить разработку задачи в короткую итерацию, от команды требуется продуктивная слаженная работа по всем направлениям, использование методов экстремального программирования, коллективное владение кодом, единство в понимании целей проекта. На ключевую позицию выступают принципы agile.При таком подходе программные продукты будут создаваться быстро и без потерь по вине разработчиков, так как риски при разработке небольших конкретных задач сводятся к минимуму или вовсе исключаются. Иногда agile-проекты называют разработкой без риска.
Теперь давайте пристальнее рассмотрим, какие риски могут угрожать разработке программного обеспечения.
Они тесно связаны с расписанием проекта. Процесс разработки ПО сложно подчинить какому-либо регулярному расписанию. Это связано со спецификой конечного продукта и методами его получения. Сам продукт – это комплекс компьютерных программ, а методы его производства – это набор знаний и навыков программистов и аналитиков, то есть их интеллектуальный потенциал. А интеллектуальная сфера неразрывно связана с человеческим фактором. И если сегодня у программиста отличное настроение, он с самого утра и до вечера творит шедевры, то завтра работа у него может совсем не ладиться из-за насморка или скверного настроения.
По вине рисков, связанных с расписанием, происходит увеличение сроков проекта, следовательно – его удорожание. Поэтому для соблюдения расписания, следует активно вовлекать команду и заказчика в обсуждение прогресса и отставания задач каждого спринта. Коллективный поиск решения помогает найти причины отставания и усилить работу на слабых участках.
К этой же категории рисков можно отнести и риск недостаточного контроля и общего управления проектом, связанный с отсутствием интереса к делу или мотивации у главного менеджера. Это влечет за собой отсутствие общей заинтересованности в результатах проекта у всей команды. Если руководитель позволяет себе относиться к работе кое-как, то участники команды скоро начнут делать то же самое.
Существует еще один проектный риск – риск низкой продуктивности команды. Тут срабатывает так называемый «закон Паркинсона», гласящий, что темп работы замедляется, а работа удлиняется, полностью заполняя предоставленные временные рамки. Ту же можно упомянуть и о «синдроме студента», когда в течение длительного времени работа почти не выполняется, а к концу срока она начинает выполняться в интенсивном режиме. Поэтому применение гибких технологий и спринтов позволяет сильно сократить срок между началом и завершением работы и всегда поддерживать на должном уровне «чувство срочности» у членов команды – ведь спринт имеет очень короткий временной промежуток и во время него разработчикам нельзя отвлекаться и расслабляться. Благодаря такой методологии, проекты разрабатываются значительно быстрее традиционных.
Эти риски связаны с использованием оборудования и технологий. Технологии и оборудование могут быть как устаревшими, не отвечающими современным требованиям, так и новейшими, «сырыми», мало опробованными. Чем новее технология или оборудование, тем выше потенциальные возможности повышения производительности труда, но при этом также выше и вероятность наступления рисков по их вине. Несмотря на потенциальную выгоду от использования, к примеру, новой среды разработки, тем не менее, велика вероятность, что в ней есть плохо отработанные части, которые будут не ускорять, а тормозить работу, либо сделают ее завершение вовсе невозможным. Тогда придется все начинать сначала, а время, затраченное на разработку, окажется потерянным зря. Чтобы избежать подобных проблем менеджер проекта должен быть уверен в качестве используемого оборудования и технологий. Лучше всего заранее создавать прототип проекта и тестировать его с применением данной технологии.
Это риски, связанные с рыночной ценностью проекта. Если программный продукт изготовляется не на заказ, а для свободной продажи, то к моменту завершения проекта на него может измениться спрос, снизиться его конкурентоспособность, уйти целевая аудитория. Чтобы избежать подобных рисков, лучше всего разрабатывать программные продукты под конкретные заказы, предусматривая в контракте материальную ответственность сторон.
Кроме того, данный риск снижается до минимума путем непосредственного вовлечения заказчика в процесс разработки. Заказчик, заинтересованный в коммерческом успехе своего будущего продукта, следит за ситуацией на рынке и, по мере необходимости, вносит изменения в требования проекта.
Одним из таких рисков является различный уровень подготовки персонала. Чтобы сгладить эти различия, еще до начала совместной проектной работы команды необходимо организовать обучение персонала опытными наставниками, которые знают, как обходить возможные ошибки, возникающие на пути разработчиков программ. Такой подход выгоднее взаимного «притирания» и обучения команды уже в процессе работы над проектом, поскольку в этом случае велика вероятность рисков именно по вине персонала. Программисты, аналитики, дизайнеры должны понимать работу друг друга. В команде не должно быть дилетантов и вся она должна «говорить на одном языке».
В этой же категории рисков находится квалификация главного менеджера. Этот специалист будет способен организовать продуктивную и качественную работу команды только в том случае, если имеет за плечами опыт аналогичных проектов и управления персоналом. Ведь именно от него зависит мотивация и прогресс работы всего коллектива в целом, именно он должен координировать работу каждого и всех вместе.
К рискам, связанным с персоналом, можно отнести и утечку информации. Обычно она происходит с уходом из команды сотрудников. Коллективное владение кодом, помогающее команде более полно и быстро разрабатывать проект, иногда может стать критическим, если уволившийся сотрудник заберет с собой тексты кода и передаст их конкурентам. Поэтому в проектных командах риск потери сотрудников должен быть сведен к минимуму. Для этого в команде должен поддерживаться единый корпоративный дух, материальная заинтересованность и единство целей.
К этой же категории рисков можно отнести нарушения закона об авторском праве вследствие использования в проекте чужого исходного кода, защищенного законом об авторском праве. Менеджер проекта должен строго отслеживать такие ситуации и не допускать их.
Проектными рисками необходимо управлять, чтобы свести к минимуму их влияние на ход реализации проекта. Для этого параллельно с разработкой программного продукта должен идти систематический процесс идентификации рисков – то есть процесс выявления рисков и оценки степени их влияния на проект. В первую очередь должны идентифицироваться известные, предсказуемые риски. Это будет вести к усилению контроля за проектными рисками в целом, и в том числе к профилактике предсказуемых и непредсказуемых рисков, а значит и к снижению потерь при разработке проекта.
Как уже говорилось, сегодня существует огромное количество методологий управления проектами. Каждая из них имеет свои достоинства и, разумеется, свои недостатки. Каждая из этих методологий лучше других применима к какой-либоодной ли нескольким предметным областям и совершенно неэффективна в других.
Давайте рассмотрим основные методологии, применяемые сегодня в управлении проектами.
Каскадная (или водопадная) модель является классической методологией управления проектами. В этой методологиикаждая реализуемая задача, словно капля воды в водопаде, последовательно проходит все этапы реализации проекта.
Эта модель предполагает разбиение всего комплекса реализации проекта на несколько больших этапов:
· постановка задачи и системный анализ;
· планирование;
· реализация;
· тестирование;
· внедрение.
На этапе постановки задачи определяются требования к проекту, предметная область, стоимость проекта, возможные риски. Выделяются главные цели проекта.
На этапе планирования – а это обычно самый большой и тщательный этап во всем проекте – все цели проекта разбиваются на более мелкие задачи, те в свою очередь – на еще более мелкие подзадачи, и так до тех пор пока весь проект не будет разбит на множество элементарных действий, которые можно количественно оценить по срокам и стоимости. После этого выстраивается очередность исполнения полученных элементарных действий и оценивается срок исполнения проекта в целом. Между крупными этапами плана устанавливаются так называемые «вехи» - контрольные даты окончания определенных видов работ. К каждой такой дате каждый этап должен быть завершен. На этом же этапе формируется финансовая смета проекта, критерии оценки качества, а также возможные риски и меры реагирования на них.
Реализация проекта происходит в строгом соответствии с составленным планом. Все этапы реализации плана сверяются с запланированными вехами. В результате в установленный срок на выходе получается продукт, отвечающий всем целям и требованиям проекта.
Производится тестирование с целью проверки полученного продукта на работоспособность и соответствие требованиям качества. При выявлении отклонений производится его доработка .
Внедрение предполагает передачу реализованного проекта в эксплуатацию заказчику, а также обучение обслуживающего персонала.
В качестве примера давайте рассмотрим строительство дома. В таком проекте все требования четко определены, все ресурсы заранее просчитаны и поэтому каскадная модель управления идеально подойдет для его реализации. В план будет заложено несколько крупных этапов, ограниченных вехами (датами завершения):
• Подготовка участка под строительство;
• Рытье котлована, забивка свай и заливка фундамента;
• Возведение стен (по этажам);
• Возведение кровли и подведение коммуникаций, внутренняя отделка.
• Чистовая отделка;
• Оформление придомовой территории.
Каждый этап разбивается на некоторое количество необходимых работ, которые должны быть выполнены в определенном объеме к определенному сроку. Какие-то работы внутри этапа могут исполняться параллельно друг с другом, некоторые – только последовательно. В итоге весь запланированный этап будет реализован согласно контрольному сроку. Таким образом и весь проект будет складываться из ряда реализованных этапов. Если в проекте возникнут какие-то изменения, они будут внесены в генеральный план согласно «Плану внесения изменений».
Несмотря на кажущееся удобство, каскадная модель управления – это идеальная модель. Она прекрасно бы работала, если бы все работы исполнялись в точности согласно плану и не возникало бы никаких непредвиденных обстоятельств. На практике же зачастую она оказывается далеко не всегда применимой. Данная методология может довольно успешно использоваться в условиях высокой определенности требований к проекту, то есть когда заранее известны исходные и выходные параметры, а также перечень необходимых работ – например, в строительстве или при установке нового оборудования.
При разработке программного обеспечения водопадная модель применима только для очень небольших проектов со строго обозначенными требованиями. Если же перечень требований постоянно пополняется в процессе разработки проекта, то внесение бесчисленных изменений в план сделает проект громоздким и малоподвижным.
Отдельно стоит упомянуть о проектных рисках в каскадной методологии. Детальное управление возможными рисками предусматривается на этапе планированияв специальном разделе плана. Сюда заносятся все возможные способы реакции на потенциальные риски. Но зачастую дальше этого раздела плана дело не идет и управление рисками остается только на бумаге. При реализации больших проектов об управлении рисками попросту забывают. Это тоже является одним из серьезных недостатков каскадной методологии – негибкая система управления рисками.
Спиральная (итерационная) модель уже лучше, чем водопадная подходит для разработки программного обеспечения. Она позволяет работать в условиях неопределенности требований. Готовый проектный продукт получают путем прохождения нескольких итераций - «витков спирали». Каждый виток делится на следующие этапы:
· планирование;
· анализ рисков;
· конструирование;
· оценка результата.
На первом витке создается базовая версия продукта, в которой реализованы лишь самые основные свойства конечного продукта. На каждом последующем витке разработки предыдущая версия продукта дорабатывается и оснащается новыми возможностями. Этот процесс продолжается до тех пор, пока не будут реализованы все поставленные цели.
На каждом витке большое внимание уделяется анализу рисков. Именно поэтому этап анализа рисков стоит раньше этапа конструирования. К непосредственной разработке версии продукта можно приступать только когда будут минимизированы все возможные риски. Такая модель применима только для крупных проектов, когда наступление рисков может угрожать срыву проекта в целом и приведет к невосстановимым финансовым потерям. Поэтому в спиральной модели принятие мер для исключения рисков из проекта играет решающую роль.
С применением спиральной методологии разрабатываются крупные программные проекты – например, операционные системы или ИСР. Сначала выпускается начальная, базовая версия продукта с минимальным набором возможностей, а затем, с каждым новым витком разработки, к этой базовой версии добавляются новые и новые возможности. Зачастую такой процесс совершенствования не имеет конца, а продолжается по мере выдвижения все новых требований к продукту.
Гибкие методологии управления проектами стали дальнейшим развитием спиральной методологии и предназначены для разработки проектов в условиях высокой неопределенности требований, а также гибкой адаптации к меняющимся условиям рынка. При использовании данных методологий зачастую в самом начале проекта цели и требования бывают не определены полностью, а это значит, что уточняться и дополняться они будут уже в ходе разработки. Чаще всего гибкие модели управления применяют при разработке программного обеспечения. Далее мы будем рассматривать гибкие модели разработки именно в применении к разработке ПО.
Гибкие методологии разработки могут быть самыми различными, но все они основываются на принципах agile-манифеста. Agile-манифест декларирует четыре основные ценности и двенадцать принципов разработки программного обеспечения (подробнее с agile-манифестом вы можете познакомиться, перейдя по ссылке в конце документа). Методологии, основанные на данных принципах тяготеют к предпочтению неформального общения между разработчиками и сведению до минимума работ по составлению письменной документации.
Такие модели управления обычно реализуются группой разработчиков-единомышленников, которые объединены единым стремлением создать к требуемому сроку качественный программный продукт и получить за него вознаграждение. Внутри группы происходит тесное неформальное общение, часто один специалист может замещать сразу нескольких ролевых исполнителей (роли участников группы мы рассматривали выше, см. схему 1). Участники группы нацелены на конструктивное сотрудничество и взаимную поддержку друг друга.
После определения предметной области и главных целей весь проект разбивается на комплекс небольших задач, которые могут быть реализованы как отдельные функциональные единицы. Каждая такая задача разрабатывается в течении небольшого промежутка времени - спринта. Спринты имеют одинаковую продолжительность и продолжаются от двух недель до двух месяцев. В течение спринта участники группы на ежедневных совещаниях (митингах) обсуждают прогресс в достижении целей спринта, задачи, выполненные каждым участником группы от начала спринта, задачи предстоящего дня, а также выявляют возникшие затруднения и способы их скорейшего устранения.
При разработке ПО для максимального достижения целей спринта используются различные методы, позволяющие повысить производительность труда всей группы в целом, такие как:
коллективное владение кодом;
парное программирование;
разработка через тестирование;
непрерывная интеграция продукта;
частые небольшие релизы;
социальная защищенность программистов.
Каждый спринт завершается выдачей готовой функциональной единицы продукта. Эта функциональная единица передается заказчику, чтобы тот имел возможность испытать новый кусочек софта и дать обратную связь. Затем заказчик и разработчики совместно оценивают качество нового функционала, его актуальность, эргономичность, а также дальнейшее направление разработки проекта и расстановка дальнейших приоритетов работы. При необходимости корректируются цели: если , например, какая-то часть проекта потеряла актуальность, либо у заказчика нет денег на ее реализацию, то этой задаче присваивают более низкий приоритет, либо вообще отказываются от ее разработки. При таком подходе заказчик оказывается полностью вовлеченным в процесс реализации проекта и имеет возможность оценивать и корректировать весь процесс разработки.
Давайте рассмотрим основные направления разработки ПО, основанные на принципах Agile.
Технология «Scrum» появилась на свет в недрах Федерального бюро расследований (США). Этот инновационный, ранее нигде не применявшийся метод, в короткий срок и при минимальных затратах позволил небольшой группе разработчиков завершить многолетнюю безуспешную работу. Термин «scrum» стал нарицательным, означающим совершенно определенную технологию реализации высококачественных проектов за жестко фиксированное время в условиях неопределенности требований.
В основе данной технологии лежит слаженная работа кросс-функциональной команды, состоящей из всех необходимых в проекте специалистов. Обычно команда состоит из 7-9 человек, которые могут вести работу сразу по нескольким направлениям: например совмещать обязанности аналитика и тестировщика, backend и frontend специалистов.
Руководит командой scrum-мастер, который координирует сохранение конструктивной атмосферы в коллективе и соблюдение scrum-принципов. Важно помнить, что scrum-мастер – это в первую очередь не начальник, а именно координатор. Он помогает команде разрешать возникающие проблемы и противоречия, защищает ее от отвлекающих факторов, руководит ежедневными совещаниями.
После постановки целей создается Backlog – документ, описывающий все требования проекта. Все задачи в этом документе расставлены строго по степени значимости. Если у заказчика появляются новые требования, или вдруг изменяются условия рынка – то приоритеты в backlog могут быть перераспределены. Все пункты backlog представляют из себя функционально завершенные части проекта, которые могут разрабатываться независимо друг от друга.
Каждая часть беклога разрабатывается за короткий и строго фиксированный промежуток времени – спринт. Длина спринта зависит от опыта команды и обычно составляет от 2 до 4 недель. Функционал, который должен появиться в конце спринта, планируется в самом начале и не подлежит изменению в течение всего спринта. Разрабатываемая единица софта делится на фиксированные задачи, список которых вывешивается на доске. Каждый из членов команды берет на себя ответственность за выполнение определенных задач и за прогресс которых он отчитывается на ежедневных совещаниях – скрам-митингах. Во время скрам-митинга участники команды отчитываются о проделанной работе, синхронизируют свою деятельность, обсуждают проблемы и выбирают пути их решения.
Остановить спринт можно только по исключительным причинам, когда выявлена ошибка, несовместимая с целями проекта, либо возникла необходимость перейти к другому спринту. Спринт может быть остановлен только по решению скрам-команды.
В конце спринта команда выдает законченный инкремент программного продукта, который передается заказчику. Заказчик проводит оценку полученного функционала и выдает свое заключение для обратной связи. На основе оценки заказчика команда разработчиков проводит ретроспективный обзор завершившегося спринта, чтобы иметь возможность оптимизировать дальнейшую работу. После этого в беклог могут быть внесены изменения по требованию заказчика. Считается, что чем короче время спринта – тем более гибок процесс разработки. Минимизируются риски, чаще происходят релизы, чаще производители получают отзывы от владельца продукта, что позволяет быстрее реагировать на изменения требований и оптимизировать проект.
Скрам-технология позволяет путем детального прототипирования свести к минимуму изначально высокую степень неопределенности требований. Команда никогда не находится в состоянии застоя, все ее участники всегда вовлечены в энергичный творческий процесс. Ввиду того, что каждый пункт беклога представляет собой лишь небольшой инкремент будущего продукта, то заказчику не составляет особого труда понять и оценить его. Заказчик оказывается полностью вовлеченным в процесс разработки. В итоге получает именно то, что ему нужно, а не то, что получилось.
Scrum часто используют лишь на начальных стадиях разработки проекта, когда необходимо достичь определенного уровня прогресса. Дальше проект может управляться при помощи других технологий. Такой подход позволяет сделать процесс разработки еще более гибким и эффективным.
Под экстремальным программированием (Extreme Programming, XP) понимают применение традиционных и продуктивных методов разработки ПО, но в усиленном, «экстремальном» варианте. Экстремальное программирование предполагает исполнение следующих принципов:
1. Простота решений.
2. Интенсивная разработка продукта путем коротких итераций силами небольших групп разработчиков. Активное неформальное общение в группах и между группами.
3. Постоянная связь с заказчиком ПО.
4. Смелость в принятии решений, готовность идти на риск.
В ХР главным является процесс, приводящий к результату, а все факторы , связанные с документированием этого результата, – вторичны. Это позволяет за короткое время разрабатывать качественные программные продукты. Но чтобы достичь таких результатов, экстремальное программирование должно основываться на самом высоком уровне дисциплины и самодисциплины. Только тогда, когда каждый участник группы будет чувствовать себя ответственным за работу всей команды, команда будет способна создавать продукты на самом высоком уровне скорости и качества.
Давайте рассмотрим основные приемы и практики, принятые в ХР:
· Планирование процесса. В начале каждой итерации всей командой принимается решение о перечне задач, которые будут решены за итерацию.
· Постоянная прямая и обратная связь с заказчиком, который является главным специалистом в предметной области проекта.
· Метафора системы. Этот термин означает простоту в именовании функций, классов и переменных. Такая простота ведет к большему пониманию кода.
· «Ничего лишнего!». Все возможности системы должны быть реализованы как можно проще, не должно создаваться функционала, не включенного в список требований.
· Стандарты кодирования. Это субъективное понятие, означающее требование определенного стандарта в группе при разработке наиболее важных частей системы. Использование стандарта позволяет использовать описанные ниже механизмы, такие как коллективное владение кодом, рефакторинг и парное программирование.
· Коллективное владение кодом. Это свободный доступ любого программиста в группе к любой части кода и возможность ее корректирования. При внесении изменения в код, программист отвечает за работоспособность всей системы в целом и должен добиваться ее корректной работы на измененном участке.
· Парное программирование заключается в одновременном написании кода одним и проверке ее другим программистом. Такой подход позволяет добиваться высоких результатов качества и экономить время, но для его использования вся группа должна располагаться на одной общей территории.
· Рефакторинг – это упрощение с сохранением его функционала. Программисты постоянно работают над упрощением уже существующего кода.
· Частые релизы. Чем короче итерации – тем большее число ошибок, допущенных на начальных стадиях удается выявить. Остановить и исправить ошибки на короткой итерации гораздо дешевле, чем на длинной.
· Непрерывная интеграция системы. Как только инкремент софта прошел тестирование – его немедленно присоединяют к уже готовой части системы. Если тест не прошел – инкремент возвращается на доработку.
· Тестирование. Это один из важнейших принципов ХР. При разработке кода параллельно пишутся и тесты для его проверки. Не тесты пишутся «под код», а наоборот – коды пишутся под тест. И только когда код становится способен пройти все тесты, только тогда он интегрируется в готовую систему.
· 40-часовая рабочая неделя. Программист работает 8 часов в день, а остальное время тратит на отдых. Только в этом случае он может продуктивно работать (к тому же заказчик не оплачивает сверхурочное время). Если разработка задачи требует сверхурочного времени, то практика ХР требует скорейшего поиска и устранения проблемы.
Таким образом, применение методов экстремального программирования позволяет повысить уровень адаптации проекта в ситуации неопределенных и постоянно меняющихся требований. Но этот метод является радикально зависимым от человеческого фактора. Если весь коллектив не будет полностью и безоговорочно принимать правила ХР, то данная практика вместо колоссального успеха принесет колоссальный провал.
Японская производственная система по выпуску автомобилей «Тойота» характеризуется уменьшением выполняемой в данный конкретный момент работы и бережливым производством. На предприятиях «Тойота» нет складов деталей и узлов. Все произведенные изделия хранятся всего несколько минут, после чего оказываются немедленно задействованными в дальнейшей технологической цепочке. Это означает, что не производится ничего лишнего, кроме того, что нужно. Каждая деталь изготовляется к нужному сроку и в нужном количестве.
Фирма имеет годовой план изготовления и продажи автомобилей. Этот годовой план поставляется на главную сборочную линию. Там этот план начинает дробиться на технологические операции: какие узлы и к какому сроку должны быть выпущены на главный конвейер. Эта информация передается на производственные участки, где будут собираться эти узлы. Там каждая такая технологическая операция снова дробится на технологические цепочки уже по своему направлению: сколько деталей, механизмов и агрегатов и к какому сроку должно быть поставлено для сборки нужного количества узлов для постановки их на главный конвейер… И так будет продолжаться до тех пор, пока операции не достигнут элементарного уровня, после чего начинается работа согласно плану. Каждое звено технологической цепочки точно в срок обеспечивает следующее звено необходимыми деталями, механизмами, агрегатами. Таким образом, план, разбитый на множество операций, движется в обратном направлении в виде собранных механизмов, агрегатов, узлов будущего автомобиля и к нужному сроку готовые части поступают на главный конвейер.
На каждом этапе сборки благодаря непрерывному потоку работы продукция обретает добавочную стоимость. Это тоже один из основных принципов производственной системы «Тойота» - работа без потерь. На производстве была сделана полная идентификация потерь и выявлены следующие их источники:
· потери из-за перепроизводства. При хранении избыточного количества готовых деталей «про запас» можно легко не заметить брак. Кроме того для этого требуются дополнительные расходы на складские помещения, землю, зарплату кладовщиков.
· потери из-за излишних запасов. Аналогичная проблема. Легко не заметить бракованные детали или заготовки. Длительное хранение запасов снижает качество их учета и требует дополнительных расходов на складские помещения.
· потери из-за транспортировки. Чем ближе расположены друг к другу производственные линии, тем меньше будет затрат на перевозку и перегрузку деталей.
· потери из-за перемещений. Если бы контейнеры с заготовками доставлялись прямо на рабочее место, то рабочие, перемещающиеся для приема сырья и сдачи готовых изделий, могли бы тратить это время на выполнение технологических операций.
· потери из-за ожидания. Это одна из самых сложных потерь. Рабочий не может выполнять свою работу, если ему приходится ожидать доставки сырья или отправки готовых изделий из-за не синхронного производства.
· потери из-за избыточных технологических этапов. При совершенствовании технологических процессов обычно происходит совмещение нескольких операций в одну, а также исключение избыточных операций, что значительно экономит общее время производства.
· потери из-за выпуска бракованной продукции. Компания несет ответственность за выпуск бракованной продукции, которая выпадает в потери производства.
Для устранения всех этих потерь была сокращена избыточная рабочая сила, выявлены новые возможности оборудования, изменены технологии, организована доставка деталей между производственными участками. При такой организации работы постепенно снизились и косвенные потери.
На предприятии действует «интеллектуальная автоматика», позволяющая останавливать все производство при обнаружении неполадок или брака. Это приводит к меньшим потерям, чем выпуск бракованных автомобилей.
Каждое рабочее место снабжено списком стандартных операций, чтобы работник всегда мог его видеть. Также на каждом рабочем месте есть электронное табло, где отображается вся информация о производственном процессе, видны все производственные линии и выявленные на них неполадки.
Любая возникающая проблема решается при помощи системы «пяти вопросов», также придуманной на предприятии. Суть этой системы в том, что с помощью цепочки из пяти взаимоподчиненных вопросов можно добраться до первопричины проблемы. Вопросов может быть, конечно, и больше, но специалисты из «Тойота» утверждают, что пяти обычно бывает вполне достаточно. А когда понята причина проблемы, то можно приступать к ее решению.
Для устранения перепроизводства на предприятии принята система учета Kanban. Эта система оказалась настолько удачной, что ее переняли многие производства во всем мире.
Слово Канбан (камбан) в обобщенном переводе означает «точно в срок». В буквальном – «видимый на доске». Этим термином принято обозначать одну из гибких методологий, которая возникла на предприятии по производству автомобилей «Тойота». А вообще, этим словом у японцев обозначается карточка. Канбан является одним из инструментов «вытягивающей технологии», являющейся, в свою очередь, частью общей системы «точно в срок», применяемой на предприятии. Вытягивающая технология обеспечивает непрерывную поставку только что изготовленных деталей между производственными участками и позволяет четко синхронизировать все процессы, происходящие на предприятии от производства автомобилей до строительства новых производственных зданий. Ее принцип состоит в информировании предшествующего производственного участка о своей потребности в деталях и получении от него готовых изделий – точно в срок.
Система Канбан существует в двух вариантах: тарном и карточном. В тарном варианте работник ставит пустую тару из-под деталей на нижний ярус стеллажа, а сам работает с деталями из полной тары.
На таре жестко закреплен ярлык с идентификатором детали (код, наименование), количеством деталей в таре, адресом получателя и адресом отправителя. Логист, видя тару на нижнем ярусе, забирает ее и передает производителю указанной детали. Когда производитель произведет и поместит в тару необходимое количество деталей, логист доставляет их заказчику.
В карточном варианте на карточке с кодом детали заказчик пишет количество деталей и срок, относит его производителю и прикрепляет на специальной доске, где производитель видит все заказы. На современных предприятиях «Тойота» работник не относит сам свои карточки-заказы на предыдущий участок – он просто опускает их в специальный ящик, откуда их забирает логист и относит производителю.
Там он прикрепляет карточку на специальную доску заказов и уходит. Доска обычно делится на четыре части:
1. Поданные заказы.
2. Принятые заказы
3. Заказы в работе
4. Выполненные заказы.
Когда производитель видит поданный заказ и распределяет время на его выполнение, он перевешивает карточку в раздел 2, когда приступает к работе – в раздел 3, когда заканчивает – в раздел 4. Логист, видя карточку в четвертом разделе, забирает ее и вместе с выполненным заказом отправляет заказчику.
Благодаря такой системе каждый технологический процесс точно в срок получает необходимые ему детали от предшествующего процесса и таким образом оказывается синхронизированным весь производственный цикл. Если поставленные детали содержат брак, то работник останавливает производственную линию, а бракованные детали возвращаются обратно. При этом все сразу видят, на каком участке было остановлено производство. Такая система выработала важное правило на предприятии: проблема случается один раз, повторение ее исключено. Тот же принцип относится и к распределению рабочего времени. Продукция «Тойота» - 100 % качества.
Сегодня система Канбан реализована также в виде электронных информационных систем для обмена информацией между территориально удаленными друг от друга подразделениями предприятий.
Система Канбан получила широкое распространение в самых разных отраслях производства, как технология, позволяющая организовать эффективное бережливое производство. В чистом виде эта система успешно зарекомендовала себя в производстве штучных изделий. Как составная часть Канбан нередко используется совместно со Scrum при разработке программного обеспечения.
В данном методическом пособии мы с вами рассмотрели современные способы разработки программного обеспечения, проектные риски и способы их устранения, а также существующие на сегодняшний день основные методологии управления проектами.
Надо всегда помнить, что в управлении проектами нет универсальных рецептов и что каждый новый проект на самом деле – уникален. Тут можно использовать только обобщенные концепции – методологии управления проектами, выбирая для каждой сферы деятельности именно свою.
В особенности это можно сказать о проектах разработки новых программных продуктов. Несмотря на колоссальные достижения в области IT, эта сфера по-прежнему остается молодой и постоянно обновляющейся. Разработка программного обеспечения в данной сфере тесно

Рекомендуем посмотреть:

Что такое технология потоковых данных Использование облачного хранилища данных в образовательном пространстве Восьмеричный переход Конспект урока информатики по теме «Разветвляющие алгоритмы», 10 класс

Похожие статьи:

Оценка достижений учащихся на уроках информатики

Конспект открытого урока по информатике в 9 классе

Конспект урока информатики в 8 классе

Конспект урока информатики в 3 классе

Конспект урока информатики во 2 классе