процесс разработки


Прочел вот здесь:

Недавно обсуждал со своем начальником следующий вопрос: Как лучше разделять задания для выполнения по проекту. Есть два мнения: необходимо делить проект на мелкие части и выдавать части любому свободному программисту, размер части не более 8 часов – одного рабочего дня – так думаю я и программисты в моей команде. Мнение начальника – выделять в проекте большие блоки и назначать ответственных за каждый блок, что бы он постоянно отвечал за него и в случае наличия проблемы решал ее.

Не могу спокойно смотреть, как люди ходят по граблям… Попробую высказать свои мысли по поднятой теме.

Затронуто, по сути, два вопроса – о единице планирования и о ротации разработчиков. Сегодня я расскажу про планирование.

О единице планирования

Много написано о том, что работы в плане должны быть максимально подробными. Джоэль Спольски, насколько я помню, пишет о 8-16 часах как о максимальной длительности, после которой задачу надо дробить на несколько более мелких. Техника действительно полезная, но там акцент делался на персональном планировании или, на худой конец, о группе из 2-3 человек.

Ну а если пытаться делать то же самое в относительно крупном проекте?

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

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

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

В следущее утро ему досталась задача по модификации билд-файлов и перенастройке билд-сервера. Что ж, надо опять лезть в документацию… Через пару часов прибегает взмыленный тестер – выясняется, что написанный в понедельник Ajax-код, некорректно работает в седьмой версии Internet Explorer, а в 6-й версии и Опере не работает совсем. Документация по билдам заброшена и вдвоем с хорошо разбирающимся в Ajax коллегой Константин к концу дня таки исправляет этот чертов глюк.

В пятницу утром прибегает тестер, проверявший функцию комментирования…

Ну как вам такой распорядок?

“Да вообще отвратительно, убила бы такого руководителя” – одна моя хорошая знакомая.

В чем ошибка?

  1. Не все задачи одинаковы. Не все программисты одинаковы. Я уже писал раньше о том, насколько чревато думать, что можно безнаказанно тасовать задачи, не учитывая особенности каждого конкретного исполнителя.

  2. Планы должны быть предсказуемы. Когда человек не знает, что он будет делать завтра – это нонсенс. Не меньше половины ключевых идей для решения какой-то проблемы возникает у людей в «фоновом режиме», пока они работают над предыдущими задачами. Если человек не знает что через неделю он будет решать задачу X, то он легко может думать «в фоне» о решении для задачи Y. А решать придется задачу Z, про которую он не думал вообще. В итоге качество решений, требующих тщательного обдумывания снизится в проекте где-то в два раза. Оно вам надо?

  3. Планы должны быть предсказуемы, часть 2. Люди чисто психологически не любят неожиданностей. Делая каждую следующую работу неожиданной вы сильно напрягаете всех участников проекта. Не буду говорить здесь о важности здоровой психологической обстановки в проекте – думаю что это очевидно для любого хорошего менеджера.


На сегодня все. В воскресенье читайте продолжение, про ротацию программистов.

« Previous PageNext Page »