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