[Agile] Принципы PDD — Panic Driven Development
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, Хабр! Уважаемые читатели, сие есть перевод замечательной статьи за авторством Мауро Фрезза. Надеюсь, он доставит вам истинное наслаждение и поддержит вас в курсе современных тенденций в методологиях разработки.
После того как прошла волна успеха методологий разработки из семейства Agile, проверку временем выдержали лишь немногие из них. Но среди них есть одна особая техника: PDD Panic Driven Development — Разработка через панику.
Эта техника разделяет основные принципы методологии разработки Agile, но она лишена бесполезных церемоний и технологической нагрузки, которые лишь снижают скорость работы команды. Давайте подробнее ознакомимся с принципами этой методологии.
Чем новее задача — тем выше приоритет
Как только среди спринта возникает новая задача — её приоритет воспаряет над всей ранее запланированной работой. Ведь всё новое всегда лучше и важнее. Вообще, этот пункт следовало бы включить в основные принципы методологии Agile.
Фокус на предоставлении ценности клиенту предполагает, что команда должна отложить ранее запланированную работу в сторонку и позаботиться о новых фичах.
Пишем ровно столько кода, сколько требуется для результата
Разработчики зарабатывают на жизнь написанием кода. Ошибки можно исправить только кодом. Обсуждение дизайна и UX только замедляет разработку. Поэтому поступаем так: Пишем решение, убеждаемся что фикс рабочий. Если всё ок, то проблема решена. Едем дальше.
Не надо торопиться с тестированием
После внедрения фикса тесты нужно планировать в виде отложенных задач. Тесты, конечно, полезны, но не надо перегибать. О них можно позаботиться позже. Создайте тикет и закиньте его в бэклог. Для проверки работоспособности вполне можно обойтись и ручным тестированием.
Доверьтесь чувствам
Программирование — это искусство. Неотъемлемой частью любого искусства являются инстинкты и интуиция. Слушай своё сердце. Пиши решение. Смелее выкатывай его. Только смелым улыбается удача.
Процесс должен приспособиться под вас
Любой процесс разработки, тестирования и выпуска программного обеспечения — это просто набор соглашений и правил. Они не высечены на камне. Критические же исправления требуют гибкости. Вполне ожидаемо, что для повышения скорости процессы будут изменены под нужды команды.
Всё исходит от менеджера
Менеджер команды уполномочен высказываться по вопросам разработки. Всякий рефакторинг и всякое соблюдение хороших практик могут и должны быть отвергнуты потребностями бизнеса. Инженеры, конечно, могут выразить свое мнение, но в конечном итоге им следует работать на потребности, переданные им сверху.
Заключение
PDD — это техника, стремительно повышающая скорость работы в команде любого проекта за кратчайшие сроки.
Она находит применение в компаниях по всему миру и является фундаментом для гибкого и бескомпромиссного программирования.
===========
Источник:
habr.com
===========
Похожие новости:
- [Карьера в IT-индустрии, Тестирование IT-систем, Тестирование веб-сервисов] Что должен знать QA? Приглашаем на большой онлайн-интенсив с 1 октября
- [Agile, Развитие стартапа, Управление проектами] Agile-трансформация: всё по-настоящему
- [Agile] Домашняя школа Scrum
- [Тестирование IT-систем, Программирование, Тестирование веб-сервисов, Управление разработкой] Зачем нам вулканец на борту: обзор Spock Framework
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений, Учебный процесс в IT, Карьера в IT-индустрии] Нужен ли девушкам в IT особый подход? О первой QA-школе Women in Tech в России
- [Проектирование и рефакторинг, Управление разработкой, Микросервисы] Что делать если никто не хочет документировать? Организация документирования микросервисов по минимуму
- [Проектирование и рефакторинг, Управление разработкой, Микросервисы] Что делать если никто не хочет документировать? Организация документирования микросервисов по минимуму — часть 2
- [Тестирование IT-систем, Управление разработкой, Конференции] 26 августа приглашаем на круглый стол QA&SDET
- [Тестирование IT-систем, Тестирование веб-сервисов] Меньше, чем пара. Еще один способ сокращения количества тестов
- [Разработка веб-сайтов, JavaScript, Тестирование веб-сервисов] Эффективное тестирование верстки
Теги для поиска: #_agile, #_agile, #_metodologii_razrabotki (методологии разработки), #_testirovanie (тестирование), #_tdd, #_luchshie_praktiki (лучшие практики), #_agile
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 02:08
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Привет, Хабр! Уважаемые читатели, сие есть перевод замечательной статьи за авторством Мауро Фрезза. Надеюсь, он доставит вам истинное наслаждение и поддержит вас в курсе современных тенденций в методологиях разработки. После того как прошла волна успеха методологий разработки из семейства Agile, проверку временем выдержали лишь немногие из них. Но среди них есть одна особая техника: PDD Panic Driven Development — Разработка через панику. Эта техника разделяет основные принципы методологии разработки Agile, но она лишена бесполезных церемоний и технологической нагрузки, которые лишь снижают скорость работы команды. Давайте подробнее ознакомимся с принципами этой методологии. Чем новее задача — тем выше приоритет Как только среди спринта возникает новая задача — её приоритет воспаряет над всей ранее запланированной работой. Ведь всё новое всегда лучше и важнее. Вообще, этот пункт следовало бы включить в основные принципы методологии Agile. Фокус на предоставлении ценности клиенту предполагает, что команда должна отложить ранее запланированную работу в сторонку и позаботиться о новых фичах. Пишем ровно столько кода, сколько требуется для результата Разработчики зарабатывают на жизнь написанием кода. Ошибки можно исправить только кодом. Обсуждение дизайна и UX только замедляет разработку. Поэтому поступаем так: Пишем решение, убеждаемся что фикс рабочий. Если всё ок, то проблема решена. Едем дальше. Не надо торопиться с тестированием После внедрения фикса тесты нужно планировать в виде отложенных задач. Тесты, конечно, полезны, но не надо перегибать. О них можно позаботиться позже. Создайте тикет и закиньте его в бэклог. Для проверки работоспособности вполне можно обойтись и ручным тестированием. Доверьтесь чувствам Программирование — это искусство. Неотъемлемой частью любого искусства являются инстинкты и интуиция. Слушай своё сердце. Пиши решение. Смелее выкатывай его. Только смелым улыбается удача. Процесс должен приспособиться под вас Любой процесс разработки, тестирования и выпуска программного обеспечения — это просто набор соглашений и правил. Они не высечены на камне. Критические же исправления требуют гибкости. Вполне ожидаемо, что для повышения скорости процессы будут изменены под нужды команды. Всё исходит от менеджера Менеджер команды уполномочен высказываться по вопросам разработки. Всякий рефакторинг и всякое соблюдение хороших практик могут и должны быть отвергнуты потребностями бизнеса. Инженеры, конечно, могут выразить свое мнение, но в конечном итоге им следует работать на потребности, переданные им сверху. Заключение PDD — это техника, стремительно повышающая скорость работы в команде любого проекта за кратчайшие сроки. Она находит применение в компаниях по всему миру и является фундаментом для гибкого и бескомпромиссного программирования. =========== Источник: habr.com =========== Похожие новости:
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 02:08
Часовой пояс: UTC + 5