Документ представляет собой семинар о важности письменных артефактов в практике командной работы в сфере программирования. Основное внимание уделяется созданию единого информационного поля, обмену информацией и формализации процессов разработки для повышения эффективности команды. Обсуждаются различные практические советы по улучшению коммуникации и структурированию рабочих задач на примерах из опыта ведущего семинара.

1. 16 октября 2014 года
Практики командной работы:
о пользе письменных
артефактов
Денис Гаврилов
Руководитель группы

2. О себе, о компании
 Денис Гаврилов
 Программирование меня
увлекло аж 18 лет назад,
и что-то никак «не отпустит» 
2/104

3. QBasic
Pascal
VisualBasic
C++
PHP
C#
Java
Тема семинара актуальна
для каждого языка
3/104

4. О себе, о компании
 Денис Гаврилов
 Программирование меня увлекло
аж 18 лет назад
 Уже почти 5 лет работаю в CUSTIS,
и что-то никак не надоест
4/104

5. Почему так долго в CUSTIS?
 Иногда задаю себе этот вопрос…
 Изначально пришел посмотреть на SCRUM
 Оказалось, что попал в довольно необычную
компанию, внутренний настрой которой мне очень
подходит
 На одном месте сидеть не привык, до CUSTIS
рекорд – 1,5 года
 За 5 лет успел 5 раз сменить «направление
деятельности», оставаясь при этом в CUSTIS
 Каждый раз – будто новая работа,
но в том же прекрасном и дружном коллективе
 Новые запросы – новые возможности
5/104

6. О себе, о компании
 Денис Гаврилов
 Программирование меня увлекло
аж 18 лет назад
 Уже почти 5 лет работаю в CUSTIS
 Из них крайние 3,5 года в отделе
технологического развития
 (Библиотеки, фреймворки, платформы, вот это вот все)
 Вижу работу сразу нескольких прикладных групп
разработки
 Везде похожие задачи и проблемы
 Тема семинара актуальна для разных групп
6/104

7. О себе, о компании
 Денис Гаврилов
 Программирование меня увлекло
аж 18 лет назад
 Уже почти 5 лет работаю в CUSTIS
 Из них крайние 3,5 года в отделе
технологического развития
 Регулярно помогаю организовать
процессы разработки
7/104

8. О себе, о компании
 Денис Гаврилов
 Программирование меня увлекло
аж 18 лет назад
 Уже почти 5 лет работаю в CUSTIS
 Из них крайние 3,5 года в отделе
технологического развития
 Регулярно помогаю организовать
процессы разработки
 Образование высшее, женат, двое детей
8/104

9. План
1. Теория
1. Цель семинара
2. Единое информационное поле
3. Дерево архитектурных решений
4. Процесс разработки
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
9/104

10. Цель семинара
10/104

11. Цель семинара – рассказать
о важности «легкого обмена
информацией и ее восстановления»,
а также об определенном наборе
практик, которые позволят достичь
прозрачности и «упростить
раскопки».
11/104

12. Зачем это все?
 Разработка должна быть эффективной
 Члены команды должны быть погружены
в «единое информационное поле»
 Информация должна легко передаваться внутри
команды
 Важная информация должна фиксироваться
и быстро восстанавливаться
12/104

13. Единое информационное поле
13/104

14. Разное понимание задач
Аналитик Разработчик
Тестировщик
14/104

15. Чем больше общего, тем лучше
Аналитик Разработчик
Тестировщик
Общее понимание
15/104

16. Зачем это все?
 Разработка должна быть эффективной
 Члены команды должны быть погружены
в «единое информационное поле»
 Информация должна легко передаваться внутри
команды
 Важная информация должна фиксироваться
и быстро восстанавливаться
16/104

17. Дерево архитектурных решений
Задача
Вариант 1 Вариант 2
17/104

18. Дерево архитектурных решений
Вопрос
Опять
вопрос
Снова
вопрос
18/104

19. Что самое важное?
 Ключевые вопросы
 Возможные ответы
 Выбранный нами ответ
19/104

20. Самое важное
20/104

21. Лишние детали
21/104

22. Пример
Фредерик П. Брукс
Проектирование процесса проектирования
22/104

23. Зачем нужны все эти описания?
Деревья всякие…
В коде же все написано!
23/104

24. Идея Код
разработка
Код Идея
разбор кода
reverse engineering
Читаемый код?
24/104

25. Код Идея
разбор кода
reverse engineering
Зачем читать код, если есть слова?
время и дополнительные усилия
Описание
идеи
25/104

26. А самое главное:
 Код описывает, что сделано
 Но из него никак нельзя понять,
зачем это сделано
 А еще возможности IDE
по комментированию кода ограничены
только неформатированным текстом
26/104

27. Совет №1
Одна картинка вместо тысячи слов
!
27/104

28. Тест 1
 Читаем текст, отвечаем на вопросы
28/104

29.  Форма состоит из трех частей
 Фильтры
 Список логистических узлов
 Карточка для редактирования узла
 Фильтров три. По источнику, по получателю, по промежуточному узлу.
Для каждого фильтра мы показываем 2 текстбокса для «кода»
и «наименования» и кнопку «…» для показа списка для выбора элементов
 В списке должны быть видны следующие колонки: Наименование, Источник,
Получатель, Активна?, Способ доставки, ТЗ ФРЦ
 Над списком одна команда – Создать
 Карточка содержит поля: Наименование, Активна с, Активна по, Лаг доставки
до получателя, Через ТЗ ФРЦ?, Дельта отгрузки клиенту на КД. При этом поля
«Активна с:» и «активна по:» находятся на одной линии и для второго поля
слово «активна» не пишем, только «по:». Все остальные поля выстроены
по одному на горизонтальную линию. Наименование описываем как набор
узлов разделенных знаком >
 Далее на карточке должен быть грид со списком узлов цепочки. Поля грида:
Номер, Откуда, Куда, Способ доставки. Грид редактируемый
 Еще добавляем поля с аудитом. Там видно, кем и когда создано, и кем и когда
изменено. Делаем 2 линии сначала «Создано» или «Изменено», потом
соответственно текстбокс с именем и контрол для дат с датой
 На карточке поля группируются в 3 группы: Логистическая цепочка, Узлы
цепочки, Аудит
29/104

30. Проверка
 Из скольких больших блоков состоит форма?
 Какие это блоки?
 В каком формате заполняется поле
«Наименование» в карточке?
 Как выглядят поля с датами активности
на карточке?
 Сколько групп контролов на карточке?
 Как оформлены поля аудита?
30/104

31. Тест 2
 Смотрим на картинку, отвечаем
на вопросы
31/104

32. 32/104

33. Проверка
 Из скольких больших блоков состоит форма?
 Какие это блоки?
 В каком формате заполняется поле
«Наименование» в карточке?
 Как выглядят поля с датами активности
на карточке?
 Сколько групп контролов на карточке?
 Как оформлены поля аудита?
33/104

34. Каждой задаче – своя модель
34/104

35. UML-диаграмма классов
35/104

36. UML-диаграмма
последовательностей
36/104

37. Картинка в свободной форме
37/104

38. И даже «майндмап»
38/104

39. Где мы?
1. Теория
1. Цель
2. Единое информационное поле
3. Дерево архитектурных решений
4. Процесс разработки
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
39/104

40. Процесс разработки
Задание Процесс Результат
40/104

41. Ошибки случаются
Задание Процесс Результат
!=
41/104

42. Тестирование – избыточно,
но обязательно
Задание Процесс Результат Тестирование
!=
Исправление
42/104

43. Трудозатраты тоже важны
Задание Процесс Результат
Трудозатраты
Контроль процесса
Больше прозрачности – легче контроль!
43/104

44. Эффективная разработка это:
 Делается то, что нужно
 В оговоренные сроки
44/104

45. Задачи и состояния
 Как правило, большая работа делится
на более мелкие задачи
 Для учета задач есть специальные
системы – Jira, Bugzilla, TFS, …
 У задач есть состояния
 «Новая», «В работе», «Сделана»,
«Проверяется», «Исправляется»,
«Проверена»
45/104

46. Совет №2
Полезно дробить задачи так,
чтобы разработка
помещалась в 2 рабочих дня
!
46/104

47. CodeReview
 Специальный тип проверки, когда один
разработчик смотрит на код другого
разработчика
 Смотрим на качество кода
 Ищем архитектурные проблемы
47/104

48.  На CodeReview можно смотреть на:
 Правильность написания кода
 Правильность работы кода
 Как правильно?
 Зависит от задачи
 Но я рекомендовал бы не тратить много
времени на тестирование при CR
Совет?
48/104

49. Где мы?
1. Теория
1. Цель
2. Единое информационное поле
3. Дерево архитектурных решений
4. Процесс разработки
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
49/104

50. 50/104

51. Практика
51/104

52. План
1. Теория
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
1. Постановка задачи
2. Задача берется в работу
3. Началась разработка
4. Разработка завершена
5. Проверка
52/104

53. Постановка задачи
задание
53/104

54. Постановка задачи
 А про постановку я ничего не скажу 
 Но желательно, если она будет
 Scope, оценка
 Оценка как инструмент сверки понимания
задачи
 Тут планирование и карты
54/104

55. Какая постановка лучше?
 Решение
 Решение + проблема
 Проблема
Совет №3
55/104

56. Какая постановка лучше?
 Решение
 Решение + проблема
 Проблема
– плохо
– хорошо
– хорошо
Совет №3
56/104

57. Совет №3
В хорошей постановке обязательно
описана исходная проблема
!
57/104

58. Задача берется в работу
Задание Процесс
58/104

59. Проблема
 Разработчик Василий взял задачу «Добавить
на форму экспорт в Excel», оцененную в 8 часов
 Через неделю Василий сделал следующее:
 Запилил инфраструктуру, которая позволяет
выгружать любые данные в формате CSV
 Задача была переоткрыта, так как экспорт
требовался в *.XLS и для подобных задач в других
местах использовалась готовая библиотека
 Кроме того, версия не была выпущена вовремя,
так как задача заняла в 5 раз больше времени
59/104

60. Задача берется в работу
 Definition of done (DOD)
 Как я понял требуемый результат
 План
 Как я буду это делать
60/104

61. Definition of done (DOD)
 Основные характеристики результата,
по которым можно проверить его валидность
 Одинаковое понимание результата
61/104

62. Пример
 Задача
 Настроить сборку проекта Server.WebAPI
на TeamCity
 DOD
 Две конфигурации:
 Билд на коммит: NuGet-пакет публикуется в фид CUSTIS-dev
 Релиз: NuGet-пакет публикуется в фид CUSTIS
 Версия пакета должна совпадать версией сборки
 Идентификатор пакета: CUSTIS.Server.WebAPI
 Имя пакета: CUSTIS Server WebAPI Tools
62/104

63. План
 Основные шаги и ключевые решения
 Концентрация на процессе
 Решает проблемы:
 Используются не те инструменты/библиотеки
 Решение не оптимально
 Упущено что-то важное
 Позволяет соотнести оценку и объем работ
63/104

64. Пример хорошего плана
 Отключаем все проекты 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

65. Пример идеального плана
План:
 Создаем новую форму CheckPersonalInformationAccess
 Ссылка на эту форму будет присутствовать в панели задач
справочник «Видимость ПД»
 На форме доступно три вида отчета:
 Отчет, дублирующий содержимое Excel файла, который получается при
экспорте справочника «Видимость ПД»
 «Кто видит ПД сотрудника». Просмотр списка сотрудников, которые видят
ПД указанного сотрудника с описанием, в рамках каких правил
осуществляется доступ к видимости ПД.
 «Чьи ПД видит сотрудник». Просмотр списка сотрудников, чьи ПД видит
указанный сотрудник с описанием, в рамках каких правил осуществляется
доступ к видимости ПД. Mockup интерфейса описан в Bug162057
На планировании в оценку не входило формирование списка правил
с описанием, по которым осуществляется доступ. Считаю, что оценка
выросла с 5 до 8ч
65/104

66. Пример плана,
который лучше не писать
 Нужно:
1. Удалить сущность и таблицу.
2. Удалить использование сущности и внешние ключи на
таблицу.
3. Проанализировать Data Service (витрины данных)
на необходимость внесения изменений. Если они нужны –
оформить отдельным багом
 План:
удаляем сущности, которые относятся к прайс-листу;
удаляем использование сущностей прайс-листа;
проверяем необходимость внесения изменений в Data
Service'ы (витрины данных)
 Задача сформулирована предельно четко, план не пишу
66/104

67. Задача берется в работу
Задание Процесс DOD
67/104

68. Классика
68/104

69. Ранняя верификация понимания
результата
!=
69/104

70. Уточнение аналитики
 План и DOD также можно рассматривать
как финишную обработку результата
аналитики, добавление к нему того,
что знает только программист
!
70/104

71. Началась разработка
Задание Процесс
71/104

72. Началась разработка
 Умеренно подробные комментарии
при коммите
 Комментарии в коде
 Корректировка «плана», если всплывают
новые подробности
 Обязательный сигнал, если появилось
опасение не вписаться в оценку
72/104

73. Комментарии при коммите
 Номер бага
 Описание сути коммита
73/104

74. Комментарии в коде
 Про них и так все всё знают
 Они должны быть
 Они должны быть полезными
 Лишние комментарии замусоривают код
и удорожают его поддержку
74/104

75. Как не нужно
 Не пишите название задачи, его и так все
прочитают по номеру
75/104

76. Как не нужно
 Слишком общие слова не говорят ничего
76/104

77. Как не нужно
 Сравнение без комментариев
77/104

78. Корректировка плана
 Новые технические ограничения
 Недостаточная аналитика
 Свежая идея
Обновляем план!
78/104

79. Корректировка плана
 Первоначальный план – это контракт
(обязательства) перед командой!
!
!
79/104

80. Оценка будет превышена
 Превышение случается
 Дайте возможность на него правильно
отреагировать
 Увеличить время
 Уменьшить объем задачи
 Помочь советом
80/104

81. Совет №3
Разделяй контексты, в которых
работаешь. Переключение контекста –
фиксация результата, достигнутого
в предыдущем
!
81/104

82. Очевидные контексты
 Аналитика
 Разработка
 Тестирование
82/104

83. Неочевидные контексты
 Прикладная задача
 Инфраструктурная задача
83/104

84. Прикладное-инфраструктурное
 Решение обычной прикладной задачи
и создание инфраструктуры – это разная
работа
 Разные требования к качеству
проектирования и оформления
 Какая-то инфраструктура, возможно, уже есть
84/104

85.  Не трогай код вне своей задачи!
 Увидел проблему – заведи баг!
Совет №4
85/104

86. Разработка завершена
Задание Процесс Результат
86/104

87. Разработка завершена
 Краткое резюме, чем фактические действия
и решения отличаются от «плана»
 Аналогично для DOD
 Советы тестировщикам и CodeReview’ерам,
на что посмотреть особенно тщательно
87/104

88. Отличия «плана» и «факта»
 Могут быть
 Но должны быть максимально описаны
в процессе
 По завершению – только краткое резюме
88/104

89. CodeReview
 Почти всегда – от изменений (план в помощь)
 Замечания лучше нумеровать
 В коммитах по исправлению указывать номер
 Не править самому!
89/104

90. Тестирование
Задание Процесс Результат Тестирование
!=
90/104

91. Тестирование
 Задачу описывают:
 Первоначальная постановка
 DOD
 «Советы тестировщику»
 Замечания фиксируются письменно
 Обязательно описываются сценарии
воспроизведения
91/104

92. Резюме
 План
 DOD
 …
92/104

93. Где мы?
1. Теория
2. Перерыв (чай, кофе, печеньки, вопросы)
3. Практические советы
4. О раскопках
93/104

94. Немного о раскопках,
или Где же обещанные артефакты?
94/104

95. Без письменности нет истории
Возможно, самым знаменательным
в истории Месопотамии является то,
что её начало совпадает с началом
мировой истории. Первые письменные
документы принадлежат шумерам.
Из этого следует, что история
в собственном смысле началась в Шумере
и, возможно, была создана шумерами.
95/104

96. Шумерская клинопись
96/104

97. Египетские иероглифы
97/104

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

99. Письма в будущее
 Следующим поколениям разработчиков
должно быть понятно, почему было
принято то или иное решение в рамках
«дерева»
 20 минут «сейчас» экономят дни,
а то и недели «потом»
 Ключевые решения, костыли,
неочевидные аргументы
99/104

100. Нет комментариев –
нет разработчика?
 Этих людей я на работе не застал!
 Но ключевые решения они зафиксировали,
и я им благодарен 
100/104

101. То самое ключевое решение
101/104

102. С отсылкой к багу
102/104

103. Напиши коммент –
войди в историю!
103/104

104. Спасибо!
Вопросы?
Денис Гаврилов
dgavrilov@custis.ru
104/104