Около года назад посетил две лекции Кента Бека: «Привычка к гибкости» (Habits for agility) и «Четыре стратегии отзывчивого дизайна» (Four strategies for responsive design). Сегодня наткнулся у себя на сделанную тогда выжимку из них и решил поделиться.
Первая лекция актуальна для всех людей, работающих в команде, вторая относится больше к программированию.
Под гибкостью в данной ситуации понимается не гибкость гимнаста, которая ограничена пространством арены и не связана с движением вперед, а умение изменить направление движения при появлении препятствия.
Привычка — то, к чему мы приходим в стрессовых ситуациях, действия без размышлений.
Далее приведены привычки, выработка которых в себе способствует улучшению работы в команде.
Позитивный настрой. Крайне важно мыслить позитивно, если говоришь: «Все плохо, катастрофа, мы ничего не можем сделать» — ничего и не сделаешь. Если очень хочется поплакаться о том, как все плохо — надо выйти, сделать это в одиночестве, вернуться и сказать: «Так что мы будем с этим делать?».
Крайне важно открыто говорить о достижениях и особенно о проблемах проблемах.
Игра в «труса графика» — все знают, что график срывается, на совещании у начальства на вопрос о сроках все молчат, а когда кто-то первый говорит «кажется мы не успеваем по графику» — все оборачиваются на него и спрашивают «Как не успеваем?!?!», хотя все отлично об этом знают. В итоге все валится на того, кто первый сказал, а опоздание по графику нарастает как лавина.
Прозрачность экономит время — когда говоришь «У нас не собирается проект» все начинают думать «А из-за кого он не собирается? А не из-за имярек ли? А пойду ка я проверю», в результате чего тратится гораздо больше времени, чем если честно сказать «Я где-то допустил ошибку и проект не собирается» и услышать столь же честные, пусть и негативные отзывы.
Ложь может хорошо действовать на коротких промежутках времени (например в продажах), но для долгосрочной перспективы правда всегда лучше.
При выполнении работы, которая быстро приносит уважение (например при структурировании make-файлов, которым никто не рискует заняться) важно помнить, что если не обучишь этому кого-нибудь еще — то будешь заниматься этим еще не один год в гордом одиночестве.
В экстремальном программировании часто вводится термин готово-готово (done-done), поскольку говоря «готово» (done) люди часто подразумевают что лично у них все готово, но проблемы наверное могут быть, но они в них точно не виноваты. Готово-готово значит, что все действительно в порядке и этот участок проекта уже не доставит никаких проблем.
Важно вначале действовать, потом рефлексировать. Если вначале будешь собирать теоретический материал, читать книжки, изучать опыт других людей на форумах — скорее всего непосредственно к действию и не перейдешь. Надо вначале попробовать сделать. Если не получится с первой попытки — подумать и попробовать еще раз. При этом поскольку подход во многом итерационный — не столь важно с чего именно начать, в очередной из попыток найдешь нужную точку старта. На вопрос «Как это сделать?» правильным ответом является «Давайте попробуем вот-так, если не получится — придумаем что-нибудь еще».
Так же важным вопросом является «А что столь сложного в этом?». Скорее всего обнаружишь, что большую часть сложностей ты себе просто напридумывал, но даже если задание действительно сложное — появится четкое представление о существующих препятствиях.
При этом важно не забывать про измерение полученных результатов для рефлексии (см. ниже).
Единственный ресурс который точно есть в наличии и столь же точно кончится.
Работу двух недель нельзя сделать за одну неделю.
Хороший результат дает короткая фокусировка на разных задачах, нарезка времени на неблольшие участки.
Принцип помидора:
Покупаем кухонный таймер (желательно в виде помидора ), заводим на 25 минут, эти 25 минут работаем не отвлекаясь на звонки, смс, почту и т.д. Приходящим с вопросами коллегам молча указываем на таймер и продолжаем работать. По истечении этих 25 минут заводим таймер на 5 минут и эти 5 минут занимаемся мелкими делами. Для начала такое глубокое погружение делается раз в день, потом два раза и т.д.
Установившийся ритм работы важнее железной самодисциплины.
Простые вещи должны быть автоматизированны. В 90% установщиков надо много раз нажать next, при этом почти нет необходимости менять параметры — плохая автоматизация.
У каждого члена команды есть свои связи, которые важно использовать — связи с специалистами и т.д.
Связь по навыкам между членами команды — каждый умеет хоть немного во всех областях, поэтому если например специалист по css в отпуске — остальные могут худо-бедно выполнить его часть работы.
Наиболее важной является связь с заказчиком, причем под заказчиком здесь подразумевается непосредственный пользователь программы, поскольку именно его в первую очередь задевают принятые программистами решения. Недовольный пользователь гораздо лучше довольного — если смог удовлетворить недовольного, то он сделает программе и тебе как разработчику такую рекламу, какую не сделает ни один изначально довольный пользователь.
Если ты не умеешь общаться с пользователями — пробуй, пусть вначале выйдет плохо, но если будешь действовать — со временем станет получаться лучше. При обсуждении изменений вносимых в систему между программистом и конечным пользователем должен быть минимум посредников.
Важно помнить о глобальном направлении при решении локальных задач. Если в голову пришла идея — кристаллизуй ее в несколько простых ясных фраз и задай себе вопрос «А поможет ли это решению общей задачи?». Так же важно чтобы у команды был открытый набор принципов работы.
Ключевой вопрос в данном случае «Как оно прошло?», при этом важно не только отбрасывать плохие варианты, но и отмечать хорошие и использовать их снова и снова.
Итоговый дизайн проекта != исходному дизайну.
Отзывчивый в данной ситуации значит изменяющийся в зависимости от окружающих реалий.
Дизайн это набор полезных связанных элементов или полезно связанных элементов.
Изучение дизайна интроспективно, эмпирично и квантативно.
Дизайн программного обеспечения фрактален (проектирование связи двух объектов не сильно отличается от проектирования связи двух систем).
Продвигаться надо безопасными шагами — внесение одного изменение не должно приводить к поломкам в десяти местах.
Перед тем, как изменить что-либо надо изолировать этот кусок и встроить обратно, если все будет успешно.
Цель разработки — непрерывный поток функционала.
Добавление нового функционала должно быть прямым, а не закрученым.
Если решение проблемы полностью известно, то отзывчивость дизайна не столь обязательна. Требуется она в следующих случаях:
Делая безопасные шаги надо балансировать следующие параметры:
Применяется если:
Тогда:
+: выше эффективность
-: выше риск
Применяется если:
Тогда:
+: Безопасность
-: Очень много дополнительной побочной работы
Применяется если:
Тогда:
+: Получение компонентов, которые потом можно использовать в других проектах
-: Большое количество лишней работы
-: Отсутствие обратной связи на данном этапе.
Применяется если:
Тогда:
+: можно применять почти всегда
+: Развивает инициативу
-: Нелинейная стоимость в зависимости от порядка восстановления требований.
Если не можешь добавить функционал прямым путем:
Глобальную смену дизайна в любом случае оплачивают заказчики, наиболее выгодно растянуть ее на некоторое время, чтобы не сильно замедлить добавление нового функционала и не сделать каждое добавление безумно дорогим.
Первая лекция актуальна для всех людей, работающих в команде, вторая относится больше к программированию.
Привычка к гибкости
Под гибкостью в данной ситуации понимается не гибкость гимнаста, которая ограничена пространством арены и не связана с движением вперед, а умение изменить направление движения при появлении препятствия.
Привычка — то, к чему мы приходим в стрессовых ситуациях, действия без размышлений.
Далее приведены привычки, выработка которых в себе способствует улучшению работы в команде.
Подход
Позитивный настрой. Крайне важно мыслить позитивно, если говоришь: «Все плохо, катастрофа, мы ничего не можем сделать» — ничего и не сделаешь. Если очень хочется поплакаться о том, как все плохо — надо выйти, сделать это в одиночестве, вернуться и сказать: «Так что мы будем с этим делать?».
Прозрачность
Крайне важно открыто говорить о достижениях и особенно о проблемах проблемах.
Игра в «труса графика» — все знают, что график срывается, на совещании у начальства на вопрос о сроках все молчат, а когда кто-то первый говорит «кажется мы не успеваем по графику» — все оборачиваются на него и спрашивают «Как не успеваем?!?!», хотя все отлично об этом знают. В итоге все валится на того, кто первый сказал, а опоздание по графику нарастает как лавина.
Прозрачность экономит время — когда говоришь «У нас не собирается проект» все начинают думать «А из-за кого он не собирается? А не из-за имярек ли? А пойду ка я проверю», в результате чего тратится гораздо больше времени, чем если честно сказать «Я где-то допустил ошибку и проект не собирается» и услышать столь же честные, пусть и негативные отзывы.
Ложь может хорошо действовать на коротких промежутках времени (например в продажах), но для долгосрочной перспективы правда всегда лучше.
Ответственность
При выполнении работы, которая быстро приносит уважение (например при структурировании make-файлов, которым никто не рискует заняться) важно помнить, что если не обучишь этому кого-нибудь еще — то будешь заниматься этим еще не один год в гордом одиночестве.
В экстремальном программировании часто вводится термин готово-готово (done-done), поскольку говоря «готово» (done) люди часто подразумевают что лично у них все готово, но проблемы наверное могут быть, но они в них точно не виноваты. Готово-готово значит, что все действительно в порядке и этот участок проекта уже не доставит никаких проблем.
Действие
Важно вначале действовать, потом рефлексировать. Если вначале будешь собирать теоретический материал, читать книжки, изучать опыт других людей на форумах — скорее всего непосредственно к действию и не перейдешь. Надо вначале попробовать сделать. Если не получится с первой попытки — подумать и попробовать еще раз. При этом поскольку подход во многом итерационный — не столь важно с чего именно начать, в очередной из попыток найдешь нужную точку старта. На вопрос «Как это сделать?» правильным ответом является «Давайте попробуем вот-так, если не получится — придумаем что-нибудь еще».
Так же важным вопросом является «А что столь сложного в этом?». Скорее всего обнаружишь, что большую часть сложностей ты себе просто напридумывал, но даже если задание действительно сложное — появится четкое представление о существующих препятствиях.
При этом важно не забывать про измерение полученных результатов для рефлексии (см. ниже).
Время
Единственный ресурс который точно есть в наличии и столь же точно кончится.
Работу двух недель нельзя сделать за одну неделю.
Хороший результат дает короткая фокусировка на разных задачах, нарезка времени на неблольшие участки.
Принцип помидора:
Покупаем кухонный таймер (желательно в виде помидора ), заводим на 25 минут, эти 25 минут работаем не отвлекаясь на звонки, смс, почту и т.д. Приходящим с вопросами коллегам молча указываем на таймер и продолжаем работать. По истечении этих 25 минут заводим таймер на 5 минут и эти 5 минут занимаемся мелкими делами. Для начала такое глубокое погружение делается раз в день, потом два раза и т.д.
Установившийся ритм работы важнее железной самодисциплины.
Простые вещи должны быть автоматизированны. В 90% установщиков надо много раз нажать next, при этом почти нет необходимости менять параметры — плохая автоматизация.
Связи
У каждого члена команды есть свои связи, которые важно использовать — связи с специалистами и т.д.
Связь по навыкам между членами команды — каждый умеет хоть немного во всех областях, поэтому если например специалист по css в отпуске — остальные могут худо-бедно выполнить его часть работы.
Наиболее важной является связь с заказчиком, причем под заказчиком здесь подразумевается непосредственный пользователь программы, поскольку именно его в первую очередь задевают принятые программистами решения. Недовольный пользователь гораздо лучше довольного — если смог удовлетворить недовольного, то он сделает программе и тебе как разработчику такую рекламу, какую не сделает ни один изначально довольный пользователь.
Если ты не умеешь общаться с пользователями — пробуй, пусть вначале выйдет плохо, но если будешь действовать — со временем станет получаться лучше. При обсуждении изменений вносимых в систему между программистом и конечным пользователем должен быть минимум посредников.
Перспектива
Важно помнить о глобальном направлении при решении локальных задач. Если в голову пришла идея — кристаллизуй ее в несколько простых ясных фраз и задай себе вопрос «А поможет ли это решению общей задачи?». Так же важно чтобы у команды был открытый набор принципов работы.
Рефлексия
Ключевой вопрос в данном случае «Как оно прошло?», при этом важно не только отбрасывать плохие варианты, но и отмечать хорошие и использовать их снова и снова.
Четыре стратегии отзывчивого дизайна
Итоговый дизайн проекта != исходному дизайну.
Отзывчивый в данной ситуации значит изменяющийся в зависимости от окружающих реалий.
Исходные предпосылки
Дизайн это набор полезных связанных элементов или полезно связанных элементов.
Изучение дизайна интроспективно, эмпирично и квантативно.
Дизайн программного обеспечения фрактален (проектирование связи двух объектов не сильно отличается от проектирования связи двух систем).
Продвигаться надо безопасными шагами — внесение одного изменение не должно приводить к поломкам в десяти местах.
Перед тем, как изменить что-либо надо изолировать этот кусок и встроить обратно, если все будет успешно.
Цель разработки — непрерывный поток функционала.
Добавление нового функционала должно быть прямым, а не закрученым.
Если решение проблемы полностью известно, то отзывчивость дизайна не столь обязательна. Требуется она в следующих случаях:
- Неизвестно, как что-то сделать;
- Известно как, но не хватает ресурсов;
- Известно как, ресурсы есть, но остальная команда не понимает этого варианта.
Делая безопасные шаги надо балансировать следующие параметры:
- Эффективность;
- Риск;
- Отзывы;
- Командная работа.
Стратегии
Прыжок
Применяется если:
- Знаем как это делать
- Уверены, что сможем безопасно сделать и встроить этот вариант
Тогда:
- -Выполняем несколько действий одним шагом.
+: выше эффективность
-: выше риск
Параллельность
Применяется если:
- Знаем как это делать
- Не уверены, что сможем безопасно сделать и встроить
Тогда:
- Временно поддерживаем оба варианта дизайна, постепенно перенося функционал из старого в новый
+: Безопасность
-: Очень много дополнительной побочной работы
Опорный камень
Применяется если:
- Не знаем как это делать
- Знаем что можно сделать, чтобы упростить решение задачи
Тогда:
- Строим дополнительный проект, с помощью которого будет проще достичь цели
+: Получение компонентов, которые потом можно использовать в других проектах
-: Большое количество лишней работы
-: Отсутствие обратной связи на данном этапе.
Упрощение
Применяется если:
- Не знаем, как это делать
- Нет ресурсов на выполнение всей задачи
Тогда:
- Выбрасываем требования, пока задача не будет решаться в один безопасный шаг
- Постепенно восстанавливаем требования к проекту.
+: можно применять почти всегда
+: Развивает инициативу
-: Нелинейная стоимость в зависимости от порядка восстановления требований.
Дополнительное замечание
Если не можешь добавить функционал прямым путем:
- Делай как получится
- Будь готов заплатить цену этого решения позже
Глобальную смену дизайна в любом случае оплачивают заказчики, наиболее выгодно растянуть ее на некоторое время, чтобы не сильно замедлить добавление нового функционала и не сделать каждое добавление безумно дорогим.
