воскресенье, 19 июня 2016 г. - www.msmirnov.ru

Летний Аналитический Фестиваль-2016 (ЛАФ-2016)

Вот и закончился 7-й Летний Аналитический Фестиваль-2016 - моя любимая IT-конференция.

На мой взгляд, этот фестиваль был самым лучшим из всех 7-ми как по уровню докладов, так и по атмосфере.

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

Примечательно также то, что в этом году я взял с собой 4-х свежеиспеченных аналитиков, для которых это был первый выход в серъезный аналитический свет и первая возможность встретиться с людьми, находящимися на переднем крае российской аналитической мысли.

Из докладов мне особенно понравились следующие:
  1. Макс Гапонов "User Story Canvas" - отличное пошаговое руководство для начинающего аналитика для описания User Story

  2. Сергей Рассамакин "Борьба за доверие Заказчика. Почему её надо вести? Как её надо вести?"

  3. Дмитрий Безуглый "Гибкий бизнес и системный анализ"

  4. Юля Ерина "Выявление и оценка компетенций аналитиков"

  5. Круглый стол Дмитрия Безуглого "Уровень зрелости процессов постановки задачи"

  6. Круглый стол Ани Абрамовой "Нужно ли продавать бизнес-анализ"

Большое спасибо всем организаторам и участникам фестиваля!

Увидимся в следующем году!

All you need is ... ЛАФ.

P.S. И как всегда, немного фоток.







Мой сайт - www.msmirnov.ru

понедельник, 6 июня 2016 г. - www.msmirnov.ru

Современные процессы разработки программного обеспечения

Сегодня выступил с небольшим докладом для своих коллег "Современные процессы разработки программного обеспечения".

Содержание доклада:
1. Основные термины
2. Основные этапы жизненного цикла любых проектов
3. Waterfall
4. RUP
5. Agile
- Экстремальное программирование
- Scrum
- Kanban
6. Метод освоенного объема

Уровень доклада - для начинающих и для среднего уровня.

Презентация доклада доступна здесь:
http://www.msmirnov.ru/public/processes.pptx

Также доступно видео семинара:
Мой сайт - www.msmirnov.ru

четверг, 2 июня 2016 г. - www.msmirnov.ru

Водопады

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

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

При этом подход часто в таких случаях выбирается следующий - заказчик передает бизнес-требования для относительно небольшой порции изменений имеющейся системы подрядчику на изучение и оценку (Change Request), потом согласовывает бюджет и запускает в разработку.

Т.е. используется небольшой водопадный процесс (waterfall) для реализации изменений.



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

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

Для заказчика это опять же выглядит хорошо по описанным выше причинам - он платит только за то, что заказал, всегда контролирует бюджет, ясно видит как изменяется его система и т.п.

Однако, такая организация работы приводит к тому, что заказчик и подрядчик ориентируются на краткосрочные цели в ущерб долгосрочным целям и в конечном счете в ущерб внутреннему качеству продукта.

Причин тому несколько:
  • Пытаясь представить и согласовать наименьший бюджет (особенно в условиях тендера) заказчик часто вынужден предлагать сиюминутное решение, которые удовлетворит заказчика в рамках текущего запроса, но внесет некоторый (пусть и небольшой) дисбаланс во внутреннюю организацию системы
  • Заказчик, даже если он и осведомлен о том, что с точки зрения архитектуры, решение предлагается не самое оптимальное, тоже идет на это, находят под давлением со стороны учредителей, которые не желают тратить лишний бюджет.
  • Узкий горизонт планирования, сопутствующий реализации запросов, приводит к тому, что архитектурные решения могут приниматься даже и оптимальные с точки зрения текущего запроса, но не самые удачные с точки зрения стратегии развития системы в целом. Стратегия в данном случае теряется за большим количеством параллельных запросов на изменения.
  • Параллельно работающие команды над слабосвязанными изменениями системы часто уводят развитие архитектуры системы в различные направления, разрабатывают частично-дублирующиеся подсистемы и т.п.
Все это с течением времени приводит к постепенной деградации внутреннего качества и постепенной деградации архитектуры, а в итоге и к увеличение стоимости ее поддержки и развития.

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

В конечном итоге это приводит к смерти продукта и запуску разработки нового.
Мой сайт - www.msmirnov.ru