sclinede · August 29, 2015 14:10
diff --git a/mars_planning_result b/mars_planning_result
 Если конкретно по разработке Марса:

 1) Со стороны сервиса:

 1.1), 1.2), 1.3), 1.4) 
 Не сразу все взлетело, повозился с обновлением rvm, postgres'ом, тут и новые гемы и 
 пришлось по гему отчетов немного дописывать чтоб все работало как надо и 
 подключать ранее нигде не использовавшийся у нас гем Mechanize 
 +2 д
 1.5) так и вышло около +2 дней, сейчас еще уйдет время на отладку с resque, по последним проверкам там есть неясные проблемы с загрузкой записей разговоров
 1.6) Написание тестов еще в процессе +2 д будет

 2) Со стороны гема интеграции:

 А) При проектировании:
  1) Не была зафиксирована конечная логика поведения, происходили уточнения на лету переписывалась логика +1.5д
     Конкретно - требование к замене всех номеров компании на портале на номер МТС при редактировании. Это отдельный джоб. 
                 поведение формы редактирования телефонов не было детально прописано, а там тоже оказалось не мало времени
  2) В процессе реализации стало понятно что нужно немного перестроить хранение в связи с уточнениями в требованиях +0.5д
     Изначально полагалось что вся инфа о номере будет в сервисе, но понадобилось дополнительно хранить универсальный номер и в проекте,
     потребовалось редактировать запросы, экстеншены и апи сервиса.
  3) Изначально не была заложена, пришлось дописывать +0.5д
    * транзакционность тоже не была продумана +0.5д

 Б) При разработке:
  1) Не всегда получается начинать разработку с гема => 
    1.1) основное решение было сначала сделано в проекте, потом приехало в плагин +0.5д (ибо зависимости, инит плагина и проч.)
    1.2) +1д
    1.3) не реализовано
  2) в процессе 2д

 (везде где написано что-то типа "дописывать" или "дорабатывать" - имеется ввиду время с отладкой)
diff --git a/service_planning b/service_planning
 Цель: обратить внимание на моменты которые не были учтены при планировании времени необходимого на реализацию программного решения как сервиса, как следствие - снизить погрешность в оценке необходимого времени.

 Какие особенности проявляются в случае реализации решения в виде сервиса:

 1) Со стороны сервиса:

 1.1) Настройка среды локально (в зависимости от практики больше или меньше времени)
 1.2) Новые рельсы (или вообще другой каркас разработки) (!)
 1.3) Gemset (и необходимые компоненты) с нуля (подбор необходимого и достаточного набора гемов для сервиса, установка необходимых компонентов)
 1.4) Обновленные по максимуму версии гемов -> новый синтаксис, новые DSL (необходимо разбираться = время) 
 Особенности новых гемов:
  1.4.1) Интеграция (синтаксис, DSL, ...)
  1.4.2) Тестирование
  1.4.3) Запуск среды
  1.4.4) при Deploy
 1.5) Настройка отладка Deploy (в среднем 1-2 дня, на сервере почти всегда не все работает так как надо)
 1.6) Написание тестов, строгий must have + большой объем для покрытия, так что нельзя не учитывать


 2) Со стороны гема интеграции:

 А) При проектировании:
  ?) Для минимизации неучтенного при проектировании по хорошему набросать прототип решения или что-то вроде того
     В прототипе нужно раскрыть главные риски, т.е. опробовать новые гемы, вероятно определиться с инструментами которыми будет все реализовано (с т.з. Марса: тут я про Mechanize веду речь), 
  1) Надо детально проработать с заказчиком что требуется от гема интеграции, как точно изменится логика поведения на портале после подключения интеграции.
     (с т.з. Марса: тут я про функцию подключения номера МТС как замены существующего номера везде и про поведение формы редактирования номера)
  2) Четко распределить и разобраться детально что необходимо на стороне интеграции, и что должно быть в сервисе (в дальнейшем 
 перекраивать может оказаться затратно)
  3) Обработка исключений при работе с сервисом при всех возможных use case'ах
    * Обязательно подумать про транзакционность взаимодействий (требуется время на продумывание, проще сразу спроектировать, чем делать 2 раза)

 Б) При разработке:
  1) Не всегда получается начинать разработку с гема => 
    1.1) надо заложить время на реализацию в плагине (этап 1) -> 
    1.2) минимизацию зависимостей, уход от них (этап 2) -> 
    1.3) вынос в гем (этап 3)
  2) Написание тестов, строгий must have + большой объем для покрытия, так что нельзя не учитывать
	Если конкретно по разработке Марса:

	1) Со стороны сервиса:

	1.1), 1.2), 1.3), 1.4)
	Не сразу все взлетело, повозился с обновлением rvm, postgres'ом, тут и новые гемы и
	пришлось по гему отчетов немного дописывать чтоб все работало как надо и
	подключать ранее нигде не использовавшийся у нас гем Mechanize
	+2 д
	1.5) так и вышло около +2 дней, сейчас еще уйдет время на отладку с resque, по последним проверкам там есть неясные проблемы с загрузкой записей разговоров
	1.6) Написание тестов еще в процессе +2 д будет

	2) Со стороны гема интеграции:

	А) При проектировании:
	1) Не была зафиксирована конечная логика поведения, происходили уточнения на лету переписывалась логика +1.5д
	Конкретно - требование к замене всех номеров компании на портале на номер МТС при редактировании. Это отдельный джоб.
	поведение формы редактирования телефонов не было детально прописано, а там тоже оказалось не мало времени
	2) В процессе реализации стало понятно что нужно немного перестроить хранение в связи с уточнениями в требованиях +0.5д
	Изначально полагалось что вся инфа о номере будет в сервисе, но понадобилось дополнительно хранить универсальный номер и в проекте,
	потребовалось редактировать запросы, экстеншены и апи сервиса.
	3) Изначально не была заложена, пришлось дописывать +0.5д
	* транзакционность тоже не была продумана +0.5д

	Б) При разработке:
	1) Не всегда получается начинать разработку с гема =>
	1.1) основное решение было сначала сделано в проекте, потом приехало в плагин +0.5д (ибо зависимости, инит плагина и проч.)
	1.2) +1д
	1.3) не реализовано
	2) в процессе 2д

	(везде где написано что-то типа "дописывать" или "дорабатывать" - имеется ввиду время с отладкой)
	Цель: обратить внимание на моменты которые не были учтены при планировании времени необходимого на реализацию программного решения как сервиса, как следствие - снизить погрешность в оценке необходимого времени.

	Какие особенности проявляются в случае реализации решения в виде сервиса:

	1) Со стороны сервиса:

	1.1) Настройка среды локально (в зависимости от практики больше или меньше времени)
	1.2) Новые рельсы (или вообще другой каркас разработки) (!)
	1.3) Gemset (и необходимые компоненты) с нуля (подбор необходимого и достаточного набора гемов для сервиса, установка необходимых компонентов)
	1.4) Обновленные по максимуму версии гемов -> новый синтаксис, новые DSL (необходимо разбираться = время)
	Особенности новых гемов:
	1.4.1) Интеграция (синтаксис, DSL, ...)
	1.4.2) Тестирование
	1.4.3) Запуск среды
	1.4.4) при Deploy
	1.5) Настройка отладка Deploy (в среднем 1-2 дня, на сервере почти всегда не все работает так как надо)
	1.6) Написание тестов, строгий must have + большой объем для покрытия, так что нельзя не учитывать


	2) Со стороны гема интеграции:

	А) При проектировании:
	?) Для минимизации неучтенного при проектировании по хорошему набросать прототип решения или что-то вроде того
	В прототипе нужно раскрыть главные риски, т.е. опробовать новые гемы, вероятно определиться с инструментами которыми будет все реализовано (с т.з. Марса: тут я про Mechanize веду речь),
	1) Надо детально проработать с заказчиком что требуется от гема интеграции, как точно изменится логика поведения на портале после подключения интеграции.
	(с т.з. Марса: тут я про функцию подключения номера МТС как замены существующего номера везде и про поведение формы редактирования номера)
	2) Четко распределить и разобраться детально что необходимо на стороне интеграции, и что должно быть в сервисе (в дальнейшем
	перекраивать может оказаться затратно)
	3) Обработка исключений при работе с сервисом при всех возможных use case'ах
	* Обязательно подумать про транзакционность взаимодействий (требуется время на продумывание, проще сразу спроектировать, чем делать 2 раза)

	Б) При разработке:
	1) Не всегда получается начинать разработку с гема =>
	1.1) надо заложить время на реализацию в плагине (этап 1) ->
	1.2) минимизацию зависимостей, уход от них (этап 2) ->
	1.3) вынос в гем (этап 3)
	2) Написание тестов, строгий must have + большой объем для покрытия, так что нельзя не учитывать