Персональные инструменты
 

Модель принятия инженерных решений — ключ к ответам на технические вопросы (Евгений Кривошеев, AgileDays-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

Докладчик
Евгений Кривошеев
  • Нужен ли в дизайне моей системы паттерн Singleton?
  • Почему при изменении требований затраты на внесение изменений возрастают?
  • Сколько времени уделять проектированию?
  • Зачем мне модель предметной области, ведь и без нее все работает?
  • Чем архитектура отличается от дизайна?
  • С чего начать проектирование?
  • Я запутался в паттернах — они противоречат друг другу!
  • Вся остальная команда — придурки, они ничего не понимают!
  • Где располагать модульные тесты?
  • Нужно ли документировать? Что именно документировать?
  • Мучают эти вопросы? Конфликты в команде? Тогда мы идем к вам :)

Ответ есть :)

Бухтелово посвящено модели принятия инженерных решений. Ожидается, что слушатели выступления получат мощный инструмент — стройную систему, которая позволит в лучших традициях agile-подхода вырабатывать оптимальный дизайн систем и разрешать конфликты в команде.

В качестве отправной точки будут представлены типичные грабли и антипаттерны разработки, которые автор считает наиболее типовыми и массовыми. Отталкиваясь от них, мы коллективно смоделируем решения, которые помогут резко снизить затраты на разработку и приведут к качественному дизайну.

Видео


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).


Примечания и отзывы

Запомнился Евгений Кривошеев с его моделью принятия инженерных решений. все кто учился на инженера помнят, что надо подумать, измерить какие последствия своих решений ты хочешь получить: например: гибкое, но сложное, или топорное, но простое из из этого исходить при проектировании и разработке, но в процессе разработки некоторые вещи переходят в привычку, некоторые просто забываются и получается, что зачастую программа пишется, как придется. Напомнил, для чего инженеру голова нужна) ©

Евгений Кривошеев, ScrumTrek

Достаточно интересный и познавательный, но малополезный на практике (ИМХО) доклад.

Что можно попробовать:

  • оформить Architecture Guideline — руководство по принятию архитектурных решений
  • сформулировать хотя бы устно требования по надежности, производительности и другим нефункциональным требованиям.

Антипаттерны:

  • «Категорическое мышление»
  • Неспособность обосновать инженерное решение — хотя бы на словах оттрасировать к (нефункциональным требованиям)
  • Неверный акцент усилий (слишком много дизайна/аналитики перед разработкой и т. п. — аналогично потерям в Lean)
  • Overengeneering (тоже потери)

Модель компетентности

Colb cycle.jpg



Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.