Я заранее прошу прошение у читателя за обилия терминологии на английском, просто иногда трудно перевести на русский, да и стоит ли переводить?
Я уже полтора года работаю в условиях Agile а именно по Scrum методологии. причем мы проповедуем Large Scale Distributed Scrum. У нас порядка 8 команд распределенных по всему земному шару, которые работают над одним продуктом и в одном codebase.
Пару спринтов назад к нам поступила в работу User Story которая требовала дополнительного технического исследования перед планированием и оцениванием трудозатрат для реализации. К сожалению сценариев еще не было готово поэтому Specification by Example, которые потом практически безболезненно ложатся на интеграционные или функциональные тесты, мы сочиняли параллельно исследованию. Решено было попробовать описать сценарий интеграционным тестом который бы покрывал один из пунктов Spec by Example.
Интеграционные тесты в нашем продукте по сравнению с функциональными достаточно легковесные и не требуют запуска всей инфраструктуры а лишь маленькой её части, поэтому писать такие тесты быстрее и результат их можно увидеть также гораздо быстрее, а также итерации TDD заметно короче чем если писать функциональный тест.
Так вот, выигрыш в использовании такого подхода был просто колоссален, по логам мы сразу поняли как ведет себя система до нашего вмешательства подав ей на вход данные нового сценария, а также всплыли на поверхность детали реализации которую необходимо будет сделать.
Конечно идеально распланировать задачи в условиях высокой степени неопределенности практически не возможно, но если на ранней стадии спринта понять, что именно необходимо делать, то можно вовремя скорректировать план и количество задач на спринт, и тем самым повысить вероятность своевременной сдачи готового продута.
Я уже полтора года работаю в условиях Agile а именно по Scrum методологии. причем мы проповедуем Large Scale Distributed Scrum. У нас порядка 8 команд распределенных по всему земному шару, которые работают над одним продуктом и в одном codebase.
Пару спринтов назад к нам поступила в работу User Story которая требовала дополнительного технического исследования перед планированием и оцениванием трудозатрат для реализации. К сожалению сценариев еще не было готово поэтому Specification by Example, которые потом практически безболезненно ложатся на интеграционные или функциональные тесты, мы сочиняли параллельно исследованию. Решено было попробовать описать сценарий интеграционным тестом который бы покрывал один из пунктов Spec by Example.
Интеграционные тесты в нашем продукте по сравнению с функциональными достаточно легковесные и не требуют запуска всей инфраструктуры а лишь маленькой её части, поэтому писать такие тесты быстрее и результат их можно увидеть также гораздо быстрее, а также итерации TDD заметно короче чем если писать функциональный тест.
Так вот, выигрыш в использовании такого подхода был просто колоссален, по логам мы сразу поняли как ведет себя система до нашего вмешательства подав ей на вход данные нового сценария, а также всплыли на поверхность детали реализации которую необходимо будет сделать.
Конечно идеально распланировать задачи в условиях высокой степени неопределенности практически не возможно, но если на ранней стадии спринта понять, что именно необходимо делать, то можно вовремя скорректировать план и количество задач на спринт, и тем самым повысить вероятность своевременной сдачи готового продута.
No comments:
Post a Comment