Здравствуйте, turbocode, Вы писали:
T>>>Поменялась архитектура (не все учли) что в таком случае делает скрам-мастер? L>>А ты точно уверен, что понимаешь, что такое скрам и какая роль у скрам мастера? L>>С прищуром T>А ты точно скрам-мастер?
T>>>>Поменялась архитектура (не все учли) что в таком случае делает скрам-мастер? L>>>А ты точно уверен, что понимаешь, что такое скрам и какая роль у скрам мастера? L>>>С прищуром T>>А ты точно скрам-мастер?
L>То есть не понимаешь. В общем, как я и думал
У тебя роль свадебного генерала на проекте? Тогда понятно почему изменение архитектуры ставит тебя в тупик.
Или гибкие методологии разработки ПО сегодня не учитывают изменение архитектуры на проекте? Тогда какие они нахрен гибкие?
Здравствуйте, turbocode, Вы писали:
T>У тебя роль свадебного генерала на проекте? Тогда понятно почему изменение архитектуры ставит тебя в тупик.
Переход на личности, слив защитан.
T>Или гибкие методологии разработки ПО сегодня не учитывают изменение архитектуры на проекте? Тогда какие они нахрен гибкие?
Рекомендую все же почитать что-то про скрам. В частности, следует поподробнее почитать о роли скрам мастера и emergency процедуре.
Ежедневное изменение архитектуры есть бардак и указывает на полную некомпетентность лиц, принимающих решения.
Вне зависимости от подхода к разработке.
L>Ежедневное изменение архитектуры есть бардак и указывает на полную некомпетентность лиц, принимающих решения. L>Вне зависимости от подхода к разработке.
Не обязательно ежедневное, можно поставить еженедельное, ежемесячное. Суть одна — архитектура поменялась. Что делает скрам-мастер в таком случае?
Бизнес осознал что вчера/на прошлой неделе/прошлом месяце напорол фигни, нужно делать по новому. А новое не совсем вписывается в старое.
Зачем делать в текущем спринте то что уже больше не нужно?
Здравствуйте, IncremenTop, Вы писали:
IT>Собственно вопрос, куда податься от этого цирка уродства?
Открывай компанию и делай свой продукт где всё будет по феншую.
Здравствуйте, turbocode, Вы писали:
L>>Такой стартап закапывать можно сразу. T>Ты не модный это Scrum.
Как ловко подменил понятия и затролил собеседника.
Здравствуйте, turbocode, Вы писали:
L>>Ежедневное изменение архитектуры есть бардак и указывает на полную некомпетентность лиц, принимающих решения. L>>Вне зависимости от подхода к разработке. T>Не обязательно ежедневное, можно поставить еженедельное, ежемесячное. Суть одна — архитектура поменялась. Что делает скрам-мастер в таком случае?
Суть в том, что архитектура изначально должна предусматривать определенную гибкость. И изменение хотелок бизнеса или приоритетов не должно приводить к необходимости ее изменения. Не благодари.
(Я предполагаю что под понятием "архитектура" мы видим одно и то же. Если ты изменением архитектуры называешь добавление параметра в функцию, то у меня для тебя есть две новости)
T>Бизнес осознал что вчера/на прошлой неделе/прошлом месяце напорол фигни, нужно делать по новому. А новое не совсем вписывается в старое.
Если бизнес решил вместо трамваев производить носки, то возникает вопрос — как вообще в таком бардаке мог появиться скрам мастер?
Во всех остальных случаях процесс ставится именно так, чтобы подстраиваться под требования бизнеса.
T>Зачем делать в текущем спринте то что уже больше не нужно?
Хинт — а в следующем спринте выясняется, что все-таки было нужно. Дальше продолжать, или все же почитаешь про скрам?
L>Суть в том, что архитектура изначально должна предусматривать определенную гибкость.
Например? А если эта гибкость затянет лишний месяц(ы) разработки? Заказчик не обрадуется платить за какую то мифическую гибкость.
L>И изменение хотелок бизнеса или приоритетов не должно приводить к необходимости ее изменения.
Что это у тебя за гибкие методологии разработки ПО такие, которые не позволяют делать изменения?
Здравствуйте, IncremenTop, Вы писали:
IT>Собственно вопрос, куда податься от этого цирка уродства?
Напиши сам успешный продукт и отдай его на поддержку нанятым программистам
Здравствуйте, turbocode, Вы писали:
L>>Суть в том, что архитектура изначально должна предусматривать определенную гибкость. T>Например? А если эта гибкость затянет лишний месяц(ы) разработки? Заказчик не обрадуется платить за какую то мифическую гибкость.
А если наоборот?
Все можно сделать двумя способами — правильно и через жопу. Ты за какой способ?
L>>И изменение хотелок бизнеса или приоритетов не должно приводить к необходимости ее изменения. T>Что это у тебя за гибкие методологии разработки ПО такие, которые не позволяют делать изменения?
Не "не повзоляют", а "отвечают изменяющимся требованиям бизнеса". Почувствуй разницу (с).
Здравствуйте, turbocode, Вы писали:
L>>Все можно сделать двумя способами — правильно и через жопу. Ты за какой способ? T>Это как спросить: вы за мир или за войну? Все за мир, но реальность другая и войну не отменяет.
Иными словами, ты привык создавать ядерную войну по ничтожному поводу...
L>>>Все можно сделать двумя способами — правильно и через жопу. Ты за какой способ? T>>Это как спросить: вы за мир или за войну? Все за мир, но реальность другая и войну не отменяет. L>Иными словами, ты привык создавать ядерную войну по ничтожному поводу...
Причем я?
Ты можешь выбрать делать правильно долго и дорого, а заказчик выбрать делать дешево и быстро. Но так как деньги платит заказчик поэтому ему решать c кем работать.
Здравствуйте, turbocode, Вы писали:
L>>Иными словами, ты привык создавать ядерную войну по ничтожному поводу... T>Причем я? T>Ты можешь выбрать делать правильно долго и дорого,
Я делаю быстро и правильно.
А вот твоя рефлексия как бы намекает, как делаешь ты
Здравствуйте, DiPaolo, Вы писали:
DP>Не нравится этим заниматься — не беретесь за такую работу.
Вот и спросил выше — как меньше на такую работу попадать. Может область сменить?
DP>Научить, подсказать, передать опыт, если авторы работают вместе. Кстати, где гарантия, что Вы сам не "зелененький", и глядя на Ваш код люди не ужасаются?
Может быть, но на практике они в этом коде могут исправить багофичу за разумное время, что в процессе работы подтверждалось. Кстати, я не перфекционист и в данном случае говнокодом называю истинный говнокод.
IT>Вот и спросил выше — как меньше на такую работу попадать. Может область сменить?
Нет универсального решение. В качестве вариантов:
Каким-то образом заранее оценивать качество кода. Например, попросить прислать какой-то кусок.
В случае, если есть основания полагать, что код некачественный, вводить коэффициент для стоимости своей работы.
Продавать услуги рефакторинга за отдельную плату. При этом предварительно объяснив, чем это выгодно клиенту. Если весомых аргументов не найдется, значит это не так уж важно -> забить, смириться или искать другой выход.
P>Однажды в подобной ситуации разработчики обратились к руководителю проекта с вопросом: а как же качество кода? Ответом было: вы в какой реальности находитесь? Ваша гланая задача — выдавать в срок запланированные фичи.
Здравствуйте, IncremenTop, Вы писали:
IT>Ощущаю себя регулярно последние годы ассенизатором — количество говнокода от зеленых человечков просто запредельное. Т.е. зачастую человек написал проект для кого-то и потом нанимает других(в т.ч. меня) править его багофичи в его говнокоде. Последней каплей терпения стал класс на 6к строчек кода. И он не один такой терминатор (целая армия апокалипсиса) в этом творении из говна и палок. Когда-то я считал, что за вызовы бд из обработчиков UI надо убивать, но теперь даже это кажется не таким злом.
IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким? Где это наилучшим образом оплачивается?
Хуже говнкодера только говнокодер, который еще тебя же пытается учить, как правильно.
недавно работал с таким. он думал, что надо обязательно код из одной функции поразмазывать по другим функция, потому как "слишком большие". Ага, аж 10 строчек. И еще менял учил говнокодить в таком же стиле -- "да ты не бойся, мы так уже делали в другой команде".
