Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

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

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

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

Очень важно, чтобы проект не хромал на контрольных точках и проходил их твердо и уверенно, а члены группы были едины в своих действиях и по завершении этапа испытывали чувство гордости за проделанную работу. Всегда существует искушение заняться проблемами производительности "когда-нибудь потом", поскольку их решение непосредственно не венчается созданием каких-либо новых инструментальных средств или возможностей; ни в коем случае не поддавайтесь этому соблазну! Как неоднократно доказано на практике, гораздо лучше пройти контрольную точку, пусть и с нарушением установленных сроков, но строго выполнив все необходимые требования, чем быстро ее проскочить, ограничившись компромиссными решениями.

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

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