За свой опыт в разработке ПО я работал на многих проектах, и часто приходилось включаться в уже существующий проект или видеть как новая команда на моих проектах подхватывает проект с историей. Часто новый разработчик приходящий на проект и приступающий к выполнению задачи первым делом начинает плеваться на существующий дизайн. Ему кажется, что всё сделано не правильно, не очевидно и слишком переусложнено. И как результат, при выполнении задачи, начинают появляться дыры в уже разработанном дизайне и существующая архитектура начинает обрастать костылями. В конце концов, проект или его подсистему требуется переписать почти полностью. Чем старше проект, тем таких случаев может быть больше.
Также бывает и другая крайность, для реализации нового функционала или переделки существующего, один и разработчиков говорит: «Я знаю как сделать лучше!» после чего, вместо того чтобы дать идее «отлежаться» и оценить все плюсы и минусы, сразу начинает её делать. Где-то через месяц разработки может возникнуть ситуация, что чего-то он не предусмотрел, и приходится отказываться от разработки и выкидывать код или срочно искать варианты решения проблемы. Почти каждому разработчику в этом случае хочется сохранить лицо: «Как же так? Я же профессионал!» — думает он, «Если я признаю свою ошибку то все подумают, что я не настолько крут как всем говорю». И в этом случае Идея которая недостаточно проработана входит в проект и становится проблемой уже всей команды. Что также удорожает проект. А так как это становится заметно не сразу и внимания на причинно-следственные связи почти никто не обращает, то ситуация может повторяться снова и снова.
Все описанные выше случаи встречаются достаточно часто на всех проектах, но особенно заметы в длинных проектах с длительностью от одного года. Но есть пара техник позволяющих снижать вероятность наступления похожих случаев или исключать их совсем. Это не чистая теория, а уже готовый рецепт, который я применяю на своих проектах.
Введение
При разработке любого программного продукта всегда существует целый набор рисков, наступление любого из которых приводит к увеличению сроков разработки продукта и соответственно удорожанию проекта. Однако, среди них стоит выделить два, по моему мнению, самых важных: это автобусный фактор и архитектурный риск. Эти два риска очень сильно влияют на предсказуемость проекта. И Я не случайно выделяю их, как связанные и важные так, как при наступлении первого, увеличивается вероятность наступления второго.
Под риском «автобусного фактора» Я понимаю потерю важной информации о проекте с связи со сменой разработчиков. Важно не только КТО делал проект, а что он при этом ДУМАЛ. И обычно из кода, даже накрытого модульными тестами, не всегда понятно почему было выбрано именно это решение и зачем вот так сложно если есть множество других простых решений. Стоимость этого риска Я снижаю почти полным документированием проектного решения ДО того, как решение будет применено. А также документирование всех задач по разработке или изменению проекта. Это обеспечивает возможность единовременной смены 90% команды безопасно для проекта. Так как основная информация об Идее и ее изменениях задокументирована, что позволяет последующим разработчикам просто следовать задуманному сценарию не отметая все неправильные с их точки зрения варианты, что соответственно снижает вероятность наступления рисков связанных с архитектурой.
Архитектурным риском я буду называть риск, связанный с неправильно выбранным архитектурным решением или фреймворком или аппаратной платформой. Часто бывает, что разработке любой архитектуры проекта всегда есть шанс, что новое решение не справится с возлагаемыми на нее задачами или в самый неподходящий момент всплывет: «ой, а мы об этом не подумали». После чего, как правило начинается придумывание костылей и вариантов обхода проблемы уже на этапе реализации. Что в итоге может привести в увеличению сроков и стоимости разработки продукта.
Рецепт приготовления проекта
Возьмите стакан муки, стакан сахара… ой это не тот рецепт.
Чтобы приготовить вкусный проект, и он не подгорел вам понадобится: База знаний (вики), Маркерная доска, стикеры и несколько разработчиков…
Прежде чем подойти к поиску самих рисков, важно решить несколько вопросов еще на уровне идеи и оценить жизнеспособность самой идеи.
Все движение проекта в любую сторону я сначала блокирую формулировкой:
— У тебя есть гениальная Идея потрясающая своей новизной?
— Отлично! Задокументируй свое предложение в вики, мы его обсудим.
К этому случаю конечно может подойти формулировка «Инициатива наказуема», с одной стороны, а с другой стороны это может быть задача на прокачку аналитических способностей инженера.
Когда новая идея задокументирована, то она может немного потерять свою красочность и яркость, что позволяет ее получше обдумать и задать ей (идее) дополнительные вопросы. Иногда, после ответа на этот вопрос в письменном виде выясняется, что менять в системе ничего существенно не надо, нужно чуть-чуть подкрутить существующий процесс, или система уже умеет то, что изложено в Идее.
У этого подхода есть один маленький недостаток, который важно учитывать. Хорошие идеи могут выдавать начинающие разработчики (или кодеры), но документация идеи в базе знаний требует уже относительно продвинутого уровня аналитических способностей. И тут возможно два варианта развития события, с одной стороны задача может быть расценена исполнителем как задача на развитие навыков архитектора, или он может заявить что «мне за это не платят», если ему не хочется дополнительно думать. Поэтому тут важно не перегнуть палку и вовремя заметить наличие желания анализировать у автора Идеи.
Если идея действительно стоящая и требует реализации, то переходим к шагу два:
К чему приведет внедрение этого решения?
У любого изменения проекта могут быть очевидные последствия и не совсем очевидные, на этом шаге наша задача найти все не очевидные последствия внедрения Идеи. Для выяснения всех последствий в Теории Ограничений Систем (ТОС) есть замечательный инструмент Дерево Будущей реальности (ДБР). поэтому, рисуем на доске дерево будущей реальности, смотрим последствия, если есть нежелательные явления (НЖЯ), то ищем варианты блокировки таких явлений, то есть какими способами мы можем снизить влияние нежелательных явлений на систему. Может случиться, что нежелательных явлений появляется столько, что имеет смысл отложить Идею до лучших времен. Или, же, мы находим более элегантные варианты изменения архитектуры системы.
Пояснение: Дерево будущей реальности, это диаграмма причинно-следственных связей показывающая как наше изменение системы повлияет на систему после его внедрения (подробности).
Мы выяснили все нежелательные явления и нашли способы снизить их влияние на наш проект, однако появляется вопрос:
Всех ли целей мы достигнем этим решением?
Для ответа на этот вопрос, можно дополнить существующее ДБР или нарисовать новое но уже построенное от целей. На построенном дереве должно быть хорошо видно за счет чего мы будем достигать поставленных целей. Так, как дерево представляет собой причинно-следственные связи, то мы может отследить: «а достигаем ли мы своих целей?» или какие-то из намеченных целей останутся за пределами изменений. Если какие-то из целей не достигаются нашим решением, или появляются нежелательные явления (НЖЯ), то необходимо продумать улучшения Идеи так чтобы на дереве не осталось открытых НЖЯ и все поставленные цели достигались.
После этого шага, как правило архитектурное решение имеет законченный вид, но это еще не повод сразу его внедрять:
Сколько стоит внедрение решения?
Любое изменение проекта стоит и денег и времени. Всегда стоит вопрос в том, готовы ли мы инвестировать средства сегодня или можно отложить на завтра. Для изменения расписания проекта может потребоваться дополнительное согласование с третьими лицами (заказчиками, начальниками и тд). На этой фазе, новое решение нужно разбить на задачи и оценить, хотя бы с какими то допусками. Что позволит, к моменту обсуждения с заинтересованными лицами, иметь детальный план по внедрению и более предметно обсуждать сроки и затраты.
Мы выяснили почти всё о нашей новой идее, и подготовили предмет для переговоров, однако:
Есть ли альтернативы, и сколько они стоят?
Всегда есть альтернативные решения, более простые или более сложные, но они есть. И у этих решений тоже есть стоимость и вероятная «прибыль», может оказаться и так, что альтернативное решение будет лучше изначально предложенного. Но на этот вопрос можно ответить только тогда когда Идея задокументирована в базе знаний, а не крутится в голове разработчика в виде «У меня есть Идея и я ее сейчас реализую». Вполне может быть, что проще купить сторонний продукт или даже Компанию чем делать какую-то работу самостоятельно.
Если ответы на данные вопросы показывают эффективность нашей Идеи, её реализуемость и «дешевизну» реализации по сравнению с аналогами, то задаем самый важный вопрос:
Что нам может помешать при внедрении/реализации решения?
При ответе на этот вопрос мы выявляем все или большую часть архитектурных рисков которые нам могут помешать. На одном из последних обсуждений главными рисками стали:
- Достигнем ли заданной производительности?
- А есть ли в этом фреймворке функционал который нам нужен?
- Реализуемо ли наше решение теми средствами которые мы задумали?
Дальнейшая разработка начинается со снижения архитектурных рисков путем разработки нескольких прототипов которые проверяют каждый риск на влияние. Сами прототипы делаются по принципу hacker-driven-development (у меня есть мысль и я ее закодирую) поэтому достаточно дешевые. В то время, как внедрение решения в проект, может быть весьма дорогим и долгим.
На этапе проверки архитектурных рисков конечно могут возникнуть проблемы, что тот или иной риск сработает, но на это имеет смысл заложиться сразу и запланировать работу по «Плану Б» где будут исследоваться альтернативные варианты. Если риск не сработал значит Вам повезло, в противном случае будет затрачено дополнительное время на исследования.
Итог
… через 40 минут вынимаете из духовки, пирог готов.
Ответы на все вопросы получены, все риски успешно решены, Ваш проект становится более предсказуемым и дальнейшая разработка будет идти по плану, без неожиданных отклонений.
Коллеги, а как Вы готовите свои проекты?
Другие рецепты
Автор: sbase
