Знаю пары, которые всегда при неудобных разговорах прикрываются второй половинкой («муж перепутал, вы уж извините», «жена цену назвала, давайте подумаем»), так что для меня ваш пример совсем не показательный.
На первый взгляд — нет такого правила, что mvp за 4 недели. Кроме того, рефакторинг и архитектуру вообще можно вынести за mvp и делать только если прототип окажется кому-то нужен. Тут правда всплывает другой тонкий момент — руководство захочет пускать в прод как есть и надо быть готовым отстоять время на приведение кода в порядок.
Это пример того, как не разобраться и сделать криво, а не скрам не работает. Что в случае вашей организации мешало отдельным командам выбирать длину спринта индивидуально и делать демо только когда нужно? Ну и включать голову и адаптировать процессы. Если так подумать, многие правильные но хайповые идеи не работают, так как их внедряют абы как и потом страдают.
Все поля, которые выбираются, должны присутствовать в group by секции.
Для запроса «select f1, f2 from t group by f1» будет так: Postgre ругнётся, а MySQL сгруппирует по f1, и для f2 вернёт первое значение. Поскольку порядок возвращаемых строк неопределён и зависит от стратегии выборки, то может получиться что значение f2 будет разным при разных вызовах, что не очень-то и хорошо.
А каким образом QA, который не написал ни строчки кода, может гарантировать качество этого самого кода? Он может только констатировать его качество. Иначе у вас получается, что во всех сырых продуктах виноват QA отдел.
Цитата из книги Джеймса Баха Lessons Learned in Software Testing:
It’s all too easy to think of yourself as the guardian of quality. But you [QA] don’t create quality, and you don’t take it away. [...] Quality comes from the people who build the product, and that is sometimes a heavy burden for them to bear.
То есть, если
— в среду разработчик Роман отдал код на проверку
— в четверг QA Кузьмич нашёл кучу багов
— в пятницу релиз и ничего не исправлено и не перетестировано,
то за качество продукта отвечает QA? Нет, по уму он в данной ситуации QA даёт информацию о качестве ПО главному на проекте, который должен принять решение о релизе или переносе оного.
Я прокручиваю колёсико средним пальцем, его удобнее перемещать с правой кнопки мыши. ИМХО, идея хороша как разминка для программиста (в смысле — нераспространённая задача заставит призадуматься) но плоха как интерфейсное решение.
Потому что уже сейчас есть игры размером за 40 Гб. Сомнительно, что флешка такого объёма будут стоить сопоставимо с DVD болванкой, даже через 2 года. Ну и многие просто смотрят кино с DVD\Bluray.
Если не секрет, какие были причины смены SQL сервера? Я человек в базах не сильно сведущий, Postgre даёт значительный прирост производительности или что-то ещё?
Например, если корпоративная почта на базе Gmail, ваш почтовый ящик закрывают, а хочется по каким-то причинам, да хоть и на память, сохранить переписку.
Читать я эту почту не буду с вероятностью 99,9%, но приятно знать что всегда можно разворошить архивы и найти описание того самого забавного бага :)
Наверняка в комментариях к этим топикам были высказаны сходные мысли, но всё равно напишу.
Всегда есть реальные условия, которые определяют и язык разработки в том числе, и тут PHP на коне — и хостинги, и CMS, и что хочешь. Но при этом всегда стоит стремиться к лучшему. Вспомните, как ещё совсем недавно многие и ООП не воспринимали и говорили «А что мне, я на Delphi формочки накидаю.»
В PHP действительно есть немало странных идеологических решений, которые «воспитывают» программистов с мыслью, что так и должно быть и это нормально; но если пропагандировать правильные подходы в программировании и правильные ЯП, которые заставляют писать код верно, то вся IT индустрия от этого только выиграет.
А говорить что «мы привыкли» и «фигня конечно, но ведь всегда так было» — это средневековье и закостенелость :)
Знаю пары, которые всегда при неудобных разговорах прикрываются второй половинкой («муж перепутал, вы уж извините», «жена цену назвала, давайте подумаем»), так что для меня ваш пример совсем не показательный.
На первый взгляд — нет такого правила, что mvp за 4 недели. Кроме того, рефакторинг и архитектуру вообще можно вынести за mvp и делать только если прототип окажется кому-то нужен. Тут правда всплывает другой тонкий момент — руководство захочет пускать в прод как есть и надо быть готовым отстоять время на приведение кода в порядок.
Это пример того, как не разобраться и сделать криво, а не скрам не работает. Что в случае вашей организации мешало отдельным командам выбирать длину спринта индивидуально и делать демо только когда нужно? Ну и включать голову и адаптировать процессы. Если так подумать, многие правильные но хайповые идеи не работают, так как их внедряют абы как и потом страдают.
Для запроса «select f1, f2 from t group by f1» будет так: Postgre ругнётся, а MySQL сгруппирует по f1, и для f2 вернёт первое значение. Поскольку порядок возвращаемых строк неопределён и зависит от стратегии выборки, то может получиться что значение f2 будет разным при разных вызовах, что не очень-то и хорошо.
5. Monopoly (Монополия)
6. Scrabble (Эрудит)
7. Pente (Pente — классическая абстрактная стратегия из семейства «N в ряд»)
8. The Settlers of Catan (Колонизаторы)
9. Puerto Rico (Пуэрто-Рико)
10. Ticket to Ride (Билет на поезд)
11. Carcassonne (Каркассон)
12. Catan: The Card Game (Колонизаторы: Быстрая карточная игра)
13. Munchkin (Манчкин)
14. Contract Bridge (Бридж)
15. Arkham Horror (Ужас Аркхема)
16. Nuclear War (Ядерная война)
17. Paranoia (Troubleshooters) (Паранойя)
18. Call of Cthulhu (Зов Ктулху)
19. The Logic Puzzles of Nikoli (Группа логических загадки, таких как судоку, филломино и др.)
20. Crossword Puzzles (Кроссворды)
It’s all too easy to think of yourself as the guardian of quality. But you [QA] don’t create quality, and you don’t take it away. [...] Quality comes from the people who build the product, and that is sometimes a heavy burden for them to bear.
То есть, если
— в среду разработчик Роман отдал код на проверку
— в четверг QA Кузьмич нашёл кучу багов
— в пятницу релиз и ничего не исправлено и не перетестировано,
то за качество продукта отвечает QA? Нет, по уму он в данной ситуации QA даёт информацию о качестве ПО главному на проекте, который должен принять решение о релизе или переносе оного.
Читать я эту почту не буду с вероятностью 99,9%, но приятно знать что всегда можно разворошить архивы и найти описание того самого забавного бага :)
Всегда есть реальные условия, которые определяют и язык разработки в том числе, и тут PHP на коне — и хостинги, и CMS, и что хочешь. Но при этом всегда стоит стремиться к лучшему. Вспомните, как ещё совсем недавно многие и ООП не воспринимали и говорили «А что мне, я на Delphi формочки накидаю.»
В PHP действительно есть немало странных идеологических решений, которые «воспитывают» программистов с мыслью, что так и должно быть и это нормально; но если пропагандировать правильные подходы в программировании и правильные ЯП, которые заставляют писать код верно, то вся IT индустрия от этого только выиграет.
А говорить что «мы привыкли» и «фигня конечно, но ведь всегда так было» — это средневековье и закостенелость :)