Я заметил.
что работа с любым заказчиком очень похожа на работу с веб-приложением.
В статье показано, как можно использовать эти знания для улучшения процессов.
О том, кто контролёр, а кто модель под катом.
В этой статье предполагается, что читатель знает, что такое MVC .
При построении модели я сознательно делаю упрощения.
- Все участники отношений — ответственные люди и хотят добиться одинакового результата.
- Мы рассматриваем типовую заказную разработку.
Персонажи
Клиент — человек, который заказывает продукт или проект. Оно может быть как внешним, так и внутренним.Компания (исполнитель) - сторона договорных отношений с Заказчиком.
Менеджер — лицо, взаимодействующее с Заказчиком и конечным исполнителем (программистом).
Принимает на вход задания от Заказчика, передает эти задания Исполнителю и возвращает результат Заказчику.
Конечный исполнитель - программист, реализующий задачу.
В идеале общается только с менеджером.
Процесс
Процесс индивидуальной разработки выглядит примерно так:- Заказчик ставит перед Компанией задачу.
- Компания, выступающая в роли маршрутизатора, доводит задачу до менеджера.
- Менеджер уточняет детали у Заказчика.
- Менеджер ставит задачу Программисту.
- Программист выполняет задачу и отправляет выполненную задачу.
- Менеджер выявляет недостатки и возвращается к пункту 4.
- Если недостатков не выявлено, Менеджер передает задачу Заказчику.
- Заказчик выявляет недостатки и возвращается к пункту 3.
- Если недостатков не выявлено, работу оплачивает Заказчик.
Проблема с этим процессом
На первый взгляд в этом процессе все правильно и улучшать нечего.Однако это не так.
Выделим проблемы.
Очень плохой менеджер — это просто маршрутизатор задач.
Надеюсь вам повезет и вы не будете работать с такими менеджеры маршрутизаторы.
Я счастливчик.
Есть проблемы и при работе с настоящим менеджером.
Менеджер ставит задачу программисту, произнося ее голосом или в чате.
Уточнения по заданию нигде не фиксируются.
Программист вроде понял суть задачи.
Но я, конечно, понял это по-своему, а не так, как объяснил менеджер (с точки зрения менеджера).
Поскольку постановка задачи не фиксирована, каждый участник интерпретирует ее по-своему.
При таком подходе появляется множество итераций 4-6 и 3-8. Что отличает хорошего менеджера от плохого, так это соотношение количества этих итераций.
У хорошего менеджера число попыток поставить задачу заказчику равно одной.
И попытка, как вы догадались, сразу увенчалась успехом.
При этом итераций сдачи работы с программистом может быть много.
Маршрутизатор ничего не перепроверяет программисту и просто передает задачу Заказчику.
А количество итераций 3-8 достигает максимальных значений и равно числу итераций 4-6. И конечно во всем виноват программист, потому что с точки зрения менеджера он некачественно выполнил задачу.
Большое количество коммуникаций между Менеджером и Программистом в процессе выполнения задачи приводит к увеличению негатива между ними.
Кроме того, сроки выполнения задач срываются, затраты перерасходуются и так далее.
При этом я не возражаю против общения во время уточнения требований и на этапе постановки задачи.
Что делать, чтобы избежать таких нежелательных явлений?
Ассоциации
Рассмотрим упрощенную схему работы с Заказчиком:
Опытный разработчик увидит полное совпадение с MVC:
Сопоставлять сущности очень легко.
- Клиент = Пользователь
- Менеджер = Контролер
- Художник = Модель
- Результат = Посмотреть
- Компания = Все приложение
Если закономерности взаимодействия совпадают, то можно попробовать применить те подходы, которые мы используем в разработке, к процессу управления заказной разработкой.
Первые шаги в ремонте
Какие инструменты у нас есть, когда мы занимаемся разработкой? Определяем слои приложения.Мы определяем контракты взаимодействия между уровнями и делим приложение на модули.
Попробуем применить эти инструменты и здесь.
Слои
Программист в своей обычной роли не общается с заказчиком.Его можно привлечь на этапе уточнения требований в качестве эксперта.
В остальных случаях с Заказчиком общается только менеджер, тем самым изолируя слой модели от прямого влияния Заказчика.
В процессе сдачи задачи Заказчику не должен быть задействован программист, выполнявший задачу.
Никогда.
Никогда.
Разложение
Большие задачи необходимо разбивать на маленькие.Небольшая задача — это задача максимум на пару дней.
ТК
Всем известно выражение: «Без четкого технического задания возникает техническая проблема».При уточнении требований у Заказчика должен возникнуть такой артефакт, как Техническое задание.
Затем ставим задачу программисту обогащается дополнены техническими характеристиками.
Пока будем воспринимать это как договор не только между Компанией и Заказчиком, но и между менеджером и программистом.
В любой нормальной компании техническое задание является обязательным элементом поставленной задачи.
Правда, это касается только больших задач.
Казалось бы, техническое задание очень похоже на контракт в контексте программирования.
Какие проблемы я вижу с техническими характеристиками:
- Для большой задачи будет техническое задание в 400 страниц и более, которое программисту совершенно не уместиться в голове.
Я начинаю засыпать на десятой странице.
- Для средней задачи будет ссылка на раздел или пункт в ТЗ.
Тогда программист будет только читать этот параграф.
Потом, конечно, оказывается, что один маленький момент в другом разделе технического задания в корне меняет всю реализацию.
- Для небольшой задачи, входящей в состав поддержки, технического задания вообще не будет.
- Технические характеристики не всегда четко интерпретируются сторонами процесса разработки.
И все, что можно понять неправильно, будет понято неправильно.
Возникает вопрос: что делать?
Критерии приемки
Тестирование занимает почетное место в практике разработки.Тесты доказали свою необходимость для качественного развития.
Можем ли мы использовать тесты в нашей практике? Да мы уже все тестируем и даже в описании процесса это есть, скажет внимательный читатель.
Да, но нет. Я говорю немного о других тестах.
Тестирование в описанном выше процессе заключается в ручной проверке соответствия результата заявленным техническим характеристикам.
Каждый участник такого тестирования, ознакомившись с техническими характеристиками, так или иначе интерпретирует их в свою картину.
Проблема в том, что у всех разная картина.
Человек не является идеальным переводчиком.
Вам необходимо один раз скомпилировать спецификацию в двоичный файл.
Не трактуйте это много раз и по-разному.
И однажды на «бумаге».
В результате должен появиться определенный набор артефактов.
Это могут быть тестовые примеры или критерии приемки.
Критерии приемки должны быть разработаны менеджером совместно с клиентом.
Критерии приемки не противоречат техническому заданию, а лишь уточняют его.
Критерии приемки могут или даже должны стать отдельным документом, который подписывается Заказчиком и Компанией.
Далее Заказчик примет задание в соответствии с теми же критериями приемки.
При правильно сформулированных критериях приемки у Программиста не может быть каких-либо расхождений в техническом задании и даже сомнений в том, что именно он должен делать.
Для небольшой задачи может не быть технического задания, но критерии приемки должны присутствовать.
Критерии приемки аналогичны тестам, которые пишутся до реализации.
Вам это ничего не напоминает? Для описания критериев приемки можно использовать язык Gherkin, который предлагает БДД .
Чтобы было легко начать, можно описать их обычным русским языком.
Возражения
Предвижу вопрос от менеджеров: Разработка критериев приемки требует дополнительного времени.Где я могу получить это? Не выделяя времени на разработку критериев приемки, вы распределяете эти затраты по всем этапам.
И многие люди теряют время: менеджер, программист, тестировщик, заказчик.
Но вы все равно разрабатываете критерии приемки.
И не один раз.
При подготовке технического задания в сознании аналитика и заказчика возникают некоторые критерии приемки.
То же самое происходит и при постановке задачи.
Программист формирует их в своей голове.
Когда задача отправляется на любом этапе, выполняется тот же процесс.
Но ни на одном этапе не появился какой-либо артефакт. Вот и вся разница.
При наличии критериев приемки количество итераций, прежде чем заказчик примет задачу, существенно сокращается.
Количество негативных коммуникаций закономерно уменьшается.
Соответственно, улучшаются отношения с Заказчиком, которому Компания передает задачу впервые.
Я могу заверить вас, что разработка критериев приемки окупается сторицей.
Результат
Как меняется процесс после введения критериев приемки наряду с техническими условиями? Программист выполняет свою работу в соответствии с критериями приемки.Менеджер принимает работу.
Затем Клиент делает то же самое.
И у него нет причин не платить за эту задачу.
Всегда ли это будет работать без сбоев? Думаю, нет. Во-первых, возникнут проблемы с разработкой и формулированием критериев приемки и их согласованием с Заказчиком.
И это будет поводом для повторения итераций с Программистом и Заказчиком.
Но их количество сведено к минимуму.
Что Вы думаете об этом? Теги: #Управление разработкой #Управление проектами #ИТ-компании #ИТ-компании #тестирование #Тестирование ИТ-систем #bdd #tdd #критерии приемки
-
Онлайн-Сервисы Резервного Копирования
19 Oct, 24 -
Palm Приносит Мало Пользы Hp?
19 Oct, 24 -
Самомотивация – Это Миф.
19 Oct, 24 -
Обновление Линейки Lenovo Thinkpad
19 Oct, 24 -
Денвер 3 Альфа
19 Oct, 24 -
Блоки/Модули Или Как Всё Организовать?
19 Oct, 24 -
Апплеты
19 Oct, 24
