Comments 38
Из описания CMMI-0 в каком-то фициальном документе мне понравилось «Производственный процесс подобен хаосу, результат достигается за счет героического усилия отдельных лиц»
Вот если бы автор изложил предложенную шкалу с характеристиками отдельных этапов своими словами, исходя из собственного опыта — было бы гораздо интереснее. Сейчас же первое, что приходит в голову при ознакомлении с предложенной классификацией — «поверхностная», «формальная», «местами подменяющая понятия». Впрочем, это могут быть и проблемы перевода. Примеры ниже.
И да… Что я отчаянно люблю в моделях зрелости, так это то, как скромно молчат их продвиженцы о естественных результатах любого процесса взросления. Да и сами модели этот вопрос обходят как-то стороной. :)
Пример 1.
«Первый шаг перехода от полного отсутствия требований к их появлению — это выявление и документирование требований.»
Первый ли? Вот, например, отечественные ГОСТы 19 и 34 серии. Они позволяют документировать требования в ряде простых и непритязательных документов, которые отвечают всем перечисленным в пункте критериям.
А кроме того, они в своем составе предполагают много чего разного, включая инструменты трассировки, характерные лишь для 4-го уровня предложенной классификации.
Пример 2.
«набора требований который понятно, непротиворечиво и однозначно описывает желаемое поведение разрабатываемого продукта. Для того, чтобы получить требования с указанными критериями качества, необходимо придерживается принятых правил оформления спецификаций, хранить их в доступном всем участникам проекта месте, разграничить права доступа к требованиям и вести историю изменений.»
«Для продолжения рода нужно совсем другое» (с) «Тот самый Мюнхгаузен»
Все перечисленное «необходимое» улучшит лишь доступность набора требований (как техническую, так и в какой-то степени «когнитивную»). Перечисленные условия не имеют ничего общего с обеспечением непротиворечивости и однозначности. «Понятность» же в первую очередь зависит от косноязычия формулировщика требований, и только затем (не сильно) от выбранного способа их оформления.
Пример 3.
«Таким образом, на третьем уровне зрелости выполняются активности по планированию процесса управления требованиями и группировки выявленных требований по типам в соответствии с объединяющими признаками, что облегчает управление и приводит к лучшему пониманию требований всеми участникам проекта.»
Можно подумать, на других «уровнях зрелости» об этих активностях никто и не помышляет. Например, двумя уровнями ранее, без всяких специальных инструментов запросто происходит и планирование управления, и само управление, и группировка требований.
И да… Что я отчаянно люблю в моделях зрелости, так это то, как скромно молчат их продвиженцы о естественных результатах любого процесса взросления. Да и сами модели этот вопрос обходят как-то стороной. :)
Пример 1.
«Первый шаг перехода от полного отсутствия требований к их появлению — это выявление и документирование требований.»
Первый ли? Вот, например, отечественные ГОСТы 19 и 34 серии. Они позволяют документировать требования в ряде простых и непритязательных документов, которые отвечают всем перечисленным в пункте критериям.
А кроме того, они в своем составе предполагают много чего разного, включая инструменты трассировки, характерные лишь для 4-го уровня предложенной классификации.
Пример 2.
«набора требований который понятно, непротиворечиво и однозначно описывает желаемое поведение разрабатываемого продукта. Для того, чтобы получить требования с указанными критериями качества, необходимо придерживается принятых правил оформления спецификаций, хранить их в доступном всем участникам проекта месте, разграничить права доступа к требованиям и вести историю изменений.»
«Для продолжения рода нужно совсем другое» (с) «Тот самый Мюнхгаузен»
Все перечисленное «необходимое» улучшит лишь доступность набора требований (как техническую, так и в какой-то степени «когнитивную»). Перечисленные условия не имеют ничего общего с обеспечением непротиворечивости и однозначности. «Понятность» же в первую очередь зависит от косноязычия формулировщика требований, и только затем (не сильно) от выбранного способа их оформления.
Пример 3.
«Таким образом, на третьем уровне зрелости выполняются активности по планированию процесса управления требованиями и группировки выявленных требований по типам в соответствии с объединяющими признаками, что облегчает управление и приводит к лучшему пониманию требований всеми участникам проекта.»
Можно подумать, на других «уровнях зрелости» об этих активностях никто и не помышляет. Например, двумя уровнями ранее, без всяких специальных инструментов запросто происходит и планирование управления, и само управление, и группировка требований.
Leonid76, я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий. А встречал, когда наоборот — документы по указанным стандартам готовились постфактум и носили формальный характер. Если же требования и готовились перед началам проекта, то исключительно для того, чтобы потешить самолюбие заказчика, повторяющего магическое заклинание: «Техническое задание». После чего про документ забывали и начинали просто «кодить».
По поводу косноязычия согласен, но уверен, что не один я сталкивался с «трудностями перевода» при чтении документа, написанного литературным языком, но сплошным текстом.
В статье категорично не заявляется, что структурирование требований должно производиться исключительно с использованием специализированных инструментов. Указанные активности являются показателями зрелости процесса и если команда проекта прибегает к ним ранее, то это говорит исключительно об ее профессионализме.
По поводу косноязычия согласен, но уверен, что не один я сталкивался с «трудностями перевода» при чтении документа, написанного литературным языком, но сплошным текстом.
В статье категорично не заявляется, что структурирование требований должно производиться исключительно с использованием специализированных инструментов. Указанные активности являются показателями зрелости процесса и если команда проекта прибегает к ним ранее, то это говорит исключительно об ее профессионализме.
я еще ни разу не встречал
А я встречаю регулярно. В основном — по 34 серии. Когда и ТЗ, и технорабочий проект — не формальность, а насущная потребность. И в отношениях с заказчиком, и в организации разработки (особенно когда работает несколько команд от разных юрлиц, да еще и раскиданных по разным городам).
Разумеется, количество таких проектов на нашем ИТ-рынке сильно меньше, чем «сделайте мне магазин, быстро и дешево».
В статье категорично не заявляется, что структурирование требований должно производиться исключительно с использованием специализированных инструментов
Разве?
Уровень 3. Структурирование требований
На данном уровне зрелости возникает необходимость применения специализированных инструментальных средств, предназначенных для работы с требованиями.
если команда проекта прибегает к ним ранее, то это говорит исключительно об ее профессионализме
Либо о недостатках классификации.
Поймите правильно — я не стараюсь забросать статью экскрементами. Просто становится не по себе, когда неплохие, в общем, мысли продвигаются в жизнь в такой вот наивной оболочке. Это чревато вполне измеримыми потерями и снижением КПД нашего «производства».
Кроме всего прочего, такое вот разделение на «уровни взросления» между строк говорит, что 1 — это детский лепет, а 5 — это круто и солидно. Но в реалиях, 5й уровень — это высочайшей цены компромисс между управляемостью и производительностью рабочих команд в масштабах крупных организаций. И у него масса отрицательных эффектов. Один из них — то, что фокус профессионального мастерства «постановщика требований» смещается от содержания к форме (от самих требований к инструментам управления ими). То есть, специалист считается крутым не потому, что он круто обращается с требованиями, а потому, что у него 5-й дан по какому-нибудь энтерпрайз-архитектору.
разделение на «уровни взросления» между строк говорит, что 1 — это детский лепет, а 5 — это круто и солидно
В свое повествование я вкладывал несколько иной смысл:
принятие решения о достижении того или иного уровня зрелости процесса управления требованиями должно осуществляться взвешено и на основании четкого понимания целей и задач, стоящих перед командой проекта или компанией
и еще
достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом
Я сам сторонник того, что бОльший уровень развития порождает бОльшие накладные расходы. Это не всегда бывает оправдано и только крупная компания может себе позволить пожертвовать производительностью в угоду управляемости.
Что же касается категоричности, то я смягчил формулировку в статье.
Leonid76, спасибо за обратную связь!
В свое повествование я вкладывал несколько иной смысл:
Это неотъемлемый атрибут моделей взросления. Мол, «взрослеть надо, чада неразумные».
Пришлось бы приложить очень большие усилия, чтобы его нивелировать. Гораздо больше процитированных. А самое главное, делать это особо незачем. Иначе суть подхода теряется.
принятие решения о достижении того или иного уровня зрелости
Сейчас звучит примерно как «всё, я решил, что мне теперь есть 18!»
Наверное, можно принять решение о приведении процессов в соответствие с требованиями того или иного уровня зрелости. Но решить, что «мы теперь зрелые вот на столько» — это вряд ли.
и только крупная компания может себе позволить пожертвовать производительностью в угоду управляемости.
Гм… Скорее, крупная компания не может себе позволить не жертвовать. Иначе у нее будет беда. Исключение — крупные компании, состоящие из относительно маленьких полуавтономных «ячеек».
спасибо за обратную связь!
Рад стараться!
«я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий.»
ГОСТ 34 — не на программы, а не информационные системы, если вы последними не занимались, немудрено, что вы не встречали :)
А ГОСТ 19 достаточно простой по сути, там значимых разделов — раз-два и обчёлся, поэтому сейчас распространены более современные стандарты на структуру требований типа IEEE 838: school.system-analysis.ru/standards/
ГОСТ 34 — не на программы, а не информационные системы, если вы последними не занимались, немудрено, что вы не встречали :)
А ГОСТ 19 достаточно простой по сути, там значимых разделов — раз-два и обчёлся, поэтому сейчас распространены более современные стандарты на структуру требований типа IEEE 838: school.system-analysis.ru/standards/
Что за мещанская склонность к искажению смысла цитируемого текста и желание интерпретировать его в удобном для себя контектсте? А контекст тут простой — самопиар, ведь цитирующий руководит и преподает в указанной Школе.
Моя фраза полность звучит так:
Кроме того, в ГОСТ'е нет понятия «информационная система», а есть термин «автоматизированная система» (см. ГОСТ 34.003-90). Именно это, а не выдернутая из контекста фраза, иллюстрирует кто с чем не знаком. :)
Моя фраза полность звучит так:
Я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий. А встречал, когда наоборот — документы, по указанным стандартам, готовились постфактум и носили формальный характер.
Кроме того, в ГОСТ'е нет понятия «информационная система», а есть термин «автоматизированная система» (см. ГОСТ 34.003-90). Именно это, а не выдернутая из контекста фраза, иллюстрирует кто с чем не знаком. :)
Все верно, но это отлично работает, когда есть заказчик и его требования. Да, есть такое мнение, что заказчик бывает внутренним. Верно, бывает, но формализация этих отношений как с внешним заказчиком часто несет лишние риски проекту. (Это отдельная большая тема, достойная большой статьи)
Если разработка продуктовая и тем более инновационная (стартапы) — требования превращаются в гипотезы и эксперименты. В таком режиме строгое структурирование требований часто вступает в противоречие с гибкой разработкой. Это уже высший пилотаж, управления требованиями в гибкой разработке.
Если разработка продуктовая и тем более инновационная (стартапы) — требования превращаются в гипотезы и эксперименты. В таком режиме строгое структурирование требований часто вступает в противоречие с гибкой разработкой. Это уже высший пилотаж, управления требованиями в гибкой разработке.
ncix, не соглашусь! Не важно, какой заказчик — внешний или внутренний, важно, что у каждого программного продукта есть заинтересованное лицо или лица, которые ждут от него разрешения своих проблем (удовлетворения потребностей). И команда проекта должна быть нацелена как раз на удовлетворение этих самых потребностей, а не на реализацию собственного видения решения, изучение новых технологий и т.д. То есть основная задача состоит в синхронизации видения конечного продукта между всеми участниками проекта. В каком виде описывать и насколько подробно доносить — это вопрос другой, но требования должны быть!
Вы с чем именно не согласны?
Требования конечно должны быть, только эти требования — гипотезы. Т.е. мы предполагаем что клиенты захотят такой продукт с такими фичами. Через полгода выясняется что не с такими а с другими. А мы уже два месяца потратили на спеку и ее согласование и 4 на первый черновой релиз.
В такой ситуации требования должны максимально быстро перемещаться из области идей в задачу разработчику.
Требования конечно должны быть, только эти требования — гипотезы. Т.е. мы предполагаем что клиенты захотят такой продукт с такими фичами. Через полгода выясняется что не с такими а с другими. А мы уже два месяца потратили на спеку и ее согласование и 4 на первый черновой релиз.
В такой ситуации требования должны максимально быстро перемещаться из области идей в задачу разработчику.
Не согласен с тем, что Вы заведомо усложняете. Разве где-то сказано, что для проверки гипотезы нужно потратить большое количество времени на разработку спецификации по стандарту IEEE 830, например? Скорее наоборот.
Но тогда я не очень понимаю: если для проверки гипотезы нужно что-то запрограммировать, требования на данном этапе будут или нет?
И еще, управление требованиями подразумевает многоэтапное и многоуровневое их согласование. Что, без должного вмешательства, очень сильно растягивает разработку. Поэтому, управляя требованиями, нельзя забывать об эффективности согласовательного процесса между участниками.
Нет, не подразумевает. Оно вполне может быть, но не обязано.
Ок, возможно, бывают ситуации когда Заказчик (или Product Owner) написали спеку со своим видением, а разработке остается только взять под козырёк и делать. Но я такого никогда не видел.
Обычно спеку согласуют как минимум с экспертом по разработке, который должен сказать реализуемо ли это, в какой сррок и какими ресурсами. Если проект большой — таких экспертов несколько. А результат экспертизы может запросто привести к пересмотру требований, т.к. оценочные качество-сроки-ресурсы не устроят заказчика.
Обычно спеку согласуют как минимум с экспертом по разработке, который должен сказать реализуемо ли это, в какой сррок и какими ресурсами. Если проект большой — таких экспертов несколько. А результат экспертизы может запросто привести к пересмотру требований, т.к. оценочные качество-сроки-ресурсы не устроят заказчика.
В реальности почти всегда обязательно, т.к. в любом серьезном проекте у лиц, уполномоченных утверждать окончательный вариант требований, нет ни компетенций, ни времени (это просто не их задача) писать требования самим. А раз автор и утверждающий — разные лица, то процесс согласования неизбежен. Продуктовая разработка имеет свою специфику, но там мороки с огласованиями (правда уже внутри компании-вендора) не меньше
Процесс согласования неизбежен. Избежны такие вещи, как многоуровневость и многоэтапность.
Пример многоуровневости (как это могло бы быть прописано в Регламенте управления требованиями):
Порядок согласования требований.
Сформулированное требование согласуется в следующей последовательности:
1. С руководителем группы разработки.
2. С руководителем проекта ООО «Василек».
3. С ответственным за раз/дорабатываемый продукт ООО «Василек»
4. С функциональным заказчиком.
5. С руководителем проекта от Заказчика.
6. С генеральным директором ООО «Василек».
7. С генеральным директором Заказчика.
Там же, уже про этапы:
Этапы согласования требований
Для согласования с руководителем группы разработки (РГР) устанавливаются следующие этапы:
1. Предоставление требований на ознакомление — не менее, чем за 10 дней до плановой даты их согласования.
2. Отработка замечаний и предложений руководителя группы разработки — не позднее, чем за 3 дня до плановой даты их согласования.
3. Устранение финальных замечаний — не позднее дня плановой даты согласования требований.
Для согласования с руководителем проекта устанавливаются следующие этапы:
1. Предоставление требований на ознакомление — не менее, чем за 15 дней до плановой даты их согласования.
…
и т.д.
А по факту, аналитик пришел к программисту, спросил «я тут такую хрень придумал, закодить сможешь?». По получении утвердительного ответа пошел к заказчику и сказал: «мы для тебя разработали уникальное, не имеющее аналогов по эффективности решение!...» а дальше — рассказал про то, как замечательно свежепридуманная хрень порешает задачи заказчика до полного восторга у последнего. Менеджер продукта? Нет такого. Архитектор? А ему пофиг. Директор? Да он потом на всем техпроекте оптом распишется.
Пример многоуровневости (как это могло бы быть прописано в Регламенте управления требованиями):
Порядок согласования требований.
Сформулированное требование согласуется в следующей последовательности:
1. С руководителем группы разработки.
2. С руководителем проекта ООО «Василек».
3. С ответственным за раз/дорабатываемый продукт ООО «Василек»
4. С функциональным заказчиком.
5. С руководителем проекта от Заказчика.
6. С генеральным директором ООО «Василек».
7. С генеральным директором Заказчика.
Там же, уже про этапы:
Этапы согласования требований
Для согласования с руководителем группы разработки (РГР) устанавливаются следующие этапы:
1. Предоставление требований на ознакомление — не менее, чем за 10 дней до плановой даты их согласования.
2. Отработка замечаний и предложений руководителя группы разработки — не позднее, чем за 3 дня до плановой даты их согласования.
3. Устранение финальных замечаний — не позднее дня плановой даты согласования требований.
Для согласования с руководителем проекта устанавливаются следующие этапы:
1. Предоставление требований на ознакомление — не менее, чем за 15 дней до плановой даты их согласования.
…
и т.д.
А по факту, аналитик пришел к программисту, спросил «я тут такую хрень придумал, закодить сможешь?». По получении утвердительного ответа пошел к заказчику и сказал: «мы для тебя разработали уникальное, не имеющее аналогов по эффективности решение!...» а дальше — рассказал про то, как замечательно свежепридуманная хрень порешает задачи заказчика до полного восторга у последнего. Менеджер продукта? Нет такого. Архитектор? А ему пофиг. Директор? Да он потом на всем техпроекте оптом распишется.
аналитик пришел к программисту, спросил «я тут такую хрень придумал, закодить сможешь?». По получении утвердительного ответа пошел к заказчику и сказал: «мы для тебя разработали уникальное, не имеющее аналогов по эффективности решение!...»
Только потом окажется что программист закодил не то и не через 2 дня а через две недели. И ответит, что о сроках его не спрашивали, а задание он со слов аналитика понял именно так, как сделал. А клиент посмотрев на решение, отказался покупать. И с кого спрашивать, если нет официального согласования?
И, главное, где тут формализованные структурированные требования? В словах аналитика?
Только потом окажется что программист закодил не то и не через 2 дня а через две недели.
Это уже реализация, а не согласование. Требование согласовано аж с заказчиком (не так уж и редко у аналитика есть на это полномочия).
А клиент посмотрев на решение, отказался покупать.
Он ведь был в восторге и согласился, когда аналитик ему это презентовал?
И с кого спрашивать, если нет официального согласования?
А если есть? Если же нет — то это или нарушение процесса (в котором заказчик должен поставить согласующие подписи) или риски того же процесса (если «верим на слово»). Может быть и так, и так. И последствия будут разными.
И, главное, где тут формализованные структурированные требования? В словах аналитика?
Нет их тут. Пример — про важный участок работ под названием «согласование». Давайте считать, что после восторгов заказчика все требования были внесены «куда следует», протрассированы и включены в планы релизов.
Это уже реализация, а не согласование.Так согласование и нужно, чтобы реализация соответствовала требованию, не так ли? Поэтому требование должно быть максимально подробным. И программист, лишь один раз получивший «на орехи» за неверную интерпретацию требований, в следующий раз будет занудно и педантично выяснять все детали, и требовать их письменной спецификации, прежде чем приступит к работе. Это мое наблюдение из практики.
Он ведь был в восторге и согласился, когда аналитик ему это презентовал?Так ведь закодили не то что презентовали :)
Давайте считать, что после восторгов заказчика все требования были внесены «куда следует», протрассированы и включены в планы релизов.Так это и потребует уйму времени.
Так согласование и нужно, чтобы реализация соответствовала требованию, не так ли?
В частном случае — так.
Еще раз хочу обратить внимание: эта ветка идет от Вашего поста с утверждением «управление требованиями подразумевает многоэтапное и многоуровневое их согласование». Мои посты в ней — на тему этого утверждения.
До согласования и после него с требованиями может происходить много интересного и в разной степени полезного. Здесь я этого вопроса не касался. Только «утверждение», только хардкор.
Поэтому требование должно быть максимально подробным. И программист, лишь один раз получивший «на орехи» за неверную интерпретацию требований, в следующий раз будет занудно и педантично выяснять все детали, и требовать их письменной спецификации, прежде чем приступит к работе. Это мое наблюдение из практики.
В зависимости от того, кто на него смотрит, и от преследуемой цели (согласование — это одно, разработка — другое, тестирование — третье и т.д.), требование может выглядеть очень по-разному (не меняя своей сути). К заказчику мы идем с концепцией требования, программисту отдаем детализацию, с тестировщиком обсуждаем кейсы по требованию.
Статья очень спорное впечатление производит. Оказывается, управление изменениями требований уже не ключевая и жизненно необходимая для любого современного проекта активность, а нечто nice to have, что появляется только в идеале — на последнем уровне зрелости. А базовые вещи у нас, оказывается, не забывать картинки в доках нумеровать
Не поверхностно. За это спасибо!
Но однонаправленно. В части перед «введением» создавалось предчувствие, что будет глубоко, и совсем не плоско. Но по факту нет движения от банальной релевантности до понятий и метрик типа левериджа. Это не спорит с вашими утверждениями. Это им перпендикулярно, и именно поэтому может создать объемное восприятие и понимание проблематики.
Я хотел раздавать ссылку на эту статью! Благо есть кому и зачем давать. Пока не допишете — сделать этого не могу.
Вопросы, если есть, пишите в ЛС (хотя гугль тоже может подсказать почти все, можно просто брать и копировать заинтересовавшие фразы).
Но однонаправленно. В части перед «введением» создавалось предчувствие, что будет глубоко, и совсем не плоско. Но по факту нет движения от банальной релевантности до понятий и метрик типа левериджа. Это не спорит с вашими утверждениями. Это им перпендикулярно, и именно поэтому может создать объемное восприятие и понимание проблематики.
Я хотел раздавать ссылку на эту статью! Благо есть кому и зачем давать. Пока не допишете — сделать этого не могу.
Вопросы, если есть, пишите в ЛС (хотя гугль тоже может подсказать почти все, можно просто брать и копировать заинтересовавшие фразы).
Опять под управлением требованиями понимается разработка требований и управление требованиями.
Сходите что-ли сам CMMI почитайте, если уж:
www.software-quality-assurance.org/cmmi-requirements-management.html
www.software-quality-assurance.org/cmmi-requirements-development.html
Это всё равно, что разработку автомобиля называть управлением автомобиля.
Сходите что-ли сам CMMI почитайте, если уж:
www.software-quality-assurance.org/cmmi-requirements-management.html
www.software-quality-assurance.org/cmmi-requirements-development.html
Это всё равно, что разработку автомобиля называть управлением автомобиля.
Денис, отличные ссылки. :)
Во первых строках читаем:
Во первых строках читаем:
Disclaimer: The opinions expressed here are the authors
and do not express a position on the subject from the
Software Engineering Institute (SEI) or any organization
or SEI Partner affiliated with the SEI.
Ну так они же на CMMI основываются, а не на земельном кодексе Зимбабве. Имхо это лучше, чем никаких ссылок на первоисточники, как в статье.
Так и статья автора тоже не на земельном кодексе. И даже ссылка есть:
(А даже если была бы на земельном кодексе — какая разница? Гораздо интереснее, что получилось в результате.)
Я о том, что собственное мнение авторов по тем двум ссылкам настолько же авторитетно, сколь и собственное мнение нашего автора (в хорошем смысле).
В частности, мешать разработку требований и управление ими или нет — дело вкуса, навыков (и «качества» кадров в целом), оперативной ситуации, случая и прочих факторов.
Я, например, более эффективным вижу разработку требований со встроенными фичами под дальнейшее управление ими во вполне конкретном окружении. Цена такого подхода — невысокая эффективность разработки без понимания специфики дальнейшего управления и невысокая эффективность управления без понимания нюансов разработки. Другими словами — высокие ожидания от сотрудников и повышенная стоимость(продолжительность) выхода сотрудников на крейсерскую производительность.
Если вернуться к Вашей аналогии, эффективнее (с точки зрения раскрытия возможностей и знания недостатков) водить автомобиль, спроектированный и собранный своими руками.
обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).
(А даже если была бы на земельном кодексе — какая разница? Гораздо интереснее, что получилось в результате.)
Я о том, что собственное мнение авторов по тем двум ссылкам настолько же авторитетно, сколь и собственное мнение нашего автора (в хорошем смысле).
В частности, мешать разработку требований и управление ими или нет — дело вкуса, навыков (и «качества» кадров в целом), оперативной ситуации, случая и прочих факторов.
Я, например, более эффективным вижу разработку требований со встроенными фичами под дальнейшее управление ими во вполне конкретном окружении. Цена такого подхода — невысокая эффективность разработки без понимания специфики дальнейшего управления и невысокая эффективность управления без понимания нюансов разработки. Другими словами — высокие ожидания от сотрудников и повышенная стоимость(продолжительность) выхода сотрудников на крейсерскую производительность.
Если вернуться к Вашей аналогии, эффективнее (с точки зрения раскрытия возможностей и знания недостатков) водить автомобиль, спроектированный и собранный своими руками.
Леонид, давайте к основам.
Умение различать понятия, проводить границы — одно из важнейших аналитических умений.
Запихивая деятельность по созданию чего-то под название «управление», мы теряем важные компоненты смысла.
Про то, как совмещать эти деятельности на практике — отдельный разговор, я тут не против ваших рассуждений совершенно.
Умение различать понятия, проводить границы — одно из важнейших аналитических умений.
Запихивая деятельность по созданию чего-то под название «управление», мы теряем важные компоненты смысла.
Про то, как совмещать эти деятельности на практике — отдельный разговор, я тут не против ваших рассуждений совершенно.
Умение различать понятия, проводить границы — одно из важнейших аналитических умений.
Запихивая деятельность по созданию чего-то под название «управление», мы теряем важные компоненты смысла.
Так вроде никто и не утверждал, что созидание и управление — одно и то же. Просто они настолько пересекаются и врастают друг в друга, что рассматривать одно вне контекста другого — как раз и есть верный способ потерять важные компоненты смысла. Практически важные.
Именно поэтому я считаю, что с прикладной точки зрения полезно рассматривать разработку в составе управления. В его контексте, так сказать. Или же наоборот: что во что встраивать, зависит от относительных масштабов явлений в конкретной ситуации. Может получиться так, что управление станет «бедным родственником» при разработке.
Ну а в автоматизаторской жизни под «управлением» каким-то объектами чаще всего подразумевается активность а-ля CRUD («управление договорами», «управление учебными группами», «управление анкетами» и т.п.). То же худо-бедное управление персоналом — и то начитается с разработки образа будущего сотрудника (а не худо-бедное — с «сот» под образы в виде оргштатки).
Про то, как совмещать эти деятельности на практике — отдельный разговор
Если применение теории на практике требует большого напильника, то может, с ней что-то не так? Классик утверждал, что теория без практики мертва.
Я не призываю отказаться от этих теорий. Они милы и по-своему полезны. Я призываю не применять их как нечто, имеющее абсолютный авторитет. А уж тем более, как прокрустово ложе.
Пара ссылок на ту же тему, на которые почему-то постеснялся сослаться автор:
grigorash.ru/archives/905
www.ibm.com/developerworks/ru/library/r-requirements/
grigorash.ru/archives/905
www.ibm.com/developerworks/ru/library/r-requirements/
Тогда уж приведу ссылку на оригинал:
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb03/ManagementMaturity_TheRationalEdge_Feb2003.pdf
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb03/ManagementMaturity_TheRationalEdge_Feb2003.pdf
Sign up to leave a comment.
Уровни зрелости процесса управления требованиями