Pull to refresh
4
0
Send message
Замечательно!
Но все же одному актору с трудом удасться одновременно петь песенки и грызть орехи. Не стоит ли для углубления знаний по BPMN поставить исключительный шлюз и цикл с переходом на начало этих задач?.. Этот цикл также нам даст представление о продолжительности рабочего дня Белки. А ведь его еще надо синхронизировать с рабочим днем Дьяка…
> в Москве с хорошей зп, вполне себе этот самый «уровень жизни» отлично обеспечивается
Вы ошибаетесь. Навскидку (сравнение с Берлином):
(1) Городская среда, транспортная инфраструктура лучше (дороги, метро, наземный транспорт, велосипед)
(2) Погода лучше
(3) Воздух чище
(4) В ТЦ и вообще везде нет таких толп народа
(5) Еда в разы лучше (даже без сыра, пива и сосисок)
(6) Отношения между людьми на улице, в магазине более дружелюбные
ну и т.д.
«Из предметной области лезут такие признаки документов как «Гриф доступа», «Конфиденциальность», которые тоже влияют на доступ – в результате наша модель будет относится и к Multilevel.» Не уверен, что этот пример соответствует определению, скорее, это пример ABAC.
Наверное, пример Multilevel таков: у объекта есть признак Уровень доступа = {чтение | редактирование | удаление | полный доступ }, у субъекта выставляется его уровень доступа по отношению к этому объекту. Чтобы понять, есть ли доступ у субъекта к данному объекту, их права сравниваются и делается вывод.
«Multilevel – если доступ настраивается по отношению к некоему «уровню доступа», а объекты уже помечаются каким-то признаком, определяющим нужный уровень доступа для работы с этим объектом.»
Очень интересный опыт разработки и успешного (!) внедрения KPI для разработчиков. Особенно на фоне того, что что-то не слышно, чтобы крупные компании-разработчики ПО такое практиковали.
Суммируя, можно выделить следующие ключевые моменты:
(a) максимальная приближенность программиста к заказчику (получение требований от заказчика, общение с ним, получение feedback)
(b) отсутствие тестировщиков
автоматический расчет KPI

Автор «ожидает получить в каментах конструктивную критику и встречные идеи, не пришедшие в головы нам.» Однако, надо признать, что сделать это не так просто, поскольку не раскрыты проблемы, кот видны изнутри (уверен, что таковые имеются -). Также не освещена работа бизнес-аналитиков. Подозреваю, что они или помогают заказчику формулировать требования, или сами могут выступать в роли заказчика (в теории второе может сломать всю схему — но не факт).

Несколько мыслей/вопросов на тему.

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

(2) Интересно количество разработчиков. Понятно, что схему можно применить для любого числа, но для небольшой команды (скажем, 20-30 человек) хорошо работают простые командные методологии, позволяющие иметь меньшие требования к разработчикам и, как итог — удешевить фонд з/п и рейты специалистов.

(3) Почему бы не добавить в схему оценку разработчиком заказчика?

(4) На первый взгляд кажется, что трех градаций объема/сложности задачи недостаточно для равномерной загрузки разработчиков. Можно ввести этап уточнения данного параметра — например, старший разработчик устанавливает примерное кол-во часов, кот может быть потрачено на данную задачу. Или отправляет ее на доработку заказчику, если все так плохо с требованиями.

(5) Имея оценку трудоемкости задачи мы в теории сможем:

* сравнивать план с фактом и делать какие-нибудь выводы, например, о разработчике (или оценщике -)
* предсказывать стоимость задачи и давать эту оценку заказчику

(6) Текущая схема подразумевает отсутствие специализации у разработчиков, что не очень хорошо. Ведь не все любят и делают всё одинаково. Решить это довольно просто — можно ввести категории задач и привязать их к разработчикам (например, еще и по приоритетам).

(7) Нет ли проблемы, что надо иметь запас ресурсов-разработчиков для того, чтобы попасть в SLA при пиковых нагрузках? Например, когда 2-3-4 заказчикам надо решить их несколько срочных заявок.

Напоследок: бывают ли сильно связанные задачи? Интуитивно кажется, что при решении сильно-связанных задач может происходить «взаимная блокировка» разработчиков.
Ну, я вот тоже недавно первую статью написал — Пример написания функциональных требований к Enterprise-системе — поэтому и мучил долго двух друзей на предмет review. -)
А, кстати, знаете, про что особенно было бы интересно — про KPI для программистов. На ultimabusinessware.com/ultima_hard_work/ сказано «система квалификационного и зарплатного роста – на базе KPI». Так и хочется крикнуть: «Не верю!» -)
Ну, это как раз понятно из статьи — сразу после описания LOG_CHANGES идет разговор о сервере приложения и маскараде.
Но вообще, если уж речь зашла… Я прочитал все ваши статьи на хабре (плюс на сайте некоторые материалы просмотрел) — видна поспешность в изложении. Например, в статью про себестоимость, мне, как неспециалисту по финансам, вообще сложно въехать. Уверен, что можно было пояснить, добавив 3-4 поясняющих предложения (или ссылки на худой конец). Про макулатуру — все понятно — но есть шероховатости в логике. Просто жаль: статьи очень интересные — чуть бы побольше аккуратности — и стали бы супер! -).
Кстати, про адресное хранение понравилось — сам видел на складе разные зоны хранения.
Понятно, спасибо.
Нет, это совсем не лишние детали — без них решение не полное. Кстати, вы же сами указали, что невозможность получить эти данные при использовании Oracle Flashback Archive не позволяет его использовать. А ваше решение позволяет — но не описано, как именно.
Хорошо бы еще описать в статье, как работают функции GET_REAL_UID и GET_SESSION_ID.
Александр, прочитал с интересом — простое и элегантное решение. Несколько комментариев.

(1) Похоже, что в LOG_FIELDS_CHANGED поле TIME не нужно — оно есть в LOG_CHANGES. Собственно, в триггере оно и не используется.

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

(3) Интересно, какой механизм вы используете для сокращения времени выборки из этих таблиц. Ведь они растут очень быстро.

(4) В нашей учетной системе для протоколирования изменений мы использовали не триггеры, а логику на сервере приложения. Как минимум, это давало связь набора изменений с аудитом — операциями пользователей. Т.е. мы могли сказать, что, например, операция изменения счета пользователя Х с такого-то IP продолжалась с такого по такое время, окончилась успехом и повлекла такие-то изменения.

Но, наверно, основной момент в том, подсистема протоколирования тесно связана с подсистемой событий. Например, кто-то хочет получить оповещение, если у такого-то счета сумма превысила XXX. Т.е. если протоколирование мы делаем в БД, то подсистему событий лучше делать в БД. И наоборот, если мы подсистему событий хотим реализовать на сервере приложения, то и протоколирование лучше сделать там же.

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

Было. Должно было быть в разделе Реализация, но по факту было чуть выше. Для статьи статьи я несколько идеализировал оглавление документации.
Называние требований «системными» очень неудачно

В действительности этот раздел назывался ТЗ. Но в статье не хотел дразнить любителей ГОСТов -).
Предлагайте свое название!
Уважаемый, lair. Я могу ответить, но ответы мои будут всего лишь повторять то, что я уже писал выше. По-большому счету я не вижу больших различий в наших позициях (тем более, раз уж вы признали, что какие-то проверки можно не описывать -). Возможно, отличие в том, что я культивирую в программистах ориентацию на бизнес, а вы — на системную архитектуру. В любом случае — удачи в ваших проектах!
Можно и так. Как и во всем, здесь есть свои плюсы и минусы.
Также, могут быть проблемы, если автоматический билд что-то чекинит.
Номер WI без темы бесполезен.
нелепо

Ну, ОК. Double-click на каждой строке вам в помощь. -)
Кстати, у вас нет ни одного checkin без WI?

А вообще, я сейчас вспомнил, что я делал аудит не по истории, а по оповещениям на checkin в почту. Это позволяло (1) видеть не только комментарий, но и checkin notes, (2) понимать, что прошло аудит, что нет (прочитано письмо — прошло), (3) сортировать, например, по людям.
Вы сами писали, что вам этого не хватает, я лишь предложил универсальное решение.
Кстати, я не считаю, что оно избыточно.

Можно кликать по строкам истории и справа видеть Related Work Items. Правда, последние 6 checkin notes автоматом там не возникнут -).
Уважаемый lair. Я проводил аудит постоянно и решил это тем, что при checkin разработчики должны были заполнить поля Comment и Check-In Notes. Понятно, что пришлось убеждать народ в необходимости этого дела -).

* Comment
Описание решенных задач, поставленных в JIRA, а также, возможно, не заведенных задач. Пример:
ARIJ-345 Прикрутить к Price интерфейс IComparable
Не видна часть позиций счета Rс резервами при добавлении в груз

Здесь важно иметь не только номера, но и текст задач.

* Детальное описание изменений – обязательное
Четкое и краткое описание изменений и их смысловая нагрузка.

* Изменения в структуре БД
Удаление/создание/изменения таблиц, View, хранимых процедур.

* Улучшения производительности
Описание улучшений в производительности системы, достигнутые при реализации данных изменений.

* Изменения, видимые пользователю
Кратко описываются изменения в пользовательском интерфейсе

* Замечания для группы тестирования
Советы группе тестирования о том, как тестировать внесенные изменения

* Замечания для группы документирования
Советы группе документирования о том, что должно быть изменено в пользовательской документации в связи с данными изменениями
А вы — что нужно начать принимать бизнес-решения.

Проверка на входные параметры — это не бизнес-решение. Например, пришел тебе указатель на объект — проверь его на NULL.
Вы считаете, что поведение системы для определенного и неопределенного текущего пользователя — это низкоуровневая проверка?

В статье в приведенном алгоритме сказано, что ЗнП.Пользователь надо установить в текущего пользователя. Если текущего пользователя нет, то произошла какая-то системная ошибка. И да, программист должен провести проверку и выбросить наверх ошибку, если текущий пользователь = NULL. Иначе нельзя сказать, что алгоритм реализован верно. Ведь суть этого алгоритма (поднимаемся на уровень выше) не только в том, чтобы поменять статус ЗнП, но и указать, кто конкретно взял его в работу.
Я против _неявных_ требований.

С этим я согласен. Я лишь делаю упор на то, что лучше аналитику облегчить жизнь и оставить ему описание бизнес-требований. А то, что касается, например, таких вещей, как: какие сообщения выдавать, как проверять входные параметры, как комментировать код, — то можно и без него обойтись. У нас это было в разделе Реализации при описании программных подсистем.
он не игнорирует его, и не делает тихо, как считает лучше, а идет к постановщику задачи.

Это хорошо. Я не против (а часто и за -). Я обращаю внимание вот на что: если постановщик описал все без исключения детали алгоритма, то что остается программисту? Все лишь перевести алгоритм на язык программирования. Вот это я и называю простым кодировщиком.

И, возвращаясь к началу: «А вы — что нужно начать принимать бизнес-решения.» — верно. Понятно, что бизнес-решения бизнес-решениям рознь. Но программист должен думать не только о том, как лучше закодировать алгоритм от постановщика, но и как это все отразится на пользователе. Программист не должен думать только о красоте внутренней архитектуры системы, но и о том, как она отвечает требованиям/ожиданиям пользователя.

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

И таких вещей возникает масса. Могу лишь повторить, что «мой опыт показывает, что лучшие программисты — это не простые кодировщики». Еще раз — я пишу о системах ERP/СRM/DMS, не касаюсь, например, встроенных систем.

Уважаемый @crackpotcrackpot выше привел неплохой пример про Петю и Васю. Петя — ваш «непростой кодировщик», принимающий технические решения, а Вася — мой «непростой кодировщик», принимающий бизнес-решения. А теперь задумаемся вот над чем: какое отношение Петь и Вась надо при разработке ERP? 1 к 5? Ведь системная архитектура занимает значительно меньший объем, чем бизнес-алгоритмы.

Второй положительный эффект от Вась — это синергия. Грубо, постановщик-то тоже может ошибаться, делать что-то не лучшим образом. Безусловно, можно и нужно дать на review алгоритм другому постановщику. Но почему программист (или тестировщик) не может предложить лучшее решение? Часто так и происходит — программисту лучше виден нижний уровень системы — и от него идет подсказка аналитику.
это вопросы совместимости оборудования к которому будет привязана ваша CRM

Это про интеграцию (отдельные требования). Да, аналитик должен предусмотреть, что номер телефона должен в разные системы передаваться в разных форматах.
1

Information

Rating
Does not participate
Registered
Activity