Право на ошибку. Деньги и методологии разработки в ИТ

Есть много разных методологий разработки: Waterfall, Agile, Lean и другие. Ситуацию усложняют различные схемы оплаты разработки в ИТ. Что лучше: Fixed Price, Time&Material или взять людей на аутстафф? Человеку, далёкому от коммерческой разработки, бывает сложно разобраться что и когда стоит использовать. Чтобы помочь с этим разобраться, рассмотрим разные методологии и схемы оплаты с точки зрения работы с рисками и права на ошибку. Попробую писать простым языком, чтобы было понятно всем.

Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в L3, дорос до тимлида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в АйТи Мегагруп.

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

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

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

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

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

Деньги

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

Fixed Price

Это обычный договор на оказание услуг, фиксирующий стоимость, график платежей, объём работ, график поэтапной сдачи, если есть этапы работ, дата начала и дата окончания работ. Узкое место — фиксация объёма работ. Это могут быть функциональные требования, указанные в теле договора или ссылка на техническое задание в отдельном приложении к договору. Естественно, если вы планируете использовать Fixed Price, этот формат работы подразумевает, что вы должны очень точно знать, что именно хотите разработать, ещё до старта работ.

Из Fixed Price очень легко сделать договор без права на ошибку. Заказчик не имеет права на ошибку в зафиксированных в договоре требованиях, всё, что выходит за их рамки — доработки, оплачиваемые отдельно. Если исполнитель ошибся в оценке стоимости работ, то всё, что сверху зафиксированной в договоре суммы — исполнитель выполнит за свой счёт. Ошиблись в сроках — Заказчик может разорвать договор.

Почему так? С такими договорами легче всего работать в суде. Обычно судья не имеет опыта в разработке программного обеспечения и не знает контекста ваших взаимоотношений. Основная опора судьи при принятии решения по вашему делу — ваш договор, а также наличие или отсутствие подписанных актов сдачи работ… И опыт судьи при рассмотрении других конфликтов.

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

Time&Material

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

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

Outstaffing

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

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

Методологии разработки

Скажем прямо, методологий разработки много. Навскидку можно вспомнить каскадную модель, итеративную модель, инкрементную модель, различные вариации инкрементно-итеративных моделей, V-модель, Канбан/Lean, манифест Agile, Scrum, XP, Unified Process, RAD и целый ряд производных от этого всего. Конечно, всего не охватишь, поэтому придётся пройтись только по базовым вещам. Это не значит, что все остальное не заслуживает внимания. Наоборот, заслуживает, но придётся на каждую методологию писать по несколько статей.

Каскадная модель разработки (Waterfall / Водопад)

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

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

Каскадная модель разработки часто обсуждается, но редко используется. Это некоторый сильно упрощённый пример из учебников по разработке и тестированию начального уровня. Например, на каскадной модели можно просто и наглядно расписать основы работы QC-специалиста (quality control) и неправильно расписать основы работы QA-инженера (quality assurance). Первый работает над тем, чтобы находить ошибки в реализации программного обеспечения, а второй работает над тем, чтобы не происходило ошибок в реализации программного обеспечения. И дело тут не только и не столько в объёмах и качестве технической документации.

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

С помощью каскадной модели можно реализовывать стандартные и небольшие проекты. Например, какой-нибудь информационный сайт. Для более долгих проектов и более сложных систем ещё в процессе разработки часто выявляется упущенный либо неправильно описанный при постановке задачи или проектировании функционал. Также это может происходить на этапе приёмки либо после внедрения системы, когда появляется первый опыт использования. Как результат к первоначальному договору по Fixed Price приходится заключать ещё 2-3 дополнительных соглашения на реализацию недостающего для удобной работы функционала. То есть использовать итеративную модель разработки, о которой писал Ройс.

Когда обнаруживается какой-то недостаток, QC-специалист говорит, что такой функционал не был описан в ТЗ, поэтому его наличие, даже несмотря на всю логичность его присутствия, никто не проверял. Разработчик скажет о том, что функционала нет в ТЗ, поэтому его никто и не делал. Менеджер проекта скажет, что функционал никто не заявлял, поэтому его никто не оценивал, поэтому придётся оплачивать дополнительные работы. Кроме того, ведь ТЗ и макеты приложения согласованы с заказчиком.

Таким образом, в рамках проекта у заказчика нет права на ошибку в постановке задачи и ТЗ, а у специалистов нет права на отклонение от ТЗ. Чем больше система — тем легче допустить ошибку и тем сложнее задокументировать её описание.

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

В 70-х годах 20-го века уже была эра интерактивного программирования, когда стоимость ошибки резко снизилась. Ну, подождёт программист несколько десятков минут, пока код скомпилируется, всего-то делов. Потом его отладит и отдаст QA.

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

Итеративная разработка

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

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

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

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

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

Agile

Agile — это не методология, это подход и манифест. 13 февраля 2001 года появился Agile Manifesto, в котором заявлялись 4 ценности и 12 базовых принципов.

Ценности:

  1. Люди и взаимодействие важнее процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.

  3. Сотрудничество с заказчиком важнее согласования условий контракта.
  4. Готовность к изменениям важнее следования первоначальному плану.

Базовые принципы:

  1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
  2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
  3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
  4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
  5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
  6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
  7. Работающий продукт — основной показатель прогресса.
  8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
  9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
  10. Простота — искусство минимизации лишней работы — крайне необходима.
  11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
  12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Сам по себе Agile Manifesto не такой простой, как кажется. На то, чтобы его разобрать, понадобится отдельная статья. И потом, возможно, ещё несколько, чтобы пройтись по нюансам.

Сейчас же нужно отметить, что Agile Manifesto имеет смысл именно для продуктовой и итеративной разработки, о чем нам явно намекает принцип №8. Да, можно провести проект в соответствии с Agile Manifesto, но для этого потребуется «мотивированный профессионал» в ведении проектов, которого достаточно сложно найти.

Scrum

Люди часто путают Scrum и Agile. Хотя первое - это методология разработки родом из первой половины 90-х годов 20-го века, а Agile - это манифест родом из начала 21-го века. Наверное, путаницу породило название книги «Agile Software Development with SCRUM», вышедшей в 2001 году.

Scrum — популярная тема, по ней очень много всего написано. Повторять все это нужды нет. Хочется лишь отметить некоторые неочевидные вещи.

При первом описании подхода, ещё в 1986 году, было верно отмечено, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби» (Scrum - англ. «схватка» — термин из регби, обозначает стартовое состояние команд перед вбросом мяча). Часто это действительно так.

Scrum — достаточно формализованная и хорошо описанная методология (есть обучение и сертификация), для которой есть много вариаций и частичных реализаций (SCRUMbut, SCRUMand). Это хорошо, можно многое взять готовое и не выдумывать велосипед заново.

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

Другим слабым местом Scrum является работа с «большими командами». Если ваша команда больше 11 человек, её уже нужно дробить на две команды, после чего вам понадобится SCRUM of SCRUMs (SoS) либо Nexus. Есть ещё LeSS, а потом и LeSS Huge, когда команд больше 8. Темы достойные отдельного обсуждения.

Канбан

Нет, это не тот Канбан, что нам известен из бережливого производства и был у Тойота ещё 1962 году. Это скорее Канбан-доска, на которой вы чертите колонки, отвечающие за стадии производственного процесса, например: Сделать, В работе, Тестирование, Сделано, Внедрено. А потом клеите на эту доску стикеры с задачами, после чего перемещаете их по колонкам по ходу выполнения задачи.

Канбан — это не методология, это средство визуализации. Успешно применяется в любой методологии разработки. В том же Scrum это любимый инструмент.

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

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

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

Что даёт такая модель? Возможность разделить изначально большую систему на набор сравнительно небольших модулей, которые можно разрабатывать последовательно либо параллельно (если повезёт). За счёт небольшого размера модуля, снижается его сложность, поэтому его легче проектировать, реализовывать и тестировать. Иногда инкрементный подход неверно называют «мульти-водопад».

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

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

А ещё эта модель даёт возможность вести крупные проекты с высокой степенью неопределённости в требованиях по схеме Fixed Price, то есть можно зафиксировать объёмы работ, календарные сроки и бюджет денег. Пусть даже для этого и до этого придётся произвести этап предпроектного проектирования.

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

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

Unified Process (Инкрементно-итеративная модель разработки)

Инкрементно-итеративная модель разработки позволяет реализовывать действительно большие и сложные проекты, в том числе и с фиксацией требований, объёмов работы, бюджета денег, бюджета ресурсов и сроков. Именно такая модель заложена в основе Unified Process. А одним из самых известных представителей семейства Unified Process (UP, 1995 год) является Rational Unified Process (RUP, 1998 год).

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

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

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

И Unified Process подразумевает одновременное использование инкрементного и итеративного подхода, то есть инкрементно-итеративную модель разработки.

Таким образом, на этапе первоначального проектирования вы:

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

Затем начинаете последовательно выполнять этапы. При этом в каждый этап входит:

  1. Анализ опыта использования уже реализованных инкрементов.
  2. Анализ и детализация требований к текущему этапу.
  3. Анализ рисков проекта в целом и текущего этапа в частности.
  4. Проектирование функционала этапа, который включает в себя доработку уже реализованного функционала (для этого буферы и закладывали) и реализацию инкрементов этапа.
  5. Разработка и отладка текущего этапа.
  6. Тестирование текущего этапа.
  7. Внедрение текущего этапа.

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

Таким образом, мы можем зафиксировать объем работ, сроки, бюджет денег, бюджет ресурсов, то есть можем делать договор Fixed Price. Но при этом за счёт рамок проектирования в виде этапа мы снижаем риски ошибок в постановке задачи и проектировании. За счёт размещения буферов после этапов мы имеем возможность вести и итеративную разработку, то есть имеем право на ошибку в требованиях. Да и реализации тоже, такие ошибки просто исправляются в последующих этапах-итерациях.

Однако данная методология не прощает ошибок в архитектуре и ведении проекта. Ваш руководитель проекта и архитектор должны быть настоящими профессионалами.

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

Заключение

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

  1. Каскадная модель разработки (Waterfall), на самом деле представляет из себя некий упрощённый пример, на котором удобно рассматривать, возникающие в процессе разработки, риски.

  2. Agile — это не какая-то модель разработки либо методология, скорее это манифест, которому пытается соответствовать широкий ряд методологий разработки.

  3. Итеративная модель разработки хорошо подходит для развития продуктов. Для неё существует набор устоявшихся фреймворков, например Scrum. Основным недостатком модели является то, что в ней сложно одновременно зафиксировать сроки и объёмы работ (следовательно и стоимость). Преимуществами модели является то, что она позволяет работать с высокой степенью неопределённости в требованиях. В том числе и в случаях, когда систему просто невозможно описать на момент начала разработки.

  4. Инкрементная модель разработки хорошо подходит для проектов, у которых зафиксированы сроки и объёмы работ. Модель позволяет эффективно работать в случаях, когда в требованиях присутствует небольшая либо средняя степень неопределённости.

  5. Инкрементно-итеративная модель разработки хорошо подходит для больших и сложных проектов, в том числе в условиях высокой неопределённости в требованиях. Для неё существует набор устоявшихся фреймворков, например Unified Process. Однако эта модель предъявляет высокие требования к архитектору и руководителю проекта.

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

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

0
30 комментариев
Написать комментарий...
Stas Zaelcovsky

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

Ответить
Развернуть ветку
Константин Митин
Автор

Чаще всего мы занимаемся нестандартными и крупными проектами, для них не существует «идеальной методологии». Если удаётся ограничить объем работ, то удобно использовать Unified Process с поэтапной сдачей. К тому же поэтапная сдача и оплата повышает для заказчика безопасность и управляемость процессом разработки.
Был проект с чудовищной изменчивостью требований (по объективным причинам), его пришлось делать даже не по методологии, а по Agile Manifesto. Это было похоже на итеративную разработку, но длина итерации колебалась от 1 до 4 недель, и могли прилетать срочные изменения. Например, Scrum в таких условиях сразу бы отказал. Вытаскивать все приходилось за счёт управления ожиданиями, управления рисками и созданием общей команды проекта в которой были не только наши сотрудники, но и сотрудники заказчика.
Есть уже взрослые системы, на которых работа идёт по «Канбан», и там этого хватает.
Есть продуктовая разработка по SCRUMbut, и там это удобно, как нам, так и заказчику.

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

Единственное, что мы предпочитаем работать малыми и слаженными командами. Так скорость и эффективность выше. Но это общее для многих методологий.

Ответить
Развернуть ветку
Stas Zaelcovsky

" Например, Scrum в таких условиях сразу бы отказал." - а по каким причинам Скрам отказал бы?

Ответить
Развернуть ветку
Константин Митин
Автор

Почему Scrum отказал бы на том проекте. Не смотря на требования, которые не поддавались фиксации, сроки были жёстко зафиксированы, а так же был список бизнес-целей, которые нужно было достигнуть к этому сроку (очень сжатому). Scrum не гарантирует достижения определённых показателей к конкретному сроку.
Кроме того, Scrum — это достаточно жёсткая методология, а там проект бросало из стороны в сторону, как при сильном шторме. Даже длину спринта зафиксировать нельзя было.
P.S.
Был и ещё один забавный момент. Со стороны заказчика был бизнес-аналитик, который писал ТЗ. Это документ на несколько сотен страниц, который постоянно переписывался. В конце проекта, я спросил у человека, а зачем он это делает. Мне ответили, что ежемесячно это ТЗ отправляется в головной офис.
В ответ я спросил, а его там хоть кто-то читает? Естественно получил ответ, что нет. Дальше я спросил, а ты сам хотя бы читаешь ТЗ перед отправкой? Мне ответили — нет, конечно. Пройдёт время, а потом скажут, что это был Waterfall. )))

Ответить
Развернуть ветку
Сергей Титков
> Каскадная модель разработки (Waterfall / Водопад)
> В 1970 году Уинстон Уокер Ройс описал модель разработки....

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

Ответить
Развернуть ветку
Константин Митин
Автор

Давайте вы прочитаете первоисточник, он доступен вот по этой ссылке: https://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf

В нем следует обратить внимание на рисунок 2 и рисунок 4. А потом попробуйте, ссылаясь на первоисточник, опровергнуть вот это: "...В 1970 году Уинстон Уокер Ройс описал модель разработки, как поток последовательно проходящих фаз анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. ... Сделал он это, чтобы показать её недостатки по сравнению с итеративной разработкой...".
Хорошо?

Ответить
Развернуть ветку
Stas Zaelcovsky

а до 1970 ватерфолла не существовало? Или существовал но Ройс его просто описал. И ватерфолл использовался же на практике в те времена? То есть даже если учесть что его придумал Ройс только чтобы показать его недостатки - тем не менее фактически разработка по ватерфоллу существовала и по ней работали команды?

Ответить
Развернуть ветку
Константин Митин
Автор

Это очень интересный вопрос. С одной стороны, существует мнение, что Waterfall не существовало и после 1970-го года. Это не методология, которую когда-то и кто-то предложил, чтобы вести успешную разработку. Это маркетинговый инструмент, придуманный чтобы оттенять преимущества той либо иной новой методологии.
С другой стороны, Ройс же не зря упоминает об этом подходе в своей статье, значит кто-то пытается им пользоваться. И, действительно, это просто наивный подход к разработке, содержащий в себя ряд ошибок, которые обусловлены только отсутствием опыта. Такие ошибки делали до статьи Ройса и после статьи Ройса.
С третьей стороны, в какой-то момент каскадная модель поселилась даже в Project Management Body Of Knowledge (PMBOK).
С четвёртой стороны. Никто не мешает взять крупный проект, оформить его по Waterfall, но провести его по инкрементной либо инкрементно-итеративной модели. Не заглядывая сильно внутрь процесса разработки, их сложно отличить.
В общем, Waterfall с нами надолго.

Ответить
Развернуть ветку
Сергей Титков

А самое смешное, что его и сейчас нет. Waterfall это колективное бессознательное.
Если бы было, то был бы документ описывающий ее:)
Типа скрам гайда или аджайл манифеста

Ответить
Развернуть ветку
Константин Митин
Автор

Термин "Коллективное бессознательное" вы употребляете, явно не понимая его сути.
А еще почитайте стандарт DOD-STD-2167A от 1985 года. Там уже все есть.

Ответить
Развернуть ветку
Сергей Титков

Стоп.
Либо DOD-STD-2167 от 1985
Либо DOD-STD-2167A от 1988

Берем DOD-STD-2167A от 1988
Текст стандарта: http://everyspec.com/DoD/DoD-STD/DOD-STD-2167A_8470/

В определениях нет водопада как и в тексте стандарта.

Ответить
Развернуть ветку
Константин Митин
Автор

Вы просто смотрели наличие слова «Waterfall» в тексте? Либо посмотрели, а не описана ли там каскадная модель разработки? Как бы отсутствие одного из названий методологии в документе, не мешает документу описывать методологию.

Ответить
Развернуть ветку
Сергей Титков

Стандарты пишутся по определенным правилам.
И в частности у стандартов есть глоссарий, в котором описываются термины.
Итак в стандарте DOD-STD-2167A от 1988 введен термин водопад? Если да то где?
В документе введено понятие каскадная модель? Да? Где.

Примеры:
- Термин SCRUM был явно введен и описан.
- Пример из вашего текста: Например, на каскадной модели можно просто и наглядно расписать основы работы QC-специалиста (quality control)
Это пример ошибочного использования термина. QC(quality control) - на русский переводится как управление качеством(ГОСТ Р ИСО 9000-2015)

Итого термин водопад не описан в введен в стандрате: DOD-STD-2167A
Наиболее раннее его упоминание это статья: https://static.aminer.org/pdf/PDF/000/361/405/software_requirements_are_they_really_a_problem.pdf).

Так что мимо.
Если натягивать сову на глобус то можно сказать что Ройс описал скрам

Ответить
Развернуть ветку
Константин Митин
Автор

То есть вы просто ищите слово «водопад» в тексте, если его там нет, значит документ не описывает модель разработки «водопад»? А потом вы на всякий случай смотрите, а нет ли там слов «каскадная модель»?
Проще говоря, суть написанного в документе вас вообще никоим образом не интересует?
Не, ну тогда можно что угодно валить на «коллективное бессознательное», чего ещё сказать-то.
P. S.
Вы очень по-глупому вываливаетесь из контекста. Можете посмотреть то сообщение, которое я вам писал 7-го июня. Можно прямо его скопировать и вставить вам в ответ. На вопрос из него, вы так ответить не смогли. Кстати, и ссылку на работу Bell и Thayer я же вам и послал.

Ответить
Развернуть ветку
Сергей Титков

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

P.S. Документ я прочел.

P.S.S. Вот эти два человека и виноваты во всей вакханалии с водопадом... Наверно.

Ответить
Развернуть ветку
Константин Митин
Автор

Agile нам говорит же: «Работающий продукт важнее исчерпывающей документации»? А в стандарте же описано очень много требований к документации?
Нам же Scrum говорит о том, что разработка должна быть итерационной? А в этом стандарте исповедуется совсем иной подход.
Методологию «Канбан», я вообще комментировать не буду. Для смеха лишь отмечу, что ни про доску для визуализации процесса, ни про статистику в стандарте ни слова.
Ничего вы не читали.
P. S.
Боюсь, что рассказывать вам про PERT и CPP, которые были задолго до статьи Ройса, просто бесполезно. Вы и это прочитать и понять не сможете.

Ответить
Развернуть ветку
Сергей Титков

Вы писали:
Agile нам говорит же: «Работающий продукт важнее исчерпывающей документации»?

Верно, чуть ниже:
То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

Вы писали: А в стандарте же описано очень много требований к документации?

Верно просто создатели стандарта чуть больше сфокусировались на правой части.

Ответить
Развернуть ветку
Константин Митин
Автор

А вы манифест Agile не понимаете, как видно. И не понимаете кем и зачем он создавался. Говорите: «...создатели стандарта чуть больше сфокусировались на правой части…», выписав жёсткие требования к документации? Нет, с такими вольными трактовками и неспособностью видеть очевидные вещи, типа нарушения принципа: «Работающий продукт — основной показатель прогресса», вообще можно в любом тексте увидеть и не увидеть что угодно на своё усмотрение. Хоть описания Agile в сборнике стихов Фета.

Ответить
Развернуть ветку
Сергей Титков

Вот вы начинаете понимать суть!
В частности что если широко толковать вещи, то получиться очень не точное обобщающее описание.

Ответить
Развернуть ветку
Константин Митин
Автор

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

Ответить
Развернуть ветку
Сергей Титков

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

И в статье нет слов про каскадную модель ни про водопад.

Ответить
Развернуть ветку
Константин Митин
Автор

А почему вы уклонились от моего вопроса? Я его повторю.
Попробуйте, ссылаясь на первоисточник, опровергнуть вот это: "...В 1970 году Уинстон Уокер Ройс описал модель разработки, как поток последовательно проходящих фаз анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. ... Сделал он это, чтобы показать её недостатки по сравнению с итеративной разработкой...".
Вы сейчас в очень слабой позиции. Я же не говорю, что Ройс назвал модель Waterfall? Но это не отменяет, что уже в 1976 году её так называли Bell и Thayer (https://static.aminer.org/pdf/PDF/000/361/405/software_requirements_are_they_really_a_problem.pdf).
То, что Ройс использовал для описания процесса больше этапов, тоже ни о чем не говорит.
Похоже, вы слишком торопитесь, пытаясь заявить "Нет смысла читать дальше", поэтому и читаете не внимательно.

Ответить
Развернуть ветку
Сергей Титков

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

В статье Ройс не описывал каскадную модель и не вводил это понятие. Он просто сказал, смотрите, если у вас простая программа - то будет как на рисунке 1. А если у вас будет посложнее, то будет больше этапов. И он просто привел ряд этапов при разработке ПО. Та самая картинка 2. И написал, что такой подход очень рискованный! И объяснил почему. Все. Основной мессадж был про итеративность и почему это снижает риски.

Это моя точка зрения - не придумывать того что написано у автора между строк текста.
Ройс описал каскадную модель в своей статье? - Нет. Он описал подходы снижения рисков и почему не стоит думать о разработке как о последовательных этапах
Ройс где нибдуь использовал слово - водопад. Нет. Термин ввел не он. А кто же ввел? Вот это в статье вы не описали.

А если начать натягивать сову на глобус - думать широко и за автора, то можно начать говорить и про водопад и про модель и про MVP. Все есть в стаье, даже DevOps...

Второй пример, вы пишите: Например, на каскадной модели можно просто и наглядно расписать основы работы QC-специалиста (quality control) и неправильно расписать основы работы QA-инженера (quality assurance). Первый работает над тем, чтобы находить ошибки в реализации программного обеспечения, а второй работает над тем, чтобы не происходило ошибок в реализации программного обеспечения.

Вы максимально все РАСШИРЕЛИ. И в целом, при некой уровне абстарции, да вы написали верно.
Но если подходить к терминам чуть более строго то выше написанное оно ошибочное.
Почему.
Если говорить про каскадную модель, то там описаны действия - работа или активности. Как я писал QC это про управление качеством. То есть проверка того что, мы делаем соответсвует критериям. Верификация и валидация. И эти активности находятся в каждом этапе каскадной модели :) Далее QA(quality assurance) - это обеспечение качества. То есть делать так, что бы вы разрабатывали продукт согласно критериям качества которые ВЫ определили. И качество это вообще может быть не про отсутвие ошибок. Вот если вы ЯВНО указали атрибут качества - бездефектность и определили для него критерии, то только тогда специалист по обеспечению качества займется процессом доставке ценности заказчику и изменит его таким образом, что бы количество дефектов было равно или ниже заданных критериев.

Вот как то так.

Ответить
Развернуть ветку
Константин Митин
Автор

Ну, давайте разбирать по шагам.
1) Ройс в своей статье описал метод разработки через фиксированный набор последовательных и непересекающихся этапов, без возможности отступить назад? Безусловно. Это отображено на рисунке 2.
2) Называют ли метод разработки через фиксированный набор последовательных и непересекающихся этапов, без возможности отступить назад, каскадной моделью? Безусловно. А это это называют Водопадом (Waterfall).
3) Писал ли я где-нибудь, что Ройс назвал такую модель Waterfall? Нет, я писал, что такая модель получила название Waterfall, а от кого не указывал, так как это не важно.
4) Написал ли я: «Сделал он это, чтобы показать её недостатки по сравнению с итеративной разработкой»? Безусловно.
5) Пишите ли вы: «...И он просто привел ряд этапов при разработке ПО. Та самая картинка 2. И написал, что такой подход очень рискованный!...»? Безусловно.
6) Означает ли это, что, следуя вашим словам, Ройс в своей статье описал очень рискованный подход? Безусловно.
7) Пишите ли вы: «...Он описал подходы снижения рисков и почему не стоит думать о разработке как о последовательных этапах...»? Безусловно.
8) Означает ли это, что, следуя вашим словам, Ройс в своей статье описал несколько подходов? Безусловно.
9) Означает ли то, что Ройс нигде в своей статье не использовал слово «Waterfall», невозможность наличия в этой статье подхода, который будет позже назван «Waterfall»? Безусловно — нет.
10) Возможно ли то, что тот «опасный подход» (следуя вашим словам), который описал Ройс в своей статье, не имеем ничего общего с «Waterfall»? Безусловно — нет. Смотрим статью Bell и Thaye: «The same top-down approach to a series of requirements statements is explained, without the specialized military jargon, in an excellent paper by Royce [5]; he introduced the concept of the "waterfall" of development activities». То есть на момент 1976 года термин «Waterfall» уже использовался, чему есть документальные свидетельства.
То есть:
1) Ройс описал в своей статье два подхода (по вашим же словам), один из которых содержал цепочку последовательных этапов, которую уже в 1976 году называли «Waterfall».
2) Значит ли это, что Ройс в своей статье описал подход «Waterfall»? Безусловно.
3) Значит ли это, что при описании подхода «Waterfall» Ройс был обязан использовать термин «Waterfall»? Безусловно — нет.

Что до QC и QA, с вашим стремлением понимать терминологию неправильно. То есть термин «quality control», есть термин «quality management». Термин «control» не является синонимом термину «management». Термин «контролировать» не является синонимом термина «управлять».
Скажем прямо. К терминам вы подходите очень небрежно. Любите невнимательно читать и додумывать за автора. Отсюда очень, очень и очень много ошибок.

Ответить
Развернуть ветку
Сергей Титков

Последняя попытка.

Перевод из статьи Ройса, что описывает рисунок 2

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

Это просто его мысль! Как не стоит организовывать процесс!
Еще раз мысль! Ни модель, ни методология - просто мысль!

А вы изо всех сил приписывает Ройсу то что он не писал.

Это другие люди отличились! Это они ввели понятия водопад и каскадную модель, а не он.

Ройс должен быть там где говориться о инкрементно итеративные модели.

Вы очень напоминаете людей из этого ролика: https://vimeo.com/18951935?embedded=true&source=vimeo_logo&owner=5781173

Вы пишите:
Что до QC и QA, с вашим стремлением понимать терминологию неправильно. То есть термин «quality control», есть термин «quality management». Термин «control» не является синонимом термину «management». Термин «контролировать» не является синонимом термина «управлять».
Скажем прямо. К терминам вы подходите очень небрежно. Любите невнимательно читать и додумывать за автора. Отсюда очень, очень и очень много ошибок.

А в ГОСТе и ИСО написано другое, и я придерживаюсь их.

P.S. Кстати спасибо за статью: https://static.aminer.org/pdf/PDF/000/361/405/software_requirements_are_they_really_a_problem.pdf
я о ней не знал. И похоже именно эти двое и ввели документально термин водопад.

Ответить
Развернуть ветку
Константин Митин
Автор

Следуя вашей логике, если автор в прозаическом произведении ОПИСЫВАЕТ дерево, например, клен, то он его ВЫДУМЫВАЕТ и вводит понятия растения, дерева, клёна и так далее.
Следуя вашей логике, если человек пишет отчёт об обнаружении дерева (клёна) и описывает все его значимые характеристики, но не называет это дерево «клён», значит описание принадлежит какому-то иному дереву. Например дереву с названием «Ель», не смотря на то, что ели хвойные и клёны лиственные.

Я ещё раз могу констатировать, что вы либо не вообще не читаете то, на что ссылаетесь, либо просто не в силах это понять. У вас даже проблемы с голосарием терминов из ISO 9000:2005 (https://www.istu.edu/docs/education/fgos_14/ISO_9000-2005rus.pdf).
3.2.8 quality management coordinated activities to direct and control an organization (3.3.1) with regard to quality (3.1.1) NOTE Direction and control with re gard to quality generally includes establishment of the quality policy (3.2.4) and quality objectives (3.2.5), quality planning (3.2.9), quality control (3.2.10), quality assurance (3.2.11) and quality improvement (3.2.12).
3.2.8 менеджмент качества скоординированная деятельность по руководству и управлению организацией (3.3.1) применительно к качеству (3.1.1) ПРИМЕЧАНИЕ 1. Руководство и управление применительно к качеству обычно включает разработку политики в области качества (3.2.4) и целей в области качества (3.2.5), планирование качества (3.2.9), управление качеством (3.2.10), обеспечение качества (3.2.11) и улучшение качества (3.2.12).
3.2.10 quality control part of quality management (3.2.8) focused on fulfilling quality requirements
3.2.10 управление качеством часть менеджмента качества (3.2.8), направленная на выполнение требований к качеству
3.2.11 quality assurance 3.2.11 part of quality management (3.2.8) focused on providing confidence that quality requirements will be fulfilled
3.2.11 обеспечение качества часть менеджмента качества (3.2.8), направленная на создание уверенности, что требования к качеству будут выполнены

При этом можно сразу сказать, что перевод у «Русского регистра» - просто убогий. Надо было сначала неверно перевести слово «control», как «управления» вместо «надзора», чтобы потом не смочь перевести слово «management», как управления, и писать англицизм вместо перевода.

Ответить
Развернуть ветку
Сергей Титков

Тогда вообще не понятно зачем вы поместили упоминание Ройса в раздел про водопад.
Он писал про итерационно инкрементные подходы. Статья об этом же! А вы его запихнули в первый раздел.
И только на основании картинки...
Полностью при этом игнорировав смысл стать

Вы взяли старый стандарт, сейчас действует от 2015 года.

Ответить
Развернуть ветку
Константин Митин
Автор

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

Ответить
Развернуть ветку
Женя Сашкина

И вам спасибо за полезную статью.

Ответить
Развернуть ветку
Tatyana Kalikina

Спасибо! Было интересно! Раскрытие темы тоже интересно прочесть.

Ответить
Развернуть ветку
27 комментариев
Раскрывать всегда