Экстремальный программизм
Широко известная методология экстремального программирования показалась нам недостаточной экстремальной и мы решили ее немного пересмотреть. Вот основные тезисы:
- Планирование не имеет никакого смысла, т.к. реальная жизнь все-равно расходится с любыми планами.
- Максимально длинные итерации. Нет абсолютно никакого смысла пичкать пользователя частыми релизами с незначительными изменениями. Так пользователь не будет видеть никакого движения вперед. Если и выпускать релиз, то ого-го какой, чтобы все видели что функционал растет! Поэтому не скупитесь на время подготовки релиза, добавляйте туда новые фичи пока они не кончатся.
- Ограничение общения с пользователями. Посудите сами, откуда обычной домохозяйке (ну или инженеру) знать как должен работать ваш продукт. Пользователи окончательно запутают вас своими глупыми и бессмысленными просьбами, отнимая ваше драгоценное время. Разработчик лучше всех знает, каким должен получиться продукт.
- Не стоит ограничивать рабочее время разработчика. Работать нужно в экстремальном режиме, до тех пор пока есть физические силы. Так будет написан больший объем кода и пользователи увидят, что качество продукта и его функционал растет. Идеальный вариант — это семидневная рабочая неделя. Отпуски крайне не приветствуются, так как разработчик забывает различные детали реализации и ему потребуется время, чтобы входить в курс дела заново.
- Каждый разработчик должен работать исключительно со своей задачей, не забивая себе голову чужими проблемами. Это правило не допустит рассредоточения внимания и позволит выполнить работу в намеченные сроки. Золотое правило: одна задача — один разработчик. Это правило поможет выполнить максимальное число задач, равное числу разработчиков.
- Недопустимо использование subversion. Каждый разработчик должен сам заботиться о своих исходниках, хранить их у себя и никому не показывать, т.к. обязательно кто-нибудь испортит ваш драгоценный код.
- Новый функционал превыше всего. Багам не стоит уделять особого внимания, т.к. их мало кто замечает. А новую фичу заметят все!
С помощью таких вот нехитрых правил вы сможете повысить продуктивность и качество продукта на порядок. Удачи, друзья =))
респект. и уважуха, как принято сейчас говорить.
надо ещё добавить абсолютное игнорирование качества кода, принудительное удаление комментариев и перекладывание на пользователя составление руководств по эксплуатации.
ps. тэг «юмор» — лишний.
Антон Маркович, вчера хотел спросить, да из головы вылетело. Вы где торты покупали?))
отличное место для таких вопросов ;)