В теме 8 ответов, и 4 участника, последнее обновление сделано пользователем 
Igor Tkachenko 13 г, 6 мес. назад.
-
Сообщения
-
Сам по себе процесс анализа позволяет сделать так чтобы разработка прошла максимально предсказуемо, а клиент добился поставленных целей с минимумом затрат (или отказался от своих замыслов).
Но если взглянуть на процесс анализа со стороны (т.е. проанализировать его). То, в некотором роде, мы увидим, что он из себя представляет моделирование всего того, что могло бы произойти с проектом в будущем — не будь этого самого анализа.
В достаточно сжатые сроки (от недели до месяца) аналитик, по сути, перебирает варианты того чем может стать система и чего это будет стоить. Конечная цель — выбрать подходящий вариант.
Этот процесс происходит не путем генерации всех возможных решений, состоящих из различных требований и выбора оптимальной комбинации, а скорее путем последовательного наращивания требований, которые создавали бы минимум стоимости и максимум пользы.
Однако, при подборе каждого отдельного решения приходится перебирать множество вариантов, моделировать множество ситуаций, проверять их на соответствие ряду критериев.
Т.е. аналитик тратит время на то чтобы "пережить" тупиковые ветви развития, или отвалидировать обосновать и подробнее расписать верные и очевидные решения.
Я так и не смог найти каких-то внятных решений на тему того:
1) как в зачатке отрубить тупиковую ветвь анализа и не потратить на нее время именно самого анализа.
2) как не начать анализировать заведомо верные не требующие пояснений или подтверждений части решения и не потратить на это время аналитика (хотя тут больше ответов, но тут и меньше потерь похоже).
3) как не потратить время аналитика на "ненужные" требования и артефакты которыми не воспользуются по причинам того, что это не критично или очевидно.
3.1) как увеличить плотность "критически важной" информации в артефактах, чтобы повысить продуктивность их использования на всех стадиях создания приложения и снизить затраты на их сопровождение.P.S.> Давайте без Agile. Я долго придумывал как коротко написать почему нет. Но решил, что кто не троль — тот и так поймет. А кто хочет сделать вброс с этой стороны. Вот вам пища для размышления:
Проект который требует дня разработки (т.е. чтобы подкорректировать неверный прицел, скорее всего придется сделать выстрел равный предыдущему, и agile повысит стоимость проекта в 2 раза).
Таких примеров я могу составить много, и все они будут реальными. Но я боюсь, и так, что начнется их обсуждение, а не обсуждение проблемы. Которая собственно agile и породила.
После прочтения ПСа прочитайте еще раз проблемы. Суть моих изысканий: применять анализ к процессу анализа. И попытаться сделать его значительно более lean по отношению к самому себе. Возможно я загнался и не вижу очевидных вещей, причем в тех местах, которые скорее всего читал или видел.Вопрос поняла, проблема в чем?
С одной стороны, процесс работы над требованиями итеративен. Возможно есть аналитики, которые молча колбасят спеку в 200 страниц без обсуждения с заказчиками или кем бы то ни было, а потом дают ее на подпись — и заказчик подписывает не глядя, ибо 200 страниц — это слишком много для того, чтобы все понять в сжатые сроки. Возможно бывает и так. И спустя некоторое время выясняется, что эти 200 страниц — это вообще "не туда", и проще все выкинуть, чем исправить.
Нормальная практика — валидировать требования порциями. С одной стороны, есть высокоуровневое видение всей системы, для того, чтобы ни одна из порций в итоге не выбивалась из общей картины. С другой — проанализоровали какую-то фичу, описали ее — далее валидация. Выяснилось на этом этапе, что что-то пропущено, неправильно — добавили, исправили. Как можно заранее узнать о тупиковости какой-то ветки? Со 100% вероятностью — никак. На встрече прозвучало 2 волшебных слова — impact analysis, вот он может гарантировать, что среди требований нет таких, которые противоречат друг другу. В примере, который прозвучал на встрече (о передаче файлов большого размера), он явно не проводился. У аналитика не было в голове всей картины, только разрозненные куски требований, вот откуда проблема.
С другой стороны, если в процессе меняется бизнес-цель (именно меняется, а не изначально неправильно определена), в чем проблема изменить требования, если заказчик готов это оплатить?
Вообще дискуссия получилось бы предметнее, если бы вы привели какой-нибудь пример из жизни.Все это правильно (impact и прочее). Но оно позволяет откинуть неверное решение когда то уже сформулировано. А искать и формулировать можно довольно долго. Да и impact можно потом делать не быстро.
Но ведь неверная ветка развития решения появляется начиная с какого-то направления решения. Т.е. мы можем поменять курс еще в момент, когда мы еще только выдвигаем гипотезу о том из какой области будет решение. И не тратить время на более точное формулирование решения, и его анализ.
На сколько я понимаю ситуацию: хороший опытный аналитик делает это интуитивно. Основываясь на своем опыте. Но то что мы делаем не сознательно может срабатывать не всегда. Т.к. мы это не контролируем. Да и срабатывать это может только со знакомыми ситуациями.
Но ведь в этом поведении должна быть какая-то закономерность. Какой-то паттерн. Зная который можно сознательно контролировать управление направлением решения.Например, в докладе "ТРИЗ" Андрей Курьян демонстрировал схему того, почему метод выбора решения путем перебора может нерационально потреблять ресурсы (а ведь генерация требований и последующий impact — это и есть метод перебора. Мы выставляем гипотезу и проверяем ее).
Вопрос — не как получить хорошее решение. А как сократить время потраченное на анализ и получить тоже решение, не прибегая к agile практикам (потому что нет времени на попробовать, или нельзя оценить экономическую целесообразность без полной картинки решения ввиду его небольших размеров, например).
Прихожу к одному выводу. Если никто не понимает вопроса. Значит ни у кого нет данной проблемы. По крайней мере никто не пробовал ее решать. И каких-то рекомендаций дать не может.
Я не вижу проблемы, серьезно. Как можно сократить время, затрачиваемое на анализ, и сразу понять, той ли дорогой пошел? Для меня это вопрос опыта, причем различного:
1. Аналитического опыта, полученного в одном домене на разных проектах
2. Аналитического опыта, полученного в разных доменах
3. Неаналитического опыта из любых других областей (и при этом не обязательно вообще из IT сферы).Чем больше разноплановых проектов реализовано, тем больше знаний у аналитика про возможные методы решения типовых проблем, их сильные и слабые стороны. Интуиция не работает без багажа знаний. И интуитивное понимание правильности или неправильности решения, своеобразные инсайты, возможны только тогда, когда мозгу хватает материала для обработки (пусть сам процесс и остается неосознанным). Сомневаюсь, что использование какой-либо хитрой методологии может компенсировать это отсутствие знаний и опыта. Другой вопрос в том, что делают с этим опытом: проводят ли какие-то ретроспективы, анализируют ли, что было сделано хорошо, а что могло бы быть сделано и получше. Иначе и этот принцип не будет работать.
Давайте рассмотрим фрагмент действий аналитика.
1) сбор и анализ требований
2) превращение требований в решения
3) анализ решений. если все хорошо, то идет дальше. если нет, возвращается к п.1,2.Как аналитик превращает требования в решения?
1) использует готовые типовые решения (наиболее распространенный вариант). аналитик должен знать много решений
2) использует готовые паттерны и конкретизирует их. Паттерн по сути представляет собой обобщенное решение. аналитик должен знать много паттернов. паттернов меньше, чем решений, но они "покрывают" большее количество конкретных решений.
3) Если решений или паттернов нет, то использует системные знания, в т.ч., знания законов развития систем, и, опираясь на эти знания, конструирует собственное решение. По сути, системные знания представляют собой паттерны высокого уровня обобщения. Например, если речь идет о конструировании управленческой системы, то на самом верхнем уровне в качестве обобщенного паттерна можно использовать цикл Деминга (PDCA). Другими словами, цикл PDCA задает структуру решения верхнего уровня.
4) Если все предыдущие методы не подошли, то аналитик включает турбо-режим ППП (пол-палец-потолок).Как только получены частные решения, аналитик получает в свое распоряжение поле для деятельности. Отдельные решения нужно согласовать между собой. Одни решения могут противоречить другим. Отдельные решения можно объединять вместе и "сворачивать" ("свертывать") друг с другом. Собственно, поле для творчества становится безграничным.
Критерии проверки известны:
- повышение идеальности решений (степень идеальности);
- повышение идеальности процесса реализации решений (идеальный конечный результат).В принципе, последовательность шагов ( 2) получить решения; 3) анализировать решения ) можно делать параллельно, точнее, итерационно.
Опытный аналитик видит "картину в целом" и сразу выбирает правильные решения, без ревизий (итераций). Опыт аналитика играет еще одну важную роль: аналитик не боится "оставлять в тылу" белые пятна, потому что уверен, что справится с любыми проблемами, если они появятся.
Игорь, у меня к тебе просьба: приведи, пожалуйста, конкретный пример. Если хочешь, давай с тобой в скайпе/устно пообщаемся и обезличим этот пример. Просто как я вижу, все (и я в том числе) не до конца понимают проблему, которую ты хочешь поднять, но, судя по тому, что я могу понять и судя по твоей настойчивости, мне кажется, проблема важная и интересная. Я вижу, что по сравнению с описанием проблемы на встрече, текущее описание значительно улучшилось и я начал понимать хотя бы, в каком направлении думать, но всё же не хватает конкретики. И, как мне кажется, Ася и Андрей ответили не совсем на твой вопрос.
В общем, жду от тебя вестей (;Да — не ответили. Народ рассказывает просто то что знает. За что им спасибо. Т.к. я хотя бы убеждаюсь, что в остальном я ничего не упускаю. Т.к. я все-таки программист а не аналитик.
Ладно пример.Например, я работаю над улучшение процесса разработки (именно той части где проект находится в руках у девелоперов).
Для чего, вначале, ищу проблемы в существующей системе. Затем беру ряд методологий по организации таких процессов. Смотрю какие из них решают имеющиеся проблемы. Делаю выбор. Затем стоит задача адаптировать.
Это значит: надо учесть те тонкости, которые порождает конкретно наш контекст (уровень подготовленности людей, специфика проектов и т.д.).И тут начинается самое веселое. Вроде бы общая картина имеется, но. Есть неприятные белые пятна в общем решении которые не покрывают часть конкретно нашей ситуации. + Внедрение нового процесса, вместо старого, без остановки производства — штука сложная. И здесь приходится крутиться самому — нигде же не написано как и что заменить конкретно для нашей ситуации, когда в каком порядке и т.д..
Короче простора для фантазии больше чем хотелось бы.
По сути, каждый to-be предложенный в методологии надо разобрать и собрать заново. А в инструкциях описывающих активности учесть имеющиеся обстоятельства (для чего часто нужно искать дополнительные решения или выдумывать свои).
Процесс этот довольно трудоемкий (как не странно).
Приходится детально прорабатывать активности (т.к. предложенные в методологии примеры и советы не подходят) — иначе исполнители попросту наделают никому ненужных вещей.
Так вот, когда прорабатываешь процесс из твоего контекста появляются какие-то препятствия. Для устранения препятствий вводишь дополнительные решения (новые активности, правила для существующих активностей и т.д.). Но все эти сопли могут лезть совсем не от того что действительно есть столько проблем, которые нужно решать, а просто от того, что направление решения, на какой-то стадии, было выбрано не верно.
Например получается что не стоит брать какой-то отдельный подпроцесс из рассматриваемой методологии, а стоит заменить его чем-то другим. Или процесс взят верно но реализации отдельных активностей определены не подходящим образом.Источник конкретно этой ситуации в том что:
не существует готовых решений — есть только полуфабрикаты. — и приготовить их можно по разному, как здесь это уже было отмечено. И вот, процесс выбора полуфабриката и попытка его подготовить может занимать несколько дней. А когда в конце или в середине оказывается что есть нюансы, которые свидетельствуют о том, что с этим полуфабрикатом ничего не выйдет и надо брать другой — получается выброшенное время.Так вот:
1) Нет ли какой-то стандартной методики которая с минимумом затрат позволяет предварительно проверить полуфабрикат или новое решение на возможность быть приготовленным и съеденным?
Предварительно — значит не моделируя.
2) Или методика которая укажет верное направление?
Верное направление — например, характеристики возможного решения, которые не сложно проверить (можно проверить простым "осмотром")
(в целом задача на сходимость-расходимость системы — если кому-то так будет понятнее)Я думаю, что такая проблема есть в анализе любого проекта и сжирает она пропорционально времени (иначе на проекте аналитик реально не нужен или нужен чтобы рассказать известное и подходящее решение, а это не аналитик а скорее консультант). Потому что анализ это во многом и есть моделирование с целью проверки подходит решение или нет. Но число проб нужно минимизировать. Например, можно из аджайл реверсировать и адаптировать как-то правило первой пули. Т.е. что-нибудь типа: первое решение мы выбираем произвольное. Честно собираем все грабли. Потом на основе этого как-то формируем сразу верное подходящее решение. Правда это тоже с большой вероятностью две попытки. И значит то что можно "проанализировать" за две недели реально придется делать от двух недель до месяца.
P.S> Судя по тому что рассказывал Андрей на конференции — триз просится на роль решения. Но я не понимаю каким боком его здесь приткнуть.
Agile в моем случае не подходит. Потому что требования и цели не меняются — раз. Потому что менять людям энвайромент каждый месяц с целью корректировки проблем и недочетов — это садизм — два (если честно, уже попробовали).
Для агелистов, которые решат учить меня как непосредственно надо строить процесс разработки: решение Agile с тем что люди сами организовывают себе эвайромент — не подходит (мы от него собственно и уходим). С нашим (беларуским) менталитетом я вообще сомневаюсь, что это может прокатывать, за очень редким исключением (распинаться и объяснять почему — не буду).
Так.. из того, что я понял
1. Хочется решить задачу ещё до моделирования. Т.е. последовательность мыслей такая:
а) т.к. создание большой информационной системы очень трудоемко (и если будет сделано неправильно, то потом потребует переделок, которые будут ооой как дороги), то давайте мы её смоделируем, это дешевле и быстрее
б) т.к. бывают такие системы, что даже их моделирование занимает ооой как много и ооой как дорого стоит, то вопрос в том — нет ли чего-нибудь такого быстрого и дешёвого, что поможет понять "а надо ли моделировать?"Правильно?
Дальше.
Само собой, что все методологии, паттерны и т.д. дают решение общих задач. Если бы было что-то, что давало бы ответ на все-все будущие случаи и возможные варианты, то это была бы полная жесть и жить стало бы скучно и неинтересно. Эдакая методичка на все случаи жизни. Ну подумай сам, неужели ты бы так хотел, м?И вторая часть мармезонского балета.. приведённый пример. Могу ли я в своих рассуждениях обсуждать именно его (оптимизация работы команды разработчиков) и рассматривать его как раз как ту самую проблему, которую ты, Игорь, хочешь решать?
Такс. Свою задачу я решил и и решаю (могу развивать). Явной проблемы нет (отсутсвия решений или непомерно разросшихся сроков). Суть в том: как быстрее решать подобные задачи (а не как их вообще решать). Т.е. целью изысканий в данном случае скорее является процесс анализа а не конкретное решение ему подверженное.Я понимаю, что нельзя найти идеальное решение: т.е. нельзя придумать способ придумывания решений без необходимости преодолевать трудности — иначе все системы в мире начнут развиваться со скоростью стремящейся к бесконечности — а это невозможно.
Однако мы всегда можем улучшить существующую систему на сколько нибудь процентов. В случае проектов которые требуют нескольких недель анализа 20%-30% — это будет шикарный результат. Но упоминания о каких-то методиках, которые позволяют валидировать направление решения на ранней стадии — я не нашел. Да и не обязательно какое-то целостное решение.
Может быть есть какие-то рекомендации. Например: если решение подзадачи не приводит к схождению системы больше 2х раз (т.е. генерятся новые подзадачи) необходимо сменить направление решения — это гипотетический пример (такого правила нет).Если нет. Можно попытаться скинуться своими рекомендациями (приемами, которые позволяют нам во время остановиться).
Может быть среди них можно будет установить какие-то общие тенденции.
Самое расточительное по отношению ко времени действо — это прорабатывать решение которое не будет реализовано, с другой стороны это работа аналитика (ну условно). Поэтому, скорее всего, проблема не очевидна )У меня таких рецептов нет. Я об этой проблеме задумался только около месяца назад.
Вы должны авторизироваться для ответа в этой теме.
