Дорога в совершенство

Прослушал четырхедневный тренинг кент бека на тему: Agile, Extreme Programming, TDD, Responsible Design, и т.п. Ниже краткий коспект лекций, мое отношение к ним и выводы, которые сделал из всего услышанного.

1. Experience != Success

Первое с чего начал Бек. Успешные проекты чаще всего делают опытные разработчики (менеджеры, дизайнеры…). Обратное не верно - не факт, что опытные разработчики сделают успешный проект.

Вывод: уделять внимание не только обучению программистов в группе, но и процессу разработки.

2. Общение в группах

Командам была предоставлена возможность пообщаться на тему «Что я хотел бы изучить на этом трененге». Сначала самостоятельно, потом в парах, четвёрках, восмёрках и полной группой (20 человек). Цели:

• Показать что общение в маленьких группах гораздо эффективнее, чем в больших.
• Показать, что начиная с некоторого момента, чем больше группа, тем меньшая ее относительная и абсолютная часть принимает участие в обсуждении. В нашем случае получилось примерно так: в группе из 2х человек общается двое (причем один из них ведущий), из четырёх – трое, из восьми – шестеро, во всей группе – 4-5 человек.
• Определить интересы группы разработчиков. На протяжении всех дней оценивать и показывать прогресс группы в каждом направлении
• Показать что решение большой группы более размыто чем маленькой.

Итоги. Общими усилиями выбрали следующие темы

• Colloboration / Comminication (Взаимодействие / коммуникация)
• Planning / Time management (Планирование / управление временем)
• Better code design (Дизайн кода)

Вывод: оптимальное количество группы для обсуждения – 3-5 человек.

3. Принцип «Уже сделано» (AlreadyDone)

На примере UDD приложений (URL Drive Development) было на примере показано, как общаться с заказчиком по поводу новых фич. (В группе мысль не все сразу уловили, поэтому моя интерпретация может быть тоже ошибочной)

Пример. Приходит заказчик с новой идей. Описывает ее. При нём же делается простейший вариант, который его удовлетворяет, на чистом HTML. И получает окончательный ответ - «Уже сделано» . После чего спокойно уходит. А разработчики делают необходимую и достаточную реализацию , либо отправляют прототип в продакшн, до тех пор, пока не потребовалось чего-то большего.

Цели:

• Заказчик получает наглядую реализацию
• Быстрая обратная связь
• До конечных пользователей идея заказчика доходит очень быстро

Выводы:

• для бизнеса очень важна обратная связь
• делать прототипы
• делать минимальную и достаточную реализацию на каждом этапе

4. Mind Maps
На примере простой задачи: "в парах попеременно описать ситуацию в которой чувствовал себя успешно" - был опробован инструмент Mind-Map (интеллект-карта), позволяющий описывать / осмысливать и т.п.. любые задачи и предметные области.
Основные преимуществва по сравнению с обычным нумерованными / ненумерованнысми иерархическими списками:

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

Выводы:

• надо взять на вооружение.
• хорошо подходит для мозговых штурмов

5. Queueing Theory: B -> F -> P -> T -> O -> U->Feedback -> B
Стандартный процесс разработки ПО:

• Бизнес придумывает идеи как заработать деньги
• Идеи превращаются в фичи (требования)
• Программисты реализуют требования
• Тестировщики тестируют
• Operations выкладывают изменения
• Пользователи пользуются и дают обратную связь
• Бизнес получает обратную связь на основании которой делают выводы и запускают процесс заново.

На примере крутящихся дверей в супермаркете, проводя аналогии с разработкой ПО, Кент попытался описать эту проблему. Решения– поставить больше дверей, две сделать больше, убрать стенку и т.п. В конечном счете, пришел к выводу, что иногда нужно определить зачем посетители ходят через эту дверь и устранить эту необходимость. В его примере – перенести кофемат из соседнего помещения в основное.

Выводы:

• Short Feedback. Уменьшить время получения фидбэка на всех этапах
• Уменьшить время получения первых денег, на которые потом можно развивать продукт, если бизнес этого пожелает
• Direct Contact. Должна существовать возможность прямого получение фидбэка от конечных пользователей для всех участников процесса
• Focused Work. В некоторых случаях необходимо подняться на уровень выше (посмотреть на проблему с другой стороны), чтобы решить ее более эффективно

6. План внедрения Agile в группе разработчиков

Трём группм из 6-7 человек было предложено разработать план внедрения Agile в группе разработчиков. Каждый член в группе играл определённую заданную роль (Менеджер за внедрение Agile, старпёр-скептик, архитектро б.д. и т.п.). В одной из групп скептик на 100% справился со своей задачей и в результате плана вообще не получилось. Вот план одной из комманд:

• Short Cycles (Короткие циклы)
• Planning Iterations (Подробное планиерование итераций
• TDD (Тестирование новой функциональности)
• Regration Tests (Написание тестов перед исправлением багов)
• Continius Integration (Постоянная сборка)
• Review (Просмотр кода несколькими разработчиками)
• Meetings (Опредленённый формат встреч и обсуждений)
• Modularity (Использование модульной технологии, для облегчения внесения изменений, Incremental Design)

Замечания по ходу обсуждения – что не получилось:

• Плана больше похож на список методик / практик. Поскольку не включает
  • Упорядоченного списка задач
  • Ответственных / исполнителей
  • Сроков
• Во время доклада необходимо обращать внимание на реакцию «большого босса».
• Не нужно сбиваться на технические подробности
• В подобных задачах необходимо показать «большому боссу» - почему выполнение задач из плана, поможет работать эффективней, качественней и т.п., а значит заработать больше денег (или потратить меньше) . Это основная задача «большого боса» (а не внедрить Agile)

Выводы:

• Один человек в команде может свести на нет все усилия по внедрению чего-то нового в случае не сплоченного коллектива или не достаточно хорошем менеджменте

7. eXtreme Programming – больше Принципы, а не практики

Бек начал с того, что сделал акцент на том, что выполнение практик экстремального программирования это не сама цель. Самое важное - это ценности.

Итого Экстремальное программирование включает в себя:

• Ценности (Values)
• Принципы (Principles)
• Социальная активность (Social Activity)
  • Парное программирование
  • Сидеть вместе
  • Открытое пространство (без перегородок)
  • Вся команда в одном месте (свободное общение всех членов команды)
• Планирование (Planning)
  • Недельный цикл (Week cycle) – подробное планирование на неделю вперед
  • Квартальный цикл (Quarter cycle) – стратегическое планирование архитектурных изменений на 4 месяца вперёд
  • Истории (Stories)
  • Slack (Слабина) – не обещать того, что невозможно выполнить. Быть честным к заказчику.
• Техническая реализация (Technical)
  • 10minuties (10 минут) - Сборка проектов и прогон тестов должно составлять не более 10 минут, чтобы это делать несколько раз в день
  • Continuies Integration – Постоянная сборка проекта и прого всех тестов на тестовом сервере
  • Incremental Design – Дизайн, позволяющий легко вносить изменений
  • Test First – Написание тестов, до реализации.
• Energize Work - Если чувствуешь что не интересно работать (работаешь не эффективно) – самостоятельно исправь ситуацию:
  • Почитай книги 
  • Сходи на семинар 
  • Пообщайся над проблемой с кем-нибудь – тебе помогут 
  • Вспомни когда тебе было комфортно, определи что тогда помогало тебе, реализуй это сейчас (интерпретировав под конкретную задачу)

8. Планирование

В группах было предложено описать / нарисовать процесс разработки ПО в их коммандах в терминах Value Stream Method Mapping. После чего попытаться сократить на 20% время всего процесса разработки

Идеи:

• Распараллелить задачи
• Разбить задачи на более мелкие
• Перенести конец второй задачи в первую (например, начать тестировать до окончания разработки)
• Уменьшить время ожидания освобождения внешних ресурсов (путём создания рабочих групп, определения порядка взаимодействия и т.п.)

Вывод для нашей команды: вёрстку встраивать в код, сразу в процессе разработки. Правда мы об этом и так знали.

9. Mr TDD
Процесс разработки в стиле TDD: SPECIFY -> Test -> Design ->Programming->Design -> Specify

В качестве практического задания было предложено в парах (один раньше писал тесты, другой нет) написать тест для реальных проектов по принципу:

• Assign (Написание условия проверки требования)
• Test (Написание теста)
• Test error (Проверка того что тест выдаёт ошибку)
• Реализация (Реализация)
• Test passed (Проверка того, что тест проходит успешно)

Тестирование Ядра (Core) – в моём понимании (В терминах MVC) это – модель и контроллер. По другому – модульное тестирование

• Stable + (Функционал редко изменяется)
• Easy API + (Лёгкое, удобное API для написания тестов)
• Coverage – (Покрытие кода и функциональности не полностью)

Тестирование UI (Интерфейса пользователя) – в моём понимании (В терминах MVC) это – представление, По другому - функциональное тестирование

• Unstable – (Часто изменяется)
• Clumsy API -. Сложное / странное API,поскольку приходится работать с
  • HTTP
  • HTML
  • UI State
• Coverage + (Покрытие кода - максимальное)

10. Responsible Design.

Практически весь высший менеджмент не любит думать в рамках XP: «Почему, если продавцам можно поставить жеский план и они могут за него отвечать , то программисты, прикрываясь XP, не могут утверждать, что они сделают к определённому сроку или за определённый период». Эта идеалогия построена на трёх принципах:

• Accountability (Ответственность, Подотчетность, Отслеживаемость)
• Transparansy (Прозрачность) - Намерение предоставлять информацию
• Responsobility (Ответственность) – Doing what needs to be done. Делать всё, что должно быть сделано

Эти принципы, на самом деле, не не противоречат идеалогии AGILE и XP. На практике достаточно просто все методики / практики указанные выше свести к этим трём показателям. Моё мнение основываяс как раз на этих трёх принципах нужно было рассказывать план внедрения AGILE в группе.

Продолжением этой темы был мозговой штурм на тему

• Кому я предоставляю информацию
• За что я отвечаю
• Если бы компания была моей, чтобы я в ней изменил, или что я бы сделал.

Итоги:

• Ничего инетересного в ответах на первые два вопроса не прозвучало
• В ответе на третий очень часто назывались те вещи, которые уже есть в компании. Сам Кент Бек высказал довольно интересные мысли по этому поводу.

Выводы:

• Приципц Responsible Design не противоречат AGILE (XP)
• При внедрении каждой методики / практики нужно прогнать ее по принципам Responsible Design, чтобы на примере конкретной задачи и комады осознать как улучшадрся показатели (Accountability, Transparansy, Responsobility)

11. Метрики
Последняя тема, которую мы затронули – это определение приложения с лучшим дизайном кода. Для начала были выписаны метрики, по которым хотелось бы определить лучший дизайн.

Идея:

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

Процесс определения приложения с лучшим дизайном был примерно следующим

• Составить приблизительный список метрик
• Каждый участник генерирует задачи, пишет их на бумаге и прикрепляет на доску, изначально оценивая ее время
• Все участники разбиваются на пары.
• Пара после завершения очередной задачи берёт следующую .
• При превышении отведённого на задачу времени необходимо согласовать дальнейшую работу по этой задачи с ее постановщиком
• Над одной задачей могут работать несколько пар

Цели:

• Определить приложение с лучшим дизайном
• Определить инструменты / способы для измерения метрик
• Определить измеримость метрик
• Практика работах в парах
• Опробовать новый режим работы, который должнен был продемонстрировать Accountability, Transparansy, Responsobility

Итоги:

• Четкого ответа на главный вопрос не удалось получить
• Часть используемых метрик и способов их измерения у меня вызывают большие сомнения
• После обеда часть пар выключились из процесса работы или вели ее не в предложенном стиле. Чтобы избежать это следовало, например, разбить всю работу на 2-4 итерации.

Выводы:

• Чаще всего лучшие проекты имеют лучшие показатели метрик
• Есть бесплатные инструменты для измерения большого числа метрик.
• Нельзя считать средние показатели для метрик, важно распределение.

Так же смотри:
http://www.usu.ru/usu/opencms/today/events/2009/03/event_0012.html
http://xoposhiy.livejournal.com/62134.html
http://xoposhiy.livejournal.com/61926.html

Вам это будет интересно!

Последние новости