Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

0

Partager

Télécharger pour lire hors ligne

Преемственность продуктов

Télécharger pour lire hors ligne

Программное обеспечение не вечно. Старые продукты перестают удовлетворять каким-то требованиям и запускаются проекты по разработке новых продуктов, которые должны быть функциональнее, быстрее, надёжнее. Но вот беда: новый продукт нельзя сделать за пару месяцев. Разработка может тянуться в течение года, двух, трёх… И всё это время старый продукт требует поддержки и допилки. Вот здесь и начинаются проблемы. Должен ли опыт разработки старого продукта учитываться при создании нового? Должны ли команды работать друг с другом и насколько тесно? Как сохранить мотивацию команды, поддерживающей старый продукт и как мотивировать догоняющих? Что делать, когда оба продукта работают на боевой среде и данные в них частично дублируются, а частично противоречат друг другу?

В своём докладе я расскажу о тех ошибках, которые я встречал (и совершал тоже) при одновременной разработке легаси-проекта и его преемника, а также о том, как можно в этой ситуации избежать конфликтов между людьми, технологиями и данными.

  • Soyez le premier à aimer ceci

Преемственность продуктов

  1. 1. ПреемственностьпродуктовКолесников Степан
  2. 2. Степан Колесников@karakazyablekЯ хочу рассказать про преемственность программных продуктов и поделиться своимопытом по смене одного поколения софта следующим.
  3. 3. Поехали!
  4. 4. Впервые про преемственность я узнал незадолго до того того, как пошел в школу ислово "преемственность" воспринималось мной исключительно в контексте проблемыпередачи власти в стране. Тогда, в августе, вот эти дядьки с картинки пугали всю странус экранов телевизоров,
  5. 5. а вот эти суровые мужчины пугали тех, кто пугал всю страну. В конечном счёте мы знаемчем всё кончилось. Я не знаю, можно ли было говорить тогда о преемственности властив результате тех событий, но слово засело в моём сознании довольно крепко.
  6. 6. "А как же с преемственностью программных продуктов" - скажете вы мне. Откуда я что-то знаю про неё? Минуточку терпения. Сейчас расскажу.
  7. 7. Всё началось 4 года назад, когда я пришел в компанию 2ГИС разработчиком наединственный на тот момент внутренний продукт в компании. Продукт был довольнобольшим: сотни тысяч строк кода на плюсах и десятки тысяч строк на VBA. Тогда мнеказалось, что количество времени и сил, которые разработчики разных поколенийвложили в разработку этого продукта сопоставимо с ресурсами на постройку Саяно-Шушенской ГЭС
  8. 8. ну или Беломорканала...Примерно в то же самое время у нас в компании начались работы по разработке новыхсистем, которые должны были прийти на смену разных модулей старой. Поэтому всё этовремя, все эти годы я находился в самом центре перемен и перехода от старой системык новым.
  9. 9. Я успел побывать на обеих сторонах барикады. Я участвовал и в строительстве новогомира с новыми программными продуктами
  10. 10. и поддерживал старый рекационный продукт, чтобы он держался на плаву столько,сколько того потребует бизнес.
  11. 11. За это время я успел посмотреть на разные эффекты и процессы, которые возникали унас по ходу дела.Я видел как создавались и распадались команды разработки. Я видел, как команды иотдельные их участники демотивировались или наоборот вдохновлялись в какой-томомент и делали очень крутые штуки. Вот про это я и буду рассказывать дальше.
  12. 12. Начнем с того, что я расскажу про контекст, в котором мы работали. Когда-то у нас былвсего один внутренний продукт и он, казалось бы, вечен. Он вполне справлялся снагрузкой, его любили рабочие, а он делал их жизнь легче.
  13. 13. Но в какой-то момент стало понятно, что бизнес выдвигает нам всё новые и новыетребования и начало появляться ощущение, что старый продукт уже не сможет с нимисправиться на отлично. Мы стали думать о преемнике. Более мощном, современном исоответсвующем новым вызовам бизнеса.
  14. 14. Вывод первый:смена продуктовдолжна бытьсвоевременной.Здесь появляется первый вывод
  15. 15. Начинайте думать о преемнике, пока ваш старый добарый продукт ещё не впал вкоматоз
  16. 16. Плохой пример: нововоронежская аэс. С момента открытия инженерский состав этой аэсбыл стабильным и практически не менялся. Инженеры были молоды, полны сил иэнергии. Но в какой-то момент они все состарились. Разом. Сейчас у аэс большаяпроблема с тем, кто будет работать, когда все инженеры уйдут на пенсию.
  17. 17. Но мы подумали о преемнике вовремя и начали думать, как нам разрабатывать новыйпродукт. У нас было 2 варианта. Первый из них - обратиться к системным интеграторам.К счастью, они запросили слишком много и мы решили делать всё своими руками.
  18. 18. Мы довольно быстро собрали команду из нескольких программистов и аналитика. Но напервом этапе мы толком не знали, что мы делаем и что должно получиться. В итогепрограммисты довольно долго занимались различными сервисными задачами,настройкой окружения и так далее. Что, конечно же, не сильно-то приближало нас кзаветной цели.
  19. 19. Вывод второй:знай чего хочешь дотого, как написанапервая строчка кодаРеальная работа началась только тогда, когда аналитик разобрался, что именно нужноделать и начал транслировать свой план на программистов.
  20. 20. Человек на фото - Клаус Фукс. Один из самых эффективных разведчиков, которыйпередавал сведения по ядерному проекту в СССР. Суть в том, что человек рисковалсвоей свободой и жизнью только лишь для того, чтобы поделиться знаниями.Как правило, разработчикам из команд нового и старого продукта ничем рисковать ненужно, чтобы пообщаться и задать друг другу какие-то вопросы. Но общение междуновой и старой командами скорее редкость, чем правило.
  21. 21. Хотя для того, чтобы узнать больше, нужно уметь очень немногое: правильно задаватьвопросы.
  22. 22. Правда, не очень понятно, какие именно вопросы разработчики новой системы могутзадать программистам из старой. На самом деле это зависит от того, насколько должныбыть похожи старая и новая системы. Стоит обязательно поговорить про:1. Глоссарий. У 2-х команд возникнет гораздо меньше трудностей в общении и винтеграции, если разработчики из разных команд будут оперировать одними и теми жетерминами2. Часто изменяемые части системы.
  23. 23. Разработчики старой системы могут дать много интересной пищи для размышления отом, где новая система может остаться достаточно жесткой и неизменной
  24. 24. а где нужно добавить максимум гибкости, потому что эта часть системы регулярноменялась и скорее всего будет меняться и дальше.
  25. 25. Вывод третий:задавай вопросы,это бесплатно!
  26. 26. Ещё одна проблема совместной параллельной разработки 2-х продуктов заключается втом, что команда нового продукта всегда находится в позиции догоняющего. Догонятьвообще сложно, а ещё сложнее когда от тебя убегают, а перед тобой всё времявырастают какие-то барьеры.
  27. 27. Игра в догоняжки между новым и старым продуктом - очень плохо. Нужно стремитьсяизбегать этого.
  28. 28. Хорошей же метафорой в разработке 2-х продуктов в параллели служит передачаэтафетной палочки. В этом случае, команды подстраиваются друг под друга для того,чтобы передача эстафеты всё же произошла.
  29. 29. Вывод четвёртый:не играйте вдогоняжки -передавайтеэстафету
  30. 30. Самым плохим исходом, к которому может привести игра в догоняжки являетсяхолодная война между командами. Когда для команды новичков типичным являетсяутверждение, что старому продукту (да и команде!) место на свалке истории. А командаветеранов троллит новую команду тем, что у них после года-полутора-двух разработкитак и не произошло ни одного успешного внедрения.
  31. 31. Одним из симптомов нездоровой ситуации в отношениях между командами можетслужить желание меряться всем чем можно: "а у нас клиент толще!"
  32. 32. А у нас юзер-стори длиннее!
  33. 33. Но вот, положим, новый продукт дошел до стадии внедрения. Есть несколько вопросов,которые нужно задать себе перед внедрением, чтобы ещё раз убедиться, что мы ничегоне забыли.Вопрос первый - миграция данных. Обычно это то, о чем думают в самый последниймомент и на что обращают минимум внимания: часто нет ни требований, ни картымиграции, регламентов и так далее. Поэтому это очень багоопасный процесс. Совет:думайте о миграции сразу же, как только начали разрабатывать новый продукт. Неработайте с демо-данными в процессе разработке, лучше мигрируйте реальные иработайте с ними.
  34. 34. Второй вопрос, тесно связанный с миграцией - это очистка данных. Обязательноспросите себя, может ли новая система работать с данными старой? Или нужна какая-топроцедура очистки. У нас был случай, когда процедура очисти данных оказаласьнастолько сложной, что пришлось разработать отдельную систему для этих целей.
  35. 35. Вывод пятый:запланируйте задачуочистки данныхпосле миграции
  36. 36. Подумайте об интеграции старой и новой систем. Скорее всего она вам понадобится.
  37. 37. Вывод шестой:учите матчасть.В данном случае -шаблоны интеграции
  38. 38. Одной из проблем при внедрении новой системы может стать требованиеодновременной работы части пользователей в разных системах. т.е. может оказаться,что в разных базах у нас лежат частично пересекающиеся данные, которые со временемразъезжаются и становится не ясно, где взять правильные данные и кому, собственно,верить.
  39. 39. Я знаю про одну компанию, в которой параллельно были внедрены сразу 3 системы саналогичным функционалом. Вопрос о правильности данных решался на ежемесячномсобрании представителей всех 3-х продуктов и бизнеса.
  40. 40. Говорят, что часто в этих спорах у кого данные правильнее выигрывал тот, у когохаризма выше.
  41. 41. Вывод седьмой:для всех данныхдолжна бытьопределенаединственнаямастер-система
  42. 42. И ещё раз вернемся к вопросу интеграции. В интеграции часто бывает довольно многопроблем, связанных с недопониманием разными командами всей задачи в целом.
  43. 43. Это недопонимание - прямое следствие цехового принципа разработки, когда 2 командысчитают, что раз они договорились о программных интерфейсах и описали какие-тосхемы данных, то дело в шляпе, можно просто запилить свой кусочек и всё будетнормально. На самом деле это не так. Цеховой принцип разработки работает плохо.Всегда находится что-то, из-за чего не получается запустить интеграцию с первого раза.
  44. 44. Поэтому, для успешной интеграции нужно более тесное общение между командами. Видеале, разработчики обеих команд должны знать всё интеграционное решение, а нетолько свою часть.
  45. 45. Добиться этого не легко, но возможно. Например, можно выделить на пару спринтов по1-2 человека из каждой команд в одну команду интеграции. Желательно ещё и посадитьих рядом, чтобы они могли свободно общаться между собой.
  46. 46. Вывод восьмой:собери их все!
  47. 47. Вопросы?Степан Колесников,@karakazyablekkarakazyablek@gmail.comНа самом деле, тема гораздо шире и я успел обозначить только некоторые особенностиперехода от старой системы к новой. Какой вывод я сделал для себя? Нужно не боятьсяизменений и думать не только о новом и старом продукте, но и о всей системе в целом.

Программное обеспечение не вечно. Старые продукты перестают удовлетворять каким-то требованиям и запускаются проекты по разработке новых продуктов, которые должны быть функциональнее, быстрее, надёжнее. Но вот беда: новый продукт нельзя сделать за пару месяцев. Разработка может тянуться в течение года, двух, трёх… И всё это время старый продукт требует поддержки и допилки. Вот здесь и начинаются проблемы. Должен ли опыт разработки старого продукта учитываться при создании нового? Должны ли команды работать друг с другом и насколько тесно? Как сохранить мотивацию команды, поддерживающей старый продукт и как мотивировать догоняющих? Что делать, когда оба продукта работают на боевой среде и данные в них частично дублируются, а частично противоречат друг другу? В своём докладе я расскажу о тех ошибках, которые я встречал (и совершал тоже) при одновременной разработке легаси-проекта и его преемника, а также о том, как можно в этой ситуации избежать конфликтов между людьми, технологиями и данными.

Vues

Nombre de vues

370

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

141

Actions

Téléchargements

2

Partages

0

Commentaires

0

Mentions J'aime

0

×