Category: it

Category was added automatically. Read all entries about "it".

CEE-SEC(R) 2014

На прошлой неделе прошла 10-я конференция CEE-SEC(R). Из этих 10 лет я принимаю участие в четвертый. Общее резюме положительное. Николай Пунтиков во время открытия сказал, что уровень конференции вырос с момента вхождения Максима Цепкова в программный комитет. Не знаю, когда это произошло, но последние два года конференция меня однозначно радует. На сайте конференции выложены слайды докладов. Видеозаписи большинства докладов, как я понимаю, будут доступны через несколько месяцев.

Кратко о докладах, которые я прослушал.
1. Пилотный Lean проект: устранение потерь с помощью практик Бережливого производства. Надежда Евстифеева, ARRIS St.Petersburg Software Center
Этот доклад стал одним из многих подобных, в которых авторы делились реальным опытом. Половина доклада — введение в Lean, другая половина — опыт. Не откровение, но тренд приятный.
2. Работа распределённой SCRUM-команды. Подводные камни. Наш опыт Олеся Воронович, Universal Software
Этот доклад был более интересен. Много было сказано об ошибках. О позитивном опыте (который, как выяснилось в кулуарах, присутствует!) было сказано немного. Что характерно, позитивный опыт связан с внедрением Scrum'а сверху.
3. Ключи к формированию высокоэффективной программистской культуры Мики В. Мантл, Wanderful, Inc.
Очень хороший доклад! Руководителям и кадровикам must read/must watch.
4. Разрыв шаблона: Lean Product Management и MVP в большой компании Илья Кузнецов, Лаборатория Касперского
Очень хорошо про управление проектом и MVP.
5. Каждому проекту своя методология разработки Роман Алёшкин, Acronis
Еще один доклад про опыт выбора методологии разработки под конкретную ситуацию. От каскадной модели к канбану через Scrum.
6. Ретроспектива проектов (версия Норма Керта) Максим Дорофеев и Дмитрий Лазарев, Институт фасилитации
Прекрасный доклад о проведении ретроспектив от мастеров их фасилитации.
7. Когда стоит переходить от Agile к Waterfall Антон Семенченко, ISSoft / CoherentSolutions
Еще недавно доклады на такие темы услышать было невозможно. К недостаткам доклада можно отнести отсутствие привязки к практическому опыту.
8. Психология разработки ПО Владимир Прус, Mentor Embedded
Очередной тренд. На AgileDays тоже были доклады, раскрывающие темы психологии в контексте разработки ПО. Важнейший аспект! Внимание к нему, видимо, является признаком зрелости индустрии.
9. QUESTions – как получать простые ответы на сложные вопросы о проектах и продуктах Ирина Виноградова, Лаборатория Касперского
Интересный опыт работы с метриками. К сожалению, недостаточно глубоко раскрытый докладчиками.
10. 20 анти-паттернов, которые не позволяют вам достичь максимального эффекта от внедрения скрам или канбан Сергей Дмитриев, Unusual Concepts
Хороший доклад, основанный на практическом опыте.
11. Опыт выстраивания Канбан-системы из 45 человек в крупном Российском банке Дмитрий Лобасев, ScrumTrek
Уже знакомая по AgileDays 2014 история, не потерявшая своей актуальности.
12. JUNIPER: Создание эффективной платформы для анализа больших объёмов гетерогенных данных Андрей Садовых, SOFTEAM
Технический доклад по теме BigData. Хорош тем, что про некоторые технические детали, а не бла-бла-бла.
13. Управление правовыми рисками при разработке ПО Яна Чирко, Dentons
Доклад (в связи с длиной) стал, по сути, перечислением массы возможных рисков, специфичных для российских производителей ПО. Очень познавательно. Тоже является признаком зрелости отрасли, на мой взгляд.
14. Зачем нужна своя компания в США? Дмитрий Дубограев, FEMIDA.US
Резюме: если присутствуете на рынке США, то компания нужна, если не присутствуете — то и компания не нужна. И много интересного на пути к этому резюме.
15. Риски и возможности стремительного роста команды разработки Артем Ломакин, B2B-Center
В меру интересно по заявленной теме. Свой опыт.
16. JIRA – не таск-трекер, а экосистема Александр Горный, Mail.Ru Group
Очень интересный, преимущественно положительный, несмотря на масштаб, опыт применения Jira, подтвержденный из зала представителем, если не ошибаюсь, Transas'а.
17. Управление клиентами: нестандартные случаи взаимоотношений с заказчиками аутсорсинговых проектов Оксана Уварова, Arcadia
Полезный для технарей взгляд на разработку ПО с приближенной к клиентской точке обзора.
18. Управление дистрибуцией больших распределенных и разнородных систем Илья Акатнов, Arcadia
Опыт работы с развесистым семейством продуктов. К сожалению, без деталей.
19. Использование статического анализатора Clang для обнаружения проблем в исходном коде Евгений Павлов, Samsung R&D Institute
Russia
Опыт применения статического анализатора кода от технического специалиста именитой компании. Познавательно.

Essence по-русски

Ознакомился с начавшей складываться практикой перевода ключевой терминологии на русский. Как ни удивительно, таковая уже есть. А именно: постинги ailev'а (см. http://ailev.livejournal.com/1051048.html и http://ailev.livejournal.com/1052859.html) и перевод "Semat — three year vision" в журнале Программирование в прошлом году.

Тут изложу мой текущий рабочий вариант с объяснением расхождений с прочими вариантами.
1. Essence. На данный момент я склоняюсь к тому, чтобы не переводить, а использовать, как есть. Мы же не переводим, а транслитерируем названия языков программирования. Если же переводить, то, видимо, лучше использовать "основы" (вариант ailev'а), а "сущность" (не предыдущий рабочий вариант перевода).
2. Alpha. Предлагаемый перевод - альфа. Да, это акроним в англоязычной версии. Но я не вижу возможности перевести на русский расшифровку и получить столь же внятный акроним. Расшифровка акронима пусть будет доступна только в словаре, который, очевидно, тоже необходимо создать и опубликовать (например, на пока еще не действующем сайте SEMAT Russian Chapter.
3. Alpha state — состояние альфы.
4. Area of concern — область интересов (большое спасибо ailev'у.
4.1. Client area of concern — область интересов клиента. В наличие лобби в пользу "область интересов заказчика", что, на мой взгляд, не полностью отражает суть.
4.2. Solution area of concern — область интересов решения.
4.3. Endeavor area of concern. Здесь интересно. "Официальный" рабочий вариант — область интересов усилий [предпринимаемых для создания программной системы]. Честно говоря, я настолько уже намучался с адекватным переводом "endeavor", которое хочется переводить одним словом, а не несколько разными по контексту, что всячески поддерживаю популяризацию предложенного ailev'ом термина "предпринятие". Но словотворчество у всех в чести. В связи с чем предвижу проблемы с точки зрения принятия этого термина за пределами русскоязычного сообщества системных инженеров. В общем, пока фиксирую рабочий вариант "область интересов предпринятия".
5. Альфы.
5.1. Opportunity — возможность. В "Программировании" использовался вариант "бизнес-возможность". На мой взгляд спецификатор "бизнес-" излишен (как говорил наш quality assurance manager по поводу термина business requirement: "А у нас что есть какие-то небизнес-требования?"). Альфа области интересов клиента.
5.2. Stakeholders — заинтересованные стороны (с удовольствием принимаю вариант ailev'а, предыдущий рабочий вариант — заинтересованные лица ). Наличествует лобби, желающее протащить на уровень абстракции непременно "заказчиков", с чем я никак не могу согласиться. Альфа области интересов клиента.
5.3. Requirements — требования.Альфа области интересов решения.
5.4. Software system — программная система. Альфа области интересов решения.
5.5. Work — работа. Альфа области интересов предпринятия. ailev предлагает переводить как "работы". Множественное число отсутствует в оригинале. Я (пока?) не вижу смысла в подобной модификации при переводе.
5.6. Team — команда. Альфа области интересов предпринятия.
5.7. Way of working — технология работы. Раньше рабочим вариантом было "способ работы", предлагаемый также ailev'ом. Он был отвергнут в пользу "технология работы" в связи с тем, что фразы с использованием перевода "способ работы" режут ухо.
6. Отношения между альфами.
6.1. Stakeholders identify opportunity — заинтересованные стороны определяют возможности (вариант ailev'а "обеспечивают" мне не нравится, т.к. возможности не только обеспечиваются, но еще и выявляются заинтересованными сторонами).
6.2. Opportunity focuses requirements — возможность уточняет требования (вариант ailev'а "фокусируют" мне представляется слишком "калькированным").
6.3. Заинтересованные стороны формируют требования (вариант ailev'а "требуют" меня не вполне устраивает, т.к. не все заинтересованные стороны находятся в положении, когда могут требовать, все-таки demand — это не только требование, но и спрос).
6.4. Stakeholders use and consume software system — заинтересованные стороны используют программную систему.
6.5. Software system fulfills requirements — программная система удовлетворяет требованиям.
6.6. Team produces software system — команда производит программную систему.
6.7. Team performs and plans work (непонятно, почему сначала выполняет, а потом планирует; антисистемная инженерия какая-то, не понимаю, как мы это прозевали (ладно статья в CACM, так, ведь, и в стандарт просочилось) &mdash команда планирует и выполняет работу (я склонен заменить здесь предыдущее рабочее "осуществляет" на "выполняет".
6.8. Requirements scope and constrain work — требования определяют рамки и ограничивают работу (в варианте ailev требования "задают объем", но я не вижу, чем оно лучше того, что у нас уже было).
6.9. Team applies way of working — команда применяет технологию работы. Я не вполне доволен тем, как звучит. Но лучшего пока нет.
6.10. Way of working guides work — технология работ направляет работу.
6.11. Team produces software system — команда производит программную систему.
6.12. Work updates and changes software system — работа изменяет программную систему (дословный вариант предлагается ailev'ом (обновляет и изменяет), м.б. стоит придерживаться именно дословного варианта).
6.13. Stakeholders support team — заинтересованные стороны поддерживают команду.
6.14. Work [is] set up to address opportunity — здесь снова трудно. Текущий рабочий вариант: работа устанавливает порядок реализации возможности. Мне не нравится, то лучшего я не вижу. Калька от ailev (работы проводятся для адресования возможности) меня тоже не устраивает. Надо думать над лучшим вариантом. Вариант "работы проводятся для реализации возможности" меня не устраивает тем, что работы на данном абстрактном уровне не столько проводятеся (это уже run-time), сколько идет договорка о том, как и какие работы будут выполняться.
7. Activity space — пространство дел. Мне нравится вариант ailev'а. Во время обсуждения про activity space часто говорилось как о place holder'е, который должен заполняться какими-либо практиками, которые помогают двигать альфы вперед (вниз ;) по их конечным автоматам.
7.1. Explore possibilities — исследовать возможности. Пространство дел области интересов клиента.
7.2. Understand stakeholder needs — понять потребности заинтересованных сторон (ailev предлагает "нужды" вместо "потребности", я преимуществ не вижу; нужды более близки по дословному переводу, но "потребности заинтересованных сторон" на мое ухо ложаться лучше). Пространство дел области интересов клиента.
7.3. Ensure stakeholder satisfaction — обеспечить удовлетворение заинтересованных сторон (вариант ailev'а, представляющий собой косметическую правку предыдущего рабочего варианта). Пространство дел области интересов клиента.
7.4. Use the system — использовать систему. Пространство дел области интересов клиента.
7.5. Understand the requirements — понять требования. Пространство дел области интересов решения.
7.6. Shape the system — спроектировать систему (ailev предлагает систему моделировать, но это, видимо, уже заготовка под адаптацию к MBSE (model-based systems engineering)). Пространство дел области интересов решения.
7.7. Implement the system — изготовить систему (мне больше нравится вариант ailev'а, чем предыдущий рабочий "реализовать"). Пространство дел области интересов решения.
7.8. Test the system — протестировать систему (вариант ailev'а отличается скорее косметически, наш работчий мне нравится больше).
7.9. Deploy the system — развернуть систему. Пространство дел области интересов решения.
7.10. Operate the system — управлять системой (я принимаю вариант ailev'а, как лучше отражающий суть, чем "использовать систему", который еще и дублировался на русском с пространством дел из области интересов клиента.
7.11. Prepare to do the work — подготовиться к работе (вариант ailev'а "приготовиться", на мой вкус, больше подходит к контексту вроде "приготовиться к старту на стометровку"). Пространство дел области интересов предпринятия.
7.12. Coordinate activity. Мучаюсь выбором между текущим рабочим "координировать деятельность" и "координировать дела" ailev'а. Вопрос как лучше переводить activity? Деятельность или дела? Пространство дел области интересов предпринятия.
7.13. Support the team — поддерживать команду. Пространство дел области интересов предпринятия.
7.14. Track progress — отслеживать прогресс.
7.15. Stop the work — прекратить работу. Вариант ailev'а — остановить работу. Не вижу преимуществ. Пространство дел области интересов предпринятия.
UPD: 8. [SEMAT] Kernel — ядро [SEMAT]. ailev предлагает переводить "kernel" как "сущности", что мне не очень нравится, т.к. одно из основных утверждений касаемо ядра состоит в том, что оно расширяемое. Расширяются в таком случае не сущности, а набор сущностей. Использовать же везде выражение "набор сущностей" слишком громоздко.

Все вышесказанное не является официальной версией перевода, предлагаемой Semat Russian Chapter. Конструктивная критика приветствуется.

UPD: Обновленная версия тут: http://abayda.livejournal.com/66916.html