Upload
custis
View
94
Download
2
Embed Size (px)
DESCRIPTION
Открытый семинар для студентов в компании CUSTIS (16 октября 2014). Лектор: Денис Гаврилов, руководитель проектов. Из этого семинара вы узнаете, как наладить эффективную командную работу и выстроить коммуникации внутри группы разработчиков. Виделзапись семинара: https://vimeo.com/109793887.
Citation preview
16 октября 2014 года
Практики командной работы:
о пользе письменных
артефактов
Денис Гаврилов
Руководитель группы
О себе, о компании
Денис Гаврилов
Программирование меня
увлекло аж 18 лет назад,
и что-то никак «не отпустит»
2/104
QBasic
Pascal
VisualBasic
C++
PHP
C#
Java
Тема семинара актуальна
для каждого языка
3/104
О себе, о компании
Денис Гаврилов
Программирование меня увлекло
аж 18 лет назад
Уже почти 5 лет работаю в CUSTIS,
и что-то никак не надоест
4/104
Почему так долго в CUSTIS?
Иногда задаю себе этот вопрос…
Изначально пришел посмотреть на SCRUM
Оказалось, что попал в довольно необычную
компанию, внутренний настрой которой мне очень
подходит
На одном месте сидеть не привык, до CUSTIS
рекорд – 1,5 года
За 5 лет успел 5 раз сменить «направление
деятельности», оставаясь при этом в CUSTIS
Каждый раз – будто новая работа,
но в том же прекрасном и дружном коллективе
Новые запросы – новые возможности
5/104
О себе, о компании
Денис Гаврилов
Программирование меня увлекло
аж 18 лет назад
Уже почти 5 лет работаю в CUSTIS
Из них крайние 3,5 года в отделе
технологического развития
(Библиотеки, фреймворки, платформы, вот это вот все)
Вижу работу сразу нескольких прикладных групп
разработки
Везде похожие задачи и проблемы
Тема семинара актуальна для разных групп
6/104
О себе, о компании
Денис Гаврилов
Программирование меня увлекло
аж 18 лет назад
Уже почти 5 лет работаю в CUSTIS
Из них крайние 3,5 года в отделе
технологического развития
Регулярно помогаю организовать
процессы разработки
7/104
О себе, о компании
Денис Гаврилов
Программирование меня увлекло
аж 18 лет назад
Уже почти 5 лет работаю в CUSTIS
Из них крайние 3,5 года в отделе
технологического развития
Регулярно помогаю организовать
процессы разработки
Образование высшее, женат, двое детей
8/104
План
1. Теория
1. Цель семинара
2. Единое информационное поле
3. Дерево архитектурных решений
4. Процесс разработки
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
9/104
Цель семинара
10/104
Цель семинара – рассказать
о важности «легкого обмена
информацией и ее восстановления»,
а также об определенном наборе
практик, которые позволят достичь
прозрачности и «упростить
раскопки».
11/104
Зачем это все?
Разработка должна быть эффективной
Члены команды должны быть погружены
в «единое информационное поле»
Информация должна легко передаваться внутри
команды
Важная информация должна фиксироваться
и быстро восстанавливаться
12/104
Единое информационное поле
13/104
Разное понимание задач
Аналитик Разработчик
Тестировщик
14/104
Чем больше общего, тем лучше
Аналитик Разработчик
Тестировщик
Общее понимание
15/104
Зачем это все?
Разработка должна быть эффективной
Члены команды должны быть погружены
в «единое информационное поле»
Информация должна легко передаваться внутри
команды
Важная информация должна фиксироваться
и быстро восстанавливаться
16/104
Дерево архитектурных решений
Задача
Вариант 1 Вариант 2
17/104
Дерево архитектурных решений
Вопрос
Опять
вопрос
Снова
вопрос
18/104
Что самое важное?
Ключевые вопросы
Возможные ответы
Выбранный нами ответ
19/104
Самое важное
20/104
Лишние детали
21/104
Пример
Фредерик П. Брукс
Проектирование процесса проектирования
22/104
Зачем нужны все эти описания?
Деревья всякие…
В коде же все написано!
23/104
Идея Кодразработка
Код Идеяразбор кода
reverse engineering
Читаемый код?
24/104
Код Идеяразбор кода
reverse engineering
Зачем читать код, если есть слова?
время и дополнительные усилия
Описание
идеи
25/104
А самое главное:
Код описывает, что сделано
Но из него никак нельзя понять,
зачем это сделано
А еще возможности IDE
по комментированию кода ограничены
только неформатированным текстом
26/104
Совет №1
Одна картинка вместо тысячи слов
!
27/104
Тест 1
Читаем текст, отвечаем на вопросы
28/104
Форма состоит из трех частей Фильтры
Список логистических узлов
Карточка для редактирования узла
Фильтров три. По источнику, по получателю, по промежуточному узлу.
Для каждого фильтра мы показываем 2 текстбокса для «кода»
и «наименования» и кнопку «…» для показа списка для выбора элементов
В списке должны быть видны следующие колонки: Наименование, Источник,
Получатель, Активна?, Способ доставки, ТЗ ФРЦ
Над списком одна команда – Создать
Карточка содержит поля: Наименование, Активна с, Активна по, Лаг доставки
до получателя, Через ТЗ ФРЦ?, Дельта отгрузки клиенту на КД. При этом поля
«Активна с:» и «активна по:» находятся на одной линии и для второго поля
слово «активна» не пишем, только «по:». Все остальные поля выстроены
по одному на горизонтальную линию. Наименование описываем как набор
узлов разделенных знаком >
Далее на карточке должен быть грид со списком узлов цепочки. Поля грида:
Номер, Откуда, Куда, Способ доставки. Грид редактируемый
Еще добавляем поля с аудитом. Там видно, кем и когда создано, и кем и когда
изменено. Делаем 2 линии сначала «Создано» или «Изменено», потом
соответственно текстбокс с именем и контрол для дат с датой
На карточке поля группируются в 3 группы: Логистическая цепочка, Узлы
цепочки, Аудит
29/104
Проверка
Из скольких больших блоков состоит форма?
Какие это блоки?
В каком формате заполняется поле
«Наименование» в карточке?
Как выглядят поля с датами активности
на карточке?
Сколько групп контролов на карточке?
Как оформлены поля аудита?
30/104
Тест 2
Смотрим на картинку, отвечаем
на вопросы
31/104
32/104
Проверка
Из скольких больших блоков состоит форма?
Какие это блоки?
В каком формате заполняется поле
«Наименование» в карточке?
Как выглядят поля с датами активности
на карточке?
Сколько групп контролов на карточке?
Как оформлены поля аудита?
33/104
Каждой задаче – своя модель
34/104
UML-диаграмма классов
35/104
UML-диаграмма
последовательностей
36/104
Картинка в свободной форме
37/104
И даже «майндмап»
38/104
Где мы?
1. Теория
1. Цель
2. Единое информационное поле
3. Дерево архитектурных решений
4. Процесс разработки
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
39/104
Процесс разработки
Задание Процесс Результат
40/104
Ошибки случаются
Задание Процесс Результат
!=
41/104
Тестирование – избыточно,
но обязательно
Задание Процесс Результат Тестирование
!=
Исправление
42/104
Трудозатраты тоже важны
Задание Процесс Результат
Трудозатраты
Контроль процесса
Больше прозрачности – легче контроль!
43/104
Эффективная разработка это:
Делается то, что нужно
В оговоренные сроки
44/104
Задачи и состояния
Как правило, большая работа делится
на более мелкие задачи
Для учета задач есть специальные
системы – Jira, Bugzilla, TFS, …
У задач есть состояния
«Новая», «В работе», «Сделана»,
«Проверяется», «Исправляется»,
«Проверена»
45/104
Совет №2
Полезно дробить задачи так,
чтобы разработка
помещалась в 2 рабочих дня
!
46/104
CodeReview
Специальный тип проверки, когда один
разработчик смотрит на код другого
разработчика
Смотрим на качество кода
Ищем архитектурные проблемы
47/104
На CodeReview можно смотреть на:
Правильность написания кода
Правильность работы кода
Как правильно?
Зависит от задачи
Но я рекомендовал бы не тратить много
времени на тестирование при CR
Совет?
48/104
Где мы?
1. Теория
1. Цель
2. Единое информационное поле
3. Дерево архитектурных решений
4. Процесс разработки
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
49/104
50/104
Практика
51/104
План
1. Теория
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
1. Постановка задачи
2. Задача берется в работу
3. Началась разработка
4. Разработка завершена
5. Проверка
52/104
Постановка задачи
задание
53/104
Постановка задачи
А про постановку я ничего не скажу
Но желательно, если она будет
Scope, оценка
Оценка как инструмент сверки понимания
задачи
Тут планирование и карты
54/104
Какая постановка лучше?
Решение
Решение + проблема
Проблема
Совет №3
55/104
Какая постановка лучше?
Решение
Решение + проблема
Проблема
– плохо
– хорошо
– хорошо
Совет №3
56/104
Совет №3
В хорошей постановке обязательно
описана исходная проблема
!
57/104
Задача берется в работу
Задание Процесс
58/104
Проблема
Разработчик Василий взял задачу «Добавить
на форму экспорт в Excel», оцененную в 8 часов
Через неделю Василий сделал следующее:
Запилил инфраструктуру, которая позволяет
выгружать любые данные в формате CSV
Задача была переоткрыта, так как экспорт
требовался в *.XLS и для подобных задач в других
местах использовалась готовая библиотека
Кроме того, версия не была выпущена вовремя,
так как задача заняла в 5 раз больше времени
59/104
Задача берется в работу
Definition of done (DOD)
Как я понял требуемый результат
План
Как я буду это делать
60/104
Definition of done (DOD)
Основные характеристики результата,
по которым можно проверить его валидность
Одинаковое понимание результата
61/104
Пример
Задача
Настроить сборку проекта Server.WebAPI
на TeamCity
DOD
Две конфигурации:
Билд на коммит: NuGet-пакет публикуется в фид CUSTIS-dev
Релиз: NuGet-пакет публикуется в фид CUSTIS
Версия пакета должна совпадать версией сборки
Идентификатор пакета: CUSTIS.Server.WebAPI
Имя пакета: CUSTIS Server WebAPI Tools
62/104
План
Основные шаги и ключевые решения
Концентрация на процессе
Решает проблемы:
Используются не те инструменты/библиотеки
Решение не оптимально
Упущено что-то важное
Позволяет соотнести оценку и объем работ
63/104
Пример хорошего плана
Отключаем все проекты Research из солюшена
Отключаем все проекты Samples из солюшена, связанные
с датасервисами
Оставляем только доменную модель NHibernate и сэмпловый сервис
Samples.Server.WebAPI.NHibernate. Так же оставляем гибридный модуль
и его конфигурацию
Добавляем в сэмплы новый проект WinClient.Samples.Client.ODatav4
Копируем в него тестовую форму
CUSTIS.WinClient.Research.Client.ViewModel.WebAPIScenario1TestViewModel
Настраиваем гибридный модуль на запуск этой формы и отключаем все
остальные формы
Удаляем из проекта WinClient.Data.Client папку DataServiceQueryHelpers
Заменяем в проекте WinClient.Client шаблон ServiceReferenceTemplate.tt
на WebAPI.CodeGeneration.ttinclude
Отдельным коммитом (!) отправляем в svn изменения шаблона
WebAPI.CodeGeneration.ttinclude по сравнению с оригиналом
Убеждаемся, что солюшен собирается и запускается гибридный модуль
64/104
Пример идеального плана
План:
Создаем новую форму CheckPersonalInformationAccess
Ссылка на эту форму будет присутствовать в панели задач
справочник «Видимость ПД»
На форме доступно три вида отчета:
Отчет, дублирующий содержимое Excel файла, который получается при
экспорте справочника «Видимость ПД»
«Кто видит ПД сотрудника». Просмотр списка сотрудников, которые видят
ПД указанного сотрудника с описанием, в рамках каких правил
осуществляется доступ к видимости ПД.
«Чьи ПД видит сотрудник». Просмотр списка сотрудников, чьи ПД видит
указанный сотрудник с описанием, в рамках каких правил осуществляется
доступ к видимости ПД. Mockup интерфейса описан в Bug162057
На планировании в оценку не входило формирование списка правил
с описанием, по которым осуществляется доступ. Считаю, что оценка
выросла с 5 до 8ч
65/104
Пример плана,
который лучше не писать
Нужно:
1. Удалить сущность и таблицу.
2. Удалить использование сущности и внешние ключи на
таблицу.
3. Проанализировать Data Service (витрины данных)
на необходимость внесения изменений. Если они нужны –
оформить отдельным багом
План:
удаляем сущности, которые относятся к прайс-листу;
удаляем использование сущностей прайс-листа;
проверяем необходимость внесения изменений в Data
Service'ы (витрины данных)
Задача сформулирована предельно четко, план не пишу
66/104
Задача берется в работу
Задание Процесс DOD
67/104
Классика
68/104
Ранняя верификация понимания
результата
!=
69/104
Уточнение аналитики
План и DOD также можно рассматривать
как финишную обработку результата
аналитики, добавление к нему того,
что знает только программист
!
70/104
Началась разработка
Задание Процесс
71/104
Началась разработка
Умеренно подробные комментарии
при коммите
Комментарии в коде
Корректировка «плана», если всплывают
новые подробности
Обязательный сигнал, если появилось
опасение не вписаться в оценку
72/104
Комментарии при коммите
Номер бага
Описание сути коммита
73/104
Комментарии в коде
Про них и так все всё знают
Они должны быть
Они должны быть полезными
Лишние комментарии замусоривают код
и удорожают его поддержку
74/104
Как не нужно
Не пишите название задачи, его и так все
прочитают по номеру
75/104
Как не нужно
Слишком общие слова не говорят ничего
76/104
Как не нужно
Сравнение без комментариев
77/104
Корректировка плана
Новые технические ограничения
Недостаточная аналитика
Свежая идея
Обновляем план!
78/104
Корректировка плана
Первоначальный план – это контракт
(обязательства) перед командой!
!
!
79/104
Оценка будет превышена
Превышение случается
Дайте возможность на него правильно
отреагировать
Увеличить время
Уменьшить объем задачи
Помочь советом
80/104
Совет №3
Разделяй контексты, в которых
работаешь. Переключение контекста –
фиксация результата, достигнутого
в предыдущем
!
81/104
Очевидные контексты
Аналитика
Разработка
Тестирование
82/104
Неочевидные контексты
Прикладная задача
Инфраструктурная задача
83/104
Прикладное-инфраструктурное
Решение обычной прикладной задачи
и создание инфраструктуры – это разная
работа
Разные требования к качеству
проектирования и оформления
Какая-то инфраструктура, возможно, уже есть
84/104
Не трогай код вне своей задачи!
Увидел проблему – заведи баг!
Совет №4
85/104
Разработка завершена
Задание Процесс Результат
86/104
Разработка завершена
Краткое резюме, чем фактические действия
и решения отличаются от «плана»
Аналогично для DOD
Советы тестировщикам и CodeReview’ерам,
на что посмотреть особенно тщательно
87/104
Отличия «плана» и «факта»
Могут быть
Но должны быть максимально описаны
в процессе
По завершению – только краткое резюме
88/104
CodeReview
Почти всегда – от изменений (план в помощь)
Замечания лучше нумеровать
В коммитах по исправлению указывать номер
Не править самому!
89/104
Тестирование
Задание Процесс Результат Тестирование
!=
90/104
Тестирование
Задачу описывают:
Первоначальная постановка
DOD
«Советы тестировщику»
Замечания фиксируются письменно
Обязательно описываются сценарии
воспроизведения
91/104
Резюме
План
DOD
…
92/104
Где мы?
1. Теория
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
4. О раскопках
93/104
Немного о раскопках,
или Где же обещанные артефакты?
94/104
Без письменности нет истории
Возможно, самым знаменательным
в истории Месопотамии является то,
что её начало совпадает с началом
мировой истории. Первые письменные
документы принадлежат шумерам.
Из этого следует, что история
в собственном смысле началась в Шумере
и, возможно, была создана шумерами.
95/104
Шумерская клинопись
96/104
Египетские иероглифы
97/104
Новгородские берестяные грамоты
98/104
Письма в будущее
Следующим поколениям разработчиков
должно быть понятно, почему было
принято то или иное решение в рамках
«дерева»
20 минут «сейчас» экономят дни,
а то и недели «потом»
Ключевые решения, костыли,
неочевидные аргументы
99/104
Нет комментариев –
нет разработчика?
Этих людей я на работе не застал!
Но ключевые решения они зафиксировали,
и я им благодарен
100/104
То самое ключевое решение
101/104
С отсылкой к багу
102/104
Напиши коммент –
войди в историю!
103/104