[Из песочницы] Принципы PDD — Panic Driven Development
Привет, Хабр! Уважаемые читатели, сие есть перевод замечательной статьи за авторством Мауро Фрезза. Надеюсь, он доставит вам истинное наслаждение и поддержит вас в курсе современных тенденций в методологиях разработки.
После того как прошла волна успеха методологий разработки из семейства Agile, проверку временем выдержали лишь немногие из них. Но среди них есть одна особая техника: PDD Panic Driven Development — Разработка через панику.
Эта техника разделяет основные принципы методологии разработки Agile, но она лишена бесполезных церемоний и технологической нагрузки, которые лишь снижают скорость работы команды. Давайте подробнее ознакомимся с принципами этой методологии.
Чем новее задача — тем выше приоритет
Как только среди спринта возникает новая задача — её приоритет воспаряет над всей ранее запланированной работой. Ведь всё новое всегда лучше и важнее. Вообще, этот пункт следовало бы включить в основные принципы методологии Agile.
Фокус на предоставлении ценности клиенту предполагает, что команда должна отложить ранее запланированную работу в сторонку и позаботиться о новых фичах.
Пишем ровно столько кода, сколько требуется для результата
Разработчики зарабатывают на жизнь написанием кода. Ошибки можно исправить только кодом. Обсуждение дизайна и UX только замедляет разработку. Поэтому поступаем так: Пишем решение, убеждаемся что фикс рабочий. Если всё ок, то проблема решена. Едем дальше.
Не надо торопиться с тестированием
После внедрения фикса тесты нужно планировать в виде отложенных задач. Тесты, конечно, полезны, но не надо перегибать. О них можно позаботиться позже. Создайте тикет и закиньте его в бэклог. Для проверки работоспособности вполне можно обойтись и ручным тестированием.
Доверьтесь чувствам
Программирование — это искусство. Неотъемлемой частью любого искусства являются инстинкты и интуиция. Слушай своё сердце. Пиши решение. Смелее выкатывай его. Только смелым улыбается удача.
Процесс должен приспособиться под вас
Любой процесс разработки, тестирования и выпуска программного обеспечения — это просто набор соглашений и правил. Они не высечены на камне. Критические же исправления требуют гибкости. Вполне ожидаемо, что для повышения скорости процессы будут изменены под нужды команды.
Всё исходит от менеджера
Менеджер команды уполномочен высказываться по вопросам разработки. Всякий рефакторинг и всякое соблюдение хороших практик могут и должны быть отвергнуты потребностями бизнеса. Инженеры, конечно, могут выразить свое мнение, но в конечном итоге им следует работать на потребности, переданные им сверху.
Заключение
PDD — это техника, стремительно повышающая скорость работы в команде любого проекта за кратчайшие сроки.
Она находит применение в компаниях по всему миру и является фундаментом для гибкого и бескомпромиссного программирования.
