Инструменты и методы эффективной удалённой работы Дмитрий Лебедев [email_address] obnob.com
Чего в этом докладе не будет
Чего в этом докладе не будет <ul><li>Как запустить стартап </li></ul>
Чего в этом докладе не будет <ul><li>Как запустить стартап
Как стать фрилансером </li></ul>
Чего в этом докладе не будет <ul><li>Как запустить стартап
Как стать фрилансером
Как искать заказчиков и работать с ними </li></ul>
Чего в этом докладе не будет <ul><li>Как запустить стартап
Как стать фрилансером
Как искать заказчиков и работать с ними
Как перейти с ADD* на Agile
* Asshole Driven Development </li></ul>
Чего в этом докладе не будет <ul><li>Как запустить стартап
Как стать фрилансером
Как искать заказчиков и работать с ними
Как перейти с ADD* на Agile
Как довести проект до релиза
* Asshole Driven Development </li></ul>
Что в этом докладе будет
Что в этом докладе будет <ul><li>Укажу на проблемы </li></ul>
Что в этом докладе будет <ul><li>Укажу на проблемы
Расскажу про их решения: </li></ul>
Что в этом докладе будет <ul><li>Укажу на проблемы
Расскажу про их решения: </li><ul><li>Как звонить по скайпу
Как делать  работающие  скетчи компонент
Как делать  качественный  обзор кода </li></ul></ul>
Что в этом докладе будет <ul><li>Укажу на проблемы
Расскажу про их решения: </li><ul><li>Как звонить по скайпу
Как делать  работающие  скетчи компонент
Как делать  качественный  обзор кода </li></ul><li>Назову полезные инструменты </li></ul>
Чем хороша удалённая работа <ul><li>Консервативный подход: удалённая работа между офисами </li><ul><li>Не нужно гонять спе...
Можно следить за работой ПО круглые сутки
Можно обмениваться опытом на бо́льшие расстояния  </li></ul><li>Полностью автономная работа без офиса: </li><ul><li>Свобод...
Учит терпению, самоорганизации и самостоятельности </li></ul></ul>
Чем плоха́ удалённая работа <ul><li>По умолчанию ты – в четырёх стена́х
Ночная работа и подъём в полдень
В общении с коллегами есть  лаги </li></ul>
<ul><li>Общение: </li><ul><li>– Вот есть проблема
– Исправили, проверяйте
– Всё равно не работает
– А теперь?
– Работает. Спасибо! </li></ul><li>Вопрос залу: что здесь не так? </li></ul>Проблема №1
<ul><li>Общение: </li><ul><li>– Вот есть проблема
– Исправили, проверяйте
– Всё равно не работает
– А теперь? </li></ul><li>Пауза между репликами – 12 часов.
Этот диалог шёл всю неделю, потому что две стороны находились в 12 часовых поясах, и их рабочее время не пересекалось. </l...
Решение проблемы №1: звонки <ul><li>Звонок проще почты
Назначаем регулярные звонки в определённое время, удобное всем
Upcoming SlideShare
Loading in …5
×

Выступление: инструменты и методы эффективной удалённой работы

358 views
305 views

Published on

Выступление на Сибирских Интернет-Неделях, 25.9.11

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
358
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Выступление: инструменты и методы эффективной удалённой работы

  1. 1. Инструменты и методы эффективной удалённой работы Дмитрий Лебедев [email_address] obnob.com
  2. 2. Чего в этом докладе не будет
  3. 3. Чего в этом докладе не будет <ul><li>Как запустить стартап </li></ul>
  4. 4. Чего в этом докладе не будет <ul><li>Как запустить стартап
  5. 5. Как стать фрилансером </li></ul>
  6. 6. Чего в этом докладе не будет <ul><li>Как запустить стартап
  7. 7. Как стать фрилансером
  8. 8. Как искать заказчиков и работать с ними </li></ul>
  9. 9. Чего в этом докладе не будет <ul><li>Как запустить стартап
  10. 10. Как стать фрилансером
  11. 11. Как искать заказчиков и работать с ними
  12. 12. Как перейти с ADD* на Agile
  13. 13. * Asshole Driven Development </li></ul>
  14. 14. Чего в этом докладе не будет <ul><li>Как запустить стартап
  15. 15. Как стать фрилансером
  16. 16. Как искать заказчиков и работать с ними
  17. 17. Как перейти с ADD* на Agile
  18. 18. Как довести проект до релиза
  19. 19. * Asshole Driven Development </li></ul>
  20. 20. Что в этом докладе будет
  21. 21. Что в этом докладе будет <ul><li>Укажу на проблемы </li></ul>
  22. 22. Что в этом докладе будет <ul><li>Укажу на проблемы
  23. 23. Расскажу про их решения: </li></ul>
  24. 24. Что в этом докладе будет <ul><li>Укажу на проблемы
  25. 25. Расскажу про их решения: </li><ul><li>Как звонить по скайпу
  26. 26. Как делать работающие скетчи компонент
  27. 27. Как делать качественный обзор кода </li></ul></ul>
  28. 28. Что в этом докладе будет <ul><li>Укажу на проблемы
  29. 29. Расскажу про их решения: </li><ul><li>Как звонить по скайпу
  30. 30. Как делать работающие скетчи компонент
  31. 31. Как делать качественный обзор кода </li></ul><li>Назову полезные инструменты </li></ul>
  32. 32. Чем хороша удалённая работа <ul><li>Консервативный подход: удалённая работа между офисами </li><ul><li>Не нужно гонять специалистов в командировки
  33. 33. Можно следить за работой ПО круглые сутки
  34. 34. Можно обмениваться опытом на бо́льшие расстояния </li></ul><li>Полностью автономная работа без офиса: </li><ul><li>Свободный график (есть плюсы и минусы), свобода передвижения
  35. 35. Учит терпению, самоорганизации и самостоятельности </li></ul></ul>
  36. 36. Чем плоха́ удалённая работа <ul><li>По умолчанию ты – в четырёх стена́х
  37. 37. Ночная работа и подъём в полдень
  38. 38. В общении с коллегами есть лаги </li></ul>
  39. 39. <ul><li>Общение: </li><ul><li>– Вот есть проблема
  40. 40. – Исправили, проверяйте
  41. 41. – Всё равно не работает
  42. 42. – А теперь?
  43. 43. – Работает. Спасибо! </li></ul><li>Вопрос залу: что здесь не так? </li></ul>Проблема №1
  44. 44. <ul><li>Общение: </li><ul><li>– Вот есть проблема
  45. 45. – Исправили, проверяйте
  46. 46. – Всё равно не работает
  47. 47. – А теперь? </li></ul><li>Пауза между репликами – 12 часов.
  48. 48. Этот диалог шёл всю неделю, потому что две стороны находились в 12 часовых поясах, и их рабочее время не пересекалось. </li></ul>Проблема №1: лаги
  49. 49. Решение проблемы №1: звонки <ul><li>Звонок проще почты
  50. 50. Назначаем регулярные звонки в определённое время, удобное всем
  51. 51. Общение голосом намного быстрее, чем почта или мессенджеры </li><ul><li>Мессенджеры несут только вспомогательную функцию (например, послать ссылку) </li></ul></ul>
  52. 52. Проблема №2: пустая болтовня <ul><li>Звонки по телефону или скайпу не приносят ясности
  53. 53. Письма влом писать </li></ul>
  54. 54. Решение проблемы №2 <ul><li>Звонки по телефону или скайпу не приносят ясности
  55. 55. Письма влом писать
  56. 56. Общение по Гугло-Толку бестолковое
  57. 57. Решение: звонить и писать одновременно. </li><ul><li>Etherpad (openetherpad.com), Collabedit, Emacs Rudel, Unix Screen (ssh, screen -x) </li></ul></ul>
  58. 58. EtherPad
  59. 59. EtherPad: подсветка
  60. 60. EtherPad: опции
  61. 61. EtherPad: история правок
  62. 62. Важный навык <ul>Важное умение для решения проблемы №2: <li>Все умеют кивать и говорить ”понятно”
  63. 63. Потом становится непонятно
  64. 64. Не все умеют спрашивать, но этому можно научиться </li><ul><li>Для начала можно попробовать задавать вопросы обо всём, что непонятно </li></ul></ul>
  65. 65. Проблема №3 <ul><li>На почиркушках всё красиво, а в коде не выходит
  66. 66. ”Вот, всё ж просто, делай.”
  67. 67. Рядовые разработчики оставлены один на один с трудными задачами
  68. 68. Не идёт обмен опытом
  69. 69. Ошибки, рефакторинг </li></ul>
  70. 70. Отступление: авиация <ul><li>Программисты, как и пилоты, принимают много решений
  71. 71. Мозг фокусируется на решении задачи и отбрасывает ”помехи” </li></ul>Иллюстрация: http://www.airliners.net/photo/1958210/L/
  72. 72. Решение проблемы №3 <ul><li>Парное программирование </li><ul><li>Звоним голосом, пишем в редакторе
  73. 73. Одновременно пишет только один
  74. 74. Тот, кто должен будет продолжать задачу дальше, пишет больше (иначе тот, кто долго не пишет, заснёт) </li></ul><li>Обмен опытом происходит мгновенно
  75. 75. Посмотрел-повторил – особенность поведения homo sapiens, она зашита в мозг. Чтение книг по паттернам – нет. </li></ul>
  76. 76. Инструменты для ПП <ul><li>Emacs Rudel
  77. 77. SSH + Unix Screen + любой редактор типа Emacs/Vim
  78. 78. Попробовать туннелировать окно Gedit через SSH (не делали)
  79. 79. OpenEtherPad, collabedit (есть подсветка синтаксиса)
  80. 80. Mercurial или Git </li></ul>
  81. 81. Проблема №4 <ul><li>Обзор кода проводится так: </li><ul><li>Ведущий программист смотрит диффы (пакеты изменений) и выявляет ошибки: </li><ul><li>Говнокод
  82. 82. Плохой нейминг
  83. 83. Код без комментариев
  84. 84. Копипаст </li></ul><li>Насколько это эффективно? </li></ul></ul>
  85. 85. Упражнение: обзор кода
  86. 86. Ответ <ul><li>Этот код корректен (комментарии, имена переменных)
  87. 87. Он проходит статический тест pyflakes
  88. 88. Проходит тест pep8 (стандарт форматирования в Питоне)
  89. 89. Код находится не на своём месте
  90. 90. Я это заметил, когда объяснял принципы работы приложения своему коллеге </li></ul>
  91. 91. Решение проблемы №4 <ul><li>Тот, кто писал код знает его лучше всего
  92. 92. Во время работы он фокусируется на решении задачи, не качестве решения
  93. 93. Поэтому обзор делаем так: </li><ul><li>Ведущий и рядовой программисты садятся и смотрят новый код
  94. 94. Тот, кто писал его, объясняет, что и где делается (и смотрит на свой код чужими глазами)
  95. 95. Исправления пишем сразу же на месте </li></ul></ul>
  96. 96. Звонок с Кевином <ul><li>Пора звонить </li></ul>
  97. 97. Системы управления версиями <ul><li>Пара примеров работы в РСУВ </li></ul>
  98. 98. Обходим проблемы на главной ветке bug Рабочая ревизия
  99. 99. Совет: интеграционные ветки <ul><li>В Mercurial мы используем интеграционные ветки
  100. 100. Большие изменения, которые затрагивают много чужого кода ведутся в своей ветке
  101. 101. Вместо вливания в основную ветку, мы сливаем две ветки, но коммитим в новую
  102. 102. Получаем то, каким был бы проект после слияния веток.
  103. 103. Если проект работает, вливаем интеграционную ветку обратно в основную </li></ul>
  104. 104. Merge with default Fix Merge with feature Merge with default Merge with feature-integration Work Work Work Work Интеграционная ветка Ветка feature Ветка default Ветка feature-integration
  105. 105. Проблема №5 <ul><li>Кто чем занимается? (Кому на Руси...)
  106. 106. Обычно: </li><ul><li>Ведущий программирует API и архитектуру и кайфует
  107. 107. Рядовые пытаются встроить всё это в сайт и заставить работать </li></ul><li>Результат: </li><ul><li>Пишем на деньги инвестора свои фреймворки
  108. 108. Фреймворки не работают, потому что их автор сам не использует их в деле. Фактически он разрабатывает стороннюю библиотеку. </li></ul></ul>
  109. 109. Решение проблемы №5 <ul><li>Ведущий программист </li><ul><li>занимается архитектурой сервера
  110. 110. ищет инструменты для программирования (дебагеры, библиотеки) </li></ul><li>Рядовые </li><ul><li>Пишут крупные компоненты в паре с ведущим или друг с другом и кайфуют. (Людям инстинктивно нравится заботиться о том, что они построили сами.)
  111. 111. Несут за свои архитектурные решения ответственность, то есть исправляют баги </li></ul></ul>
  112. 112. Полезная деятельность <ul><li>Выделяйте внутренние компоненты в отдельные опенсорсные проекты </li><ul><li>Очень просто делать на Mercurial Subrepo </li></ul><li>Выкладывайте их на GitHub, ButBucket
  113. 113. Пусть авторами компонент будут рядовые программисты, они будут тратить и свободное время на эти проекты </li></ul>
  114. 114. Вариация проблемы №5 <ul><li>”Зачем нам умный тестировщик, знающий Git/Mercurial, а тем более X, Y, Z? Он же убежит!”
  115. 115. Решение: не держите его за быдло.
  116. 116. ”Тупые” задачи решаются автоматизацией тестов (buildbot, django-coverage, selenium), пусть он пишет скрипты </li></ul>
  117. 117. Как быть командой <ul><li>Регулярно проводить встречи всей команды, например, программистов.
  118. 118. На встречу выносим вопросы, касающиеся всех. Кто что сделал – обсуждаем поменьше, это не интересно.
  119. 119. Приветствуем сообщения о плохих решениях и плохом коде
  120. 120. Приветствуем обсуждение новых технологий, случайно найденных в Сети
  121. 121. Документ из встречи для архива отправляем в почтовую рассылку </li></ul>
  122. 122. Общие советы <ul><li>Удалённо можно работать только небольшой командой.
  123. 123. Рабочих рук мало, поэтому минимум собственного кода. В Сети уже много готовых компонент
  124. 124. Люди работают над разными частями, чтобы избежать конфликтов правок, но помогают друг другу по запросу </li></ul>
  125. 125. Общие советы <ul><li>Окружение проекта должно быть как можно более одинаковым </li><ul><li>У кого система Windows, запускает VMWare
  126. 126. Buildout </li><ul><li>$ python bootstrap.py [--distribute]
  127. 127. $ bin/buildout </li></ul><li>Конфигурация проекта и рецепты – в buildout.cfg
  128. 128. virtualenv </li></ul><li>Автоматизируйте работу </li><ul><li>buildbot </li></ul></ul>
  129. 129. Вёрстка задом наперёд <ul><li>В веб-проекте мы попробовали делать вёрстку задом-наперёд </li></ul><ul><ul><li>Делаем работающий макет на JavaScript
  130. 130. Делаем обслуживающий его серверный код
  131. 131. Делаем дизайн
  132. 132. Делаем вёрстку </li></ul></ul><ul><li>Не проходите мимо: Object Oriented CSS (oocss.org) </li><ul><li>Сокращаёт вёрстку, позволяет не верстальщикам верстать неплохие страницы </li></ul></ul>
  133. 133. PivotalTracker
  134. 134. Dropbox
  135. 135. Культура работы <ul><li>Обратите внимание на регулярные ошибки и решите, как их можно исправить автоматически, не полагаясь на ”культуру работы” (к вопросу Mercurial vs Git) </li></ul>Иллюстрация: codinghorror.com
  136. 136. Культура работы <ul><li>Наша психика – не компьютер. Можно приблизиться к этому через повышение культуры работы, но это будет болезненно. </li></ul>
  137. 137. Выводы <ul><li>Удалённая работа – это </li><ul><li>обмен опытом на большие расстояния и значительное расширение кругозора
  138. 138. защитный экран для самолюбия: меньше опасность показаться глупым, задавать вопросы – поощряется. </li></ul><li>В удалённой работе многие плохие привычки из офиса развалили бы работу
  139. 139. Решения этих проблем применимы и в офисе </li></ul>

×