서버, 도커 컨테이너, 데이터베이스, WAS, 네트워크, 쿨링랙, 서버 취약점, IP 주소 관리, 가동률 등 IT 인프라 모니터링 솔루션 ...옥시즌
‘인사이트뷰 모니터링 (insightVew Monitoring)’ 솔루션은 클라우드/IDC 운영자를 위한 IT 인프라 모니터링 솔루션으로 Linux/Unix, Windows 서버 OS 및 도커 컨테이너, 데이터베이스, WAS, 네트워크, 쿨링랙, 서버 취약점, IP 주소 관리, 가동률 등 IT 인프라 자원에 대한 장애/성능/구성정보 모니터링을 통하여 IT 인프라 자원의 안정적인 운영을 지원합니다. IT 인프라 자원에 대한 주요 상태 정보를 직관적으로 파악하고 관리할 수 있도록 효율적인 각종 기능을 제공하고 있습니다.
- Linux/Unix, Windows 서버 통합 모니터링 관리 지원
- 계정그룹을 통한 관리자 계정 권한 위임
- 서버 OS 및 도커 컨테이너 통합 모니터링 지원
- Port 및 URL 모니터링 지원
- MySQL/MrariaDB 등 데이터베이스 모니터링 지원
- Apache HTTP Server, Tomcat, NGINX 등 WAS 모니터링 지원
- SNMP를 통한 네트워크 장비 모니터링 지원
- 쿨링랙(Cooling Rack) 컨트롤러 모니터링 지원
- 서버 OS 취약점 분석 지원
- 사용자 스크립트 실행을 통한 모니터링 지원
- 모니터링 설정 기본값 적용에 따른 설치 즉시 사용 가능
- 태스크 별 적용을 통한 유연한 모니터링 항목 관리
- 현 상태 정보 제공을 통한 모니터링 설정의 편의성 제공
- 통지 메시지에 대한 데이터 속성값 매핑 지원
- 장애 이벤트의 다양한 통지 방법 제공(이메일, 슬랙, 텔레그램 등)
- DB 연계를 통한 대시보드 구성
Работа с бизнес-требованиями на стадии выхода продуктаSQALab
The document discusses user stories in user acceptance testing (UAT) time. It covers why changes to user stories during UAT need to be discussed, provides examples of common types of changes like changing a story's size or adding support, and examines what those changes mean for tasks like code, design, and testing updates. It poses the question of whether such changes can be prevented.
This document discusses handwriting recognition in Russian using Silverlight. It covers algorithms for recognition, including preprocessing, segmentation, feature extraction and classification. Diagrams show the recognition process and components involved. The document also defines common terms like segments and paragraphs. Examples of applications using these techniques are provided.
1. Три вопроса
Схема презентации
О ЧЁМ И ЗАЧЕМ
«Аналитик в Agile» 1 из 80
2. Три распространенных
1. Как быть с fix-price
контрактами в Agile?
2. Какова роль менеджера в Agile
и как эта роль соотносится с
понятием «Product Owner»?
3. Нужны ли аналитики в Agile, и
если да, как должно быть
организовано взаимодействие с
ними?
«Аналитик в Agile» 2 из 80
3. Jeff Sutherland
Fix-price контракты в Agile
http://jeffsutherland.com/scrum/2008/08/agile-2008-money-for-nothing.html
«Аналитик в Agile» 3 из 80
4. Stacia Broderick
Fix-price контракты в Agile (2)
http://www.infoq.com/presentations/Introduction-Agile-Stacia-Broderick
«Аналитик в Agile» 4 из 80
5. Henrik Kniberg
Менеджер в Agile
http://blog.crisp.se/henrikkniberg/2007/11/14/1195064820000.html
«Аналитик в Agile» 5 из 80
7. Позже на InfoQ появилась статья:
http://www.infoq.com/articles/agile-business-analyst-role
«Аналитик в Agile» 7 из 80
8. Схема презентации
В Agile И как
А чем его встроить в
аналитик не
занять? процесс?
нужен?
Схемы взаимодействия
Мифы Agile Функции аналитика
аналитик-команда
Но есть еще
Так есть разница: много вопросов
Agile и НЕ-Agile? и нюансов!
Еще раз про особенности Кратко про ряд смежных
аналитика в Agile вопросов
«Аналитик в Agile» 8 из 80
9. Бизнес-аналитик vs.
системный аналитик
Scrum, Scrum, Scrum
НО ПРЕЖДЕ – ПАРА ОГОВОРОК!
«Аналитик в Agile» 9 из 80
10. Бизнес-аналитик vs. системный аналитик
• Экспертиза в предметной • Систематизация знаний
области • Построение информационных
• Глубокое знание бизнес- моделей
процессов
• Умения внятно излагать и • Умение «спрямлять углы»
верифицировать • Участие в дизайне системы
«Аналитик в Agile» 10 из 80
11. Scrum, Scrum, Scrum
Other
21%
XP Scrum
8% 49%
Scrum
& XP
22%
Источник:
3rd Annual ”State of Agile Development” Survey June-July 2008
• 3061 respondents
• 80 countries
«Аналитик в Agile» 11 из 80
12. Google, Yahoo, Microsoft, IBM, Oracle, MySpace,
Adobe, GE, Siemens, Sony/Ericson, …
Из презентации Jeff-а Sutherland-а
http://jeffsutherland.com/scrum/Agile2008MoneyforNothing.pdf
«Аналитик в Agile», (с) 2008 12 из 80
13. Scrum: общая схема (итерация == спринт)
Источник:
http://www.crisp.se/henrik.kniberg/presentations/JAOO-2007-Henrik-Kniberg.pdf
«Аналитик в Agile» 13 из 80
14. Nokia-тест: часть 1
У вас итерации фиксированы, т.е. начинаются в
определенное время и заканчиваются в
назначенное время?
Длина итерации не превышает 6 недель?
В конце итерации вы имеете работающее ПО?
Вам не нужна детальная спецификация для
того, чтобы начать итерацию?
Важно иметь работающее ПО в конце итерации:
вы проводите тестирование во время процесса
разработки?
Если все ответы – «ДА», то это итеративный
процесс в полном смысле этого слова
Источник: http://www.infoq.com/interviews/jeff-sutherland-scrum-rules
«Аналитик в Agile» 14 из 80
15. Nokia-тест: часть 2
У вас есть Product Owner, т.е. есть кто-то, кто
представляет заказчика и работает с вами?
Если у вас есть Product Owner, ведет ли он Product
Backlog, т.е. список «фич», которые нужно
запрограммировать? Приоритизирован ли он по
важности для заказчика? Есть ли оценка
трудоемкости по каждому пункту?
Строите ли вы график сгорания работ (burndown
chart) во время итерации, чтобы видеть, сколько
работы осталось, и успеваете ли вы к концу
итерации?
Во время итерации команда работает по принципу
самоорганизации, т.е. менеджеры не вмешиваются в
работу команды по ходу итерации?
Если и здесь все «ДА», то это Scrum
«Аналитик в Agile» 15 из 80
17. Кроссфункциональность
Нет подробным спецификациям
Минимум документации
Прямое общение разработчиков с пользователями
МИФЫ AGILE
«Аналитик в Agile» 17 из 80
18. «Слоганы»
из Agile-пропаганды
1. Наиболее эффективные
команды – это кросс-
функциональные команды
2. В начале итерации команде
не должно требоваться наличие
подробных спецификаций
3. Не следует создавать лишние артефакты,
в частности, write-only документацию
4. У разработчиков должна быть
возможность общаться с пользователями
и представителями бизнеса напрямую
«Аналитик в Agile» 18 из 80
19. Распространенные ошибочные
выводы из них ?
• И что, при переходе на
Scrum нам нужно учить
аналитиков программировать?!
• Product Owner — это
руководитель проекта,
выполняющий еще и функции аналитика?!
• Теперь вообще не следует предварительно
прорабатывать задачу или требование перед
постановкой их реализации в итерацию?!
«Аналитик в Agile» 19 из 80
20. Это значит, больше
Мы собираемся никакого
попробовать кое-что планирования, никакой Так вот как
документации. Просто Твоя
под названием «Agile это
начинайте писать код и школа.
программирование». называется.
жаловаться.
Даже Скотт Адамс (Scott Adams) по этому прошелся…
Источник: http://dilbertru.blogspot.com/2007/11/20071126.html
«Аналитик в Agile» 20 из 80
25. Кроссфункциональность:
избегайте искусственных ограничений
уровень Границы
навыков должностных
обязанностей
ОБЫДНО!
Пропадает!!!
КПД < 30%
Профиль навыков
сотрудника
область навыков
«Аналитик в Agile» 25 из 80
26. Про слоган №2:
Нет подробным спецификациям
- это в пику Heavy Weight:
Вера в магию и ум
А дальше дело за
аналитиков и
малым – за кодерами
архитекторов
«Аналитик в Agile» 26 из 80
27. 1 1 – так объяснил заказчик
2 2 – так спроектировали
3 3 – так реализовали
4
А было нужно:
5
4 – после тестирования
5 – так внедрили
Еще баян про дерево и качели
Извините! Не удержался…
«Аналитик в Agile» 27 из 80
28. Agile-спецификации – что рулит:
• User story (Пользовательские истории)
• Use cases (Сценарии использования)
• Domain Models
(Модели предметной области)
• Data Flow Diagrams (Потоки данных)
• Vision (Концепции)
• …
Подробнее про Agile-спецификации:
http://agileconsortium.blogspot.com/2008/04/nokia-test-agile-specifications-3.html
«Аналитик в Agile» 28 из 80
29. Про слоган №3:
Минимум документации
Чем подробнее и больше документация,
тем быстрее она «протухает»:
через год
Изначально красивая
и качественная
документация
Она же через год
«Аналитик в Agile» 29 из 80
30. Минимум, но не ноль!
Без документации могут быть проблемы:
Тяжело вводить новых людей в проект;
Велика вероятность потери общих
концепций и видения проекта;
Сложно осуществлять контроль качества;
Некомфортно сопровождать и развивать
старую функциональность;
…
«Аналитик в Agile» 30 из 80
31. Про слоган №4:
Прямое общение разработчиков с
пользователями/бизнесами
Кто из них кто – решайте сами…
«Аналитик в Agile» 31 из 80
32. Весьма полезно!
Повышает вовлеченность и
мотивацию
Повышает качество
Выше вероятность сделать то, что
нужно, а не просто «что просили, то и
кушайте»
Ускоряет процесс
Однако никто не запрещает иметь
катализатор (читай – Аналитика)!
«Аналитик в Agile» 32 из 80
33. Связующее звено между
разработчиками и заказчиками
Экспертиза в предметной области
Систематизация и построение моделей
Контроль качества
Участие в пилотных внедрения
VIP-сопровождение
ВОЗМОЖНЫЕ
ФУНКЦИИ АНАЛИТИКА
«Аналитик в Agile» 33 из 80
34. Функция 1: Связующее звено между
разработчиками и заказчиками
Профили
сотрудников Граница заказчик-исполнитель
заказчика
Например,
помощник Профили
бухгалтера разработчиков
Например,
DBA
«Аналитик в Agile» 34 из 80
35. Даже в такой ситуации
аналитик – хорошее усиление связи
Профили
сотрудников Граница заказчик-исполнитель
заказчика
Например,
Профили
помощник разработчиков
бухгалтера
Например,
DBA
«Аналитик в Agile» 35 из 80
37. В них роль аналитика
становится
экстремально важной
«Аналитик в Agile» 37 из 80
38. Кроме того, не Занятость ключевого
персонала у заказчика
следует забывать
о рисках:
Уход лидера
проекта
«Аналитик в Agile» 38 из 80
39. Аналитик может Занятость ключевого
персонала у заказчика
(и должен)
вас спасти!
Уход лидера
проекта
«Аналитик в Agile» 39 из 80
40. Функция 2: Экспертиза в
предметной области
Эксперты в предметной
области и представители
заказчика, пользователи
Команда
разработчиков
Информация
«Разжеванная»
информация
Аналитик здесь похож на
RSS-агрегатор + портал
(единая точка доступа)
«Аналитик в Agile» 40 из 80
41. Функция 3: Систематизация и
построение моделей
• В Agile в сессиях моделирования
(построения моделей) обычно
принимает участие большая часть
команды
• Но удобно иметь начальное
приближение!
• Если аналитик способен его
«сгенерировать», то это отлично, ну а
если нет, то не фатально – команда
спасѐт (подогретые коммуникации
рулят)!
«Аналитик в Agile» 41 из 80
43. Функция 4:
Контроль качества
• Как?!
Аналитик превращается в тестера?!
• И да, и нет. Более подходящая
параллель – «лѐтчик-испытатель»
(первым опробует свежую
функциональность)
«Аналитик в Agile» 43 из 80
44. Definition of Done (aka «DoD»)
(критерий «Сделано»)
коллега аналитик
(2) Code Review
сборочный (3) Сделано то, что нужно? Feedback
сервер (1) автоматические
Оно работает? Это удобно?
сборка + тесты
Демо
Feedback
Подробнее см. например:
http://chrissterling.gettingagile.com/2007/10/05/building-a-definition-of-done/
«Аналитик в Agile» 44 из 80
45. Функция 5:
Участие в пилотных внедрениях
Аналитик может сильно помочь:
• обучение пользователей (документации не
хватает, процесс не отлажен)
• «живая справка» (аналитик должен знать
систему, как свои пять пальцев)
• исправление последствий некорректных
действий пользователей (требует
специальных прав и навыков)
• фиксация всех недочетов и пожеланий
(«взять на карандаш»)
• перегрузка и выверка данных
• начальная настройка системы
«Аналитик в Agile» 45 из 80
46. Функция 6: VIP-сопровождение
Аналитик хорошо знает и
VIP: систему, и предметную
• крупные заказчики
область. Кроме того, он умеет
понимать пользователей и
• первые клиенты объяснять разработчикам
Особенности:
• проблемы нестандартные
• пожелания сложные
• bug-report-ы зачастую выливаются в
большие доработки
«Аналитик в Agile» 46 из 80
47. Product Owner – аналитик
Аналитик – помощник Product Owner-а
Аналитик внутри команды
Внешний отдел аналитиков
СХЕМЫ ВЗАИМОДЕЙСТВИЯ
АНАЛИТИК-КОМАНДА
«Аналитик в Agile» 47 из 80
48. Схема 1: Product Owner – аналитик
Самая простая и очевидная
Источник:
http://www.crisp.se/henrik.kniberg/presentations/JAOO-2007-Henrik-Kniberg.pdf
«Аналитик в Agile» 48 из 80
49. Однако есть
высокие риски:
бутылочное горлышко
экстремальная незаменимость:
а если в отпуске,
а если заболел (дай Бог ему здоровья)
трудно найти на рынке труда
вряд ли удастся полноценно вовлечь в
активное участие во внедрениях и
тестировании
есть вероятность приоритизации
работ, исходя из готовности
постановки, а не business value и
трудоемкости
«Аналитик в Agile» 49 из 80
50. Схема 2: Аналитик – помощник
Product Owner-а
Исходя из недостатков предыдущей,
напрашивается следующая:
Источник: «Agile MASHUPS» Rachel Davies, QCon London 2008
http://www.slideshare.net/deimos/rachel-davies-agile-mashups
«Аналитик в Agile» 50 из 80
51. Недостатки
• риск недостаточной
прозрачности
деятельности
аналитика для
команды
• вероятность
восприятия аналитика
как руководителя
«Аналитик в Agile» 51 из 80
52. Недостатки (продолжение)
Один не заметен на
Кто в доме хозяин? фоне другого
«Аналитик в Agile» 52 из 80
53. Схема 3: Аналитик внутри команды
«Все, кто могут быть погружены внутрь
команды, должны быть в команде.»
Аналитик сидит вместе со всеми
Аналитик участвует в Scrum-митингах
наравне со всеми
Работа аналитика учитывается при
планировании
Аналитик может «делиться» своей работой с
другими (по общему согласию)
И наоборот: аналитик может привлекаться к
другим работам (например, подготовить
тестовые данные, рассказать про проект
новому сотруднику и т.п.)
«Аналитик в Agile» 53 из 80
54. Неэффективно, если:
• Одной предметной областью занимается
несколько команд;
• В частности, Scrum-of-Scrum;
• Проект, где технические трудности и
особенности превалируют над
проблемами предметной области
(например, a la Web 2.0);
• Нехватка квалифицированных
аналитиков
«Аналитик в Agile» 54 из 80
55. Схема 4:
Отдельный отдел аналитиков
• Экстремально высокая отдаленность
от разработчиков
• Высока вероятность отката к прежним
практикам и прежним проблемам
«Аналитик в Agile» 55 из 80
56. Итого:
PO
PO
PO’
1 2
PO
PO
3 4 PO
«Аналитик в Agile» 56 из 80
57. Ключевой момент
Лекарство от страха
Типовые ошибки-дуализмы
ЕЩЕ РАЗ ПРО ОСОБЕННОСТИ
АНАЛИТИКА В AGILE
«Аналитик в Agile» 57 из 80
60. У аналитика в Agile
есть «лекарство от страха»
помощь команды
быстрая обратная
связь от заказчика
небольшое количество
вспомогательных
артефактов
активные устные
коммуникации
Ошибки аналитика не столь дороги
«Аналитик в Agile» 60 из 80
61. Качели №1
Команду не
допускают к
аналитической
работе
Разработчикам
самим приходится
полностью
прояснять, что же
нужно
«Аналитик в Agile» 61 из 80
62. Качели №2
Аналитик мало
общается с
заказчиком
Аналитик
всѐ время
проводит у
заказчика
«Аналитик в Agile» 62 из 80
63. Качели №3
Подробные
спецификации
перед началом
итерации
Отсутствие какой-
либо проработки
требований до
постановки их в
итерацию
«Аналитик в Agile» 63 из 80
64. Качели №4
Аналитик не
рисует никаких
диаграмм и схем
Аналитик не
пишет текст –
исключительно
рисует диаграммы
и схемы
«Аналитик в Agile» 64 из 80
65. Качели №5
Команда с
«придыханием»
относится к
постановкам
аналитика
Команда
не доверяет
результатам
работы аналитика
(не использует их)
«Аналитик в Agile» 65 из 80
66. Качели №6
Аналитик не
участвует в
тестировании (QA)
Аналитик вынужден
постоянно
«протыкивать»
много старых
интерфейсов
«Аналитик в Agile» 66 из 80
67. Качели №7
Команда
воспринимает
аналитика как
руководителя
Аналитик для
команды –
мальчик/девочка
«на побегушках»
«Аналитик в Agile» 67 из 80
68. Качели №8
Аналитик
взаимодействует с
командой исключительно
при помощи
документации
и Bug-трекера
Аналитик
взаимодействует с
командой
исключительно
посредством устных
коммуникаций
«Аналитик в Agile» 68 из 80
69. Качели №9
С заказчиком и
пользователями
общается только
аналитик
Все члены команды без
исключения
вынуждены плотно
общаться с заказчиками
и пользователями
«Аналитик в Agile» 69 из 80
70. Можно продолжать, но я остановлюсь.
Найдите свой идеальный баланс!
«Аналитик в Agile» 70 из 80
71. Как «выращивать» аналитиков
Инструменты для ведения документации по проекту
Почему модели предметной области снова в моде
КРАТКО ПРО
РЯД СМЕЖНЫХ ВОПРОСОВ
«Аналитик в Agile» 71 из 80
72. «Выращивание»
аналитиков
• Сейчас готовые аналитики
на рынке труда стоят
неоправданно дорого
• Может, кризис это исправит?
• Да и уровень их навыков
в большинстве случаев
оставляет желать лучшего…
• Нужно уметь выращивать внутри Компании
(таких, какие вам нужны):
– способный инженер-тестировщик => будущий аналитик
– способный инженер службы сопровождения => аналогично
«Аналитик в Agile» 72 из 80
73. Средства документирования
• Multimedia:
– фотографии с досок
– сканы листков
– видео (с обсуждений, семинаров и т.п.)
• Презентации
– плюс векторная графика (Visio/SVG)
• Wiki
– обязательно ПЛЮС текстовые нотации для
графических диаграмм
«Аналитик в Agile» 73 из 80
75. Почему модели предметной области
снова в моде
ПО без «чего-то»
основополагающего
и
направляющего
рискует
превратиться в кучу
сараев-пристроек без
какой-либо
концептуальной
целостности
!!!
Чем ПО больше и сложнее или чем оно дольше живет и
развивается, тем выше становится этот риск
«Аналитик в Agile» 75 из 80
76. Почему модели предметной области
снова в моде
Нужен своего рода «концептуальный план»
- это и есть модель предметной области
«Аналитик в Agile» 76 из 80
77. Domain Driven Design (aka DDD)
Проектирование и дизайн системы должны
вращаться вокруг одного Солнца и это Солнце –
модель предметной области
Eric Evans
http://www.infoq.com/minibooks/domain-driven-design-quickly
«Аналитик в Agile» 77 из 80
78. В DDD ничего принципиально
нового нет
Всѐ это похоже на:
• Объектно-ориентированное моделирование
• Model Driven Architecture (MDA)
Только смещены акценты
«Аналитик в Agile» 78 из 80
79. Тренинг по созданию моделей
предметной области (Domain Modeling)
«Аналитик в Agile» 79 из 80
80. Тренинг по созданию моделей
предметной области (Domain Modeling)
«Аналитик в Agile» 80 из 80
81. НЕ Agile Agile
Это всё!
Вопросы?
«Аналитик в Agile»