вторник, 25 декабря 2007 г.

Как ставить правильные цели

Ставить грамотные цели трудно, это особенно видно на ретроспективах и тренигах, когда участникам задается казалось бы простой вопрос: "А в чем цель вашего проекта (итерации, вопроса, действия..)?". Ответов на этот вопрос бывает много, но все они в основном описывают методы, а не суть цели.





В современном мире общепринятой характеристикой цели являет аббревиатура SMART:

  • Specific: Do you know exactly what you want to accomplish with all the details?

  • Measurable: Are you able to assess your progress?

  • Attainable (Achievable): Is your goal within your reach given your current situation?

  • Relevant: Is your goal relevant towards your purpose in life?

  • Time-Sensitive: What is the deadline for completing your goal?

Create Specific Goals
Bad example: “I want to write a book.”
Good example: “I want to write a book on time management that is at least 200 pages in length and have it done by December 16th. I’ll commit myself to writing at least 2 pages every workday until I reach completion.”

Create Measurable Goals
Bad example: “I want to be rich.”
Good example: “I want to generate $100,000 in passive income within 5 years from this date.”

Create Attainable (Achievable) Goals
Bad example: “I want to become a millionaire in 2 months.”
Good example: “I want to become a millionaire within 10 years by starting my own personal development company and doing seminars all over the world and by creating a line of passive income products.”

Create Relevant Goals
Bad example: “Within one year, I want to become a warlord and have many loyal soldiers who will commit acts of terrorism on my behalf.”
Good example: “By the end of the year, I want to build a philanthropic foundation that helps feed the homeless.”

Create Time-Sensitive Goals
Bad example: “I am going to do my homework.”
Good example: “I am going to finish my homework by 8pm tonight and I’ll achieve this deadline by spending one hour on each subject.”


Давайте учиться ставить правильные цели!

Текст описания SMART и примеры взяты отсюда.

Еще одно описание можно посмотреть тут.

понедельник, 24 декабря 2007 г.

Радислав Гандапас - Камасутра для оратора

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

Никогда и низачто не купил бы себе в магазине книгу с подобным названием, а от прилавка отошел бы подальше - срабатывает стереотип тупой серии "для чайников" и не менее тупых книг ни о чем, написанных для зарабатывания денег.

Но эту книгу посоветовали, а когда я сегодня в понедельник с утра на совещании всем начал ее расхваливать, оказалось что коллеги вокруг ее читали :) И даже смотрели видеоверсию, до которой я пока не успел добраться.

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

Сайт автора: http://www.radislavgandapas.com

Скачать аудиоверсию в отличном качестве можно по ссылке.

среда, 19 декабря 2007 г.

Тренинг по Test Driven Development

Сегодня провел в компании пилотный и, не побоюсь этого слова, первый в России тренинг по TDD!

Отзывы на него прислали хорошие, заинтересованность и блеск в глазах у участников были :)

Из забавного: трудно ребятам на практическом занятии далась философия инкрементального проектирования, постоянно пытались продумать все до мелочей и в итоге медленно начинали писать код.
Зато очень понравилась их парная работа - здорово было видеть, как они порой выхватывали друг у друга клавиатуру, прямо как в классическом XP :)

Очень надеюсь, что теперь практику разработки через тестирование они привнесут в свои проекты.

UPD: Подробная информация о тренинге здесь.

понедельник, 17 декабря 2007 г.

Are you Agile or Not?

Искал в сети критерии оценки "гибкости" проектов, в одном из блогов наткнулся на такие :)

(1) The “Send/Receive” and “Save As” buttons initiate most team communications.
(2) Your whiteboards are mostly white.
(3) “Test-driven” still refers to your car.
(4) You don’t yet know what PHB stands for.
(5) You know what CPM stands for, and continue to rely upon it.
(6) You spend more time trying to manage project dependencies than remove them.
(7) Someone still believes in the “Can’t Chart.” (Oops, that’s the Gantt chart.)
(8) Developers only develop, testers only test and managers just manage.
(9) Simplicity is presumed to be simple.
(10) A change control board meets…ever.

четверг, 13 декабря 2007 г.

Оценка покрытия кода модульными тестами

Последние бесплатные и совместимые между собой версии nCover и nCoverExplorer можно скачать отсюда:

Лично я замучился искать :)

среда, 12 декабря 2007 г.

Clean the kitchen

Clean the kitchen - очень хорошая метафора с уборкой на кухне, применимая к написанию кода, разработке модульных тестов и рецензированию кода.

Утверждение: наиболее быстрый способ приготовить еду на кухне, поесть и пойти заниматься делами или отдыхать - это не убирать за собой после еды. Трудно не согласиться, правда?

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

Но даже это не изменит сути - по прежнему, наиболее быстрый способ уйти с кухни раньше - это не убирать за собой.

Зато с другой стороны, если каждый раз сразу убирать за собой, то общее время, проведенное на кухне за год будет существенно меньше..

Когда вы пишете код:

  • Делайте рефакторинг сразу после изменений в коде;
  • Проводите рецензирование кода до выкладывания кода в систему контроля версий;
  • Пишите модульные тесты если не перед функциональностью, то сразу после нее.

Эти вещи нельзя откладывать "на потом".
"Потом" будет очень трудно и дорого разбирать завалы.

понедельник, 10 декабря 2007 г.

SharpDevelop - бесплатная IDE для C#

Озадачившись проведением тренинга по Test Driven Development с практическими занятиями в неподготовленном классе, я столкнулся с проблемой установки на каждый компьютер VS2005 - дело, согласитесь, неблагодарное. И занимает немеряно времени, и конфигурация компьютера это может запросто не позволить сделать.

Порывшись в гугле нашел SharpDevelop - бесплатную среду для разработки на C#. Дистрибутив занимает (я сначала не поверил) - 8 МБ!

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

Встроенная интерграция с nUnit, nCover, fxCop, nDoc, nAnt - ребята молодцы, постарались.

Резюме: отличная среда как минимум для демонстрационных проектов!

четверг, 6 декабря 2007 г.

Ежедневная поставка сборки заказчику


Сегодня в одном из проектов родилась концепция Testable & Viewable.

У нас недельные итерации, но билд заказчику мы должны поставлять каждый вечер. Причем такой билд, чтобы он был пригоден для тестирования. И в силу особенностей заказчика это никак не изменить.

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

В итоге, единственной концепцией, которая прозвучала убедительно для заказчика и позволяла нам не делать лишнюю работу по созданию заглушек, оказалась Testable & Viewable - мы каждый вечер поставляем билд, который может быть протестирован, но при условии что:

  • если все задачи, из которых состоит фича, завершены - фича может быть протестирована;

  • если есть нерешенные задачи, фича протестирована быть не может; однако, решенные задачи могут быть проревьювлены (одна из особенностей заказчика в том, что он даже указывает как называть таблицы в базе данных и функции в коде).
Таким образом, с одной стороны мы продолжаем поставлять ежедневные testable билды заказчику, но оговариваем, что частично реализованные фичи могут быть только viewable.