Gaperton - Software People 2012
Upcoming SlideShare
Loading in...5
×
 

Gaperton - Software People 2012

on

  • 1,427 views

 

Statistics

Views

Total Views
1,427
Views on SlideShare
812
Embed Views
615

Actions

Likes
1
Downloads
10
Comments
0

1 Embed 615

http://xss.yandex.net 615

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Gaperton - Software People 2012 Gaperton - Software People 2012 Presentation Transcript

  • Проектирование как процесс решения проблемВладислав БалинИнвестиционный холдинг «ФИНАМ»Зам. руководителя IT-департамента по R&D
  • Разработка ПО – это производство?Проведем правильную аналогию
  • Разработка устройстваКонструкторское бюро Испытания и Испытания и 100 Проектирование правки РКД правки РКД изделий 10 Исправленная 10 Исправленная РКД образцов РКД образцов РКДФабрика Производство Производство Производство опытных опытных установочной образцов образцов партии месяц месяц месяц•  Производство – ответственный и затратный этап•  Его не перепутать с проектированием
  • Hardware  People   Готовность к производству: Проектирование Ключевые - Рабочие изделия требования и непрерывный процесс - Прохождениехарактеристики испытаний постановки и решения - Комплект РКД (для проблем производства) •  Логистика важна на этапе проектирования •  Развита дисциплина работы с документацией •  Явный фокус на решении проблем •  В ТЗ только ключевые требования и ТТХ •  РКД - не более чем средство
  • Куда девалась фабрика?Компьютер разработчика ПО Разработка Отладка Отладка Дистрибутив Исходный Исправленный Исправленный код EXE код EXE код Компиляция и Компиляция и Компиляция и сборка сборка сборка минуты минуты минуты•  Наша технология производства – верх совершенства•  Настолько, что мы не склонны его замечать
  • So-ware  People   "Промышленная" Программный код:Технические разработка - Проходит тестытребования процесс написания - Соответствует и отладки кода требованиям•  Главный результат – отлаженный код•  «Заказчик никогда не знает, что он хочет»•  Упорная аналогия с конвейерной сборкой •  нет Ватерфолу, да здравствует Канбан!
  • Разработка – непрерывный процесс проектирования Проектирование – процесс решения проблем
  • Проблема  имеет  много  решений   ? Проблема Так? Ага! Пространство решений
  • …которые  ставят  новые  проблемы   ? Проблема Так? Ой! Пространство решений ?!
  • …и  мы  перебираем  решения   ?Проблема Так? Ой! Пространство решений ?! Или так? ?
  • …чтобы  найти  оптимальное.   ? Проблема Так? Теплее! Ой! Пространство решений А может, вообще вот-так? ?! Или так? Э-э-э... ?
  • «Требования  меняются»  «Заказчик  не  знает,  что  он  хочет»   А  так-­‐ли  хорошо  люди  умеют   разделять  проблемы,  и  их   решения?  
  • «Добавьте в эту табличкувот такое поле,считающееся вот-так».«Брокерская комиссиядолжна рассчитыватьсясекунда в секунду по всемклиентам!»«Необходимо слить вашисистемы в одну, с единойбазой!».«Надо переписать риск-сервер!»
  • Решение Проблема«Добавьте в эту табличку Менеджеру надо знатьвот такое поле, актуальный остаток денег насчитающееся вот-так». счете, чтобы оформить клиенту выдачу наличных.«Брокерская комиссия Менеджеру надо знатьдолжна рассчитываться актуальный остаток денег насекунда в секунду по всем счете, чтобы оформитьклиентам!» клиенту выдачу наличных.«Необходимо слить ваши Процесс выдачи наличных –системы в одну, с единой неудобен, требуетбазой!». дублирования операций в разных системах.«Надо переписать риск- В риск-сервере есть порядка 10сервер!» неприятных ошибок, которые давно пора исправить.
  • Пользователь  прекрасно  осознает  свои  проблемы.  Но  почему-­‐то  не  считает  нужным  о   них  говорить.  
  • «Требования»  –  решение  проблемы   Проблема пользователя Функции системы
  • …которое  ставит  частные  проблемы   Проблема пользователя Функции системы Как Как будет Как будет отобразятся выглядеть? работать? на систему? Алгоритмы и Структура Внешний вид структуры модулей, UI данных классов, и пр. …имеющие множество возможных решений
  • …которые  можно  по  разному   реализовать   Проблема пользователя Функции системы Как Как будет Как будет отобразятся выглядеть? работать? на систему? Алгоритмы и Структура Внешний вид структуры модулей, UI данных классов, и пр. ? ? Исходный код ? ? ?
  • …но  кое-­‐что  ограничивает  пространство  решений   Каковы Как в целом Проблема ключевые устроена пользователя ТТХ? система? Базовые Функции технологии системы и принципы Как Как будет Как будет отобразятся выглядеть? работать? на систему? Алгоритмы и Структура Внешний вид структуры модулей, UI данных классов, и пр. ? ? Исходный код ? ? ?
  • «Наше С++ приложениебудет мелко нарезано наизолированные COM-объекты»«Исходный код торговыхроботов будут храниться вбазе данных»«Будем все писать наДельфи».«Необходимо всепереписать на .NET!»«Необходимо переписатьэтот кривой, как турецкаясабля, код!».
  • Решение Проблема«Наше С++ приложение Наше приложение должно уметьбудет мелко нарезано на на чем-то скриптоваться. Леньизолированные COM- думать, пусть это будет Visualобъекты» Basic. И точка.«Исходный код торговых Я сходил на недельные курсы пороботов будут храниться в MS SQL, и не могу держать этобазе данных» знание внутри себя.«Будем все писать на Ничего кроме Delphi не умеем, иДельфи». изучать не хотим.«Необходимо все Нам очень не нравится Дельфи,переписать на .NET!» изучения которого надо избежать.«Необходимо переписать Этот код не мой. Я ничего в немэтот кривой, как турецкая не понимаю, и панически боюсьсабля, код!». его.
  • Разработчик  прекрасно  осознает  свои  проблемы  Но  почему-­‐то  не  считает  нужным   о  них  говорить.  
  • Поэтому,  мы  выбираем   решения  наугад!   И  да  поможет  нам  Ag:)e.  
  • Нам  поможет  Методология  Х?   Или,  может,  стоит  осмысленно   выбирать  решения?  
  • «Чеклист  детектива»  •  Выяснить  проблему  •  Определить  критерии  успешного  решения  •  Рассмотреть  несколько   «версий»  (вариантов  решения)  •  Отработать  все  версии,  собирая  факты  и   «улики»  •  «Отбросьте  невозможное,  и  останется   истина».  ШХ.    
  • Проектирование  супер-­‐ЭВМ  Отбор кандидатов Вариант 1 Вариант 2 Вариант 3 Вариант 4 Вариант 5Глубокая проработка Эльбрус-2 БЭСМ-10Детальное проектирование Эльбрус-2
  • Цикл  «гипотеза-­‐эксперимент»  •  Умение  выдвигать  разумные  гипотезы,  и   проверять  их  логически  •  Умение  ставить  эксперименты,  и  делать  из   них  правильные  выводы  •  Необходимо  умение  отделять:   –  Факты  от  предположений   –  Проблемы  от  решений   –  Цели  от  задач  
  • Группа  эффективнее  одиночки  в   выработке  и  проверке  гипотез   Группа  должна  быть  организована,   чтобы  быть  эффективнее  
  • Сессия  проектирования  •  Собираем  проектную  группу  •  Вводная:   –  Проблема  пользователя   –  Очевидные  варианты  решений   –  «Что  нам  мешает  сделать  это  прямо  сейчас?»  •  Дополняем  список  вариантов  решений  •  Составляем  список  открытых  проблем   –  Что  мы  не  знаем,  и  должны  узнать  
  • Список  открытых  проблем  •  Главный  предмет  совещания  •  Виден  всей  группе  на  маркерной  доске  •  Всегда  актуален  •  Должен  меняться  со  временем   – Количество  проблем  высшего  порядка   должно  уменьшаться,  сменяясь   частными  
  • Правила  проверки  решений  •  «Это  неправильно»  «Как  ваше  решение   будет  работать  вот  в  такой  ситуации?»  •  Давление  на  авторитеты  Ссылки  на   конкретный  опыт  с  примерами  •  Убеждения  В  инженерии  все  можно   обосновать  логически  •  Это  будет  так!  «В  закон  Ома  верю.  Все   остальное  надо  проверять»  
  • Хорошо  известные  вам  вещи..   –  Прототипы   –  Дизайн-­‐ревью   –  Код-­‐ревью   –  Тесты     …являются не «практиками», а   средствами проверки «гипотез»
  • «-­‐  Ты  должен  мне  поверить!  -­‐  Ты  кто  -­‐  Иисус  Христос,  чтобы   тебе  верить?»     Главный   А.  М.  Степанов.   программист  первого  советского   комплекса  ПВО.  
  • Роль  руководителя  •  Организует  и  ведет  совещание  •  Поддерживает  список  открытых  проблем  •  Отвечает  за  логику  и  формат,  разрешая   конфликты,  оставляя  креатив  подчиненным  •  Направляет  процесс,  выдавая  задания   (схема  «научного  семинара»)  •  Вникает  в  проблемы,  которые  не   меняются  
  • Для  одного  программиста  •  Периодически  подходить  к   программисту  •  Беседовать  о  текущих  проблемах  •  Отмечать  те,  что  не  меняются  •  Вникать  только  в  них,  и  разбираться,   почему:   –  Человеку  может  быть  нужна  помощь   –  Выдумывать  проблемы  тяжело  
  • Спасибо  за  внимание!  Владислав  Балин  hrp://gaperton.livejournal.com