Какие методологии используете в разработке? Какие методологии - прошлый век?

одиночное программирование в две руки

парное программирование «на брудершафт»

программирование ногами

одиночное программирование в две руки

Методологическая составляющая очень много значит. Без разницы - «всколькером» выполняешь работу. Она позволяет планировать сроки выполнения работ.

в RL есть такая вещь - менеджер, эта вещь не знает что программиста как и медведя лучше не будить, если хочется от него добиться чего-либо кроме шатуна, так вот.

Я успешно использую эту.

Оригинал

Я серьёзно.

Плюсую. Это самая действенная методология, остальные в лучшем случае могут быть дополнениями к ней.

Блин, опередил, тоже хотел эту ссылку запостить :)

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

Инкрементирую. Из опробованного самая действенная.

Я успешно использую эту.

Документация - это часть кода? (в методологии «Пиши код, #$%^»)

Всегда подозревал что программеры сектанты

Нет, но думаю, здесь просто надо небольшое обобщение.

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

что программеры сектанты

выражаясь юридически точным языком - «члены тоталитарных сект», порабощённые ядром Линукса

P.S. Не всякий философ - сектант. Бывают и здравомыслящие люди.

Здравомыслие не самый лучший способ выживания в нашем мире.

Вы путаете методологию управления проектами (скрум) и методологии разработки (xp).

Пусть манагеры себе этим голову пудрят, мое дело - продумывать архитектуру, писать код, настраивать сервера, и т. д. Методики - для бездельников, которым нужно показать перед начальством свою значимость.

Я успешно использую эту.

нельзя не плюсануть, со временем понял всю действенность этого подхода

которым нужно показать перед начальством свою значимость.

Возможно, возможно ... я 10 лет назад был увлечён таким теоретизированием.
Сказалось фундаментальное университетское образование.
Потом мне это аукнулось очень сильно — довело меня до перфекционизма.
Правда, потом это прошло, сейчас тоже использую методологию «Пиши код,...»
На сайт википедии наткнулся случайно, вот и подумалось ...

IDEF* для обдумывания и понимания функций того, для чего пишешь программу (не всегда), UML для моделирования структуры программы. А уж потом только набиваю код.

Правда, потом это прошло, сейчас тоже использую методологию «Пиши код,...»

ИМХО без предварительного обдумывания архитектуры ПО такая методология скоро превращается в «Перепеши код, ...!»

Я делом занимаюсь, а не методологии использую.

ИМХО без предварительного обдумывания архитектуры ПО такая методология скоро превращается в «Перепеши код, ...!»

Продумывание архитектуры никоим образом не относится к методикам типа «XP», «agile» или «pair programming».

Потом мне это аукнулось очень сильно — довело меня до перфекционизма.

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

По-моему, методология - это всё-таки ответ не на вопрос «что делать?», а на вопрос «что делать, если я пишу, ***, код, а получается, ***, ***ня?!»

Т.е. «пиши, ***, код» подразумевается по умолчанию.

Раньше использовал Scrum, потом перешёл на Kanban. Теперь перешёл в другой департамент и забросил все эти методологии, просто пишем код.

Scrum и Kanban хороши тем, что можно статистику начальству показать, начальству ведь редко нужен конечный результат, им всё больше красивые цифры подавай.

просто пишем код.

Золотые слова!

пытаюсь использовать TDD для всего более-менее крупного.

Я успешно использую эту.

Поддерживаю.
Ничего умнее и эффективней еще не придумали.

Для одиночной разработки метод раскрутки прототипа с постоянным тестированием самое то, а схемки можно и в гимпе порисовать.

без предварительного обдумывания архитектуры ПО такая методология скоро превращается в «Перепеши код, ...!»

Для скриптов-однодневок методика Пиши-код очень даже подходит.
Если работа растягивается на неделю и более - то да, надо взять бумагу и ручку - рисовать алгоритм.

аналогично

Скрам юзаем. Если возникает вопрос «нахуа», то отвечу: поторговаться с заказчиком насчет задач типа что успеем сделать в следующую итерацию, делать только приоритетные для него задачи в намеченный срок.

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

Еще есть опыт работы по канбану, хорошо показал себя на сапорт задачах.

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

Еще могу про инженерные практики рассказать: код ревью, багтрекер, юнит тесты, архитектурная доска - все это маст хев по моему опыту. Но тут уже у кого какие задачи

скрам это кусок говна который дает ложную уверенность манагерам что что-то развивается. на самом деле все катится в сраное говно, но многим это и надо - ведь это тру энрепрайз)))

долго не мог вкурить что такое чудодейственное есть юнить тесты

ведь некое CS образованьеце тихо нашептевало что для частично определёных функций тестирование частных случаев гарантирует лиш проверку этих случаев.

оказывается в реальном мире важна реакция в штатных ситуациях ( и в штатных не штатных :) ) - а что не предусмотрели в этой версии выкатим в следующую ( ибо собрали на заказчике реальную статистику) - уверен что софт жёсткого реального времени пишется нетолько используя(если вообще) юнит-тесты

В mission critical задачах используют формальные методы, да. Юнит тесты - средство повысить качество (или скорость разработки, одно в другое запросто конвертится), но не более того.

Как называется методология, когда приходит начальник, дает новое задание и на вопрос, к какому числу это надо отвечает «вчера».

rabstvo - slavery

+1 :)

когда приходит начальник, дает новое задание и на вопрос, к какому числу это надо отвечает «вчера».

Это просто означает, что директор конторы (который контролирует начальника) не
выполняет свои служебные обязанности. В нормальных конторах, если директор,
если узнает о неэффективности управления в отделе, делает разгон или внушение
начальнику.

если узнает о неэффективности управления в отделе

А кто сказал, что это неэффективный тип управления?

Никак. Что бы построить сортир не нужна никакая методология. А что бы построить небоскреб - нужна.