Comments 18
Как однажды затянутый в секту - подписываюсь под каждым словом. Но мне повезло , я вырвался .
Про "waterfall" - в самую точку . Их реально корежить начинает.
Первые сомнения появились когда в ответ на вопрос "когда мы начнем заниматься нагрузочным тестированием и оптимизацией производительности ?" , я получил ответ product owner - "а это не наша задача , не по аджайл, этим будет другая команда сопровождения заниматься. Наша задача закрыть спринты и передать продукт в эксплуатацию".
А потом они просто взяли и перешли на ORM полностью похерив предыдущую модель "бизнес логика в СУБД". Зато , я вырвался из секты .
В результате имеем то, что имеем - в ходе реализации импортозамещения 100% продуктов созданных по самым передовым методикам имеют 100% проблем как только передаются в опытную эксплуатацию. И всегда "ой у нас все тормозит".
я получил ответ product owner - "а это не наша задача
Вот, в этом месте проблема. Product owner обязан быть заинтересован в работе всего проекта в целом, а не спринты закрывать.
Ну получается эта проблема у ВСЕХ product owners из тех , чти продукты потом приходится сопровождать . Я не знаю , как положено по agile, я повторюсь вышел из секты.
Та тема и продукт который я веду, классический waterfall - Я якудза старой школы.
Ну получается эта проблема у ВСЕХ product owners из тех , чти продукты потом приходится сопровождать
Да нет, это проблема в том, что аджайл и в частности скрам натягивают на весь процесс разработки. Хотя в нем самом практически черным по белому написано, что это методология для программистов. Опять же, разные методологии подходят под разные задачи - глупо пытаться для всего использовать единую методику как универсальное решение.
Продакт должен быть вне Ажаль
Продакт это стратег
Продакт должен быть вне Ажаль
Вот так новость !
BTW, просто любопытно , вопрос от не знатока agile - а вообще , мероприятия performance test -> tuning -> improvement предусмотрены методологией ?
Или , как я понял - разработка отдельно, сопровождение и развитие отдельно ?
Судя по всему , второе, наверное больше половины проблем с производительностью можно было бы избежать, если бы об этом подумали на этапе дизайна и разработки и если бы нагрузочное тестирование проводилось на этапе разработки.
Вопрос к постановке требований и постановке процесса управления качеством. В частности, формулировка требований качества, процесс улучшения качества, баланс цена/качество.
постановке процесса управления качеством.
Когда то давным давно , когда я работал в одном банке, разработчики одной информационной системы, тогда это называлось "Опердень банка", очень часть употребляли стандартный рекламный слоган - "Наша система лучшая по соотношению цена-качество".
Мы в ответ, громко смеялись - "ребята это банк, тут деньги считают, качество должно быть МАКСИМАЛЬНЫМ. Ошибок, округлений, приближений, потерь данных не может быть В ПРИНЦИПЕ".
Не бывает осетрины второй свежести. Свежесть осетрины только первая, она же и последняя(c).
"Опердень банка"
Даже не знаю - ржать, или молча восхищаться.
Вы наверное и не застали времена когда "Опердень банка" писали на Access.
И оно работало.
Но недолго .
Потом пришел DBase работать стал дольше.
И только потом , пришел Оракл .
Я далек от этих техническиих подробностей.
Восхищен игрой слов от смены интерпретации первого слова названия: аббревиатура --> отглагольное существительное.
Точнее осознанием что это втюхали (почти) на серьезных щах, суровым толстомордым дядям, во времена когда кушать было еще не сильно сладко, но уже негарантированно.
а вообще , мероприятия performance test -> tuning -> improvement предусмотрены методологией ?
Технически - да. Так как один из концептов Аджайла - Постоянное совершенствование через регулярную обратную связь.
Фактически же.. очень и очень по-разному. Ибо другие принципы аджайла, как-то:
"Люди и взаимодействие важнее, чем инструменты и процессы.", "Рабочий продукт важнее документации" могут входить в противоречие с задачей выше.
Опять же, описанный выше процесс куда лучше накладывается на Канбан.
Ну и если утрировать, то аджайл почти идеальный инструмент на R&D, когда приходит клиент, хочет странного, но сам толком не может сказать чего именно. Вот тут подход спринтов с демонстрацией промежуточного результата и перекраиванием планов на ретро отлично себя показывает. Главное не прозевать момент когда проект из этих рамок вышел уже.
Спасибо за комментарий.
В общем то было понятно по жизни
В результате имеем то, что имеем - в ходе реализации импортозамещения 100% продуктов созданных по самым передовым методикам имеют 100% проблем как только передаются в опытную эксплуатацию. И всегда "ой у нас все тормозит".
"Люди и взаимодействие важнее, чем инструменты и процессы.", "Рабочий продукт важнее документации"
Эти два постулата лично меня всегда особенно веселили :-)
Фигня война , главное - маневры ;-)
аджайл почти идеальный инструмент на R&D, когда приходит клиент,
В моем случае все информационные системы это Business2Business.
Клиента как такового нет, есть бюджет, максимально размытый и непонятный ТР и так далее.
Пользователь приглашён сегодня в 08:15.
Статья написана сегодня в 08:15.
Т.е. автор специально зарегистрировался, чтоб написать этот искромётный (нет) опус.
три дня я гналась за вами, чтоб сказать, как вы мне безразличны!
В тему же приведённых автором аналогий с религией можно ответить классиком:
Любая достаточно развитая технология неотличима от магии
Когда не знаешь (не понимаешь), как это работает - оно выглядит религией. А когда понимаешь - просто берёшь полезное, откидывая лишнее.
А ныть на эджайл перестало быть модно ещё лет 5-7 назад.
Демонстрация того, что в упрощенном, вульгарном, представлении и методологии, и традиции выглядят одинаково.
Уже после написания статьи я провел небольшой гуглёж и нашел первое упоминание Свидетелей Аджайла в этом комментарии https://habr.com/ru/companies/quadcode/articles/578080/comments/#comment_23486460. Увы, не я творец этого прекрасного названия.
Свидетели Аджайла