Чур меня

нормально ли делать локализацию при помощи xml?

Как-то не очень

Но если потом распрасить этот файл и загрузить в бд, то почему бы и нет

Но если потом распрасить этот файл и загрузить в бд, то почему бы и нет

а потом доставать локаль из бд?

Ну это уже вопрос программирования и возможны тыщи вариантов

Ну это уже вопрос программирования и возможны тыщи вариантов

ну раз ты говоришь распарсить и в бд

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

ну раз ты говоришь распарсить и в бд

что потом, тупо любоватся на нее чтоли?

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

хотя можно в редис...да

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

а дорогущий vds для стартапа брать не выгодно

у, там мемчачед есть ?

а с канбаном выстроенным гуру никто не работает?

Гуру в канбан не хотят

Гуру в канбан не хотят

почему?

В основном потому что непонятны временные рамки. Ну э

Это из моей практики, все кто гуру - приходят к тому что без спринтов это не работает

во всяком случае в коммерческой разработке

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

Сам активно интересуюсь как эфффективно работать по канбан, если найдется гуру - с удовольствием послушаю.

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

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

на релизы то это напрямую не влияет

как можно выполнить задачи в спринт если ты их не оценил ;)

оценивает спринт мастер

назначает балыл в попугаях

*баллы

есть разрабы Вася, Иван и Петя

спринт мастер знает что Вася за неделю делает 120 баллов, Иван 150, а Петя 80. Накидывает в спринт задач на 350 баллов

в канбане нет такого

и надеется что все пройдет гладко

в канбане нет такого

в канбане взял задачу и делаешь

и делаешь и делаешь пока свет клином не сойдется

=)

берешь и уже сделал пол работы.... пока скрам все еще в покер играет :)

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

Ну это ты в идеальном мире

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

ну не ты один над задачей работаешь в канбане по идее... это вот то, что я понять хочу

Скрам это жесткий менеджмент, а менеджмент это сложно.

в этих системах задачи в теории надо бить чтобы ты один работал

и чтобы закрыть мог в течение 8 часов

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

это лажа, ежедневный стендап в канбане не отменяется

если задача больше 16 часов - это плохая постановка. Надо бить

это лажа, ежедневный стендап в канбане не отменяется

Это полная лажа. Он и зп получал )

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

и опять же... если верить источникам, то WIP должен быть меньше чем число разработчиков...

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

потмоу что можно и два месяца говорить что "высокая степень готовности"

я утрирую

в общем всех успешных кого я встречал - это спринты

и работа летит со скоростью паровоза

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

но на практике непонятно что делать, ведь из теста почти всегда задача возвращается на допил

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

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

"в работе", и предлагается даже меньше, чем разработчиков

почему меньше

но на практике непонятно что делать, ведь из теста почти всегда задача возвращается на допил

они уходят в очередь, откуда берутся в работу

то есть закрывать чужие баги?

Я работал в таком режиме. В принципе норм, но баг на баге и багом погоняет в итоге.

и это норма (ц)

почему меньше

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

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

фиг конечно знает как ты можешь это администрировать. Задачи надо разбивать хотя бы формально. Типа part 1 / 3 задача Х.

то есть закрывать чужие баги?

так а в скраме иначе что ли...

ERROR: S client not available

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

В скраме возвращается автору

фиг конечно знает как ты можешь это администрировать. Задачи надо разбивать хотя бы формально. Типа part 1 / 3 задача Х.

ну предполагается, что это делают когда берут задачу в работу

Ещё было дело, что спринты делили по командам

ну это можно было сказать канбан

в команде тимлид и 8 разрабов

тимлид выдавал задачи исполнителям

и формировал подкоманды для работы над одной задачей

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

ну тоже хреново, тимлил заснул и все кукуют

Да, так и было

Но опять же это менеджмент

а тимлида просто тыкнули пальцем - ты тимлид теперь

теперь 8 чел тебе будут трахать голову, а програмить тебе надо столько же )

и тут кто как кстати, некоторые хорошо справлялись, а некоторые просто ушли в игнор

а скрам слишком много требует для внедрения

да, но и многое дает

но опять же с плохзой командой он ничего не даст

но если у тебя 20 программистов, из которых 5 - пинают куи, то это не только потеря бабла на их зп, это ещё и тормоза развития, от этого стрессуют инвесторы

когда бизнес готов ждать итерацию до внедрения фичи...

я в таком не работал, который не готов

неделя - это очень хорошо

обычно от заказа фичи до релиза месяц

неделя + ибо еще тестирование и деплой

ещё бизнес аналитик неделя перед тем как она придет

но срочные задачи за неделю закрывали

хотфиксами занималась отдельная маленькая команда

но они в основном баг на баге залатывали новым багом поверху

кстати заказчику насрать на баги и вообще на все =) Не знаю, это особенность русских заказчиков или все такие.

ну вот не хочется выделять отдельных людей на быстрые фиксы...

они были в супорте

на отдельном оутсорсе