Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
Softline — один из лидеров на рынке решений САПР/ГИС. Мы выполняем полный спектр работ по внедрению современных средств автоматизированного
проектирования ведущих зарубежных и отечественных производителей.
Основополагающий принцип автоматизированного проектирования — комплексный подход к решению задач. Размер наших проектов — от мелких доработок функционала сред проектирования до масштабного внедрения информационных систем поддержки процесса проектирования.
Достоинства и ограничения проектных моделей водопада и гибких подходов: скрам, аджайл (scrum, agile).
Как на основе специфичных характеристик проекта подобрать модели планирования и управления ИТ проектом
Выступление Валерия Боронина, посвященное внедрению безопасной разработки с точки зрения руководителя, на встрече PDUG Meetup: SSDL for Management 25 ноября 2016 года.
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
Softline — один из лидеров на рынке решений САПР/ГИС. Мы выполняем полный спектр работ по внедрению современных средств автоматизированного
проектирования ведущих зарубежных и отечественных производителей.
Основополагающий принцип автоматизированного проектирования — комплексный подход к решению задач. Размер наших проектов — от мелких доработок функционала сред проектирования до масштабного внедрения информационных систем поддержки процесса проектирования.
Достоинства и ограничения проектных моделей водопада и гибких подходов: скрам, аджайл (scrum, agile).
Как на основе специфичных характеристик проекта подобрать модели планирования и управления ИТ проектом
Выступление Валерия Боронина, посвященное внедрению безопасной разработки с точки зрения руководителя, на встрече PDUG Meetup: SSDL for Management 25 ноября 2016 года.
Презентация к выступлению на Сибирском бизнес-форуме 2015.
Доверие рассматривается, как инструмент, существенно влияющий на вашу эффективность и эффективность вашей команды.
Мы пройдем по ключевым аспектам деятельности руководителя и разберем механизм действия доверия и его эффект в каждой из них:
- Принятие решений
- Переговоры
- Продажи
- Делегирование
- Мотивация
- Контроль
- Долгосрочность отношений
Мы разберем как мы теряем и приобретаем доверие, как строить доверительные отношения в коллективе, а так же развенчаем несколько мифов о доверии.
2013.08.24 Антон Киселёв семинар "Agile (Scrum)"Alexey Fedorov
Антон Киселёв (Undev, Tester's Life) сделал для SPB SQA Group обзорный доклад о Agile и Scrum. В презентации много ссылок на истоки, прошлое, настоящее и тендеции будущего Scrum
Истории Пользователей (User Stories) - семинар на AgileUkraine 7, 2009-04-25Timofey (Tim) Yevgrashyn
Семинар на тему Историй Пользователя (User Stories) прошел в рамках седьмой конференции AgileUkraine.
Первоначально задуманный как практическое упражнение для 20 человек, он превратился в захватывающую тематическую дискуссию с аудиторией в 50 человек.
Судя по отзывам, участникам было о чем пообщаться.
Presentation for BUPRSSA's 2015 PR Advanced Conference: Breaking Boundaries breakout session, Content Creation and Viral Marketing.
This presentation shows how content goes from the mind of a creative to its various platforms and gives some best practices in getting content to go viral.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
Tech Talks @NSU: Методологии разработки ПО. Что на самом деле скрывается за с...Tech Talks @NSU
http://techtalks.nsu.ru
15 марта 2012. Методологии разработки ПО (Семён Факторович и Алексей Сапожков, Noveo)
«Семён Факторович (Noveo) рассказывает про методологии разработки и про то, что на самом деле скрывается за словами "scrum" и "agile"»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Similar to Семинар ФКН: современные подходы к разработке ПО - часть 1 (20)
Let's start GraphQL: structure, behavior, and architectureAndrii Gakhov
In this talk, I describe the path to start with GraphQL in a company that has experience with Python stack and REST API. We go from the definition of GraphQL, via behavioral aspects and data management, to the most common architectural questions.
Exceeding Classical: Probabilistic Data Structures in Data Intensive Applicat...Andrii Gakhov
We interact with an increasing amount of data but classical data structures and algorithms can't fit our requirements anymore. This talk is to present the probabilistic algorithms and data structures and describe the main areas of their applications.
Too Much Data? - Just Sample, Just Hash, ...Andrii Gakhov
Code & Supply | Pittsburgh Meetup | May 31, 2019
Probabilistic Data Structures and Algorithms (PDSA) is a common name of data structures based on different hashing techniques. They have been incorporated into Spark SQL. They are also used by Amazon Redshift and Google BigQuery, Redis and Elasticsearch, and many others. Consequently, PDSA is not just some interesting academic topic.
Book "Probabilistic Data Structures and Algorithms for Big Data Applications" (ISBN: 978-3748190486 ) https://pdsa.gakhov.com
This document discusses using DNS delegation to load balance traffic across application servers without a single point of failure. It describes configuring multiple nameservers each with their own zone file that resolves the domain's A record to the nameserver's own IP address. When a user resolves the domain, they will be routed to one of the nameservers randomly, load balancing traffic. It provides steps for implementing this using Puppet including opening ports, configuring the bind9 module and zone file, deploying, and testing.
Implementing a Fileserver with Nginx and LuaAndrii Gakhov
Using the power of Nginx it is easy to implement quite complex logic of file upload with metadata and authorization support, and without need of any heavy application server. In this article you can find the basic implementation of such Fileserver using Nginx and Lua only.
Have you heard about Salad Olivje, Vereniki, Pirogi and Bliny, but you are unsure what it is all about? This easy Pecha Kucha presentation can help you to become an expert :)
Probabilistic data structures. Part 4. SimilarityAndrii Gakhov
The book "Probabilistic Data Structures and Algorithms in Big Data Applications" is now available at Amazon and from local bookstores. More details at https://pdsa.gakhov.com
In this presentation, I described popular algorithms that employed Locality Sensitive Hashing (LSH) to solve similarity-related problems. I started with LSH in general and then switched to such algorithms as MinHash (LSH for Jaccard similarity) and SimHash (LSH for cosine similarity). Each approach came with some math that was behind it and simple examples to clarify the theory statements.
Probabilistic data structures. Part 3. FrequencyAndrii Gakhov
The book "Probabilistic Data Structures and Algorithms in Big Data Applications" is now available at Amazon and from local bookstores. More details at https://pdsa.gakhov.com
In the presentation, I described popular and very simple data structures and algorithms to estimate the frequency of elements or find most occurred values in a data stream, such as Count-Min Sketch, Majority Algorithm, and Misra-Gries Algorithm. Each approach comes with some math that is behind it and simple examples to clarify the theory statements.
Probabilistic data structures. Part 2. CardinalityAndrii Gakhov
The book "Probabilistic Data Structures and Algorithms in Big Data Applications" is now available at Amazon and from local bookstores. More details at https://pdsa.gakhov.com
In the presentation, I described common data structures and algorithms to estimate the number of distinct elements in a set (cardinality), such as Linear Counting, HyperLogLog, and HyperLogLog++. Each approach comes with some math that is behind it and simple examples to clarify the theory statements.
Recurrent Neural Networks. Part 1: TheoryAndrii Gakhov
The document provides an overview of recurrent neural networks (RNNs) and their advantages over feedforward neural networks. It describes the basic structure and training of RNNs using backpropagation through time. RNNs can process sequential data of variable lengths, unlike feedforward networks. However, RNNs are difficult to train due to vanishing and exploding gradients. More advanced RNN architectures like LSTMs and GRUs address this by introducing gating mechanisms that allow the network to better control the flow of information.
Apache Big Data Europe 2015: Selected TalksAndrii Gakhov
This document summarizes a talk given at the Apache Big Data Europe 2015 conference. It discusses the Apache Kafka distributed commit log system and how it can be used for real-time data processing and analytics. Specifically, it compares the Lambda and Kappa architectures for stream processing, describing how the Kappa architecture uses Kafka to allow reprocessing of data from the commit log and avoid maintaining separate batch and stream processing systems. Examples of using Kafka and stream processing for applications like fraud detection and IoT data analysis are also provided.
The document provides an overview of Swagger 2.0 and how it can be used to define REST APIs. Swagger allows both humans and computers to understand APIs without access to code or documentation. It includes a specification and tools like an editor, code generation, and UI. The document demonstrates defining a sample DEMO API in Swagger format and generating interactive documentation with Swagger UI. It also introduces PySwagger for testing APIs based on their Swagger definition.
Some highlights and impression from the API Days Berlin + API Strat Europe // April 24-25, 2015
* microservices
* hypermedia API
* swagger
* 3scale API Gateway
Apache Spark is a fast and general engine for large-scale data processing. It was originally developed in 2009 and is now supported by Databricks. Spark provides APIs in Java, Scala, Python and can run on Hadoop, Mesos, standalone or in the cloud. It provides high-level APIs like Spark SQL, MLlib, GraphX and Spark Streaming for structured data processing, machine learning, graph analytics and stream processing.
Семинар ФКН: современные подходы к разработке ПО - часть 1
1. СОВРЕМЕННЫЕ
ПОДХОДЫ К РАЗРАБОТКЕ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ ИМЕНИ В. Н. КАРАЗИНА
ФАКУЛЬТЕТ КОМПЬЮТЕРНЫХ НАУК
КАФ. ИСКУССТВЕННОГО ИНТЕЛЛЕКТА И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
К.Ф.М.Н., ДОЦ. КАФ. ИСКУССТВЕННОГО ИНТЕЛЛЕКТА И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ГАХОВ АНДРЕЙ ВЛАДИМИРОВИЧ
4. Первое формальное описание «модели
водопада» было дано в статье У. У.
Ройса (Winston W. Royce) 1970 года, в
которой он представил эту модель и
описал ее недостатки.
5. Принципы модели
модель состоит из набора фаз.
переход от одной фазы разработки к
другой происходит только после
полного и успешного завершения
предыдущей фазы.
переходов назад либо вперёд или
перекрытия фаз — не происходит.
9. Основные принципы
Программная система разделяется на
этапы (increments).
На каждом этапе каждая порция
функциональности продукта
проходит все фазы от разработки
требований до доставки (deployment).
10. Основные фазы
Исследование
Разработка.
На данной фазе оценивается масштаб проекта,
функциональные и нефункциональные требования, риски
и происходит оценка работы.
На данной фазе разрабатывается архитектура с учетов
уменьшения рисков и нефункциональных требований.
11. Основные фазы
Реализация
Переход.
На данной фазе пишется код и реализуются
архитектурные решение. Включаются стадии анализа,
проектирования, реализации и тестирования
функциональных требований.
На данной фазе система передается в промышленное
использование.
12. Основные фазы
Каждая фаза может быть разделена на 1 или
более итераций, которые скорее ограничены
временем, а не функциями продукта.
Архитекторы и аналитики обычно работают
на 1 шаг впереди, чем разработчики.
13. Сравнение с моделью водопада
В моделе водопада бизнес-ценность
появляется один раз и в самом конце
разработки проекта.
В итерационной модели возможна
обратная связь и коррекция процесса.
15. В феврале 2001 г. в штате Юта, США
был выпущен «Agile Manifesto» как
альтернатива управляемым
документацией, «тяжеловесным»
практикам разработки ПО.
16. Agile Manifesto
Люди и взаимодействие важнее
процессов и инструментов.
Работающий продукт важнее
исчерпыващей документации.
Сотрудничество с заказчиком важнее
согласований условий контракта.
Готовность к изменениям важнее
следования первоначальному плану.
17. Основные принципы
Найвысший приоритет –
удовлетворение потребностей
заказчика благодаря регулярной и
ранней поставке ценного ПО.
Изменение требований
приветствуется, даже на поздних
стадиях разработки.
19. Основные принципы
На протяжении всего проекта
разработчики и представители бизнеса
должны ежедневно работать вместе.
Над проектом должны работать
мотивированные профессионалы.
Чтобы работа была сделана, создайте
условия, обеспечьте поддержку и
полностью доверьтесь им.
20. Основные принципы
Непосредственное общение является
наиболее практичным и эффективным
способом обмена информацией как с
самой командой, так и внутри команды.
Работающий продукт – основной
показатель прогресса.
21. Основные принципы
Инвесторы, разработчики и
пользователи должны иметь
возможность поддерживать
постоянный ритм бесконечно.
Постоянное внимание к техническому
совершенству и качеству
проектирования повышает гибкость
проекта.
22. Основные принципы
Простота – искусство минимизации
лишней работы – крайне необходима.
Самые лучшие требования,
архитектурные и технические
решения рождаются у само-
организующихся комманд.
23. Основные принципы
Команда должна систематически
анализировать возможные способы
улучшения эффективности и
соотвественно корректировать стиль
своей работы.
25. Scrum
Спринт (Sprint).
Скрам-мастер (Scrum Master).
Жестко фиксированные и небольшие по времени итерации.
Возможности ПО к реализации на очередном спринте определяются в начале
спринта на этапе планирования и не могут изменяться на всем его
протяжении. При этом строго фиксированная небольшая длительность придает
процессу разработки предсказуемость и гибкость.
Проводит совещания (Scrum Meeting) и следит за соблюдением всех принципов
скрам, разрешает противоречия и защищает команду от отвлекающих
факторов.
26. Scrum
Владелец продукта (Product Owner).
Скрам-команда (Scrum Team).
Представляет интересы конечных пользователей и других заинтересованных
сторон.
Команда разработчиков проекта, состоящая из специалистов разных профилей:
тестировщиков, архитекторов, аналитиков, программистов и т.д. Размер
команды в идеале 5-9 человек. Команда является единственным полностью
вовлеченным в процесс участником и отвечает за результат как единое целое.
Никто, кроме команды не может вмешиваться в процесс разработки на
протяжении спринта.
29. Короткий цикл обратной связи
Разработка через тестирование.
Игра в планирование.
Основное внимание уделяется тестированию модулей (unit testing) и
функциональному тестированию. Тесты позволяют быть уверенному в
правильности кода, понять назначение того или иного фрагмента кода, логику
работы. Наличие тестов являются неободимым условием рефакторинга.
Приоритетным является подход Test Driven Development (TDD, разработка через
тестирование) - сначала пишется тест, а потом реализуется логика.
Используются бумажные карточки с пожеланиями заказчика (stories) и
примерный план работы по выпуску следующих версий продукта.
Необходимым условием является разделение в принятии решений: заказчик
принимает бизнес-решения, команда разработчиков – технические решения.
30. Короткий цикл обратной связи
Заказчик всегда рядом.
Парное программирование.
Конечный пользователь программного продукта («заказчик») должен быть всё
время на связи и доступен для вопросов.
При парном программировании исходный код создаётся парами людей,
программирующих одну задачу, сидя за одним рабочим местом. Один
программист («driver») управляет компьютером и думает над кодированием в
деталях. Другой программист («navigator») сосредоточен на картине в целом и
непрерывно просматривает код, производимый первым программистом.
Обычно, каждые полчаса они меняются ролями. Как правило, такие пары не
фиксированы и могут меняться при решении разных задач.
31. Непрерывный процесс
Непрерывная интеграция.
Рефакторинг.
Интеграция должна выполнятся несколько раз в день после успешного
выполнения всех тестов.
Реорганизация кода (рефакторинг) – это процесс изменения внутренней
структуры программы, не затрагивающий её внешнего поведения и имеющий
целью облегчить понимание её работы.
Частые небольшие релизы.
Готовые версии продукта (release) должны поступать в эксплуатацию как
можно чаще. Каждая версия должна нести полезную бизнес-составляющую.
32. Понимание, разделяемое всеми
Простота дизайна.
В процессе работы условия задачи могут неоднократно измениться,
следовательно нет смысла проектировать заблаговременно полностью.
Проектирование должно выполнятся постоянно и небольшими этапами,
учитывая меняющиеся требования. На каждом этапе выбирается наиболее
простой дизайн и меняется при изменении требований на следующих этапах.
Метафора системы.
Метафора системы являтся аналогом архитектуры – представления о
компонентах системы и их взаимодействии. Выбор хорошей метафоры
облегчает понимание системы разработчиками.
33. Понимание, разделяемое всеми
Коллективное владение кодом.
Стандарты кодирования.
Каждый член команды несет отвественность за весь код. Действует правило:
«Испортил - исправь». Парное программирование и наличие хорошего набора
тестов, позволяет не беспокоиться при изменениях любого участка кода.
Команда должна сформировать набор правил и все члены команды должны
их соблюдать. Не нужно тратить много времени на первоначальный набор
правил – сделайте их простыми и усложняйте только при необходимости.
34. Благосостояние программиста
Без сверхурочных.
40-часовая рабочая неделя программиста. Необходимость в сверхурочной
работе означает неправильное планирование. Принята концепция, что задание
выполняется лучше и более творчески только хорошо отдохнувшими людьми.
36. Принципы
Усиленное изучение.
Решай как можно позже.
Процесс разработки – это непрерывный процесс изучения. Вместо добавления
большего количества документации или более детального планирования
разные идеи должны быть опробованы в коде! Процесс изучения ускоряется
за счет коротких итераций (каждая из которых сопровождается рефакторингом
и интеграционными тестами). Благодаря коротким периодам заказчик и
разработчики лучше понимают как потребности пользователей, так и
особенности предметной области. Обязательны частые контакты с заказчиком.
Лучшие результаты получаются за счет подхода, основанного на разработке
продукта по опциям. Принимаем решение с задержкой до тех пор, пока новая
опция не будет основываться на реальных фактах, а не предположениях. Это
не означает отсутствие планирования!
37. Принципы
Доставляй как можно быстрее.
Доверие к команде и мотивация.
В современном мире выживает не большие, а быстрые. Чем быстрее продукт
будет доставлен без критических ошибок, тем быстрее будут получены отзывы
пользователей, а значит факты для следующей итерации.
Отлично работает стратегия «just-in-time», заключающаяся в определении
необходимого результата и предоставлении возможности команде
самоорганизоваться и выделить задачи, необходимые для достижения
результата.
Со статистической точки зрения люди – это ресурсы, но в разработке ПО это
совсем не так. Людям необходима мотивация. Разработчик должен иметь
доступ к заказчику, а Team Lead должен быть вовлечен в поддержку
пользователей в сложных ситуациях.
Find good people and let them do their job.
38. Принципы
Целостность видения.
Интегрирование.
Современная программная система это не просто сумма своих частей, это
продукт их взаимодействия. Важным является стандартизация процессов
разработки и разделение всем разработчиками принципов бережливости.
Think big, act small, fail fast; learn rapidly!
Заказчик получает целостный продукт, отдельные компоненты системы
работают хорошо друг с другом как единое целое. Целостность достигается
изучением предметной области и решением задачи в одно и тоже время (а не
последовательно).
Главным инструментом сохранения целостности системы выступает
рефакторинг (и тестирование).
40. TDD
Test-Driven Development (TDD) —
техника разработки ПО, которая
основывается на повторении очень
коротких циклов разработки: тест ->
код -> рефакторинг.
Тест — это процедура, позволяющая
подтвердить либо опровергнуть
работоспособность кода.
41. Test-Driven Development
Создание теста.
Запук всех тестов: тесты не проходят.
Добавление каждой новой функциональности начинается с написания тестов.
Для успешного написания тестов необходимо понимать требования,
рассмотрев все возможные сценарии.
После написания новых тестов необходимо убедиться, что они не проходят –
иначе тест написан не верно или необходимая функциональность уже
присутствует в системе.
42. Test-Driven Development
Написание кода.
Запук всех тестов: тесты проходят.
Необходимая функциональность реализуется в коде, причем главной целью
является прохождение теста. Не следует добавлять лишней функциональности,
которая не покрыта тестом.
Если тесты проходят, следовательно разработанный код удовлетворяет всем
требованиям. Пришло время для улучшения кода.
43. Test-Driven Development
Рефакторинг.
Повторение цикла.
Когда функционально код готов, необходимо его «подчистить» - внести
изменения во внутреннюю структуру (не затрагивая функциональность, т.е. ее
внешнюю структуру) с целью облегчить понимание, улучшить дизайн и
устранить возможное дублирование кода.
Указанный цикл повторяется снова и снова, реализуя новую функциональность
небольшими шагами – 1-10 изменений между запусками тестов. Если новый
код не удовлетворяет новым тестам или старые тесты перестают проходить, то
необходимо вернуться к отладке.
44. BDD
Behavior-Driven development (BDD) -
процесс разработки ПО, основанный на
TDD, но использующий также идеи
дизайна на основе предметной области
(DDD) с целью разработки ПО
«имеющего смысл».
45. Behavior-Driven Development
User story (пользовательские истории).
В BDD пользовательские истории выступают в качестве основных документов,
описывающих поведение системы, над которым совместно работают
разработчики и бизнес-аналитики. Каждая user story должна иметь
определенную структуру.
Спецификация - Ubiquitous Language
Ubiquitous Language (общеупотребительный язык) - термин, использованный
Эриком Эвансом (Eric Evans, создатель Domain Driven Design) для описания
языка, одинаково понятного разработчикам, так и пользователям .
Инструментальная поддержка
Важное значение в BDD (как и в TDD) отдается наличию инструментов,
поддерживающих автоматизацию спецификаций и их проверку (JBehave,
Cucumber и др.).
46. User story
Title (название).
Каждая история должна иметь простое и понятное название.
Narrative (поветствование, содержание).
Краткое описание, дающее ответы на следующие вопросы:
Who? – Кто является заинтересованной стороной в данной истории?
Which? – Какой эффект заинтересованная сторона ожидает получит?
What? – Что за бизнес-ценность будет получена от данного эффекта?
Acceptance criteria (критерии приемки).
Описание сценариев приемки для каждого случая повествования в формате:
• Начальные условия (считающиеся выполнеными в начале сценария).
• Определение события, которое начинает выполнение сценария.
• Определение ожидаемого результата.
47. User story - пример
As a Scrum Master I want to see Lead/Cycle time progress.
As a Scrum Master
I want to see Lead/Cycle time progress
So that I know whether we are improving our development process or not.
Scenario #1
Given Reports section in project and Bug Tracking practice is disabled
When I navigate to Lead and Cycle Time Report
Then I see Lead Time chart
And chart contains 1 line for stories
Scenario #2
Given Reports section in project and Bug Tracking practice is disabled
When I navigate to Lead and Cycle Time Report
Then I see Cycle Time
And chart contains 1 line for stories
48. TDD vs BDD
BDD – это «правильное» TDD.
BDD делает упор на то, какой система должна быть, в то время как TDD
больше озабочено тем, как реализовать систему. Очень часто в TDD
разработчики настолько увлечены тем, «как» сделать тест, забывая «для чего»
необходимо его сделать, отрываясь от проблем и задач предметной области.
BDD понятно не только разработчикам.
Одной из целей BDD является преодоление разрыва между разработчиками,
тестировщиками и пользователями. Использование user story существенно
облегчает понимание.