Светлое будущее.
Карго-культ.
Деловые отношения между бизнесом и разработчиками.
Человеческие и профессиональные отношения между фронт и бек разработчиками
"Этот код плохой, его нужно переписать". Слышали? Как обосноватьMaksym Bezuglyi
Как на языке бизнеса доказать необходимость переписывания кода. Как бизнес может объяснить инженерам, что этого делать не нужно, либо как сделать это правильно с перспективы бизнеса.
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
User Stories - этот подход к описанию знаний о продукте просто понять и очень сложно использовать :) Кроме того, складывается ощущение, что при его использовании забывается самая главная часть - умение рассказывать истории о продукте и формировать общее понимание без необходимости подробного описания всех спецификаций, которые все равно никто никогда не читает. Мы постарались собрать все темы, которые необходимо осветить для беспрепятственной реализации задумок и разработали специальный инструмент для фасилитации обсуждений - User Story Canvas
Максим Мельников. Как мы меняли ЦИАН. Эволюция продакт-менеджераScrumTrek
За последние три года ЦИАН сильно поменялся как продукт, как бизнес и как компания. Выросли в несколько раз по всем метрикам (персонал, аудитория, выручка и др.), развили продукт, географию нашей работы, принципы управления. В докладе я рассажу о том, с какими сложностями стратегического, организационного и операционного характера мы сталкивались и как их решали: - С чего начинали - Как меняли систему управления, зоны ответственности и принятия решений о том, какие продукты, когда и для кого нужно делать - Какие процессы в создании продукта мы внедряли, что из этого у нас прижилось, а что нет и почему - Как мы постепенно идем к agile и design thinking - Где во всем этом культура и ценности компании, что из них есть «мода», а что в действительности нужно для бизнеса и людей в компании.
"Этот код плохой, его нужно переписать". Слышали? Как обосноватьMaksym Bezuglyi
Как на языке бизнеса доказать необходимость переписывания кода. Как бизнес может объяснить инженерам, что этого делать не нужно, либо как сделать это правильно с перспективы бизнеса.
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
User Stories - этот подход к описанию знаний о продукте просто понять и очень сложно использовать :) Кроме того, складывается ощущение, что при его использовании забывается самая главная часть - умение рассказывать истории о продукте и формировать общее понимание без необходимости подробного описания всех спецификаций, которые все равно никто никогда не читает. Мы постарались собрать все темы, которые необходимо осветить для беспрепятственной реализации задумок и разработали специальный инструмент для фасилитации обсуждений - User Story Canvas
Максим Мельников. Как мы меняли ЦИАН. Эволюция продакт-менеджераScrumTrek
За последние три года ЦИАН сильно поменялся как продукт, как бизнес и как компания. Выросли в несколько раз по всем метрикам (персонал, аудитория, выручка и др.), развили продукт, географию нашей работы, принципы управления. В докладе я рассажу о том, с какими сложностями стратегического, организационного и операционного характера мы сталкивались и как их решали: - С чего начинали - Как меняли систему управления, зоны ответственности и принятия решений о том, какие продукты, когда и для кого нужно делать - Какие процессы в создании продукта мы внедряли, что из этого у нас прижилось, а что нет и почему - Как мы постепенно идем к agile и design thinking - Где во всем этом культура и ценности компании, что из них есть «мода», а что в действительности нужно для бизнеса и людей в компании.
Денис Тучин, Проверка гипотез Kanban Method с помощью имитационной моделиScrumTrek
Используя имитационную модель на докладе мы проверим, что лучше работает:
Что делать если команда не сбалансирована
Может ли сбалансированная команда работать без ограничения WIP
Как подобрать оптимальные ограничения WIP
Помогает ли приоритезация бизнесу
Как учиться в вузе, заниматься предпринимательством и не умереть в процессеMIkhail Neverov
Данная презентация использовалась для сопровождения лекции для русской группы Высшей IT-школы ТГУ.
Какие цели я преследовал в рамках своей презентации:
Рассказать про то, как можно отучиться в ТГУ, попробовать себя в бизнесе и не умереть в процессе
Приоткрыть завесу в разные аспекты профессиональной деятельности в сфере компьютерных наук
Рассказать как выглядит (и может выглядеть) современный IT-бизнес с моей точки зрения
Какие навыки нужны программисту, а какие - предпринимателю
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
Дмитрий Павлов. Бытовые трудности и анти-паттерны Agile-команд.ScrumTrek
- Я решил внедрить Agile у себя в команде. Какой бы тул мне купить: Rally или TargetProcess? - Jira недоступна, мы не можем проводить планирование - Вы мне там Скрам настройте у разработчиков - У нас тестировщики половину спринта простаивают, а потом не успевают... Знакомые ситуации? Больно вспоминать? В данном докладе мы детально рассмотрим эти и другие антипаттерны, подсмотренных у реальных команд, - без философии про ценности и личностный рост. Поговорим о причинах их возникновения и последствиях, к которым они приводят. Доклад будет полезен начинающим скрам мастерам, чтобы не наступать на "детские" грабли, а опытные команды смогут критическим взглядом оценить свой процесс.
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Программное обеспечение не вечно. Старые продукты перестают удовлетворять каким-то требованиям и запускаются проекты по разработке новых продуктов, которые должны быть функциональнее, быстрее, надёжнее. Но вот беда: новый продукт нельзя сделать за пару месяцев. Разработка может тянуться в течение года, двух, трёх… И всё это время старый продукт требует поддержки и допилки. Вот здесь и начинаются проблемы. Должен ли опыт разработки старого продукта учитываться при создании нового? Должны ли команды работать друг с другом и насколько тесно? Как сохранить мотивацию команды, поддерживающей старый продукт и как мотивировать догоняющих? Что делать, когда оба продукта работают на боевой среде и данные в них частично дублируются, а частично противоречат друг другу?
В своём докладе я расскажу о тех ошибках, которые я встречал (и совершал тоже) при одновременной разработке легаси-проекта и его преемника, а также о том, как можно в этой ситуации избежать конфликтов между людьми, технологиями и данными.
29-я встреча IT talk Spb.
23 апреля 2015 г.
Тема: «Особенности Agile-разработки интернет-проектов на PHP/Yii, Python/Djangо и Java/Spring»
Спикер: Петр Курышев, «ИнфоСреда»
Денис Тучин, Проверка гипотез Kanban Method с помощью имитационной моделиScrumTrek
Используя имитационную модель на докладе мы проверим, что лучше работает:
Что делать если команда не сбалансирована
Может ли сбалансированная команда работать без ограничения WIP
Как подобрать оптимальные ограничения WIP
Помогает ли приоритезация бизнесу
Как учиться в вузе, заниматься предпринимательством и не умереть в процессеMIkhail Neverov
Данная презентация использовалась для сопровождения лекции для русской группы Высшей IT-школы ТГУ.
Какие цели я преследовал в рамках своей презентации:
Рассказать про то, как можно отучиться в ТГУ, попробовать себя в бизнесе и не умереть в процессе
Приоткрыть завесу в разные аспекты профессиональной деятельности в сфере компьютерных наук
Рассказать как выглядит (и может выглядеть) современный IT-бизнес с моей точки зрения
Какие навыки нужны программисту, а какие - предпринимателю
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
Дмитрий Павлов. Бытовые трудности и анти-паттерны Agile-команд.ScrumTrek
- Я решил внедрить Agile у себя в команде. Какой бы тул мне купить: Rally или TargetProcess? - Jira недоступна, мы не можем проводить планирование - Вы мне там Скрам настройте у разработчиков - У нас тестировщики половину спринта простаивают, а потом не успевают... Знакомые ситуации? Больно вспоминать? В данном докладе мы детально рассмотрим эти и другие антипаттерны, подсмотренных у реальных команд, - без философии про ценности и личностный рост. Поговорим о причинах их возникновения и последствиях, к которым они приводят. Доклад будет полезен начинающим скрам мастерам, чтобы не наступать на "детские" грабли, а опытные команды смогут критическим взглядом оценить свой процесс.
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Программное обеспечение не вечно. Старые продукты перестают удовлетворять каким-то требованиям и запускаются проекты по разработке новых продуктов, которые должны быть функциональнее, быстрее, надёжнее. Но вот беда: новый продукт нельзя сделать за пару месяцев. Разработка может тянуться в течение года, двух, трёх… И всё это время старый продукт требует поддержки и допилки. Вот здесь и начинаются проблемы. Должен ли опыт разработки старого продукта учитываться при создании нового? Должны ли команды работать друг с другом и насколько тесно? Как сохранить мотивацию команды, поддерживающей старый продукт и как мотивировать догоняющих? Что делать, когда оба продукта работают на боевой среде и данные в них частично дублируются, а частично противоречат друг другу?
В своём докладе я расскажу о тех ошибках, которые я встречал (и совершал тоже) при одновременной разработке легаси-проекта и его преемника, а также о том, как можно в этой ситуации избежать конфликтов между людьми, технологиями и данными.
29-я встреча IT talk Spb.
23 апреля 2015 г.
Тема: «Особенности Agile-разработки интернет-проектов на PHP/Yii, Python/Djangо и Java/Spring»
Спикер: Петр Курышев, «ИнфоСреда»
Презентация делалась для JuJa конференции - Java конференции для (пре) Juniors: https://juja.com.ua/materials/jujacon-2017/
В ней
- описываются основные темы-вопросы, которые часто спрашивают на собеседовании на позицию Junior Java Developer;
- советы, что спросить собеседующего;
- как себя позиционировать, как относиться к собеседованию, как не бояться и как понять, что вам "туда".
ThemeForest: Как пробиться и стоит ли игра свеч? | Odessa Frontend Meetup #9OdessaFrontend
Роман Пшеничный делится своим 4-х летним опытом работы разработки шаблонов для площадки ThemeForest. Рассказывает плюсы, минусы, подводные камни, а так же причины почему большинство желающих не могут попасть на этот рынок. И показывает рабочий процесс создания шаблона и используемые технологии.
Как попасть на следующий уровень карьеры и зарплаты в C#geekfamilyrussia
Есть ли потолок заработной платы? Что делать, если Вы уперлись в него. Как преодолевать уровни сопротивления и избегать в ловушек в карьере .net разработчика. Результат анализа более 6.000 резюме C# разработчиков в Москве.
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"Alexey Zinoviev
Alexey Zinoviev Алексей Зиновьев рассказывает о выборе одной из следующих баз данных CouchDB, Neo4j, Mongo, Cassandra, HBase, Riak на Happydev 2013
Article "Choice of NoSQL database for your project: Don't bite off more than you can chew" presented on HappyDev 2013 (IT-conference in Omsk) by Alexey Zinoviev
The main idea of this article is comparison of the most popular NoSQL databases: CouchDB, Cassandra, Mongodb, Riak, Neo4j, HBase
IT talk Spb #34 «Performance Based Hiring» Саша Зверев, сооснователь 2DiggersDataArt
О чем пойдет речь?
Performance Based Hiring — метод найма персонала, основанный на анализе фактических данных:
-кто такие «лучшие» сотрудники и кандидаты;
-концентрируемся на производительности кандидата, в противовес его навыкам;
-интервью на основе фактических данных;
-зачем нам HR?
Почему я про это говорю?
HR и IT-специалисты друг друга не понимают, и главное, даже не представляют, как договориться. И ответственность за это — на обеих сторонах.
Очень низкий уровень проблематики при разговорах об HR.
Карго-культ — делаем, как делали до нас, но почему — никто не знает, не понимает и не может объяснить.
Результат: на основе своего опыта и под большим влиянием идей Лу Адлера я рассказываю, как надо расставить акценты и какие задать друг другу вопросы, чтобы:
-преодолеть упомянутое непонимание между нанимающими менеджерами, HR и кандидатами;
-сделать процесс найма более экологичным, эффективным;
-а крутых специалистов — более доступными для разговора.
http://it-talk.dataart.ru/events/events-spb/2015/09/priglashaem-druzej-na-34-j-it-talk-v-peterburge/
5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
От заката до рассвета | Максим Безуглый | Zlit Tech
1.
2. Обо мне
• Первую строчку JS написал в 1998 году
• Nodejs только вышел - делал R&D применимости. Верил в JS, когда еще никто не верил
• Свой аналог GraphQL сделал в 2009
• Верил в то, что фронт займет большую долю, чем слайдеры на JQuery
• Поэтому сделал фреймворк, где запросы к бизнес логике можно было делать из JS, из
микросервисов
4. GraphQL. А в чем суть?
• Values? Декларируемые
• Экономия на байтах?
• понимание
• cost function
• N+1? Удобно? Кому?
• Выгодополучатели / Бенефициары?
5. «каждый кто скажет про не получать поля,
которые не запрашивал и он не работает в
Facebook, просто случайно попал в айти»
6. Выгоды простыми словами
Фронт +1 Бек -2 (не мои проблемы)
Реальный результат для average бизнеса -1
если у него нет бабла, чтобы это покрыть, я пойду работать к тем, у кого есть
12. Всегда ли бек и
фронт равны?
Оба ли могут быть важнее другого в части проектов?
Приложений, где море бизнес логики на беке и сотня
экранов на фронте в SPA - единицы.
13. Профессиональные отношения
• С кого бизнес спрашивает за ошибки в логике?
• Хочется делать мутации с фронта? А если это деньги,
документы, юридическая информация? Есть
готовность за это финансово отвечать? (Ой)
• Есть зрелые практики работы - покрытие тестами
всего кода? TS вместо JS хотя бы?
16. Личные отношения
• Разные ценности личные
• Разная ментальность
• Разные критерии успеха с позиции бизнеса
• Кейс с аплодисментами
• УВАЖАЙТЕ ДРУГ ДРУГА
18. Prisma raises $4.5M to
build the GraphQL data
layer for all databases
The upcoming Prisma 2.0 seems to combine Prisma Client and Prisma Server
and add an Admin UI feature. Making it a direct Hasura equivalent/competitor.
19.
20. Hasura. The company
got $1.6 million in seed
funding in April.
“Our focus from the beginning has been making the
application development super fast.”
21. that’s the way that
business works
сила темной стороны огромна
22. А ты с какой
стороны денег?
А мы покупаем или продаем?
Измеримое влияние на TCO?
Какие бизнес преимущества?
«у меня все хорошо, мой дом в сайдбаре»
23. MVP круд приложенек
для инвестора?
• А что если то же самое можно получить проще? Что
если даже клиент об этом знает, а разработчики нет?
• Внезапно - Oracle APEX, XYZ?
• Low code! Цель не кодить, цель быстро получить
решение, ведь graphql про скорость разработки?
24. 1ая, 2ая и 3я космические
скорости
• Скорость выхода MV(!!!)P проекта на рынок
• Скорость разработки
• Скорость карьерного роста разработчика
25. Любая технология важна не сама по
себе. Сколько не ускоряй часть работы,
никого не интересует только часть.
+1 - 2 = -1
26. Бизнес устает от
разделения и no value
added code
Крупный бизнес делит (ради эффективности и там не забалуешь),
средний хочет фулстек (Lean, Kanban, Scrum - каждый по своему)
27. Карьерный рост
быстро
В компании никто не отрубает твоих недостатков.
Много требуют? Идешь туда, где требуют меньше,
а платят больше.
Не мешают расти карьерно.
Непрофессионалы сами.
Сами себе враги, а ты им в этом союзник
28. Профессиональный
рост быстро
все четко понимают твой уровень, на карьерный
рост еще пахать и пахать. Но помогают расти,
потому что более профессиональны.
От требования о повышении раньше, чем через 2
года в первый раз смеются, во второй увольняют
29. Анализ ценности GraphQL
с поэзии архитектуры
• functional correctness ?
• performance, scalability (на фронт можно вынести
нагрузку, но слабый grahql бекенд бьет) - +
• compatibility +
• usability ?
• reliability: - maturity - availability - fault
tolerance - recoverability -
• security -
• maintainability +
30. Темное прошлое
• МОСТЫ между беком и фронтом:
• HTTP
• AJAX
• WebSocket
• X Window - реверсная архитектура, когда gui - это
сервер, а бизнес логика в клиентах.
• MVVM Binder. Declarative (1 Vendor, растаскали, нет
полной поддержки, MVC не пошатнулся)
32. Временно vs в нише
vs истинно
(широкая поддержка, переживет 10 лет)
33. • SOAP
• XML
• REST
• OPENAPI
• ODATA
• OTHER (gRPC, Protobuf, who cares?)
• Все это имело активный маркетинг и было идеальным (как GraphQL) решением для всех
проблем
• Кто-то думает что GraphQL просуществует вечно или в такой же позиции сияния в рассветных
лучах?
• Кто будет это legacy переписывать и как скоро?
По каким часам живем? Если по часам JS мира, то скоро.
34. Светлое будущее
• Светлое будущее у RICH фронтенда, а не у JS.
• AR интерфейсы, «как в кино» Так фронтенд это про JS
или про ФРОНТ - ЕНД и язык тут не при чем?
• Unreal Engine, C++ / BluePrint (hardcode / no code)
36. Закат
Сначала важно быстро во что-то входить. Но отрасль становится
более зрелой и становится важна сумма опыта. А если все вчерашнее
отбрасывается, а не суммируется, то цена опыта - 0.
Ваше место займут другие люди
41. Есть взрослые дома?
• А на нее (бизнес логику) есть тесты?
• Которые можно без браузера запустить?
• Она в идеальном порядке?
• Она не засунута в какой-то react компонент?
• (который MVC сам по себе, а в модели с Rx, Redux он
часть замороченной системы)
• Как вообще инициировать эту логику? Есть ли команда
или она по клику запускается?
42. Допустим…
• Есть страница и она показывает что решил сервер.
Может ли страница сама начать решать, что ей делать
и отправлять команды обратно на сервер?
• CRUD - это команды или нет? CQRS - command !=
p.title = x, p.save
• Ну, бывает… Dashboard - как и GraphQL - крути в
любой комбинации заданные элементы.
43. GraphQL - еще один rest,
openapi, больше свободы в
разработке, но ничего нового в
результате
Sorry, friends :(