Одним из самых проблемных моментов любой доработки или любой проектной задачи является сдача-приемка. Очень многие разработчики даже не задумываются об этом неизбежном финале его текущей работы. Очень часто, спросив программиста или консультанта о том, как он собирается сдавать обсуждаемые доработки заказчику, приходится наблюдать настоящее смятение или полную беззаботность. А простое (и, казалось бы, очевидное) указание ни в коем случае не заниматься задачами, которые невозможно сдать, довольно часто вызывает горячие возражения со стороны разработчика.
Какие задачи принципиально невозможно сдать? В первую очередь это задачи, сформулированные общими словами: «Чтобы все хорошо работало». Затем это задачи, в которых заказчик слабо представляет себе конечный результат. Наконец, это разработка программных функций, результат которых заказчик не может увидеть, когда что-то в системе пересчитывается или оптимизируется, но убедится в этом пользователю крайне сложно или невозможно, потому что в его рабочем месте ничего не происходит.
Конечно, иногда можно просто убедить заказчика подписать протокол выполнения работ или акт используя его доверие к вам и вашей компетентности, объяснив необходимость и важность выполненных работ. Но гораздо лучше работать так, чтобы заказчику не приходилось напрягать свое доверие слишком часто. Ведь легко представить себе ситуацию, когда заказчик доверился вам, а программисты подвели, и сделали задачу плохо или неправильно.
Даже если задача поставлена и сформулирована так, что проверить ее выполнение в принципе можно, это не означает, что она будет сдана. При сдаче-приемке часто возникают споры между разработчиком и заказчиком относительно данных, на которых следует проверить работу созданной функции. Заказчик может требовать провести все больше и больше проверок, и сдача может затянуться, а в конце вы вполне можете услышать «Ну, мне надо тут еще потестировать, и когда я все проверю – приму работу». При сдаче пользователь может выполнить действия, которые разработчик не предусматривал. В проверку могут попасть данные, возможность которых разработчик не учел, а может быть их просто еще не было в системе на момент постановки задачи. На работу созданной вами функции может повлиять доработка, внесенная собственным программистом заказчика. В общем, если о процедуре сдаче-приемки не подумать заранее, ее результат может быть каким угодно.
Для того, чтобы исключить сюрпризы при сдаче-приемки задачи по программной доработке, лучше всего использовать метод контрольных примеров. Он заключается в том, что при постановке задачи вы заранее договариваетесь с заказчиком о том, на каких конкретных данных вы будете проводить сдачу-приемку.
Контрольный пример состоит из трех простых компонентов:
- Сценарий демонстрации;
- Входные данные;
- Выходные данные.
Процедура проведения сдачи-приемки заключается в том, что для проверки работы созданной вами функции разработчик совместно с заказчиком производит в системе действия, описанные в сценарии демонстрации. Если при этом нужно ввести какие-то данные, они вводят то, что указано, как входные данные контрольного примера. Если при завершении сценария в системе сформировались данные, соответствующие выходным данных контрольного примера, то задача сдана.
Например, мы сдаем доработку по помещению части поступивших на склад товаров в «карантин». В сценарии указано, что необходимо создать документ «Приходный ордер на товары». Состав товаров, количество и склад ордера указаны, как входные данные. Далее надо заполнить созданную разработчиком закладку «Карантин», состав и количеств товаров, направленных в «карантин», также указано, как входные данные. Затем надо провести документ. Для получения информации о товарах в «карантине» нужно сформировать созданный вами отчет «Карантин». Результат отчета должен совпасть с выходными данными контрольного примера.
Состав контрольного примера для каждой задачи готовится либо самим заказчиком или разработчиком (за деньги!) с последующим обязательным согласованием с заказчиком. Контрольный пример должен учитывать все возможные варианты действия созданной или доработанной функции системы или, по крайней мере, все наиболее частые случаи. Чем больше будет пример, тем качественнее будет выполнена разработка и тем надежнее будет сдача-приемка. Заказчик заинтересован в полноте контрольного примера, но, в тоже время, от крайностей его удерживает необходимость самому подготовить его или оплатить вам его подготовку.
Сдача-приемка на контрольном примере никогда не делается в рабочей базе. Только в специально существующей для этого копии! Потому что данные в рабочей базе могут непредсказуемо измениться, ведь в ней ежедневно ведется работа пользователей. А нам для достижения уверенности в том, что написанный нами код работает правильно, нужно быть уверенным в том, что никаких сюрпризов в данных нет. В документе, описывающем контрольный пример, можно так и написать: сдача-приемка выполняется на контрольном примере, подготовленным в копии рабочей базы от такого-то числа.
Очень важно еще на старте проекта договориться с заказчиком, что после сдачи-приемки на контрольном примере задача считается выполненной. Если заказчик хочет провести дополнительное тестирование – ради Бога, подписывай протокол выполнения работ или акт, и тестируй сколько душе угодно! Разумеется, если контрольный пример при сдаче не проходит, то есть выдаются ошибки или результат прохождения сценария не похож на выходные данные, то задача – не сдана, и отправляется на устранение замечаний. А все новые идеи и пожелания, возникшие у заказчика при сдаче-приемке (в том числе и выявление некорректной работы системы на каких-то данных, не вошедших в пример) считаются новыми требованиями, и реализуются в рамках новой задачи за отдельные деньги.
Не все задачи непременно требуют контрольного примера. Надо помнить, что главная цель этого подхода – дать заказчику возможность убедится, что задача выполнена. Есть тривиальные требования, например, изменение дизайна форм, где убедится в выполнении задачи можно и без контрольного примера. Но любая задача сложнее изменение цвета кнопок потребует контрольного примера.
Разумеется, иногда приходится сталкиваться с задачами, для которых придумать контрольный пример не так просто, и для этого нужно хорошенько поломать голову. Но решение, как правило всегда находится. Если же сдать задачу на контрольном примере совсем невозможно (допустим, что такая ситуация все же иногда возникает), это повод для отдельных договоренностей с заказчиком.
Сдача на контрольном примере – обязательный элемент всех серьезных методик разработки информационных систем. Например, в ГОСТе контрольный пример скрывается под видом документа «Программа и методика испытаний», про который проектировщики часто забывают, ограничиваясь техническим заданием. А в SRUM контрольный пример мимоходом описан, как «критерий готовности» или Definition of Done, (DoD).
Для руководителя проекта главная ценность контрольного примера в том, что он позволяет полностью устранить какую-либо неопределенность относительно того, сдана задача или нет, что существенно облегчает управление проектом и очень сильно снижает все риски, связанные со сдачей-приемкой.
Какие задачи принципиально невозможно сдать? В первую очередь это задачи, сформулированные общими словами: «Чтобы все хорошо работало». Затем это задачи, в которых заказчик слабо представляет себе конечный результат. Наконец, это разработка программных функций, результат которых заказчик не может увидеть, когда что-то в системе пересчитывается или оптимизируется, но убедится в этом пользователю крайне сложно или невозможно, потому что в его рабочем месте ничего не происходит.
Конечно, иногда можно просто убедить заказчика подписать протокол выполнения работ или акт используя его доверие к вам и вашей компетентности, объяснив необходимость и важность выполненных работ. Но гораздо лучше работать так, чтобы заказчику не приходилось напрягать свое доверие слишком часто. Ведь легко представить себе ситуацию, когда заказчик доверился вам, а программисты подвели, и сделали задачу плохо или неправильно.
Даже если задача поставлена и сформулирована так, что проверить ее выполнение в принципе можно, это не означает, что она будет сдана. При сдаче-приемке часто возникают споры между разработчиком и заказчиком относительно данных, на которых следует проверить работу созданной функции. Заказчик может требовать провести все больше и больше проверок, и сдача может затянуться, а в конце вы вполне можете услышать «Ну, мне надо тут еще потестировать, и когда я все проверю – приму работу». При сдаче пользователь может выполнить действия, которые разработчик не предусматривал. В проверку могут попасть данные, возможность которых разработчик не учел, а может быть их просто еще не было в системе на момент постановки задачи. На работу созданной вами функции может повлиять доработка, внесенная собственным программистом заказчика. В общем, если о процедуре сдаче-приемки не подумать заранее, ее результат может быть каким угодно.
Для того, чтобы исключить сюрпризы при сдаче-приемки задачи по программной доработке, лучше всего использовать метод контрольных примеров. Он заключается в том, что при постановке задачи вы заранее договариваетесь с заказчиком о том, на каких конкретных данных вы будете проводить сдачу-приемку.
Контрольный пример состоит из трех простых компонентов:
- Сценарий демонстрации;
- Входные данные;
- Выходные данные.
Процедура проведения сдачи-приемки заключается в том, что для проверки работы созданной вами функции разработчик совместно с заказчиком производит в системе действия, описанные в сценарии демонстрации. Если при этом нужно ввести какие-то данные, они вводят то, что указано, как входные данные контрольного примера. Если при завершении сценария в системе сформировались данные, соответствующие выходным данных контрольного примера, то задача сдана.
Например, мы сдаем доработку по помещению части поступивших на склад товаров в «карантин». В сценарии указано, что необходимо создать документ «Приходный ордер на товары». Состав товаров, количество и склад ордера указаны, как входные данные. Далее надо заполнить созданную разработчиком закладку «Карантин», состав и количеств товаров, направленных в «карантин», также указано, как входные данные. Затем надо провести документ. Для получения информации о товарах в «карантине» нужно сформировать созданный вами отчет «Карантин». Результат отчета должен совпасть с выходными данными контрольного примера.
Состав контрольного примера для каждой задачи готовится либо самим заказчиком или разработчиком (за деньги!) с последующим обязательным согласованием с заказчиком. Контрольный пример должен учитывать все возможные варианты действия созданной или доработанной функции системы или, по крайней мере, все наиболее частые случаи. Чем больше будет пример, тем качественнее будет выполнена разработка и тем надежнее будет сдача-приемка. Заказчик заинтересован в полноте контрольного примера, но, в тоже время, от крайностей его удерживает необходимость самому подготовить его или оплатить вам его подготовку.
Сдача-приемка на контрольном примере никогда не делается в рабочей базе. Только в специально существующей для этого копии! Потому что данные в рабочей базе могут непредсказуемо измениться, ведь в ней ежедневно ведется работа пользователей. А нам для достижения уверенности в том, что написанный нами код работает правильно, нужно быть уверенным в том, что никаких сюрпризов в данных нет. В документе, описывающем контрольный пример, можно так и написать: сдача-приемка выполняется на контрольном примере, подготовленным в копии рабочей базы от такого-то числа.
Очень важно еще на старте проекта договориться с заказчиком, что после сдачи-приемки на контрольном примере задача считается выполненной. Если заказчик хочет провести дополнительное тестирование – ради Бога, подписывай протокол выполнения работ или акт, и тестируй сколько душе угодно! Разумеется, если контрольный пример при сдаче не проходит, то есть выдаются ошибки или результат прохождения сценария не похож на выходные данные, то задача – не сдана, и отправляется на устранение замечаний. А все новые идеи и пожелания, возникшие у заказчика при сдаче-приемке (в том числе и выявление некорректной работы системы на каких-то данных, не вошедших в пример) считаются новыми требованиями, и реализуются в рамках новой задачи за отдельные деньги.
Не все задачи непременно требуют контрольного примера. Надо помнить, что главная цель этого подхода – дать заказчику возможность убедится, что задача выполнена. Есть тривиальные требования, например, изменение дизайна форм, где убедится в выполнении задачи можно и без контрольного примера. Но любая задача сложнее изменение цвета кнопок потребует контрольного примера.
Разумеется, иногда приходится сталкиваться с задачами, для которых придумать контрольный пример не так просто, и для этого нужно хорошенько поломать голову. Но решение, как правило всегда находится. Если же сдать задачу на контрольном примере совсем невозможно (допустим, что такая ситуация все же иногда возникает), это повод для отдельных договоренностей с заказчиком.
Сдача на контрольном примере – обязательный элемент всех серьезных методик разработки информационных систем. Например, в ГОСТе контрольный пример скрывается под видом документа «Программа и методика испытаний», про который проектировщики часто забывают, ограничиваясь техническим заданием. А в SRUM контрольный пример мимоходом описан, как «критерий готовности» или Definition of Done, (DoD).
Для руководителя проекта главная ценность контрольного примера в том, что он позволяет полностью устранить какую-либо неопределенность относительно того, сдана задача или нет, что существенно облегчает управление проектом и очень сильно снижает все риски, связанные со сдачей-приемкой.
Комментариев нет:
Отправить комментарий