Ровно сегодня хотел пересесть на что-то более быстрое и качественное, ваша стать попалась первой и больше других статей читать не понадобилось, ибо благодаря вам – решение выбрал. Через буквально полчаса после прочтения статьи уже все настроил и радовался как дебил)
Она самая) У нас нет иллюзий по поводу данного подхода, классические методы организации безопасности (в том числе операционная) – это обязательная часть разработки, плюс, без них абсолютно бессмысленны любые идеи, которые я описал в статье.
При этом подход, который я описал, еще хорош тем, что это относительно дешевые с точки зрения разработки методы. А для заказчика – это всегда приятный бонус, так как вопросы конфидениальности и безопасности для них – очень остро стоят, и даже такие вещи воспринимаются очень позитивно.
Ну и чисто необъективная и эмоциональная штука: это просто весело и прикольно, когда владеешь подобной штукой с подобными секретиками) Это как шкатулка с секретом – всегда ее можно разбить и вытащить содержимое, но все равно испытываешь пиетет.
Это значит, что я пока еще плохо доношу свои мысли) Спасибо за коммент, буду стараться улучшать этот момент в своих статьях. Категорически согласен с тем, что истина где-то посередине.
На самом деле я не считаю, что нужно месяц писать документацию, еще месяц проектировать и т.д.. Я говорю о том, что не нужно уходить в крайности.
Первая крайность – вообще не планировать и забить болт на все. Вторая – делать идеально продуманный продукт по вотерфолу.
В первом случае может выйти биоразложимое нечто, во втором – очень красивая никому не нужная штука с кучей конкурентов.
Основной посыл – делать нужно быстро, но для того, чтобы делать быстро, нужно знать, где и какие углы срезать.
Более того, суть эджайл не про скорость разработки, а про скорость доставки ценности. И вот люди постоянно неправильно интерпретируют суть подхода, называя говнокод – «эджайл-подходом».
Я сторонник именно такого подхода) Единственное исключение, где я лично себе даю добро отказываться от каких-то этапов – это если мы с командой и заказчиком как минимум год вместе работаем, запустили парочку пилотов и в целом нашли общий язык и понимание. В любом другом случае – лучше не перепрыгивать.
Очень круто, спасибо!
Ровно сегодня хотел пересесть на что-то более быстрое и качественное, ваша стать попалась первой и больше других статей читать не понадобилось, ибо благодаря вам – решение выбрал. Через буквально полчаса после прочтения статьи уже все настроил и радовался как дебил)
Так что, спасибо за топовую статью!
Она самая) У нас нет иллюзий по поводу данного подхода, классические методы организации безопасности (в том числе операционная) – это обязательная часть разработки, плюс, без них абсолютно бессмысленны любые идеи, которые я описал в статье.
При этом подход, который я описал, еще хорош тем, что это относительно дешевые с точки зрения разработки методы. А для заказчика – это всегда приятный бонус, так как вопросы конфидениальности и безопасности для них – очень остро стоят, и даже такие вещи воспринимаются очень позитивно.
Ну и чисто необъективная и эмоциональная штука: это просто весело и прикольно, когда владеешь подобной штукой с подобными секретиками) Это как шкатулка с секретом – всегда ее можно разбить и вытащить содержимое, но все равно испытываешь пиетет.
Большое спасибо за коммент, согласен с критикой. Подготовлю на этот счет статью в формате конкретных кейсов)
Спасибо :)
Это значит, что я пока еще плохо доношу свои мысли) Спасибо за коммент, буду стараться улучшать этот момент в своих статьях. Категорически согласен с тем, что истина где-то посередине.
На самом деле я не считаю, что нужно месяц писать документацию, еще месяц проектировать и т.д.. Я говорю о том, что не нужно уходить в крайности.
Первая крайность – вообще не планировать и забить болт на все.
Вторая – делать идеально продуманный продукт по вотерфолу.
В первом случае может выйти биоразложимое нечто, во втором – очень красивая никому не нужная штука с кучей конкурентов.
Основной посыл – делать нужно быстро, но для того, чтобы делать быстро, нужно знать, где и какие углы срезать.
Более того, суть эджайл не про скорость разработки, а про скорость доставки ценности. И вот люди постоянно неправильно интерпретируют суть подхода, называя говнокод – «эджайл-подходом».
Восихитительно! Спасибо, изучу :)
Я сторонник именно такого подхода) Единственное исключение, где я лично себе даю добро отказываться от каких-то этапов – это если мы с командой и заказчиком как минимум год вместе работаем, запустили парочку пилотов и в целом нашли общий язык и понимание. В любом другом случае – лучше не перепрыгивать.
Спасибо)