Практики командной работы: о пользе письменных...

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





Уже почти 5 лет работаю в CUSTIS

Из них крайние 3,5 года в отделе

технологического развития

(Библиотеки, фреймворки, платформы, вот это вот все)

Вижу работу сразу нескольких прикладных групп

разработки

Везде похожие задачи и проблемы

Тема семинара актуальна для разных групп

6/104








Регулярно помогаю организовать

процессы разработки

7/104








Регулярно помогаю организовать

процессы разработки

Образование высшее, женат, двое детей

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. Цель






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. Цель






49/104

50/104

Практика

51/104

План

1. Теория



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

http://bugs.office.custis.ru/bugs/show_bug.cgi?id=162057

Пример плана,

который лучше не писать

Нужно:

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. Теория



4. О раскопках

93/104

Немного о раскопках,

или Где же обещанные артефакты?

94/104

Без письменности нет истории

Возможно, самым знаменательным

в истории Месопотамии является то,

что её начало совпадает с началом

мировой истории. Первые письменные

документы принадлежат шумерам.

Из этого следует, что история

в собственном смысле началась в Шумере

и, возможно, была создана шумерами.

95/104

Шумерская клинопись

96/104

Египетские иероглифы

97/104

Новгородские берестяные грамоты

98/104

Письма в будущее

Следующим поколениям разработчиков

должно быть понятно, почему было

принято то или иное решение в рамках

«дерева»

20 минут «сейчас» экономят дни,

а то и недели «потом»

Ключевые решения, костыли,

неочевидные аргументы

99/104

Нет комментариев –

нет разработчика?

Этих людей я на работе не застал!

Но ключевые решения они зафиксировали,

и я им благодарен

100/104

То самое ключевое решение

101/104

С отсылкой к багу

102/104

Напиши коммент –

войди в историю!

103/104

Спасибо!

Вопросы?


[email protected]

104/104

mailto:[email protected]

Практики командной работы: о пользе письменных...

Software

Transcript of Практики командной работы: о пользе письменных...