Спасибо за коммент. Почему же фокус? Это один из этапов разработки, который надо осознать и начать внедрять, погружаясь в тему. Нефункциональные требования так же можно анализировать, записывать в виде сценариев и автоматизировать при помощи разных программ и инструментов. Только это надо делать. И процесс этот долгий.
Насчет, архитектуры и то, что ее не возможно в agile командах внедрять. Не соглашусь. У нас в компании, к примеру, архитектуре, инфраструктуре, уделяется особое внимание. Эти задачи планируются, все прорабатывается. Мы работаем по SAFe(R). Все зависит от культуры, процессов, регламентов, методологий, площадок принятых в компании.
Спасибо за комментарий. Смотрите, такой вопрос. А откуда появился такой легаси, в который даже страшно заходить? Как он разрабатывался и принимался? Проводятся ли процедуры рефакторинга и реструктуризации кода? Был ли ранее процесс code review и как его проводили?
Возможно, раньше его не проводили. Всякое бывает. Разработка MVP, потом все начинает обрастать новым кодом и...добрый вечер... имеем не очень качественную кодовую базу. Как быть тут? Как команде вникать в задачу и понять тот код, который разработан? Тут в дело вступают процессы в команде. Как работают сеньоры, как они работают с джунами, какой процесс адаптации и обучения, какие еще практики применяются? Все это можно поэтапно вводить в команду. К примуру, практики экстремального программирования - совместное владение кодом, групповые ревью, парное программирование и т.д.
Насчет форматирования... Это то, на что надо обратить внимание. Как вы это будете делать - это ваш выбор. Форматирование из IDE с принятыми настройками или какие нибудь автоматические инструменты. Не важно. Главное делать это и отлавливать. Код будет читаемым и его легко дальше передавать.
100% покрытие тестами - это БАЦ (Большая амбициозная цель). Главное, чтобы тесты покрывали максимально возможные кейсы, которые рождаются из требований и критериев приемки. Можно запустить процесс, который в долгую приблизит ваш продукт(ы) к БАЦ.
Я вам скажу за ваше ревью спасибо. Да, опечатка не влияет на смысл поста. Но, согласитесь, куда приятнее читать пост без ошибок.Тут очень важна культура в команде, компании и под каким соусом подается код ревью. Для разработчика сode review - это не инструмент порицания, а инструмент оттачивания своего мастерства (обучения).
Не не, я не игнорирую. Это в следующей "серии" буду рассматривать. Сбор требований, формирование DoD, критериев приемки - один из важнейших этапов при разработке. Любой пропуск на этот этапе отразится в следующих этапах. И именно здесь идет активная работа с заказчиком, командой. Здесь и обсуждается адекватность требований, выравниваются все ожидания.
Да, бездумное внедрение новых фреймворков, методологий (с мыслью лишь бы были и все сейчас полетит) приводит к печальным последствиям. Надо для начала менять мышление всех, кто стоит в производственном процессе.
Основная цель выстраивания процессов - это минимизация количества багов, которые утекут в прод. Подход описанный в статье, дает возможность во время этапа реализации получать обратную связь (читайте, а не наделали ли мы багов?). И на месте все правится. Это и есть Тесты-Вперед. Вы не пишите код до того пока не написали тест для него. Это подходы TDD, BDD и/или ATDD. Так у вас есть гарантия, что новый функционал не поломал то, что было написано раннее (т.е. баги не появились). Тесты править в основном нельзя (только если идет рефакторинг и реструктуризация кода), т.к. тесты отражают требования к функционалу. К примеру, Unit тесты - это из TDD. Они должны падать только по одной причине, ВDD тесты могут падать по нескольким, т.к. они сложнее. И если тест упал после реализации, то вот он баг - надо править. И в этом и есть прелесть. Вы не передаете дальше по этапам функционал с багами.
Но этого недостаточно, нужны также практики экстремального программирования - групповое владение кодом, групповые код ревью, анализаторы кода (Sonar, Purecov, Purify и т.д.). Это чтобы убрать человеческий фактор при разработке.
Совершенно верно. Применение новых методологии и фреймворков должно зависеть от всего процесса доставки ценности до клиента. Какой в компании SDLC, STLC? Какие стандарты и регламенты, практики разработки (к примеру, экстремального программирования), проектное и продуктовое управление? Культура! Все это в купе формирует встроенное качество. И, имхо, закладывать фундамент для этого лучше в начале. Конечно же, не надо внедрять все и сразу, особенно, если есть процессы.
Спасибо за коммент.
Почему же фокус? Это один из этапов разработки, который надо осознать и начать внедрять, погружаясь в тему.
Нефункциональные требования так же можно анализировать, записывать в виде сценариев и автоматизировать при помощи разных программ и инструментов. Только это надо делать. И процесс этот долгий.
Насчет, архитектуры и то, что ее не возможно в agile командах внедрять. Не соглашусь. У нас в компании, к примеру, архитектуре, инфраструктуре, уделяется особое внимание. Эти задачи планируются, все прорабатывается. Мы работаем по SAFe(R). Все зависит от культуры, процессов, регламентов, методологий, площадок принятых в компании.
Спасибо за комментарий. Смотрите, такой вопрос. А откуда появился такой легаси, в который даже страшно заходить? Как он разрабатывался и принимался? Проводятся ли процедуры рефакторинга и реструктуризации кода? Был ли ранее процесс code review и как его проводили?
Возможно, раньше его не проводили. Всякое бывает. Разработка MVP, потом все начинает обрастать новым кодом и...добрый вечер... имеем не очень качественную кодовую базу. Как быть тут? Как команде вникать в задачу и понять тот код, который разработан? Тут в дело вступают процессы в команде. Как работают сеньоры, как они работают с джунами, какой процесс адаптации и обучения, какие еще практики применяются? Все это можно поэтапно вводить в команду. К примуру, практики экстремального программирования - совместное владение кодом, групповые ревью, парное программирование и т.д.
Насчет форматирования... Это то, на что надо обратить внимание. Как вы это будете делать - это ваш выбор. Форматирование из IDE с принятыми настройками или какие нибудь автоматические инструменты. Не важно. Главное делать это и отлавливать. Код будет читаемым и его легко дальше передавать.
100% покрытие тестами - это БАЦ (Большая амбициозная цель). Главное, чтобы тесты покрывали максимально возможные кейсы, которые рождаются из требований и критериев приемки. Можно запустить процесс, который в долгую приблизит ваш продукт(ы) к БАЦ.
Я вам скажу за ваше ревью спасибо. Да, опечатка не влияет на смысл поста. Но, согласитесь, куда приятнее читать пост без ошибок.Тут очень важна культура в команде, компании и под каким соусом подается код ревью. Для разработчика сode review - это не инструмент порицания, а инструмент оттачивания своего мастерства (обучения).
Спасибо за комментарий и отличный список инструментов. Совершенно согласен, что автоматизировать нужно по максимуму.
Не не, я не игнорирую. Это в следующей "серии" буду рассматривать. Сбор требований, формирование DoD, критериев приемки - один из важнейших этапов при разработке. Любой пропуск на этот этапе отразится в следующих этапах. И именно здесь идет активная работа с заказчиком, командой. Здесь и обсуждается адекватность требований, выравниваются все ожидания.
Спасибо за комментарий!
Да, бездумное внедрение новых фреймворков, методологий (с мыслью лишь бы были и все сейчас полетит) приводит к печальным последствиям. Надо для начала менять мышление всех, кто стоит в производственном процессе.
Спасибо за вопрос!
Основная цель выстраивания процессов - это минимизация количества багов, которые утекут в прод. Подход описанный в статье, дает возможность во время этапа реализации получать обратную связь (читайте, а не наделали ли мы багов?). И на месте все правится. Это и есть Тесты-Вперед. Вы не пишите код до того пока не написали тест для него. Это подходы TDD, BDD и/или ATDD. Так у вас есть гарантия, что новый функционал не поломал то, что было написано раннее (т.е. баги не появились). Тесты править в основном нельзя (только если идет рефакторинг и реструктуризация кода), т.к. тесты отражают требования к функционалу. К примеру, Unit тесты - это из TDD. Они должны падать только по одной причине, ВDD тесты могут падать по нескольким, т.к. они сложнее. И если тест упал после реализации, то вот он баг - надо править. И в этом и есть прелесть. Вы не передаете дальше по этапам функционал с багами.
Но этого недостаточно, нужны также практики экстремального программирования - групповое владение кодом, групповые код ревью, анализаторы кода (Sonar, Purecov, Purify и т.д.). Это чтобы убрать человеческий фактор при разработке.
Надеюсь ответил на ваш вопрос.
Совершенно верно. Применение новых методологии и фреймворков должно зависеть от всего процесса доставки ценности до клиента. Какой в компании SDLC, STLC? Какие стандарты и регламенты, практики разработки (к примеру, экстремального программирования), проектное и продуктовое управление? Культура! Все это в купе формирует встроенное качество. И, имхо, закладывать фундамент для этого лучше в начале. Конечно же, не надо внедрять все и сразу, особенно, если есть процессы.