Существует множество различных методологий разработки: Waterfall, Agile, Lean и другие.
Ситуацию осложняют различные схемы оплаты ИТ-разработок.
Что лучше: фиксированная цена, время и материалы или аутстаффинг людей? Человеку, далекому от коммерческой разработки, может быть сложно разобраться, что и когда следует использовать.
Чтобы помочь разобраться в этом, давайте рассмотрим разные методологии и схемы оплаты с точки зрения работы с рисками и права на ошибку.
Постараюсь писать простым языком, чтобы всем было понятно.
Меня зовут Константин Митин, я соучредитель и руководитель компании ИТ Мегастар/ИТ Мегагрупп.
Когда-то я был простым разработчиком, работал в Л3, дорос до тимлида, затем до руководителя отдела разработки крупной ИТ-компании.
Теперь я в деле Мегастар.
Право на ошибку
Что такое ошибка? Это когда что-то делается неправильно или несовершенно.
Человек не является идеальным существом; мы все совершаем ошибки.
Но у ошибок есть цена — последствия и стоимость их исправления.
Вряд ли кто-то станет утверждать, что ошибка реаниматора, спасшая жизнь человеку в реанимации, имеет более высокую цену, чем грамматическая ошибка первоклассника, который только учится писать.
Детство — волшебная пора, время недорогих ошибок, которые помогают быстро учиться и набираться опыта.
Не следует стремиться к полному отсутствию ошибок; они были, есть и будут. Я предлагаю стремиться минимизировать цену ошибок.
Простой бытовой пример.
Нам с женой нужно решить, в какой цвет покрасить стену в нашем доме.
Для нее этот вопрос гораздо важнее, чем для меня.
Но у меня есть мнение, которое меня спрашивают, и оно отличается от мнения моей жены.
Например, она хочет покрасить потолок в зеленый цвет (шутки в сторону), а я привык к белым потолкам.
Что может произойти дальше? Вы можете высказать свое мнение, потом начать дискуссию, потом поспорить, кто-то на кого-то обидится и идти дальше.
Люди не разводятся из-за такой ерунды.
При этом можно прикинуть, что цена ошибки — это стоимость баллончика с краской и немного времени на перекраску.
Пусть попробует, если не получится, если не понравится, просто перекрасим.
И дело не в том, что мне все равно, дело в том, что цена этой ошибки для меня приемлема и я к ней готов.
И здесь быстрее и дешевле попробовать и набраться опыта, чем вести дорогостоящие дискуссии.
Другими словами, я дал жене право на ошибку и заранее согласился на цену этой ошибки.
После этого мне терять нечего, я смогу только выиграть, если моя жена окажется права.
Я буду радоваться вместе с ней.
Деньги
Ведь мы занимаемся бизнесом.IT-разработка стоит денег, а еще нужно подписывать контракты.
В договоре должны быть указаны план платежей и график платежей.
Поговорим о схемах оплаты и имеющейся в них погрешности.
Измененная цена
Это обычный договор оказания услуг с указанием стоимости, графика оплаты, объема работ, поэтапного графика поставок, при наличии этапов работ, даты начала и даты завершения работ. Узким местом является фиксация объема работы.
Это могут быть функциональные требования, указанные в тексте договора, или ссылка на техническое задание в отдельном приложении к договору.
Естественно, если вы планируете использовать фиксированную цену, такой формат работы подразумевает, что вы должны очень точно знать, что именно вы хотите разработать, прежде чем приступить к работе.
Заключить контракт без права на ошибку, используя фиксированную цену, очень легко.
Заказчик не имеет права допустить ошибку в требованиях, закрепленных в договоре; все, что выходит за их рамки – это модификации, оплачиваемые отдельно.
Если подрядчик допустил ошибку в оценке стоимости работ, то все сверх суммы, зафиксированной в договоре, подрядчик выполнит за свой счет. Если сроки не соответствуют действительности, заказчик может расторгнуть договор.
Почему это? С такими договорами проще всего работать в суде.
Как правило, судья не имеет опыта разработки программного обеспечения и не знает контекста ваших отношений.
Основной опорой судьи при принятии решения по вашему делу является ваш договор, а также наличие или отсутствие подписанных актов о сдаче работ. И опыт судьи в рассмотрении других конфликтов.
В реальной жизни в контрактах с фиксированной ценой существует много неопределенности.
Это удобно для поддержания баланса интересов сторон и партнерства.
Все-таки с точки зрения бизнеса, а не юристов, договор не нужен, чтобы потом идти с ним в суд. Да, она предоставляет такую возможность, но ее использование, по сути, выгодно не всем сторонам.
Время и материал
При такой схеме оплаты вы платите за фактически отработанное специалистами время.
С юридической стороны это рамочный договор оказания услуг без конкретного объема выполняемых работ и их конечной стоимости.
Вместо этого, например, вы можете ежемесячно писать заявки на покупку специализированных часов.
Подходит, когда вы не совсем понимаете, что хотите получить в результате работы, а требования могут измениться в процессе разработки.
За качество и оперативность работы специалистов отвечает подрядчик, а за руководителя проекта придется доплатить.
В этой схеме заказчик имеет право допустить ошибку при формировании требований, а подрядчик – оценить бюджет работ по деньгам и срокам.
Поскольку работы проводятся небольшими этапами, их легче планировать и оценивать.
Если уровень оказания услуг перестает удовлетворять, вы можете быстро прекратить сотрудничество с неподходящим подрядчиком.
Обе стороны рискуют только объемом последнего заказа, который обычно ограничивается календарным месяцем.
Аутстаффинг
Вы нанимаете специалиста, скорее всего, на несколько месяцев и более.
С юридической точки зрения все формализовано, как и в модели Time&Material. Однако постановка задач, контроль эффективности и другие организационные вопросы возлагаются на заказчика.
Он больше подходит компаниям, имеющим свой ИТ-персонал, понимающим, что они делают, и которым необходимо временно расширить команду.
Причем таким образом, чтобы не нанимать людей в штат и сэкономить на подборе персонала.
Риски подрядчика ограничиваются срочной заменой арендованного сотрудника, если он, например, уволится.
Остальные риски на стороне заказчика.
То есть заказчик должен иметь собственные компетенции в разработке ПО и просто испытывать нехватку своих ресурсов.
Методологии разработки
Давайте посмотрим правде в глаза: существует множество методологий разработки.Навскидку можно вспомнить водопадную модель, итеративную модель, инкрементную модель, различные вариации инкрементно-итерационных моделей, V-модель, Kanban/Lean, Agile манифест, Scrum, XP, Unified Process, RAD и целый ряд производных от всех этот. Конечно, вы не сможете охватить все, поэтому вам придется пройти только основы.
Это не значит, что все остальное не достойно внимания.
Наоборот, оно того заслуживает, но по каждой методике вам придется написать несколько статей.
Модель развития водопада (Водопад)
В 1970 Уинстон Уокер Ройс описал модель разработки как поток последовательных этапов анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Эта модель называется каскадной моделью развития.
Он сделал это, чтобы показать его недостатки по сравнению с итеративной разработкой.
Водопадную модель часто критикуют за недостаточную гибкость и за то, что формальное управление проектами считается самоцелью в ущерб времени, затратам и качеству.
В водопадной модели нет возможности сделать шаг назад и изменить требования или уже разработанный функционал.
Все требования известны заранее, проектирование завершается до начала разработки.
Одним из преимуществ является то, что вы можете быстро провести разработку и тестирование за оговоренные деньги и в указанные сроки.
Это очень хорошо вписывается в договор с фиксированной ценой, в котором никому не дано права на ошибку.
Водопадная модель развития часто обсуждается, но редко используется.
Это очень упрощенный пример из учебников по разработке и тестированию начального уровня.
Например, на водопадной модели можно просто и понятно описать основы работы специалиста по контролю качества (контроль качества) и неправильно описать основы работы инженера по обеспечению качества (обеспечение качества).
Первый работает для поиска ошибок в реализации программного обеспечения, а второй — для обеспечения того, чтобы ошибки не возникали в реализации программного обеспечения.
И дело тут не только и не столько в объёме и качестве технической документации.
Также представители идеологии Agile любят критиковать водопадную модель.
С одной стороны, их можно понять, оказывается наглядно.
С другой стороны, это все равно неправильно, поскольку обходят стороной методологии, которые никогда не уступают Agile по эффективности.
Используя водопадную модель, можно реализовать стандартные и небольшие проекты.
Например, какой-нибудь информационный сайт. Для более длительных проектов и более сложных систем даже в процессе разработки часто выявляется функциональность, которая была упущена или неправильно описана при формулировке задачи или проектировании.
Это также может произойти на этапе приемки или после внедрения системы, когда появляется первый опыт использования.
В результате помимо первоначального договора с фиксированной ценой приходится заключать 2-3 дополнительных договора для реализации недостающего для удобной работы функционала.
То есть использовать итеративную модель разработки, о которой писал Ройс.
При обнаружении какого-то дефекта специалист по контролю качества говорит, что в технических характеристиках такой функционал не описан, поэтому его наличие никто не проверял, даже несмотря на логику его наличия.
Разработчик скажет, что функционала нет в ТЗ, поэтому этого никто не делал.
Руководитель проекта скажет, что функционал никто не анонсировал, поэтому его никто не оценивал, поэтому за дополнительную работу придется платить.
Кроме того, с заказчиком согласовываются технические характеристики и схемы применения.
Таким образом, в рамках проекта заказчик не имеет права допускать ошибки в формулировке задания и технического задания, а специалисты не имеют права отступать от технического задания.
Чем больше система, тем легче допустить ошибку и тем сложнее документировать ее описание.
Откуда тогда взялась такая негибкая методология разработки? Из перфокарт. Представьте себе, что у программиста месячная очередь ожидания в компьютерном центре.
Просто чтобы запустить ваш код. Цена ошибки очень высока, если вы допустите ошибку при переносе кода на перфокарты, если вы допустите ошибку в коде программы, если вы допустите ошибку в алгоритме или где-то еще, то вы сможете исправьте свою ошибку только через месяц.
Поэтому люди очень внимательно подходили к постановке задачи, потом рисовали на бумаге блок-схемы алгоритмов, отлаживали их на бумаге, потом писали код, тоже на бумаге, и отлаживали его на бумаге.
Долго, неделями.
Только после этого они изготавливали перфокарты и ждали своей очереди для запуска программы.
Цена ошибки была очень высока.
В 70-е годы 20 века уже была эпоха интерактивного программирования, когда цена ошибки резко снизилась.
Ну, программист подождет несколько десятков минут, пока код скомпилируется, вот и все.
Затем он будет отлажен и передан в отдел контроля качества.
Нечто похожее на каскадную модель можно увидеть сегодня в радиоэлектронике.
Например, разводка печатных плат и взаимодействие установленных на них компонентов сначала проектируются и отлаживаются в специальных эмуляторах.
Только после этого изготавливаются испытательные устройства.
Приходится ждать несколько недель, пока будет изготовлена печатная плата, затем необходимо собрать устройство и протестировать его.
При этом всегда выявляются ошибки, которые пытаются закрыть через драйверы (программный код).
Хороший результат — когда на второй-третьей итерации получается работающее устройство.
Итеративная разработка
При итеративной разработке мы принимаем тот факт, что при постановке задачи и написании технического задания могут быть допущены ошибки или мы просто не до конца понимаем конечный вид того, что предстоит разработать.
Поэтому разработка ведется итерациями, достаточно большими, чтобы в их рамках можно было получить некоторую бизнес-ценность в виде результата разработки, но достаточно малыми, чтобы можно было проработать и записать требования к итерации.
В самом простом подходе каждая итерация представляет собой небольшой проект разработки, включающий сбор требований, анализ и формализацию, разработку, тестирование и реализацию.
В более сложных случаях итерации происходят «перекрываясь», то есть пока реализуется текущая итерация, прорабатываются требования к следующей итерации.
В результате получается непрерывный поток анализа пользовательского опыта, требований, их формализации и постановки задач для следующих итераций, а также непрерывный поток разработки, отладки и тестирования.
Управлять проектами в итеративной модели довольно сложно, поскольку проект предполагает фиксацию объема работ, бюджета денег, бюджета ресурсов и четких сроков выполнения.
При использовании итеративной модели мы должны оставить незафиксированными либо объем работ и сроки, либо бюджеты денег и ресурсов.
Таким образом, вы можете использовать только схему оплаты типа «Время и материал».
Итеративная модель наиболее подходит для разработки продукта.
Обычно у нас есть метрики продукта, мы выдвигаем гипотезы о том, какие изменения в продукте могут его улучшить, проверяем эти гипотезы, анализируем изменения и формируем новые гипотезы.
Тестирование гипотез о продукте очень хорошо вписывается в итеративный подход. Таким образом, итерационный подход дает право на ошибку в требованиях или даже позволяет работать, когда у нас еще не сформировано окончательное представление о разрабатываемом продукте.
Вместо этого мы рискуем объемом работы в рамках итерации.
Гибкий
Agile — это не методология, это подход и манифест. 13 февраля 2001 года появился Agile-манифест, в котором были сформулированы 4 ценности и 12 базовых принципов.
Ценности:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее, чем исчерпывающая документация.
- Сотрудничество с заказчиком важнее согласования условий договора.
- Быть готовым к переменам важнее, чем придерживаться первоначального плана.
- Нашим высшим приоритетом является удовлетворение потребностей клиентов посредством регулярной и своевременной поставки ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки.
Гибкие процессы позволяют использовать изменения, чтобы предоставить клиенту конкурентное преимущество.
- Работающий продукт должен выпускаться как можно чаще, от пары недель до пары месяцев.
- Разработчики и представители бизнеса должны ежедневно работать вместе на протяжении всего проекта.
- Над проектом должны работать мотивированные профессионалы.
Чтобы выполнить работу, создайте условия, окажите поддержку и полностью доверьтесь им.
- Прямое общение — наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт – главный показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм на неопределенный срок.
Agile помогает наладить такой процесс устойчивого развития.
- Постоянное внимание к техническому совершенству и качеству дизайна повышает гибкость проекта.
- Простота – искусство минимизации ненужной работы – имеет важное значение.
- Лучшие требования, архитектурные и технические решения исходят от самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы повышения эффективности и соответствующим образом корректировать свой стиль работы.
Чтобы разобраться в этом, потребуется отдельная статья.
А потом, возможно, еще несколько, чтобы разобраться в нюансах.
Теперь следует отметить, что Agile-манифест имеет смысл именно для продуктовой и итеративной разработки, на что нам ясно намекает принцип №8. Да, вести проект в соответствии с Agile-манифестом возможно, но для этого потребуется «мотивированный профессионал» в управлении проектами, которого найти довольно сложно.
Скрам
Люди часто путают Scrum и Agile. Хотя первый — это методология разработки первой половины 90-х годов 20 века, а Agile — манифест начала 21 века.
Возможно, путаницу вызвало название книги «Agile Software Development with SCRUM», вышедшей в 2001 году.
Скрам — популярная тема, и о ней много написано.
Нет необходимости все это повторять.
Я просто хотел бы отметить некоторые неочевидные вещи.
Когда этот подход был впервые описан, еще в 1986 году, было справедливо отмечено, что проекты, над которыми работают небольшие команды разных специалистов, как правило, систематически дают лучшие результаты, и объяснили это как «подход регби» (Scrum).
термин из регби, относится к стартовому состоянию команд до вбрасывания мяча).
Часто это правда.
Scrum — достаточно формализованная и хорошо описанная методология (есть обучение и сертификация), для которой существует множество вариаций и частичных реализаций (SCRUMbut, SCRUMand).
Это хорошо, многое можно взять уже готовое и не изобретать велосипед. Важно помнить, что Scrum построен на итеративной модели разработки.
В Scrum итерации называются спринтами.
И, как и любая методология итеративной разработки, Scrum больше подходит для разработки продуктов, чем для разработки проектов.
Еще одно слабое место Scrum — работа с «большими командами».
Если ваша команда больше 11 человек, ее уже нужно разбить на две команды, после чего вам понадобится SCRUM of SCRUM (SoS) или Nexus. Еще есть LeSS, а затем LeSS Huge, когда команд больше 8. Темы, достойные отдельного разговора.
Канбан
Нет, это не тот Канбан, который мы знаем из бережливого производства и который был у Toyota еще в 1962 году.
Это больше похоже на канбан-доску, на которой вы рисуете столбцы, обозначающие этапы производственного процесса, например: «Сделать», «В процессе», Тестирование, готово, внедрено.
А затем разместите на этой доске стикеры с заданиями, а затем перемещайте их по столбцам по мере выполнения задания.
Канбан — это не методология, это инструмент визуализации.
Успешно применяется в любой методологии разработки.
В том же Scrum — любимый инструмент. Несмотря на свою простоту, он по-прежнему подходит для поддержки продуктов небольшими командами и анализа инцидентов.
Модель поэтапного развития
В этой модели проект выполняется поэтапно, каждый из которых представляет собой приращение.
То есть это модуль готового и проверенного функционала.
Причём разрабатываемая система разбивается на модули таким образом, чтобы её можно было использовать в кратчайшие сроки, желательно после реализации первого этапа, а последующие приращения добавляли бизнес-ценность к «базовому» функционалу.
Что дает такая модель? Возможность разделить изначально большую систему на набор относительно небольших модулей, которые можно разрабатывать последовательно или параллельно (если повезет).
Благодаря небольшому размеру модуля снижается его сложность, поэтому его легче проектировать, внедрять и тестировать.
Иногда инкрементальный подход неправильно называют «мульти-водопадом».
За что вам возьмет такую модель? Для правильной модульной организации вашей системы вам понадобится либо опытный менеджер проекта, либо опытный архитектор.
Особенно помня, что целое всегда больше суммы его частей.
Инкрементальная модель позволяет вам внедрять системы, требования к которым вам неясны.
То есть вроде понятно, что и где должно быть «вообще», но система настолько большая и сложная, что описать ее целиком невозможно.
То есть инкрементальная модель дает право на ошибку в требованиях и постановке задачи, но требует хотя бы общего понимания системы и опытного менеджера проекта или архитектора.
Данная модель также дает возможность вести крупные проекты с высокой степенью неопределенности требований по схеме «Фиксированная цена», то есть можно фиксировать объем работ, календарные даты и бюджет денег.
Даже если для этого вам придется перед этим провести предпроектный этап.
Довольно часто перед заключением договора на разработку крупной системы с поэтапной сборкой заключается отдельный договор на нулевой этап - проектирование.
Без этого сложно оценить сроки и стоимость разработки.
Еще один важный момент, которого мы здесь не касаемся, — это бюджетное проектирование.
Его применяют, когда уже известны календарные сроки или бюджет денежных средств и необходимо найти техническое решение, которое позволило бы уложиться в известные ограничения.
При разработке больших и сложных систем часто используется такой подход.
Унифицированный процесс (поэтапно-итеративная модель разработки)
Поэтапно-итеративная модель разработки позволяет реализовывать действительно большие и сложные проекты, включающие фиксацию требований, объемов работ, денежного бюджета, бюджета ресурсов и сроков.
Это модель, лежащая в основе Единого процесса.
И одним из самых известных представителей семейства Unified Process (UP, 1995) является Rational Unified Process (RUP, 1998).
Методика содержит множество инструментов, в частности, язык UML, разработанный для этой концепции, и очень обширный набор спецификаций для артефактов.
Но требование использовать все это не является догмой.
Конкретный инструмент следует использовать только в случае необходимости.
Unified Process потребует от вас разработки сценариев использования системы, которые необходимо будет описать простым и понятным языком, чтобы быть понятным стороннему читателю.
Это не только и не столько пользовательские сценарии, сколько диаграммы обмена данными, диаграммы изменения состояний и так далее.
Вам придется уделить особое внимание архитектуре приложения.
Это фундамент, на котором будет стоять ваша система.
Без хорошей архитектуры, а значит, без сильного архитектора, вы не добьетесь успеха.
А Единый процесс подразумевает одновременное использование инкрементного и итеративного подходов, то есть инкрементно-итеративную модель разработки.
Таким образом, на начальном этапе проектирования вы:
- Дайте общее описание системы.
Например, в виде записи функциональных требований и основных сценариев использования системы.
- Вы работаете над архитектурой приложения, понимая, что требования будут меняться в процессе разработки.
То есть ваша архитектура должна позволять вам гибко реагировать на изменения требований, а также позволять легко модернизировать систему после ввода в эксплуатацию.
- Разделите спроектированную систему на этапы функциональности.
Более того, инкремент — это полноценный функционал, с которым может работать пользователь.
То есть нет никаких инкрементов типа «бэкенд», «фронтенд» и тому подобных.
- Вы планируете этапы реализации при условии, что один этап может содержать одно или несколько приращений, но одно приращение нельзя разделить между разными этапами.
- Вы рассчитываете и выделяете буферы (календарные, денежные, ресурсные) между этапами разработки.
Каждый этап включает в себя:
- Анализ опыта использования уже реализованных инкрементов.
- Анализ и детализация требований на текущий этап.
- Анализ рисков проекта в целом и текущего этапа в частности.
- Проектирование функциональности этапа, включающее в себя доработку уже реализованного функционала (именно для этого и были встроены буферы) и реализацию приращений этапа.
- Разработка и отладка текущего этапа.
- Тестирование текущего этапа.
- Реализация текущего этапа.
Таким образом, мы можем зафиксировать объем работ, сроки, бюджет денег, бюджет ресурсов, то есть мы можем создать договор с фиксированной ценой.
Но при этом за счет структуры проектирования в виде этапа мы снижаем риски ошибок в постановке задачи и проектировании.
Размещая буферы после этапов, мы имеем возможность вести итеративную разработку, то есть имеем право на ошибку в требованиях.
И реализация тоже, такие ошибки просто исправляются в последующих итерациях.
Однако эта методология не прощает ошибок в архитектуре и управлении проектами.
Ваш руководитель проекта и архитектор должны быть настоящими профессионалами.
Такой подход также позволит использовать на проекте разработанные методы управления рисками.
Вы можете использовать критические цепочки, критические пути, строить PERT-диаграммы и многое другое, что необходимо на действительно больших и сложных проектах.
Подведение итогов
Можно сказать, что универсальной модели разработки программного обеспечения не существует:
- Водопадная модель разработки (Waterfall) на самом деле является своего рода упрощенным примером, который удобен для учета рисков, возникающих в процессе разработки.
- Agile — это не конкретная модель или методология разработки, а скорее манифест, которому пытается следовать широкий спектр методологий разработки.
- Итеративная модель разработки хорошо подходит для разработки продуктов.
Для этого есть набор устоявшихся фреймворков, например Scrum. Основным недостатком модели является то, что сложно одновременно зафиксировать сроки и объем работ (а значит, и стоимость).
Преимущество модели в том, что она позволяет работать с высокой степенью неопределенности требований.
В том числе и в тех случаях, когда систему просто невозможно описать на момент разработки.
- Модель поэтапной разработки хорошо подходит для проектов с фиксированными сроками и объемом работ. Модель позволяет эффективно работать в случаях, когда требования содержат малую или среднюю степень неопределенности.
- Инкрементально-итеративная модель разработки хорошо подходит для крупных и сложных проектов, в том числе в условиях высокой неопределенности требований.
Для этого есть набор устоявшихся фреймворков, например Unified Process. Однако эта модель предъявляет высокие требования к архитектору и руководителю проекта.
Не то чтобы это невозможно, просто это не удобно.
Если вы дочитали до конца и что-то для себя поняли, то спасибо.
Несмотря на то, что многие вещи остались за рамками рассмотрения, иначе.
То, что нам удалось рассмотреть, не было рассмотрено достаточно подробно; текста оказалось довольно много, и не всегда простого.
Надеюсь, это было полезно для вас.
Теги: #программирование #Управление разработкой #Управление проектами #Разработка веб-сайтов #agile #kanban #методология разработки #итеративная разработка #водопадная модель #инкрементальный #rup
-
Eroll - Концепция Чтения Электронных Книг
19 Oct, 24 -
Компьютерный Контейнер
19 Oct, 24 -
Микросервисы
19 Oct, 24
