# Competent

• Software Development Methodologies

  • Lean software development concept
  • Extreme programming

• Scrum vs Kanban: applicability

• Distributed teams coordination and collaboration

  • Test Driven Development
  • Feature Driven Development

• Engineering Process Planning

  • Evaluating technical feasibility
  • Defining unit-testing process
  • Defining code review process

---

# Software Development Methodologies

# Lean software development concept

Бережная разработка

Принципы

• Исключение потерь Потерями считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение.

• Акцент на обучении Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

• Предельно отсроченное принятие решений Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.

• Предельно быстрая доставка заказчику Короткие итерации.

• Мотивация команды Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.

• Интегрирование Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

• Целостное видение Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, делать мало, ошибаться быстро; учиться стремительно».

---

# Extreme programming

Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающаяся в проверке одним программистом кода, написанного другим программистом, в «экстремальном» варианте представляет собой «парное программирование», когда один программист занимается написанием кода, а его напарник в это же время непрерывно просматривает только что написанный код.

Двенадцать основных приёмов экстремального программирования:

• Короткий цикл обратной связи (Fine-scale feedback)

  • Разработка через тестирование (Test-driven development) Unit & functional tests
  • Игра в планирование (Planning game)
  • Заказчик всегда рядом (Whole team, Onsite customer)
  • Парное программирование (Pair programming)

• Непрерывный, а не пакетный процесс

  • Непрерывная интеграция (Continuous integration)
  • Рефакторинг (Design improvement, Refactoring)
  • Частые небольшие релизы (Small releases)

• Понимание, разделяемое всеми

  • Простота проектирования (Simple design)
  • Метафора системы
  • Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
  • Стандарт оформления кода (Coding standard or Coding conventions)

• Социальная защищённость программиста (Programmer welfare):

  • 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

---

# Scrum vs Kanban: applicability

Scrum и Kanban — представители методологий Agile-семейства. Обе считаются гибкими и итеративными.

Scrum

• Основу Scrum составляют короткие итерации или спринты, как правило, 2-3-х недельные.
• Перед началом спринта команда сама формирует список фич на итерацию, далее запускается спринт.
• После окончания спринта выполненные фичи заливаются на продакшн, а невыполненные — переносятся в другой спринт.
• Как правило, фичи, которые делаются во время спринта, не меняются: что было на старте спринта — должно быть сделано любой ценой к окончанию спринта.
• задачи принято оценивать в Story points или в часах
• Velocity — это производительность команды за один спринт

Kanban

• Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов
• не принято делать оценку. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.
• Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей.
• WIP - ставим ограничение на число задач, которые может одновременно делать один сотрудник.
• Swimlanes
  • Blockers (берутся в работу немедленно)
  • Someday (когда-нибудь потом сделаем)

---

# Distributed teams coordination and collaboration

• Daily blog posts

  Meetings are a geographic impossibility and getting together online would require some members or our team to be working in the middle of the night. So instead we ask every team member to write a quick blog post about the work they did on a given day

• Just say no to email

  team does not use email for internal communication. Instead we have discussions in Hipchat rooms or one-to-one Hipchat sessions. The advantage is obvious. Nothing important gets buried in someone’s inbox.

• Everything in its place

  Everything we create – be it a written document, a presentation or a screenshot – is stored so it can be referred to and, hopefully, reused. This means it has to be easy for any member of the team to find.

• Clearing the clutter

  Of course, with everyone creating documents in Confluence, there is the risk that, left untended, our space could become just as disorderly as the worst email inbox.

# Test Driven Development

It is a “break first, build later” approach.

TDD can be defined as a programming practice that instructs developers to write new code only if an automated test has failed. This avoids duplication of code. TDD means “Test Driven Development”. The primary goal of TDD is to make the code clearer, simple and bug-free.

1. Write the test (which will fail, as you don’t have the code for it yet!)
2. Write the minimum amount of code to have the test to pass
3. Further enhance the tests for that code you just wrote
4. Refactor code to make the new tests pass
5. Iterate between adding tests and refactor code until the desired functionally and code quality is achieved.

# Feature Driven Development

1. Develop an overall model

Модель – это видение проекта, основанное на результатах предварительных исследований

2. Build a features list

список свойств в FDD – то же самое, что и product backlog в SCRUM. Разве что стоит еще раз напомнить: при создании списка следует оперировать именно целями и подцелями, но не задачами.

3. Plan by feature

Story Point Estimation. Мы оцениваем свойства не в человеко-днях, а в абстрактных баллах по мере сложности свойства.

4. Design by feature

Итак, приоритеты определены, выбрано свойство для реализации. Самое время описать требования. Для этого создается модель прецедентов (Use Cases) относительно выбранного свойства. Данный документ хорошо бы снабдить диаграммой активности (Activity Diagram) для визуализации логики сопряженных сценариев использования. Сами прецеденты можно отразить в соответствующей UML диаграмме (Use Case diagram). В ходе обзора (review) документа, опять же, принимают участие все члены команды.

5. Build by feature

Разрабатываем. После того, как свойство протестировано и ушло в продукт, берем следующее по приоритетам свойство, повторяем цикл дизайна/реализации.

advantages

• Simple five-step process allows for more rapid development
• Allows larger teams to move products forward with continuous success
• Leverages pre-defined development standards, so teams are able to move quickly

Disadvantages

• Does not work efficiently for smaller projects
• Less written documentation, which can lead to confusion
• Highly dependent on lead developers or programmers

---

# Engineering Process Planning

# Evaluating technical feasibility (оценка технической осуществимости)

QOS (quality of service) - a requirement that can be classified as a performance, load, availability, stress, accessibility, serviceability, or maintainability requirement

A good requirement set includes requirements that are defined from multiple perspectives. This makes a lot of sense. All projects have multiple influences. The business (or executive sponsorship) has a set of objectives and goals for the application. Users define specific tasks they need to accomplish. Developers and testers need to know what features will be required to make this application a success. There are also requirements around supporting and maintaining the application, around performance and scalability, and more. The goal is to define enough of these requirements to eliminate unknowns (risk) and to build the right project. This section will define four types of requirements: business, user, functional, and quality of service. Together, these categories represent the perspectives necessary to define the requirements for the vast majority of (if not all) business applications. They provide a common understanding from the business through to the developer. They also allow the quality assurance team to ensure that the application stays focused and on track. Let’s take a look at each requirement category in further detail.

# Defining unit-testing process

Benefits

• Provides quick feedback on implemented functionality
• Allows making big changes to code quickly
• Prevents most of regression and new defects
• Reduces development and testing overhead
• Improves overall code quality
• Minimizes amount of debugging sessions

Indicators of Successful Process

• The unit testing policy is defined and documented
• Tests are F.I.R.S.T. (Fast, Isolated, Repeatable, Self-Verifying, Timely)
• Each unit test method performs exactly one logical assertion and checks only one thing at a time
• Tests check a unit behavior not implementation details
• Test code is separated from production code
• Functional defects in code are also covered by tests
• Testing is part of the build and CI process
• Parametrized tests, common methods and test cases are used to avoid code duplication

# Defining code review process

Benefits

• allows to avoid functional and non-functional defects appearing
• prevents anti-patterns and bad practices in the code
• increases maintenance of the product, forces code conventions across the team
• increases responsibility for the code quality by each team member

Indicators of Successful Process

• The code review procedure is defined and documented
• checklist is used
• against requirements (code and project conventions, specified architecture, functional and non-functional requirements, security guidelines)
• s used as learning and knowledge sharing instrument and share typical findings among team members
• workflow is using best practices for selected tool
• Code review is automated (specialized review tools are used)
• All changes are reviewed and validated
• Process ensures that identified code review defects or action items are fixed
• Feedback cycles are reduced by introducing relevant, intelligent comments