Программист, менеджер, MVC и критерии приемки
Заметил. что работа с любым заказчиком очень похожа на работу веб-приложения. В статье показано как можно воспользоваться этим знанием для улучшения процессов.
О том кто же является контроллером, а кто моделью под катом.
В этой статье предполагается, что читатель знает, что такое MVC.
При построении модели я иду на умышленные упрощения.
Действующие лица
Заказчик — лицо, которое заказывает продукт или проект. Может быть как внешним, так и внутренним.
Компания (исполнитель) — сторона договорных отношений с Заказчиком.
Менеджер — лицо, которое взаимодействует с Заказчиком и конечным исполнителем (программистом). Принимает на вход задачи от Заказчика, транслирует эти задачи Исполнителю и возвращает Заказчику результат.
Конечный исполнитель — программист, который реализует поставленную задачу. В идеале общается только с Менеджером.
Процесс
Процесс заказной разработки выглядит примерно так:
Самым сладким пунктом для Компании является пункт 9. Но путь до него обычно долго и тернист.
Проблема такого процесса
На первый взгляд все в этом процессе правильно и тут нечего улучшать. Однако это не так. Выделим проблемы.
Совсем плохой менеджер является просто маршрутизатором задач. Надеюсь, что вам повезло и вы не работаете с такими менеджерами маршрутизаторами. Мне повезло. При работе с настоящим менеджером тоже бывают проблемы.
Менеджер ставит программисту задачу проговаривая ее голосом или в чатике. Уточнения по задаче нигде не фиксируются. Программист постановку задаче вроде бы понял. Но разумеется понял по своему, а не так как объяснял менеджер (с точки зрения менеджера). Так как постановка задачи не зафиксирована, то каждый из участников трактует ее по своему.
При таком подходе появляется много итераций 4-6 и 3-8. Хорошего менеджера от плохого отличает соотношение между числом этих итераций. У хорошего менеджера число попыток сдать задачу заказчику равно единице. И попытка, как вы догадались, сразу удачная. При этом итераций по сдаче работ с программистом может быть много. Маршрутизатор не перепроверяет ничего за программистом и просто передает задачу Заказчику. И число итераций 3-8 достигает максимальных значений и равно числу итераций 4-6. И разумеется во всем виноват программист, ведь с точки зрения менеджера он плохо выполнил задачу.
Большое число коммуникаций между Менеджером и Программистом в процессе сдачи задачи ведет к возрастанию негатива между ними. Кроме того срываются сроки сдачи задачи, перерасход и так далее. При этом я не возражаю против коммуникаций во время уточнения требований и на этапе постановки задачи.
Что же делать, чтобы избежать такие нежелательные явления?
Ассоциации
Давайте посмотрим на упрощенную схему работы с Заказчиком:
Опытный разработчик увидит полное совпадение с MVC:
Очень просто провести сопоставление сущностей.
Просто совпадение? Не думаю. Если схемы взаимодействия совпадают, то можно попробовать применять подходы, которые мы используем при разработке, и к процессу управления заказной разработкой.
Первые шаги в починке
Какие инструменты у нас есть когда мы занимаемся разработкой?
Мы определяем слои приложения. Определяем контракты взаимодействия между слоями и разбиваем приложение на модули. Давайте попробуем применить эти инструменты и здесь.
Программист в своей обычной роли не общается с заказчиком. Он может быть привлечен на этапе уточнения требований как эксперт. В остальных случаях с Заказчиком общается только менеджер, тем самым изолируя слой модели от прямого воздействия Заказчика.
В процессе сдачи задачи Заказчику программист, который выполнял задачу, не должен привлекаться. Никогда. Вообще никогда.
Декомпозиция
Большие задачи нужно разделять на маленькие. Маленькая задача — это задача максимум на пару дней.
Всем известно выражение: Без внятного ТЗ — результат ХЗ.
При уточнении требований с Заказчиком должен возникать такой артефакт, как Техническое Задание. Тогда постановка задачи программисту обогащается дополняется ТЗ. Пока примем это за контракт не только между Компанией и Заказчиком, но и между менеджером и программистом.
В любой нормальной компании ТЗ является обязательным элементом к задаче. Правда это касается только крупных задач.
Казалось бы что ТЗ вполне похоже на контракт в контексте программирования. Какие я вижу проблемы с ТЗ:
Тут видно, что ТЗ явно недостаточно. Возникает вопрос что же делать?
Критерии приемки
В практике разработки почетное место занимают тестирование. Тесты доказали свою необходимость для качественной разработки.
Можем ли мы применять тесты и в нашей практике? Да мы и так все тестируем и даже в описании процесса это есть, скажет внимательный читатель. Да, но нет. Я говорю немного о другом тестировании.
Тестирование в описанном выше процессе заключается в ручной проверке соответствия результата поставленному ТЗ. Каждый участник такого тестирования, ознакомившись с ТЗ, как-то его интерпретирует в собственную картину. Проблема в том, что у всех получается разная картина. Человек неидеальный интерпретатор. Нужно скомпилировать ТЗ в бинарник один раз. Не интерпретировать много раз и по-разному. А один раз и на “бумагу”. В результате должен появится некий набор артефактов. Это могут быть тест-кейсы или критерии приемки.
Критерии приемки должны быть выработаны менеджером совместно с клиентом. Критерии приемки не противоречат ТЗ, а лишь разъясняют его. Критерии приемки могут или даже должны стать отдельным документом, который подписывается Заказчиком и Компанией. Тогда Заказчик будет принимать задачу в соответствии с этими же критериями приемки.
При правильно сформулированных критериях приемки у Программиста не может появиться никаких разночтений ТЗ и даже сомнений в том, что именно он должен сделать.
Для маленькой задачи может не быть ТЗ, но критерии приемки должны присутствовать обязательно. Критерии приемки похожи на тесты, которые написаны до реализации. Это вам ничего не напоминает?
Для описания критериев приемки можно использовать язык Gherkin, который предлагает BDD. Для того чтобы было легко начать можно описывать их обычным русским языком.
Возражения
Предвижу вопрос от менеджеров:
Разработка критериев приемки занимает дополнительное время. Где же его взять?
Не выделяя время на разработку критериев приемки вы размазываете эти затраты по всем этапам. Причем тратят время очень многие: менеджер, программист, тестировщик, заказчик.
А вы все равно разрабатываете критерии приемки. Причем не один раз. При подготовке ТЗ какие-то критерии приемки возникают в голове у аналитика и заказчика. При постановке задачи происходит то же самое. Программист формирует их у себя в голове. В момент сдачи задачи на любом из этапов выполняется тот же процесс. Но ни на одном из этапов не появилось никакого артефакта. Вот и вся разница.
При наличии критериев приемки количество итераций до приемки задачи заказчиком существенно сокращается. Естественным образом снижается количество негативных коммуникаций. Соответственно улучшается взаимоотношения с Заказчиком, которому Компания с первого раза сдает задачу.
Смею вас заверить, что разработка критериев приемки окупается сторицей.
Результат
Как изменяется процесс после внедрения критериев приемки наравне с ТЗ?
Программист делает свою работу в соответствии с критериями приемки. Менеджер принимает работу. Затем то же самое делает и Заказчик. И у него нет повода не оплатить эту задачу.
Всегда ли это будет работать совсем без сбоев? Полагаю, что нет. Сначала будут проблемы с выработкой, формулировкой критериев приемки и их согласование с Заказчиком. И это будет причиной повторения итераций с Программистом и Заказчиком. Но их количество сведено до минимума.
Критерии Приемки (Acceptance Criteria)
Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.
Диаграмма Сгорания Работ Спринта визуально показывает прогресс Команды в Стори Поинтах по дням спринта. Это графическое представление того, сколько работы уже сделано и сколько еще остается сделать. Диаграмма позволяет Команде прогнозировать успех Спринта и предпринимать меры, чтобы к моменту окончанию Спринта все запланированные задачи были были завершены.
Описание того, что нужно сделать, чтобы работа над Инкрементом и реализованными в нем Элементами Бэклога Продукта считалась завершенной. Эта информация помогает команде оценивать, проверять и доводить работу над Инкрементом до конца. Определение Критериев Готовности звучит похоже на Критерии Приемки, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов и Инкрементов в целом.
Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.
Оценка (Estimation)
Оценка – это прогнозирование усилий, которые потребуются для завершения работы над Элементом Бэклога Продукта. Она обеспечивает Владельцу Продукта и Скрам-мастеру уверенность в дате релиза и является базой для расчета производительности Команды. Существует множество способов оценки усилий Скрам-командой, но при этом всегда используются относительные единицы: например, Стори Поинты. Обычно оценка проводится в рамках Уточнения (Груминга) Бэклога Продукта.
Величина, отражающая количество работы, которое Скрам-команда может выполнить за один Спринт. Является важной метрикой в Скраме. Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Что такое критерии приемки
Система разработки и постановки продукции на производство
ИСПЫТАНИЯ И ПРИЕМКА ВЫПУСКАЕМОЙ ПРОДУКЦИИ
System of product development and launching into manufacture. Tests and acceptance of produced goods. Principal positions
МКС 03.100.50
19.020
ОКСТУ 0015
Дата введения 2000-01-01
1 РАЗРАБОТАН Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России
ВНЕСЕН Госстандартом России
2 ПРИНЯТ Межгосударственным Советом по стандартизации, метрологии и сертификации (протокол N 13 от 28 мая 1998 г.)
За принятие проголосовали:
Наименование национального органа по стандартизации
Госстандарт Республики Беларусь
Госстандарт Республики Казахстан
Главная государственная инспекция Туркменистана
3 Постановлением Государственного комитета Российской Федерации по стандартизации и метрологии от 11 июня 1999 г. N 189 межгосударственный стандарт ГОСТ 15.309-98 введен в действие в качестве государственного стандарта Российской Федерации с 1 января 2000 г.
5. ПЕРЕИЗДАНИЕ. Август 2010 г.
1 Область применения
Настоящий стандарт распространяется на все виды народнохозяйственной продукции, кроме судов и других изделий, для которых соответствующими стандартами устанавливаются специальные правила испытаний и приемки.
Положения стандарта обязательны при разработке стандартов, технических условий и других документов, содержащих требования к контролю, испытаниям и приемке, а также непосредственно при проведении этих работ. Отдельные положения стандарта могут быть использованы при разработке несерийной продукции.
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ 15.001-88* Система разработки и постановки продукции на производство. Продукция производственно-технического назначения
* На территории Российской Федерации действует ГОСТ Р 15.201-2000.
ГОСТ 15.009-91 Система разработки и постановки продукции на производство. Непродовольственные товары народного потребления
ГОСТ 27.410-87** Надежность в технике. Методы контроля показателей надежности и планы контрольных испытаний на надежность
* На территории Российской Федерации, кроме п.2 (в части п.2 ГОСТ 27.410-87 заменен на ГОСТ 27.301-95), действует ГОСТ Р 27.403-2009.
ГОСТ 16504-81 Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения
3 Определения
В настоящем стандарте применены следующие термины:
3.1 контролируемая партия (партия продукции): Совокупность единиц однородной продукции, изготовленных в течение определенного интервала времени по одной и той же технологической документации (стандарту), одновременно предъявляемых на испытания и (или) приемку, при оценке качества которых принимают одно общее решение.
— одну плавку (для литья из металла, пластмассы и др.);
— одну садку (для термообработки, поковок);
— один режим выполнения (для свариваемых, паяных, клееных изделий и т.д.).
3.2 образец-эталон: Образец продукции (покрытия, материала, обработанной поверхности), утвержденный в установленном порядке и предназначенный для сравнения с ним единиц продукции при изготовлении, испытаниях, приемке и поставке.
3.3 приемка продукции: Процесс проверки соответствия продукции требованиям, установленным в стандартах, конструкторской документации, технических условиях (ТУ), договоре на поставку и оформление соответствующих документов.
3.4 образец-продукции: Единица конкретной продукции, используемая в качестве представителя этой продукции при испытаниях, контроле или оценке.
3.5 категория испытаний: По ГОСТ 16504.
4 Общие положения
4.2 Для контроля качества и приемки изготовленной продукции устанавливают следующие основные категории испытаний:
4.3 Средства измерений дополнительно подвергают государственным контрольным испытаниям в соответствии с требованиями Государственной системы обеспечения единства измерений.
4.4 Для оценки эффективности и целесообразности внесения предлагаемых изменений в конструкцию выпускаемой продукции и (или) технологию ее изготовления проводят испытания по категории типовых испытаний, порядок проведения которых приведен в приложении А.
1 В категорию самостоятельных испытаний в обоснованных случаях могут быть выделены испытания на надежность, радиационную стойкость и др.
2 Для целей сертификации продукции проводят сертификационные испытания или используют результаты испытаний других категорий в порядке, установленном правилами сертификации.
4.5 Приемо-сдаточные и периодические испытания в совокупности должны обеспечивать достоверную проверку всех свойств выпускаемой продукции, подлежащих контролю на соответствие требованиям стандартов, и представлять собой элементы приемки продукции у изготовителя (поставщика).
Периодические испытания не проводят в тех случаях, когда все требования стандартов проверяют при приемо-сдаточных испытаниях, объем которых достаточен для контроля качества и приемки продукции, а также если не требуется периодическое подтверждение качества изготовленной продукции.
4.6 Испытания проводят в соответствии с требованиями стандартов на продукцию, правил приемки и методов испытаний.
При отсутствии подобных стандартов или при отсутствии в них необходимых требований дополнительные требования к испытаниям включают в ТУ (программу и методику испытаний, инструкцию и т.п.).
4.7 В документах, по которым проводят испытания любой категории, в общем случае устанавливают (непосредственно либо в виде ссылок на другие документы):
— требования к продукции, подлежащие контролю (включая требования по безопасности, охране здоровья и окружающей среды, в том числе гармонизированные с требованиями международных документов):
— категории и виды испытаний, включая состав проверок, последовательность их проведения и распределение проверок по категориям испытаний с учетом приложения Б (при наличии категорий самостоятельных испытаний на надежность, радиационную стойкость и др. в документах должна быть дана ссылка на программы и методики испытаний);
— методы испытаний, условия (режимы) испытаний;
— требования к средствам испытаний (пределы измерений, пределы допускаемых погрешностей, расходуемые материалы, безопасность для здоровья персонала и для окружающей среды и др.);
— требования по количеству единиц продукции, отбираемых для каждой категории (вида, группы) испытаний, установленной в документах, а также по порядку отбора единиц продукции;
— требования по подготовке к проведению испытаний;
— порядок обработки данных, полученных при испытаниях, и критерии принятия решений по ним, а также порядок оформления и представления результатов испытаний;
— требования по принимаемым решениям и области распространения результатов испытаний.
Применительно к испытаниям конкретных категорий указанные требования дополняются требованиями, приведенными в соответствующих разделах настоящего стандарта.
При применении статистических методов контроля при выборе планов контроля на конкретные виды продукции следует руководствоваться действующими документами, в которых приведена методика применения стандартов на статистические методы приемочного контроля.
4.8 Категории испытаний по составу могут включать в себя один или несколько видов или групп испытаний (механические, электрические, климатические, на надежность и др.) и (или) видов контроля (визуальный, измерительный и др.) и проводиться в один или несколько этапов испытаний.
В случае выделения испытания в самостоятельную категорию (например, испытание на надежность, испытание на радиационную стойкость и др.) правила использования результатов испытаний при принятии решений о приемке продукции должны быть отражены в программах и методиках этих испытаний.
4.9 Применяемые при испытаниях и контроле средства измерений и контроля должны быть поверены, а испытательное оборудование аттестовано в установленном порядке.
4.11 В процессе испытаний не допускается подстраивать (регулировать) единицы продукции и заменять входящие в них сменные элементы, если это не предусмотрено специальными требованиями стандартов на продукцию (в виде непосредственной записи либо в виде ссылок на другие документы).
4.12 Единицу продукции, предназначенную для функционирования совместно с единицей продукции другого вида, рекомендуется испытывать во взаимосвязи с последней в условиях, максимально приближенных к реальным условиям эксплуатации (на стенде, с имитатором и т.п.).
4.13 Результаты испытаний единиц продукции считают положительными, а продукцию выдержавшей испытания, если она испытана в объеме и последовательности, которые установлены для данной категории испытаний в стандартах на продукцию, а результаты подтверждают соответствие испытуемых единиц продукции заданным требованиям.
4.14 Результаты испытаний единиц продукции считают отрицательными, а продукцию не выдержавшей испытания, если по результатам испытаний будет установлено несоответствие продукции хотя бы одному требованию, установленному в стандартах на продукцию для проводимой категории испытаний.
4.15 Результаты испытаний единиц продукции по каждой категории должны быть документально оформлены, в том числе и результаты поэтапных испытаний (при проведении категории испытаний в несколько этапов, если таковые предусмотрены в нормативных документах на продукцию).
5 Приемка продукции
5.1 Приемку продукции, изготовленной для ее поставки заказчику (потребителю) и (или) непосредственной продажи (реализации) покупателю, проводит ОТК.
Если условиями контрактов (договоров) между заказчиком (потребителем) и изготовителем (поставщиком) определено, что приемку продукции следует осуществлять независимому от последнего органу приемки (представительству заказчика или потребителя), то испытания и приемку проводят указанные представительства в присутствии ОТК силами и средствами изготовителя (поставщика). При этом все особенности и форму участия сторон в проведении приемки продукции, не отраженные в настоящем стандарте, определяют в договорах (контрактах), стандартах, ТУ или иных совместных документах.
5.2 Процесс приемки продукции, в зависимости от специфики выполняемых работ, может быть совмещен с проведением приемо-сдаточных испытаний в один общий этап либо осуществлен в виде самостоятельных этапов, проводящихся в следующей последовательности: приемо-сдаточные испытания, окончательная приемка продукции, что отражают в стандартах на продукцию. В зависимости от принятого варианта проведения приемки продукцию соответственно предъявляют либо одним общим предъявительским документом на приемо-сдаточные испытания и приемку, либо отдельно на приемо-сдаточные испытания и отдельно на окончательную приемку.
Критерии Готовности и Критерии Приёмки в Скраме: в чём разница
Критерии Приёмки — это часть Критериев Готовности. Критерии Приёмки показывают, соответствует ли результат работы ожиданиям заказчика. Если заказчик хотел пиццу с грибами, то он должен получить именно её, а не пирог.
В Критериях Готовности, помимо Критериев Приёмки, есть ещё ваши внутренние правила и требования, без которых Продукт не будет работать как надо. Например, требования о том, что пиццу нужно готовить чистыми руками и выпекать определённое количество времени. Критерии Готовности — это планка качества для Продукта, которую устанавливает Команда.
Критерии Приёмки
Критерии Приёмки показывают, что отдельную часть Продукта можно считать сделанной. Давайте разберём на примере.
У нас есть инновационная пиццерия «У Сергея». Её главная фишка — пицца необычных вкусов. Чтобы предприятие было успешным, пиццерия работает по Скраму. В текущем Спринте Команда «У Сергея» придумывает рыбную пиццу.
Есть много видов рыбы, поэтому Команде важно понять, что конкретно должно быть в рыбной пицце по мнению заказчиков. Команда задала этот вопрос клиентам и получила ответ: «Там должны быть кусочки рыбы, а не рыбный соус. И не надо анчоусов, они надоели. Сделайте с судаком».
Получается, что Критерии Приёмки для рыбной пиццы выглядят так: в пицце есть кусочки судака, нет анчоусов и рыбного соуса.
Для каждой новой пиццы Критерии Приёмки меняются. В рыбной пицце должен быть судак, а в крабовой — кусочки краба.
Важный момент: даже если Продукт соответствует Критериям Приёмки, то ещё не значит, что он сделан качественно. Та же рыбная пицца может быть с кусочками судака, но пережаренной. Чтобы Продуктом можно было пользоваться, он должен соответствовать Критериям Готовности.
Критерии Готовности
Критерии Готовности — это договорённость внутри Команды, когда считать Продукт готовым. Выглядит как список того, что нужно сделать, чтобы Продукт работал. На языке Скрам-мастеров это звучит так: «Критерии Готовности обеспечивают прозрачность Инкремента».
Вот как выглядят Критерии Готовности для рыбной пиццы «У Сергея»:
— делаем пиццу чистыми руками — для этого пиццамейкеры моют руки каждый час;
— пиццамейкеры работают в шапочках, чтобы не было волос в пицце;
— пиццу выпекают 12 минут;
— начинка для пиццы нарезана в день готовки;
— Критерии Приёмки для рыбной пиццы: в начинке есть кусочки судака, нет анчоусов и рыбного соуса;
— клиенту доставляют теплую пиццу.
В зависимости от вида пиццы меняются только Критерии Приёмки. Рыбную и любую другую пиццу делают чистыми руками, в шапочках, выпекают ровно 12 минут и так далее.
Детали
| Обязательны ли | Критерии Приёмки Нет, это хорошая, но необязательная практика. | Критерии Готовности Да, Критерии Готовности указаны в Руководстве по Скраму. |
| Кто создаёт | Команда Разработки + пользователи + стейкхолдеры. | Только Команда Разработки. |
| Когда создаёт | На Уточнении Бэклога Продукта (PBR). | На специальном мероприятии ещё до запуска Скрама в Команде. |
| Как меняются в процессе работы | К каждой новой фиче Команда придумывает новые Критерии Приёмки. | Критерии Готовности могут ужесточаться, ослабляться или не меняться в зависимости от работы Команды. |
| Когда применяют | Во время Спринта — чтобы понять, что задача готова. | Постоянно. |
В табличку не влезло, но мы всё равно напишем, что постоянно Критерии Готовности применяют на Планировании Спринта, во время Спринта, перед Обзором Спринта и на Ретроспективе Спринта.
На Планировании Спринта — чтобы понять, сколько задач Команда сможет сделать за Спринт. Во время Спринта — чтобы понять, что задача готова. Перед Обзором Спринта — чтобы знать, что на нём показывать, когда Команда сделала не всё, что обещала. И на Ретроспективе Спринта — чтобы постоянно совершенствовать Критерии Готовности. Например, ужесточить их, то есть добавить ещё пункты в список, или ослабить, если Команда не может их выполнить за Спринт.
Критерии Готовности и Критерии Приёмки — важная часть Скрама. Они помогают Команде держать планку качества и создавать именно то, что нужно заказчикам.
Катя Кондратьева Редактор Unusual Concepts
