Совет 16 Подход к работе

Совет 16

Подход к работе

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

К счастью, процесс создания хорошего программного обеспечения (и в целом продукции) давно как следует обдуман. И изрядная часть этой информации легла в основу целой группы методик. Они описаны в книгах, доступных как в Сети, так и в обычном книжном магазине.

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

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

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

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

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

Чтобы почувствовать причастность к процессу разработки, помоги с его внедрением.

Возможен и вариант, когда ты работаешь в фирме, где производственный процесс спускается сверху. Здесь зачастую, когда инструкция добирается до группы разработчиков, к описанию технологических приемов добавляют столько лишних слов и интерпретируют их столь вольно, что они теряют свой первоначальный смысл. Инструкцию постигает судьба фразы в игре Испорченный телефон.[9] Тут ты снова можешь взять на себя инициативу. Изучи спущенную сверху методику и помоги своей группе и руководству корректно интерпретировать описание рабочего процесса. Если ты не собираешься бороться против спускаемых сверху инструкций, по крайней мере обеспечь корректность их практической реализации.

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