Тренинг «Проектирование обоснованной архитектуры», Евгений Кривошеев

Спросите коллег – почему в последнем коммите получилось именно 3 класса? Почему не 2? И почему не 4? Старайтесь не заплакать, держитесь. Горько заплачьте.

Зачем нужен тренинг бизнесу

Вы наверняка сталкивались с неспособностью объяснить принятые решения в дизайне и архитектуре. А при отсутствии обоснованности решений уже невозможно в дальнейшем говорить о более важных характеристиках – внешнее качество, поддерживаемость, тестируемость, производительность и других. Если разработчик не может внятно объяснить, почему он так сделал, как можно ждать от него достижения бизнес-задач компании? И со временем неосознанные решения в архитектуре и дизайне превращают поддержку и развитие системы в ад, просто останавливая бизнес и принося вполне осязаемые убытки.

Зачем нужен тренинг специалисту

В ситуации неосознанного проектирования Вы, как разработчик, скорее всего, будете делать колоссальное количество ненужной работы, находясь постоянно в режиме аврала. А те задачи, которые действительно необходимо сделать, будут задерживаться – и это приведет к срыву сроков и закономерной реакции руководства.

Невозможность обосновать свои инженерные решения сильно бьет по качеству дизайна и оно стремительно страдает, что приводит к быстрому росту технического долга. И рано или поздно это превратит развитие системы в непрерывную боль. Знакомая картина? Особенно с учетом неспособности команды договариваться друг с другом.

Безусловно, мы видим огромное количество книг и статей на тему качества дизайна и архитектуры. Но большинство вопросов остается открытыми. Как поступать, если рекомендации в книгах противоречат друг другу и иногда невыполнимы? Как поддерживать качество дизайна в условиях непрерывного изменения? Как решать задачи с минимальными усилиями, при этом принося максимум пользы себе и компании? Как получать удовольствие от разработки, не спотыкаясь о техдолг? Как легко договориться о решениях в команде?

Для кого

• Разработчики и архитекторы, желающие быть Инженерами с большой буквы – шагнуть на новый уровень профессионализма: создавать элегантные и эффективные решения и всегда иметь четкие и обоснованные ответы, раз и навcегда избавиться от ненужных споров в команде
• Тимлиды и руководители проектов, желающие прекратить дрязги в команде по техническим вопросам, резко повысить скорость разработки и сфокусированность команды на бизнес-задачах, и в итоге получить легкий для развития продукт

Цели

Для непрерывного повышения качества дизайна и кода, формирования соглашений в команде, получения удовольствия от разработки разработчики, проектировщики и архитекторы:

1. осознают важность требований – функциональных и атрибутов качества и смогут в своих проектах обеспечить их реализуемость минимальными затратами
2. разберутся с эффективным способом проектирования и смогут на практике выработать общекомандные принципы и соглашения
3. поймут способы работы с неопределенностью и смогут решать бизнес-задачи даже в условиях, когда ничего не ясно и все постоянно меняется
4. разберутся, зачем нужны методология и бизнес-модель компании при разработке и как они определяют дизайн и архитектуру
5. почувствуют практику emergent design и смогут свободно развивать свой продукт в условиях непрерывного потока изменений
6. поймут способы описания архитектуры и смогут на практике концентрировать усилия на наиболее важных вопросах для обеспечения качества сейчас и в будущем
7. поймут ключевые метрики ООП-дизайна и смогут объективно оценивать состояние своего проекта
8. разберутся с принципами ООП-проектирования и смогут на практике обоснованно выбирать из них и непрерывно повышать качество дизайна

Для выработки общих архитектурных принципов и соглашений в команде, резкого ускорения разработки, фокуса команды на качестве и поддерживаемости тимлиды и PM:

1. получат четкую и простую модель принятия решений и смогут выработать общие руководства и соглашения в своей команде, направленные на минимизацию бюджетов и максимизацию качества
2. почувствуют практику emergent design и смогут значительно повысить скорость разработки за счет откладывания некритичных решений и фокусировки на критичных
3. поймут способы описания архитектуры и смогут на практике быстро проверять наиболее критические точки в результатах работы команды
4. поймут ключевые метрики ООП-дизайна и смогут быстро оценивать качество проекта в текущий момент и его динамику

Требования к слушателям

опыт промышленной разработки от 1 года

Программа

1. Обзор тренинга
2. Знакомство и сбор проблем
3. Разбивка по командам и формулировка кейсов
4. Модель принятия инженерных решений
   1. Примеры типовых рефакторингов
   2. Проблема осознанности решений
   3. Модель требований
   4. Метафора и vision
   5. Модель предметной области
   6. Дизайн как компромисс
   7. Соглашения и guidelines
   8. Модель процесса разработки
   9. Типовые процессные паттерны
   10. Бизнес-модель
   11. Типовые паттерны бизнес-моделей
5. Практика: выделение epics и QA
6. Практика: формирование guidelines
   1. Типовые критические пути в современных системах
7. Описание архитектуры
   1. Подход «точек зрения» и архитектурных представлений («view»)
   2. Точки зрения: 4+1 и Rozansky&Woods
   3. Границы системы
   4. Типовые архитектурные метафоры
8. Практика: выбор точек зрения
9. Практика: выбор границ системы и архитектурной метафоры
10. Метрики ООП-дизайна
    1. Суть ООП как работа с ответственностями
    2. Новый взгляд на инкапсуляцию, абстракцию, полиморфизм
    3. Coupling
    4. Cohesion
    5. Cyclomatic Complexity
    6. Sonar Demo w/SQA plugin
    7. Отображение метрик на атрибуты качества
11. Практика: архитектурный workshop
    1. Проектирование
    2. Вопросы для снятия неопределенности
12. Философия Emergent Design
    1. Подход Lean к принятию архитектурных решений
    2. Выявление критических путей для архитектурных решений
13. Практика: архитектурный workshop
14. Фрактальная природа проектов
    1. Множественные трассы сценариев
15. Верификация и валидация архитектуры
    1. Tracing
16. Практика: проверка архитектуры

В чем отличие от других тренингов по проектированию

Опыт авторов был структурирован так, чтобы охватить все уровни software engineering: реализацию, дизайн, требования, процесс и бизнес-модель компании. Такой подход позволяет участникам увидеть целостную картину их работы и вырабатывать максимально эффективные решения в своей работе. Ведь разработчикам нигде не объясняют, зачем именно им важно понимать бизнес-модель и требования – как конкретно они влияют на архитектуру и дизайн.

Тренинг фокусируется на конкретных понятных целях участников, поэтому все темы рассматриваются через вопросы практического применения. Участники в рамках практики сами почувствуют специфику и смогут сделать самостоятельные выводы. А все устные обсуждения основаны не на книжных примерах, а на опыте и вопросах непосредственно участников тренинга.

«Хорошая архитектура минимизирует количество решений».

О тренере

Евгений Кривошеев консультирует компании TOP-50 из российского ИТ в направлении улучшения эффективности и гибкости ИТ-подразделений. Сторонник внедрения гибких процессов “снизу”, посредством распространения инженерных практик и осознанного подхода к проектированию.

В прошлом — архитектор в крупных коммерческих проектах. Имеет более чем семилетний опыт преподавания технологий на платформах J2SE, J2EE, BEA Systems, IBM и параллельной разработки. Отличительная черта – объединение широкого кругозора и практических приемов, полученных в реальных проектах. Способен донести сложные технологические знания самому широкому кругу слушателей.

Тренер компании ScrumTrek по направлению "Гибкие методологии". В настоящее время активно развивает проект SkillTrek.