Из минусов, ничего не сказано про то, что гит и руть это слепочные системы контроля версий, а svn файловая. Отсюда у них принципиальна разный подход к изменениям.
Что еще, для просмотра изменений и мержа обычно используются специализированные утилиты, например kdif3
Ну есть нормы работы в респираторах, два часа потом перерыв 10 минут без респиратора.
Насколько я понимаю это самые суровые ограничения. В большинстве случаев меньше, но и работа там другая тяжелая.
У вас получилось круто визуализировать задачи и создать доску. Молодцы! Просто классическая прото канбан доска :) Респект!
Но скажу страшно крамольную мысль, то что вы сделали, к Канбан-методу относиться крайне слабо :) Он совсем не про это, он про улучшение процессов, и да для канбана доска не важна :)
За весь кровавый не скажу. Но обычно. Глубины около месяца хватает. Самое важное это после релиза. Плюс уровень логирования то же должен меняться динамически
Ну как бы и Java не умеет работать с гитом :)
А так, нет там сложности с интеграцией.
PL/SQL Developer и Oracle SQL Developer умеют работать с git. В конце концов можно и файлы сохранять.
Для дистрибутива лучше использовать ликвид.
Не, норм все. Весь вопрос в процессе
Я долго занимался разработкой на pl/sql. Все выше это не проблемы языка. Можно все то же самое сказать про любой язык программирования. Это проблема организации процесса разработки.
И код пере использовали и делали апи для вызова заказчиками. Много чего было сделано и работает очень хорошо.
Все так! Очень приятно, что разработка на PL/SQL не умерла!
От себя, я бы подумал использовать systimestamp вместо sysdate.
Штука полезная, благодаря ей в свое время благодаря этому находили странные ошибки
Качество не зависит от непосредственного исполнителя?
Ну вот совсем не зависит? Как руководство захочет, так и будет? Главное только захотеть?
Вот представь себе, да! И только руководство за это несет ответственность. Я понимаю это неприятный и очень болезненный факт, но когда то надо прощаться с иллюзиями.
И в руководстве бейзкампа это хорошо понимают! Перенимайте лучшие практики!
Приведу пример, в тексте:
Если каждая задача возвращается после тестирования или при починке одного бага всплывает три новых, то с качеством что-то не так.
Это не с качеством, что то не так. Это было принято положить болт на атрибут качества сопровождаемость. Это вы так бюджет распределили. И вполне возможно, что для вашего этого контекста норм. Но опять же это решение руководства, а не разработчика и тестировщика, они не решают куда вкладывать бюджет проекта, а куда нет.
1.Выполнение заранее составленных требований — не самоцель. Важнее сделать «классный» продукт в результате.
Если на входе мусор, на выходе биг дата. Разберитесь с требованиями. Перестаньте из них делать мусор и экономить на этом.
2.Пользовательский опыт важен.
См. пункт 1.
3.Уровень качества задаётся при разработке. Тратя усилия на компенсацию разработки тестированием, мы лишаем себя возможности направить эти усилия на развитие разработки и, как следствие, качества.
Уровень качества задается только руководством компани. Ни разработчик ни тем более тестировщик не способны ничего с этим сделать.
4.Тестирование — бонус, улучшающий систему, а не критическая необходимость.
Это верификация и валидация на соответствия требованиям. См. пункт 1.
Вы не стали зарабатывать больше денег. Да вы сократили ТТМ, но это не принесло вам увеличение дохода.
Вы не сократили накладные расходы. Вы делаете регрес быстрее, но вы уменьшили команду. Да вы высвободили 3 дня работы, но не превратили это в деньги.
Теперь домыслы. То что вы от масштабировались без простоев, ну это хорошо конечно, но я не знаю, может простои и никак не сказываться на доходах вашей компании.
Я пока не вижу окупаемости…
Вам в плюс, вы смогли наладить крос взаимодействие, но это можно сделать все дешевле.
Что еще, для просмотра изменений и мержа обычно используются специализированные утилиты, например kdif3
Насколько я понимаю это самые суровые ограничения. В большинстве случаев меньше, но и работа там другая тяжелая.
Да, я практикующий канбан-практик, не проблема, пиши в личку, поговорим про канбан-метод.
На русский канбан переводится по всякому, например вижу все и вижу далеко.
Канбан методология заточенная на улучшение процессов и только. Доска вообще не важна, можно без нее, хочется с ней то ок.
Не надо путать канбан для материального производства — он же tps или 6 сигм.
И Канбан-метод для IT это ооочень разные вещи.
Но скажу страшно крамольную мысль, то что вы сделали, к Канбан-методу относиться крайне слабо :) Он совсем не про это, он про улучшение процессов, и да для канбана доска не важна :)
Дорого: www.gitora.com
А так, нет там сложности с интеграцией.
PL/SQL Developer и Oracle SQL Developer умеют работать с git. В конце концов можно и файлы сохранять.
Для дистрибутива лучше использовать ликвид.
Не, норм все. Весь вопрос в процессе
И код пере использовали и делали апи для вызова заказчиками. Много чего было сделано и работает очень хорошо.
От себя, я бы подумал использовать systimestamp вместо sysdate.
Штука полезная, благодаря ей в свое время благодаря этому находили странные ошибки
Вот представь себе, да! И только руководство за это несет ответственность. Я понимаю это неприятный и очень болезненный факт, но когда то надо прощаться с иллюзиями.
И в руководстве бейзкампа это хорошо понимают! Перенимайте лучшие практики!
Приведу пример, в тексте:
Это не с качеством, что то не так. Это было принято положить болт на атрибут качества сопровождаемость. Это вы так бюджет распределили. И вполне возможно, что для вашего этого контекста норм. Но опять же это решение руководства, а не разработчика и тестировщика, они не решают куда вкладывать бюджет проекта, а куда нет.
Если на входе мусор, на выходе биг дата. Разберитесь с требованиями. Перестаньте из них делать мусор и экономить на этом.
См. пункт 1.
Уровень качества задается только руководством компани. Ни разработчик ни тем более тестировщик не способны ничего с этим сделать.
Это верификация и валидация на соответствия требованиям. См. пункт 1.
Теперь домыслы. То что вы от масштабировались без простоев, ну это хорошо конечно, но я не знаю, может простои и никак не сказываться на доходах вашей компании.
Я пока не вижу окупаемости…
Вам в плюс, вы смогли наладить крос взаимодействие, но это можно сделать все дешевле.
Почитать, подумать: habr.com/ru/post/508672