Трезвая работа

Существуют ли работы, где не обязательные эзотерические методологии и философии типа Agile, XP, Scrum, design patterns, OOD? (Лучшего заголовка не придумал. Не копировать же тело сообщения в заголовок.)

LinkedIn

Лучшие комментарии пропустить

В дайджесте вакансий каждый четверг, рубрика «вакансии гос. предприятий».

Agile, XP, Scrum, design patterns, OOD
Вы так говорите, как будто это что-то плохое.
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

«Управляемый хаос» — официальное название методологии разработки в нашей компании)

думаю стоит попробовать поискать маленькие команды (до 10 человек). Там таким не занимаються, просто незачем.

Скрам какраз создан для и нормально работает в маленьких командах до 10 человек ;-)

действительно, почему бы и нет, если 10 человек сидит в одном офисе в 2-3 комнатах, все знают кто что делает (не в деталях, но хотя бы в общей картине), надо их обязательно раз в день и собирать и напоминать им об этом. (сарказм)

Хе хе. Практика показывает — что не знают ;-)
Даж я, к примеру, буду сидеть заниматься своей задачей, мне и в голову не прийдет ломиться в соседний кабинет, спрашивать «эй пацаны, а вы чем вооще занимаетесь!?»

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

«пообщаться» ?!
Вы программист, или, извините, менеджер ? :-D

эй, чуваки, бросайте, кто там чем занимается, идите ко мне — делиться, что у кого как!

окей. давайте посчитаем, сколько потребуется времени, если каждый из 7 человек команды захочет узнать, чем занимается каждый из 6 остальных.
а потом будем говорить «стендап — фигня, я прохожу по комнате и все и так узнаю».

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

Существуют ли работы, где не обязательные эзотерические методологии и философии типа Agile, XP, Scrum, design patterns, OOD?
Мне постоянно так везет что эти базворды так и остаются на собеседовании. А на практике два митинга в неделю назначат и вот вам и весь скрам.

Хорошее дело практиков с академическим складом ума и энтузиастов превратили в маргетинговые штучки для галочки, извратили, заставили ненавидить и уничтожили;)

Кстати, Мартин Фаулер (один из отцов-основателей Agile и не только его) никогда не был религиозным фанатиком своего детища, настаивал на плюсах и минусах Agile, границах применимости и пр., как это и свойственно вменяемому автору любой технологии.

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

Майлстоновые демки также хороши.
На контору плевать давным-давно, а чтобы не опозориться перед коллегами — делаешь;)

Это вы типа хотите, чтобы всё как у людей — свободный график, некуда деть деньги, заграничные коммандировки, +500 при переходе, и при всём этом — никакой непривычной вам ереси? :-D

В пятницу, по результатам обсуждения ниже, в Часопысе всем провести ретроспективу.

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

Докладик минут на 10-15 замутить с bells and whistles для меня — милое дело.
Все, что могу гарантировать — никто не уснет во время доклада;)
Только не в эту пятницу, а в следующий четверг или лучше через один, в эту я уже забукан и должен быть как обычно поет Слепаков, в человеке все должно быть прекрасно.

Публику (3 с половиной я приведу), рекламу, прочих докладчиков и организацию на себя возьмете?(эгидку можно замутить того же Доу например или одного из «лидеров рынка»)
Или хватает на только на предложить?;)

давайте ретроспективу отложим, а то требования поменялись и надо дожать прототип

Желаю чтобы он скорее стал protoduction ;)
Подначка «на слабо» осталась.
Как-никак нам дефолт обещают, всем нужно срочно учиться «вывозить за базар»)))

Какие милые комментарии в теме. Почитаешь, и можно подумать что все эти ваши методологии с паттернами — спасают от гов-нокода.

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

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

такое у меня у самого есть, ты покажи БЕЗ методологий и паттернов :)

Как то ж работало то, что было создано до создания паттернов и методологий :)))

а че RUP какой нибуть не методология? Тут аджайлы вроде макали в основном )

Ну RUP появился только в середине-конце девяностых :)

А задолго до RUP, в 60-х тоже были свои методологии и свои баззворды.
en.wikipedia.org/...ment_life_cycle

у меня чуть глаза не выпали.
что значит «до создания»? это как «как-то ж лечили до придумывания вирусов».
Александреску, а затем Банда четырех описали и структурировали набор типичных подходов к реализации кода. То есть подходы были и раньше. Им дали определенные названия. Структурировано описали область применимисти и особенности. То есть, паттерны были и задолго до, но не назывались «паттернами проектирования/программирования». Всего-то.
Методология — это упорядоченный набор практик. То есть, что мешало до выпуска Agile манифеста разбивать проект не по модулям, а по функциям? Как незнание аббревиатуры «TDD» мешало писать тесты до собственно кода?
Это всё было задолго до того, как этому дали имя и сделали чуть ли не идеологией.

То есть, паттерны были и задолго до, но не назывались «паттернами проектирования/программирования». Всего-то.
А причём тут паттерны? Паттерны — это вообще отдельная больная тема.
Это всё было задолго до того, как этому дали имя и сделали чуть ли не идеологией.
Это называется здравый смысл, и да, он был всегда. Только проблема в том, что с методологией идёт в комплекте много наборов разрозненных здравых смыслов, навязанных извне, а не вызванных собственной необходимостью. А выбрать только необходимое не позволяет религия. Или всё или ничего :)
А причём тут паттерны?
Как это при чем? Цитирую:
Как то ж работало то, что было создано до создания паттернов
ну, да ладно, методологии — действительно, тема повкуснее.
смыслов, навязанных извне
это ни плохо и ни хорошо. ограничения, навязанные инструментом. фреймворки навязывают структуру кода. язык навязывает синтаксис. фон Неймановская архитектура накладывает ограничения. это тоже мешает самим фактом «назязанных извне здравых смыслов»?
если есть полномочия — отлично, отступайте в сторону. и набивайте собственные шишики. если нет полномочий — то чего жалеть, что какие-то рамки присутствуют? вперед, just develop it!
если есть полномочия — отлично, отступайте в сторону. и набивайте собственные шишики. если нет полномочий — то чего жалеть, что какие-то рамки присутствуют? вперед, just develop it!
Т.е. чтобы не набить шишек (а вдруг мы исключим нечто очень важное), мы включим, допустим, всю основную agile (из педивикии):

Acceptance Test Driven Development (ATDD)
Agile Modeling
Agile Unified Process (AUP)
Continuous integration (CI)
Crystal Clear
Crystal Methods
Dynamic Systems Development Method (DSDM)
Extreme Programming (XP)
Feature Driven Development (FDD)
Graphical System Design (GSD)
Kanban
Lean software development
Scrum
Scrumban
Story-driven modeling
Test-driven development (TDD)
Velocity tracking
Software Development Rhythms

Вы представляете этот хаос? Это будет похлеще Фауста Гёте.

всю основную agile (из педивикии)
Agile — это набор методологий. Это даже в многословной и косноязычной википедии указано.
это как заявить: окей, я в своем проекте реализую функциональное, процедурное, декларативное и магическое программирование! А еще — низкоуровневое, data-driven и ваще.
Agile — это набор методологий.
Свалка.
это как заявить: окей, я в своем проекте реализую функциональное, процедурное, декларативное и магическое программирование! А еще — низкоуровневое, data-driven и ваще.
Так что, придётся викидывать львинную долю здравых смыслов? %) Это то, с чего мы начали, т.е. используем только то, что нам в данный момент надо и приносит пользу, и забиваем болт на всё остальное.

С паттернами история не лучше. Иногда хочется, чтобы некоторые про паттерны забыли навсегда. Доходит до маразма, когда программер начинает натягивать задачу на паттерн, боясь отойти от него даже на дюйм, вместо того, чтобы создать какой-нибудь гибрид техник, который будет уместен при решении задачи (как и методологические гибриды). Многие рассматривают паттерны как прямой how to и руководство к действию вместо «удобного решения для какой-то конкретной задачи». Это как библия, для одних святая книга, для других учебник истории, а для третих вообще собрание сказок.

Программирование — ещё весьма молодая наука (ремесло?), так что подобные перегибы будут встречаться.

Слепое следование паттернам/методологии/любым другим трендам — это по сути отказ от ответственности и показатель низкого уровня специалиста.

Т.е. чтобы не набить шишек (а вдруг мы исключим нечто очень важное)
я имел в виду следующую ситуацию:
1. окей, у нас Скрам. Говорят, это модно и удобно.
2. но спринты будут по месяцу. нет, лучше полтора.
3. дейли стендапы нафиг, только время съедают. мне и так видно, кто чем занимается.
4. что значит — работоспособный срез функционала? будем делать по модулям.
5. эстимейтим в часах. что за странные story points?
6. я сказал — эстимейтим? нет, не надо время тратить, я сам вам расставлю примерное время, в которое должны уложиться.
....
спустя некоторое время: тьфу, дурацкий Скрам, завалили проект из-за него!

Да-да, неправильно молились, и не верили.

спустя некоторое время: тьфу, дурацкий Скрам, завалили проект из-за него!
А знаете какая сейчас самая модная отмазка для Scrum адептов? Скрам не предназначен для больших организаций. А если хорошо подумать, то видно, что скрам просто идеально ложится на формошлёпский вид бурной деятельности, где продукт труда можно измерить сразу в количестве формочек, созданных за час.
Скрам не предназначен для больших организаций.
Ух ты, а можно линки и пруфы? А то в моей «большой организации» ваккурат осеннее обострение, надо шо-то делать.
скрам просто идеально ложится на формошлёпский вид бурной деятельности, где продукт труда можно измерить сразу в количестве формочек, созданных за час.
Сразу видно человека с раньшего времени! ©
Ух ты, а можно линки и пруфы? А то в моей «большой организации» ваккурат осеннее обострение, надо шо-то делать.
Я бы посмотрел в сторону Гугля, они хоть и ввели у себя скрам, но сделали это по-уму, как всегда, т.е. прогнули скрам под себя.

Моя позиция не такая, что скрам/agile — это плохо, а что надо подходить с умом, а не слепо копировать всё подряд.

Я бы посмотрел в сторону Гугля
Где Гугл, а где мы, лапотные.
в сторону Гугля, они хоть и ввели у себя скрам,

это откуда такая инфа?

инеты такого не кажут — так, деление давним опытом от конкретных персон, работающих, само собой, в конкретных проектах, коих у такого монстра как гугель килотонны

А знаете какая сейчас самая модная отмазка для Scrum адептов? Скрам не предназначен для больших организаций.
ой, капец, где вы таких берете?
может, там еще и в зависимости от количества строк кода деньги платят? и ходят все в шапочках из фольги?
разговор у нас отлично складвается:
«методологии не нужны» уже перешло в
«фанатики — это плохо». глядишь, и придем к тому, что инструментом надо уметь пользоваться, для чего надо знать не только название. и что «я принципиально не читаю о методологиях и шаблонах, шоб не стать фанатиком, потому каждый раз изобретаю велосипедт» — не самая здравая позиция. ну, это к вопросу «зачем эти изверги спрашивают на собеседованиях об этом?!» из параллельной ветки обсуждения

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

паттерн — по сути алгоритм в общих чертах(плохой/хороший — другой разговор).

Хотите сказать, что знание базовых алгоритмов не накладывает «отпечаток» на код?

Хотите сказать, что знание базовых алгоритмов не накладывает «отпечаток» на код?
Не знаю :) За собой не замечал попыток везде всунуть Кнута :)

Скрам служит хорошую тактическую службу при выполнении конкретных небольших проектов в больших организациях.

Блин, с вами разговаривать как с самим собой %)

«Блин, с вами разговаривать как с самим собой %)»
Что вижу — то комментирую, тред не всегда читаю до конца, сорри;)

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

Согласен, за исключением того, что никакой «тёмной стороны» в предложенном вами подходе нет — примерно такой набор и понимается как наиболее оптимальный в современной трактовке Agile

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

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

мы бы очень хотели писать юнит-тесты и проводить код-ревью, да заказчик, гад, платить за это не хочет.
Слышал рассказы от тест менеджера из харьковского Циклума.о воспитании заказчика, то есть это все по собственной инициативе, а потом показываются преимущества и статистика.
Отец основатель Agile Фаулер писал что-то вроде «это мое дело, как мне решать задачу, менеджеру нужен результат, а как я использую отпущенное время — должно быть без разницы».
Убеждать нужно учиться, пригодится для инвесторов и пр.
Есть другая крайность — юнит тестами покрывается все, лишь бы покрыть.

Знать то это желательно, это все за плечами не носится.

Бесспорно, это расширяет кругозор и позволяет не вляпаться в ненужную методологию. По крайней мере при знании всего этого будет возможность откуда выбирать и лепить своего франкенштейна.

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

При этом существуют примеры людей, которые выучив паттерны, отказываются дружить со здравым смыслом, и пихают их везде (10 фабрик и 20 адаптеров для решения тривиальной задачи, даже с учетом будущих изменений). Ведь паттерны это хорошо, это архитектура! Это не ПЭХАПЭ сайты написанные студентами.
При этом, качество кода во много зависит не от паттернов и аджайлов со скрамами, а больше от простых идей, как — давать переменным понятные имена, не писать комментарии там где это не нужно, писать комментарии там где это нужно, не делать методов с 20 параметрами, не повторять один и тот же код много раз. И конечно от здравого мышления.
Также качество зависит от предварительного анализа и рисерча, который из-за этих методологий, во всяком случае в интерпретации некоторых людей, может страдать.

Изучение паттернов конечно может экономить время, так как человеку может узнать о каких то трюках заранее. Но это точно не должно происходить в такой атмосфере — что паттерны это святая истинна, и кто их не знает и не следует им — не может считаться хорошим разработчиком.

И что бы было ясно, что я имею ввиду под паттернами.
Какие то решения в OOD существовали и существуют, а паттерны, как design patterns, знание которых требуют от каждого разработчика на работе — это уже конкретные книжки, конкретное описание определенных решений. Они появились в определенный момент, и именно о них чаще всего речь. Разве нет?
По сути, тебе говорят, нам плевать насколько ты способен самостоятельно выводить OOD решения — вот учи книжку, учи этот список решений, и только тогда мы будем считать тебя хорошим разработчиком.
Кто-то скажет, что работодателю/заказчику плевать на то насколько ты способный, главное что бы ты делал работу, ну тогда о чем вообще речь, зачем требовать эти паттерны (повод и отговорка)?

Аналогично с методологиями.
Разбивать задачу на подзадачи что бы более детально представить себе — что нужно сделать. Это здравый смысл. Точно также, как не увеличивать объем работ, уже после того как договорились о сроках.
И для этого не нужно покупать священные книги, ходит на священные тренинги, и передерживаться священных ритуалов.

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

Нет, не будет. Он будет использовать решение. А паттерн это уже продукт человеческого ума (а не реальный код в программе), в результате анализа часто используемых решений.
Если тебе тяжело это понять исходя их общего определения — что pattern (вне текущего контекста). Тогда возьми любую книжку по паттернам, и прочитай, что у паттерна должно быть имя, и прочие аттрибуты, которых у решения в коде — нет.

нет, нормальный инженер не использует новое только ради новизны
Я такого не утверждал.
что кто-то называет свое решение «абстрактной фабрикой»
И кому ты будешь называть решение?
1. Обсуждение таких решений происходит в контексте какого то кода.
2. Вполне нормально объяснить «сделаю также как в <название таска>», если оба человека знают о чем речь. Даже вполне типично «посмотри как сделано в <название функционала, имя класса и т.д.>».
3. Реальное решение сложнее чем просто использование одного или двух паттернов, если ты обсуждаешь с кем то решение исключительно в названиях паттернов — то это идиотизм. Часто даже реальное решение, это даже не 100% паттерна, как ты объясняешь — какая часть паттерна отсутствует?
4. Почему именно абстрактная фабрика, часто делаешь абстрактные фабрики? Банальный пример, давай расскажи о чем то более оригинальном чем фабрика или синглтон, и то, как тебя сразу все понимают — что же ты имел ввиду, учитывая что нужно ещё сопоставить элементы эталонного паттерна с тем что у тебя реально в коде, или что необходимо реализовать?
5. Никому не интересно как ты там сделал, каким решением, давай уже таск доделывай. Уже дедлайн (всегда дедлайн и деливери).
это ж надо так сильно перепутать причину(неспособность критически мыслить и догматичность мышления) со следствием(неверное и неуместное применение шаблонов и методологий)!
Человек задал вопрос.
Ему отвечает таким образом, что можно сделать вывод,
что многие считают, что если ты не следуешь design patterns, и «методологиям» или хочешь работать там где им не следуют. То ты — студентота клепающая сайтики на ПХП, работник гос. учреждения (считай отброс с маленькой зарплатой, в окружении технически безграмотных и отсталых), гарантирования причина гов-нокода от которого будут потом плеваться другие программисты, или гарантировано попадешь к гов-но-коду, и студентоте.
Очевидно, что эти люди как раз путают, опыт, навыки, ответственность за качество своей работы, и здравое мышление,
с догматичным применением «методологий».
Тогда возьми любую книжку по паттернам, и прочитай, что у паттерна должно быть имя, и прочие аттрибуты, которых у решения в коде — нет.
Почему нет — тру инженеры пишут суффиксы.
Видишь в коде Observer или Facade — и уже не надо долго разбираться, чем занимается данный велосипед в коде давно уехавшего на тракторе программиста.

Причем язык не имеет значения, встречаешь как старого знакомого и на тебя находит просветление, как мне давеча в при разборе глюкокода в С++.

Видишь в коде Observer или Facade — и уже не надо долго разбираться, чем занимается данный велосипед в коде давно уехавшего на тракторе программиста.
Ага, только, часто, из за таких вот товарищей, как коменнтариями высше, видишь Observer или Facade и опа, опа — оно совсем ниразу не то что ты подумал...

самый эпик который я видел — это функция getRecipientId которая возвращала id отправителя.

И заметьте — без всяких паттернов...

самый эпик который я видел — это функция getRecipientId которая возвращала id отправителя.
Это не эпик, это опечатка, это лечится;)

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

Почему именно абстрактная фабрика, часто делаешь абстрактные фабрики?
вот на это не мог не ответить.
окей. давай поговорим про шаблонный метод.
миллионы здравомыслящих программистов используют шаблонный метод. и да, гораздо проще говорить «сделай себе шаблонный метод в родительском классе», чем «проведи рефакторинг этих двух братских классов, вынеся общую высокоуровневую логику в метод родительского класса, а в дочерних классах оставь конкретную реализацию логики».
многие считают, что если ты не следуешь design patterns, и «методологиям» или хочешь работать там где им не следуют. То ты — студентота клепающая сайтики на ПХП,
а это-то мнение откуда взялось? если ты презираешь инструмент только потому, что он — популярен. если заявляешь, что без инструмента или с ним — абсолютно пофиг. то да, отношение будет не очень приятное.
сложно ответить на пост целиком — очень не просто продираться через многоэтажные предложения, где запятые и точки расставляются рандомно.
А мне вообще сложно общаться с придурками. На этом можно и закончить.
И кому ты будешь называть решение?
Классический пример:
Вы приходите на работу, и вам обьясняют структуру фреймворка:
«Тут у нас модельки, тут контролеры, тут ДАО, это юзаем как синглтон, а тут используем фабрику»

Если паттернов (самых юзабельных) толком не знаешь — то стоишь и и абсолютно не понимаешь, о чем речь.

«Тут у нас модельки, тут контролеры, тут ДАО, это юзаем как синглтон, а тут используем фабрику»
Хотя бы о слоях рассказали, и то хорошо;)
«Тут у нас модельки, тут контролеры, тут ДАО, это юзаем как синглтон, а тут используем фабрику»
А открыли исходники, смотрим, а там — гомномодельки, гомноконтроллеры, гомоДАО, гомносинглтон и гомнофабрика :)
А открыли исходники, смотрим, а там — гомномодельки, гомноконтроллеры, гомоДАО, гомносинглтон и гомнофабрика :)
Плачу!!! ;-)

Главное — не начинать их править шрапнельными правками;)

а паттерны, как design patterns, знание которых требуют от каждого разработчика на работе — это уже конкретные книжки, конкретное описание определенных решений. Они появились в определенный момент, и именно о них чаще всего речь.
нет. «в конкретных книжках конкретные паттерны с конкретными именами» — это квинтэссенция того, что уже десятилетями программисты использовали и раньше. И делилилсь трюками друг с другом. Только авторы «конкретных книг» пытались по максимум обобщить частные решения. Проанализировать и обосновать пределы применимости. Как вынести общий алгоритм из конкретного кода, завязанного на конкретных структурах.
По сути, тебе говорят, нам плевать насколько ты способен самостоятельно выводить OOD решения — вот учи книжку, учи этот список решений, и только тогда мы будем считать тебя хорошим разработчиком.

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

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

Я пока не нашел лучше шпаргалки, того, что должен знать любой уважающий себя software engineer .
habrahabr.ru/post/169487

Аналогично с методологиями.
Разбивать задачу на подзадачи что бы более детально представить себе — что нужно сделать. Это здравый смысл. Точно также, как не увеличивать объем работ, уже после того как договорились о сроках.
Это все называется — отсутствие ошибок в ДНК
Для меня концентрированно выраженно здесь -
habrahabr.ru/post/188430

И для этого не нужно покупать священные книги, ходит на священные тренинги, и передерживаться священных ритуалов.
Есть другая крайность — «чистить ружья кирпичом»;)
Если человек (не любой, но способный) изучит ООП язык, то пользуясь здравым смыслом, и исходя из ограничений этого инструмента, он сможет писать удовлетворительный, а со временем и хороший код.
Ну если поставить двух человек в спарринг — то со временем (особенно если есть предпосылки в характере) они научаться драться. Быть может даже хорошо.

Однако зачем-то, считается предпочтительным все таки обучать бойцов приемам и тактике.

P.S. «функциональщиков» у нас уже людьми не считают?

А выбрать только необходимое не позволяет религия. Или всё или ничего :)
Жизнь это правит обычно.
Когда необходимо выпускать проект — весь PDD c Over Oriented Programming летит к чертям и остается только KISS и "Programming, Motherfucker!"©

Они там были, просто никто их не формализовывал.
Например, ADD, DBD и MMM были всегда;)

Щас студенты делают аналоги того, что 25 лет назад считалось ну просто мегапродвинутым. Во многом, конечно, этому поспособствовало развитие технологий, но MS DOS 6.22 в целом на поверку окажется по сложности сравнима с какой-нибудь неосновной библиотечкой поставки Windows 8...

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

В студенческие годы лучше уж писать

MS DOS 6.22
с покером и поэтессами , чем сайт на Wordpress — это потом, это всегда успеется.

Ну те, кто пишет сайты на Wordpress [их тогдашние аналоги], тогда вводили из журнала игры или ещё что-то забавное на Бейсике.

Щас студенты делают аналоги того, что 25 лет назад считалось ну просто мегапродвинутым.
Например?
но MS DOS 6.22 в целом на поверку окажется по сложности сравнима с какой-нибудь неосновной библиотечкой поставки Windows 8...
Каждая выверенная строчка на асме против нескольких формочек, не очень сравнимые вещи.

Например любая трендовая IDE того времени, скажем, Turbo C 2.0. Я уж не говорю об играх. Они, конечно, тогда были тёплые ламповые, с интересным сюжетом, но технически довольно примитивные.

Каждая выверенная строчка на асме против нескольких формочек, не очень сравнимые вещи.
Вполне сравнимо. Структурная сложность примерно та же, или мы мерилом работы считаем усталость, как Кормильцев писал, а Бутусов пел?
Например любая трендовая IDE того времени, скажем, Turbo C 2.0.
А в ней ничего такого нет. Простенькая ИДЕ того времени пишется за день, что тогда, что сейчас.
Они, конечно, тогда были тёплые ламповые, с интересным сюжетом, но технически довольно примитивные.
А что технически сложного в современных играх? Для начала попробуйте проиграть приличного качества мелодию на FM синтезаторе, коих было валом в то время и они обязательно должны были поддерживаться. На одном 2 оператора, на других платах 4,8 операторов на канал, потом поддержка Sound Blaster, Gravis Ultrasound, Roland MT32. Gravis был вообще тяжел для программирования звуковых эффектов, памяти было мало, все не влезали. А ещё надо было дрынчать на спикере в фоне! Потом надо запрограммировать видеорежим, обычно это было modex, но потом пошли vesa и банковые и линейные. Линейные поддерживались только в защищенном режиме, т.е. надо было юзать либо DJGPP либо Watcom. У каждого миллион особенностей. До этого были XMS и EMS, памяти играм не хватало, надо было юзать экстендеры. Надо было поддерживать несколько оптимизационных веток для разных процессоров. Еще не забываем про игры, которые юзали EGA 640×350 16 цветов и использовали четырёхпланарную адресацию к памяти. Она чертовски медленная, специально дизайнили уровни, чтобы было как можно меньше записей в память, например dangerous dave in the haunted house. lurkmore.to/Dangerous_Dave Технически — это нереальный писец. И вы мне будете рассказывать про технические сложности современных игр?
Вполне сравнимо.
Вполне сравнимо, если код, включая заюзанные библиотеки будет такой же по размеру. Или вы думаете тогда не было паскаля и С компиляторов?

Современная игра — это не только Angry Birds, это игра топ уровня с серьезнейшей математикой и оптимизациями, которые доводят ее почти до фотореалистичности. На такими иногда более сотни человек работает

А что сложного в фотореалистичности? Обычная оптическая физика, вопрос только в её дозировке. Ну и немаловажны очень прямые руки художника, который подаёт на вход уже качественную картинку.

А что сложного в фотореалистичности? Обычная оптическая физика

«Собрать и поделить». Ну так поинтересуйтесь как она делается, что нужно учитывать и как оптимизировать для ее работы в реальном времени на железе.

Ну так поинтересуйтесь как она делается, что нужно учитывать и как оптимизировать для ее работы в реальном времени на железе.
А с чего вы взяли, что я не делал? %)

Очевидно же. Пруф:

А что сложного в фотореалистичности?
Очевидно же. Пруф:
Ну scala инженеру, конечно же, видней.

Scala инженеру интересно узнать в создании каких ААА игр вы участвовали, может я даже играл :)

А кто говорил про игры? Я писал технологические демы для ещё не вышедших на рынок мобильных GPU. Надо ли подробно объяснять, что в таких демо ради eye candy картинки делают всё?

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

В общем, не вызывает у меня это оторопи или благоговейного ужаса.
Ковырять — это одно дело, а повторять и делать нечто подобное — совершенно другое. Вы так это произносите, режимы, прерывания, ассемблер, как будто это не «побочный шум» на фоне работы.

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

Ну всякие линуксы, шминуксы, как и сам юникс вроде без каких либо методологий писались
Linux вышла из академической среды, о чем Вы?
ru.wikipedia.org/.../Философия_UNIX

Методологию с идеологией разрабатывали Столлман с Торвалдсом, благодаря котором мы жывем сейчас в очень многополярном IT — мире.

Linux вышла из академической среды, о чем Вы?
У меня «Академическая среда» ассоциируется с отсуствием методологий.

И вооще, там только про идеологию написанно, где вы там про методологию увидели ? ;-) .

«Базарную» модель разработки Вы куда отнесете — в методологию или в идеологию?

Я не знаю о какой модели вы говорите, но Торвальдс, основу линупса выпилил сам, судя по всему по методологии «do whatever».

Я не знаю о какой модели вы говорите,
Это плохо.

но Торвальдс, основу линупса выпилил сам, судя по всему по методологии «do whatever».
Ага, будучи студентом третьего курса и «just a hobby» к тому же.
Продолжайте, это все очень интересно;)

А что «интересно» ?
Он сам без каких либо методологий запил продукт, который потом стал нужным и популярным.
Что вы мне хотите возразить ?

Он сам
Нет.

без каких либо методологий запил продукт,
Идеология Столлмана, методология Торвалдса(та самая, которую Вы не знаете)

который потом стал нужным и популярным.
Естественно, до этого «потом» он лежал где-то в пиратском сундуке, изредка доделываемый «непризнанным гением»;) как BeOS (о которой Вы тоже, видимо, не знаете и знать не хотите)
Продолжайте рассказывать Вашу собственную «Историю Linux», с каждым Вашим новым сообщением она все более и более захватывает.
С удовольствием послушаю историю Agile в Вашем исполнении.
«Фолк-хистори» — штука занятная.

А по существу есть что сказать ?

Вам сказано 6 постами выше — «Базарная» модель разработки является методологией, на которой основана разработка Linux, а так же главным фактором успеха данной ОС.
Есть что возразить?;)

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

но Торвальдс, основу линупса выпилил сам,
Это вот это?
Вы изволили выразиться не «изначально», а «основа».
Не было бы других сопутствующих факторов(а Вы их отвергаете) — так написанное самостоятельно Линусом ядро линукса версии 0.01 стало бы просто очередным курсачем неизвестного финского студента и кануло в лету.
Ибо это творение само по себе больше, чем на курсач не тянуло.

от говнокода ничто не спасает.
посмотришь на код: «методологии используем, IDE продвинутая, человек умный, руки прямые. как же так можно было?!». потом осознаешь, что код-то твой. и идешь в депутаты, чтоб не калокодить больше.

Хорошо построенная в начале архитектура может выдержать некоторое количество говнокода с формошлепством;)

Паттерны это как наличие диплома у специалиста. Оно не гарантирует что человек недурак, но это все таки лучше принятия человека на должность просто с улицы и без обучения.

Никто не знает, почему я не получил ни одного уведомления о комментариях, хотя стоит надпись «Отписаться от комментариев»?

Mandrill показывает, что письма ушли:
i.imgur.com/Ip9Jpky.png

вот и мейл автора спалили ...

человек считающий простые и устоявшиеся методики не достойными его- просто днище или же это первые признаки надвигающейся шизофрении?
Discuss it?

Еще подобные мнения встречал у джунов с «не обсохшим молоком на губах».

Может, старость и преждевременный маразм? :-)

Там где эти методологии не работают, например: Research.

Ваши слова да нам бы в проект

Есть такая работа! Попроситесь в Astelit (TM life:)) в команду Maximo. Требуется базовое знание SQL и Java (core, v1.4), PHP на уровне основ синтаксиса и, что самое главное, хорошая память и смекалка.

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

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

Таких робіт — більшість. Зокрема, дуже часто скрамом називають те, що їм насправді не є. В результаті виходить в реальності якийсь відлагоджений процес, якому дають назву з існуючого списку для заспокоєння керівництва.

Вам может подойти «Ковбой кодинг»:
en.wikipedia.org/...i/Cowboy_coding
А если серьезно — нет лучшего способа познать силу «эзотерических методологий», чем поработать на проекте, написанном без их знания. Только проект должен быть большой и чужой.
Я именно так к ним когда-то и пришел: когда понял что половину времени не пишу код, а пытаюсь разобраться в хаосе. Самому обидно работать непродуктивно, особенно если в этом моей вины нет, а обвинят именно меня. Поневоле начинаешь искать пути «упорядочить хаос».

перепробував багато. працюю по programming-motherfucker.com (рускою — xn-----clcksaplxf6byd3cyb.xn—p1ai )

Дякую, я це вже читав. Є російською, але не бачив українською.

Если на новом месте работы, тебе говорят: «у нас скрам, ща расскажем как мы работаем», при этом внятно отвечают на вопросы «а это ещё зачем?!» — значит там эзотерики нет.

Если на рабочем месте вам в первую очередь вставляют в зубы книгу по скраму — значит для них это действительно «религия».

Я «трезво» работал несколько лет, прежде чем узнать, что у нас оказывается scrum/agile, agile на то и agile, чтобы вывернуть всё наизнанку, сделать непохожим на то, что есть у других и всё равно называться agile’ом. Просто постановщик процессов, он же agile евангелист, он же поп, он же ... нуждается в том, чтобы его основательно нагнули и он работал не с книжкой, а с живым предприятием и тогда он сможет улучшить процесс, а не сделать так, как поётся в интернационале, про total destruction и возрождение свежепостроенного мира.

В дайджесте вакансий каждый четверг, рубрика «вакансии гос. предприятий».

Правда там дают деньги в экзотической валюте...

Разве там не может быть

Agile, XP, Scrum, design patterns, OOD
?

Экстремальное программирование там бывает довольно часто.

Только там экстрим другого рода :-D

Один мой знакомый, бывший одногрупник по учебному заведению, после того, как устроился работать на государство (начал с подсчета голосов на выборах, а потом как-то втянуло).

Человек он с довольно хорошими качествами, такими как настойчивость, терпение и любознательность. Так что через некоторое время, он начал писать приложения на Winforms, которые должны помогать людям работать с базой данных.

К слову, снаружи, те приложения действительно выглядели стабильно и действительно решали проблему. Но... внутри творится ад... Как пример, только завершая первое приложение, он осознал, что можно вынести некоторый повторяющейся код в отдельный метод (раньше пользовался только теми, которые генерировала VisualStudio, такими как button56_Click() ).

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

Самое интересное, что со всем этим адом он вполне управляется. Он также научился пользоваться Гуклом и в принципе, сейчас уже может найти то, что ему нужно на Стэковерфлоу. Ко мне обращается лишь когда не может сформулировать поисковый запрос.
Ну да, Аджайлов там нет. Но, как по мне, такое программирование — очень экстремально

Уж, что-что, а методология и скиллы лежат вообще ортогонально.

Весьма стремное учебное заведение ;-)

Заводы, пароходы я попробовал. Но всё равно спасибо.

Agile, XP, Scrum, design patterns, OOD
Как-то у вас смешались кони, люди... Если вместо «Agile, XP, Scrum» могут быть другие методологии, но чем плохи «design patterns, OOD»? Разве что в embedded ООП не нужно.
Разве что в embedded ООП не нужно.
Уже давненько нужно ...
Agile, XP, Scrum, design patterns, OOD
Вы так говорите, как будто это что-то плохое.

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

не уложился в спринт — расстрел?

Причем всей команды, если не ошибаюсь.

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

Несколько раз фейлил спринты. Странно, но пока не расстреляли.

Вы показали заказчику что у вас неэффективная команда и только по доброте заказчика вы продолжаете дальше работать.

Там где у нас был полезный и эффективный скрам, спринты фейлились тупо постоянно :-).

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

Притом срок сдачи [конец спринта] и дедлайн — это два РАЗНЫХ срока. Я угадал?

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

Примерно так работает раковая опухоль — учитывая что весь организм полностью неподконтролен, запускается механизм мимикрии любых процессов под продуктивные. ИЧСХ, до самой смерти организации выпилить эти «обходные» пути и «незаменимых» людей уже не выйдет. Убиваться будут как раз самые рискованные процессы.

Но бывает и по-другому. Когда скрам — подчинённый процесс. А основной к примеру на канбанах и прочих высокоуровневых объектах. Тогда скрам — всего лишь объект риск-менеджмента, и кроме всего прочего — не нуждается в сложных управленческих функциях. Его и зафейлить-то нельзя.

Так что же делать? Расстреливать команду за ошибки? Причем, интересно, Скрам выявил ошибку планирования / реализации в течении даже не одного спринта, а пары стендапов, когда стало понятно, что блокер серьезный. «Трезвый» процесс может не выявить таковую и через несколько месяцев. Хотя хороший менеджер, конечно, обратит внимание на то, что что-то идет не так за те же условные пару дней.
Может быть автор темы боится именно такого быстрого выявления проблем? Или что его сделают виноватым и расстреляют?
Дам свой ответ:
Высокая мотивация заставляет стараться не допускать затем подобные ошибки, в том числе и меняя процесс в сторону предупреждения таких ошибок в будущем.. А вот «трезвый» подход предусматривает найти виновного, наказать его или, на крайняк, пожурить. И ничего не поменять. Вот это похоже на раковую опухоль гораздо более.

Мой ответ будет таким: скрам не управляет процессом, а контролирует его, нормирует и загоняет в рамки. Но процесс — так и остаётся старым добрым «пиши-код-бьььь». Хороший скрам — вырожденный скрам. Но даже в вырожденном состоянии, если нет интеграции в вилку качества, это будет самодостаточный процесс.

Как ни странно, скрам ещё более оправдан в вертикальном взаимодействии, чем в горизонтальном. Но... скрам-мастер должен сидеть в самом низу иерархии. Другими словами, верх даёт обещания, низ контролирует исполнение. Как только верх пытается давить на подделку контроля — это сигнал к порождению процедуры планирования (которая при нормальном течении вырождена в обещания).

Фокус такой постановки в том, что система
1) автоматически развивает скорость
2) мешает что-либо сунуть в долгий ящик
3) оставляет контроль над процессом сверху, при легализации власти снизу.
4) внешние перемены незаметны для внутреннего окружения.

Но есть один серьёзнейший недостаток: Пока высшие звенья выполняют свою работу хорошо — никто ничему не учится. Некогда. Реально некогда. И пока гром не грянет. Но как только что-то пошло не так — система разворачивает полюса: верх контролирует, низ даёт обещания. Поскольку низ своих обещаний выполнить не сможет никогда [в противном случае взяли не те кадры] — то система вновь возвращается в стабильное состояние.

Важный момент: все обещания давать письменно, все контроли вести письменно. Малейшее попустительство — и эта неваляшка выродится в вотерфолл.

Физическая модель — вот.

Физическая модель — вот.
Меня часто интересовало: какие наркотики употребляет Александр Пение? :)

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

Вопрос ведь не в том, чтобы повысить скорость разработки у эффективной команды.
Вопрос в том, чтобы вменяемо организовать эту самую работу у не эффективной команды.

Отвечу вопросом на вопрос — а разве не выгоднее построить эффективную команду, чем пинать дохлую лошадь?

И как же вы ее будете строить ?

Это не сверхзадача для менеджера, это каждый сможет;)
«Другых пысателей для товарища такого-то у мэня нет»
© И.В. Сталин.

Действительно, для нормального менеджера — задача вполне тривиальная. Другой вопрос что менеджер — это профессия, а не титул. Я имею в виду не менеджеров по продажам газировки, а как раз менеджеров по менеджменту.

Есть несколько типов программистов (и команд):
1. Хорошие программисты, работают хорошо — их не нужно трогать, просто не мешай.
2. Плохие программисты, работают плохо — в их работе тоже не нужно ничего менять — просто уволь.
3. Хорошие программисты, работают плохо — тут надо найти причину, и устранить её.
4. Плохие программисты, работают хорошо — это хорошие программисты (по крайней мере для этой задачи). Смотри пункт первый.

Вы так много чего из виду упускаете в этом определении, что прям не вериться что вы СТО :-)

А нельзя ли дать Ваше определение плохого программиста?

В моем видении — это разве что clockwatcher (наиболее близкий термин — офисный планктон).
Со всеми остальными можно работать, учитывая конечно соотношение цена/качество усилий, потраченных на их «воспитание».

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

Вписывается или не вписывается в данную задачу и команду, где-то так?

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

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

Самый худший случай — это «глупый трудолюбивый».
«Креативщик велосипедов» или «Бесконечный генератор идей без реализации» не хуже ли будет?
Вашему варианту достаточно лишь более четко поставить задачу.

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

долго рассказывать про «наш вариант», но поверте, пока поставишь НАСТОЛЬКО четко задачу — проще уже самому сделать. Почитайте таки про «итальянскую забастовку» :)

долго рассказывать про «наш вариант», но поверте, пока поставишь НАСТОЛЬКО четко задачу — проще уже самому сделать. Почитайте таки про «итальянскую забастовку» :)
Я знаю термин покруче — Cover Your Back Engineering, CYAE в оригинале;).

А вот поэтому и надо использовать основополагающие принципы, например, декомпозицию. Причем не только в процессе, а еще и на этапе анализа. (это тоже есть во всяких скрамах) А иначе ничто вам не поможет.

Годичный проект для большой команды разложенный по дням на этапе анализа — это фантастика.

А по канбанам — реальность.

Сложная задача это не всегда набор простых задач, иначе ИИ уже давно был бы сделан. А то что вы подразумеваете это не сложная задача, а очень большая задача для одного человека.

Не путайте сложно и трудно и просто и легко. Это раз. Во вторых именно разбиение является сложной задаче. А для новичков еще и трудной.

Разбейте тогда создание человеческого ИИ на подзадачи? Сколько вам спринтов для этого нужно?

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

Никто ж не против декомпозиции но вы ее преподнесли как решение всех проблем что вовсе далеко не так.

Есть. Computer Vison, но там много другой анальной боли. Здесь работа будет похожа на работу под галлюциногенами, так как часто всего ни одна методика из «Agile, XP, Scrum, design patterns, OOD» просто не работает.

Научное программирование такое научное программирование.

Хорошо, вам поставили задачу — написать модуль для сайта чтобы его посещение увеличилось в 1.5 раза. Что из вышеперечисленного будете применять?

Задачу могут поставить «увеличить посещаемость в 1.5 раза» или «написать модуль для сайта».
В вашей постановке еще придется доказывать, что модуль приведет к повышению посещаемости.

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

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

Вам поставлена задача написать данный модуль. Что из вышеперечисленного будете применять?

PS
Именно так ставятся большинство задач в AI и CV.

Задачи в AI/CV ничем не отличаются от других задач, а значит поддаются стандартным методам декомпозиции, планирования и контроля.

а значит поддаются стандартным методам декомпозиции, планирования и контроля.

Вот только решение задач не всегда однозначно. Так у минимум 4 из 5 задач будет в комментариях в jira написано, что данное решение не дало ожидаемого результата, поэтому переходим к реализации задачи № X с описанной другой гипотезой.

В результате имеем, что код есть, работает по ТЗ, но того что нужно просто не делает, тоесть бесполезен.

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

Что тут такого особенного, что применять методологии хуже, чем не применять? Исчезает возможность засесть в засаду в рамках long term project without short term deliverables?

вам поставили задачу — написать модуль для сайта чтобы его посещение увеличилось в 1.5 раза. Что из вышеперечисленного будете применять?
При таком подходе проще счетчик накрутить :)
design patterns, OOD
существуют, но Индия как ни крути очень далеко, хотя ментально очень близка многим разрабочтикам\менеджерам и в нашем государстве, так что у вас не все потеряно.

ну можно например делать сайты на php в квартирной студии, безо всяких там скрамов. или еще какую-нибудь работу с самого дна рынка труда в IT.

То есть получается, что все, кто не юзает

Agile, XP, Scrum
и прочую по*бень, дно?

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

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

Нежелание использовать эффективные практики разработки — это и есть проблема человека.

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

При существующих гибких и даже частично противоречивых подходах, вполне возможно наличие фейла из-за практикуемой методологии. Даже не вполне возможно, а встречается не так уж и редко. Т.е. «нечто — зло» — это вполне обыденное явление, уж в любом случае практикуемая методология — это не панацея и не серебрянная пуля.

Смотрите какая вещь:
Есть люди, у которых по *методология* работать получается.
Есть люди, у которых по *методология* работать НЕ получается.

Почему?

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

Вы забыли уточнить одну вещь (все забывают, не переживайте). Это «зло» для вашей ситуации.

Любая методология имеет границы применения. Если человек бездарно примеяет методологию там, где не следуют — чья это вина?

Любая методология имеет границы применения. Если человек бездарно примеяет методологию там, где не следуют — чья это вина?
Только евангелист данной методологии, но который, не стоит забывать, олицентворяет методотологию.

Методологию,на мой взгляд, олицетворяет человек, который успешно её использует (и именно у этого человека стоит консультироваться по её внедрению).

Успешно использует в одном месте != успешно использует везде. Как показывала практика, если у тебя выстрелил один подход, то это ни о чём не говорит, просто удачно угадал.

Каждая методология имеет свои границы применения.

Как говорит Слава Панкратов, есть 2 типа менеджеров. У одних всегда всё получается (пусть и не без проблем), а у других — плохая методология, плохие сотрудники, заказчики и так далее

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

А почему завалит работу? Работу можно не доделать, или сделать неправильно. А вот завалить можно проект. Менеджер должен вовремя вычислить того, кто не справляется с работой еще во время итераций и заменить слабое звено.

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

Не программисты выбирают методологию. И да, ни один специалист не сможет сделать работу, если ему не скажут что делать. Точнее как, работу то делать они могут, код генерировать. А вот толку от этого не будет.

Это уже на практике проверено.

P.S. Так значит вы к первым относитесь?

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

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

Ну хорошо, рассмотрим ситуацию, что ни одна из методологий Agile не является подходящей для проекта, да и остальные, которые под Agile не встали тоже. Т.е. приходим к начальному тезису — методологии — это «зло» в мире данного проекта. Надо разработать свою методологию, которая будет являться «злом» для всего остального мира. Это понятно, что сферическая методология в вакууме без применения к практике не может быть «злом» или «добром», но без практики она в свою очередь не имеет смысла.

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

Проблема ТС в том, что он не видит леса за деревьями. Не будь agile — манагер все равно бы «кровати двигал»

помню, как-то забивал гвоздь да молотком по пальцам попал.
молоток — зло? надо было сразу «болгарку» брать и пальцы вообще напрочь отчекрыжить?

Для начала можно просто в мясорубку, потому уже по обстоятельствам.

Поддержу. Странно, что никто инструменты строительные не ругает, а только мастера. Прямо чудеса.

Не программисты выбирают методологию.
Категорически не согласен. Мы же не в рабстве живем.
Тот же Скрам подразумевает мотивацию работать по скраму. А мотивация всегда изнутри идет.

Если вы, один программист из 10, начнете работать по инной методологии, то из этого как минимум не будет толку, как максимум — будете только мешать.

Всегда есть работающие способы без создания явного противоречия. От убеждения команды и до хлопанья дверью.
Впрочем, однажды я таки смог именно работать по другому. Я когда-то на одном проекте начал использовать сорс контрол именно вопреки мнению команды. Нет, я никого не заставлял. Я поднял сервер локально и пользовался им единолично. Сначала коллеги крутили у виска пальцем, потом присматривались...
А через месяц им пользовались уже все и начали обсуждать необходимость переноса репозитория на сервер все-таки.

Это все отлично. Но есть ситуации, когда своими подвигами огрехи применяемого подхода не выправишь.

К примеру я не могу исправить огрехи подхода читать только вторую половину сообщения. Ага ;-)

Я когда-то на одном проекте начал использовать сорс контрол именно вопреки мнению команды
А как команда вообще обходилась без репозитория? Ходили к друг другу с флешками, спрашивали, что что изменял, а потом мерджили? :)

Сейчас использование контроля версий воспринимается как обязательная часть работы, а его отсутствие просто немыслимо. А ведь всего десяток лет назад находились люди, похожие на топиккастера.
Там на самом деле очень курьезная ситуация была. Мы были аутсорсеры, а у заказчика был VSS шестой, кажется, через VPN, и была там засада, что все отваливалось по таймауту. Приходилось высылать код мылом и там уже код мержили. Маразм, тот еще.
После введения на нашей стороне Subversion мы все еще высылали еженедельно код, но делали сразу общий срез.
Шикарный пример «трезвой работы», в общем.

> чья это вина?
Только евангелист данной методологии, но который, не стоит забывать, олицентворяет методотологию.
А как же люди? Овцы безмолвные?!

А причём тут люди?

При том, что процесс — это люди, которые его понимают и придерживаются. Без этого только командно-палочная система. А там еще хоть скрамом назови, хоть ватерфоллом, хоть цирком, все равно у вас армия получится. Причем австро-венгерского образца, с офицером, муштрой, наказаниями, при которой организационные вопросы решаются формулировкой «А причём тут люди?»

При том, что процесс — это люди, которые его понимают и придерживаются.
Людям, которые всё понимают — процесс не нужен.

Нужен. Называется самоорганизация и упрощение рутинных действий. А еще люди забывают. Да, да, даже лучшие из нас иногда что-то забывают или упускают из виду.
Где-то как со светофором. Можно и без них обойтись — есть такой опыт городке в Западной Европе. Но с ними — проще.

В людях искать надо не проблему, а возможности. Или вам виноватых найти надо, а не продукт сделать?

Или вам виноватых найти надо
При чем здесь это вообще? Смысл в том, что не методология определяет конечный результат, а люди. Если подбор команды правильный, то все эти свистоперделки ни к чему и можно вполне обойтись «правилами» здравого смысла.

Так и есть. Вот только правильность подбора команды можно определить очень не сразу. Обычно после завершения или провала проекта.
Интересно, что так же и про процесс можно сказать. В том смысле, что если процесс правильный, то корректировка в сторону правильной команды происходит автоматически.

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

Да проекты ж какбы разные бывают.
Гдето водопад или какойнить руп будут работать гораздо лутше чем всякие скрамы.
Известный пример: www.fastcompany.com/...ite-right-stuff

Боюсь, что РУП сломает мозги получше скрама. Я бы РУП со всеми его обязательными «проектными артефактами» послал бы очень далеко.

Подписаться на комментарии