ManageExpert.ru

Успешный менеджмент

Вверх по водопаду

Может ли роботам сниться электрическая овца? Преследуют ли менеджеров программных проектов кошмары о прыжках с водопада?

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

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

Разработчики программного обеспечения и другие представители индустрии программирования отличаются тем, что они всегда бегут впереди себя. Едва увидев титульный лист спецификации, они тут же начинают придумывать код или дизайн интерфейса. Анализируя абстрактные сценарии использования, они уже представляют иконки для панели инструментов. При планировании связей между основными модулями они начинают придумывать оригинальные способы применения программного интерфейса.

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

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

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

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

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

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

Перейти на страницу: 1 2