LT People

This is too important to miss out on. This is possibly the biggest advance in software development technology in the ten years I’ve been writing articles here.

Or, to put it another way, I’d go back to C++ before I gave up on Mercurial.

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now.

http://www.joelonsoftware.com/items/2010/03/17.html

The Rise and Fall of Waterfall

Спешу записать впечатления. Спасибо организатором за хороший семинар (см анонс). Очень приятно и интересно было послушать москвичей. Запомнился доклад Алексея Корcуна с полезными ссылками. 

Теперь просто немного основных идей и мыслей, которые остались после первой ночи.  

Саша Иванов спросил, что же мы пытаемся продать, продавая Agile? Итерации, что еще? По-моему, продавая Agile, мы пытаемся так же “продать” отказ от единого и могучего ТЗ, пытаемся доказать заказчику необходимость его непосредственного и активного участия в разработке. Кстати, по мнению большинства участников, создание своего “прокси” в случае невозможности активного участия заказчика, не решает проблему.  

Когда я шел на семинар, вопрос “как продать Agile?”, я понимал в контексте, есть ли какие-то специальные способы убедить заказчика отказаться от тяжелого и неповоротливого ТЗ в пользу активного участия в процессе разработки. На семинаре большей частью речь была о другом, но от этого он (семинар) даже выиграл.  

Итак. Серебряной пули нет. (Кто бы сомневался.) Продавать Agile надо так же, как и все остальное, т.е. не надо продавать Agile, а надо продавать решение проблем заказчика, прежде всего, того человека, который принимает решение о том, чтобы платить деньги. Надо говорить на его языке. Хороший способ выявлять скрытые проблемы и переводить их в явные - SPIN. Для установления доверительных отношений - пилотники. Agile - хороший инструмент, надо уметь объяснить, как с его помощью решаются проблемы заказчика. Но, прежде всего, заказчик должен осознать, что у него есть проблема и размер ее достаточен, чтобы потратить силы и ресурсы. Высший пилотаж, это сделать так, чтобы заказчик считал, что он сам придумал, как с помощью нашего инструмента решаются его проблемы. 

Заказчик не ищет лучшего, время и силы его ограничены. Ему не надо говорить, что Вы лучшие. Его достаточно убедить, что Вы можете решить его проблемы. Да, но задача заказчика обычно включает в себя граничные условия по деньгам и срокам. А значит, оценку предварительную делать надо. Потом это может вылиться в фикс прайс с ТЗ и технологией change request’ов или стартовую оценку для почасового договора.  

Пилотник, как способ завоевания доверия, - замечательная штука. Если удается выделить задачку на 2-3 месяца, на небольшую команду, которая с другой стороны решает конкретную проблему заказчика, то дальше обычно все хорошо. Проблема в том, что не всегда получается подобрать такую задачку, особенно если речь идет о больших клиентах и больших проблемах. Значит ли это, что Agile это удел небольших команд и небольших проектов? 

Запомнились 2 слайда Асхата про внедрение Agile по частям. Раньше я обычно слышал, что методологию надо внедрять всю разом и целиком, что, честно говоря, напрягало. Думаю, тут есть еще один момент, внедрение Agile неминуемо связано с перестройкой привычек, психологии людей вовлеченных в это. А это не происходит быстро. Но это уже скорее разговор про внедрение Agile, про границы применимости, как с точки зрения задачи, так и с точки зрения команды. Можно так же подумать о том, когда же можно считать, что мы внедрили, например, скрум, сколько практик надо внедрить, какие отклонения от практик допустимы.  

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

Вчера в команде Comapping-а состоялось пробное мероприятие под названием Scrum Day. С 12-00 до 18-00 мы обсуждали Scrum, пробовали Scrum на вкус, пили чай со Scrum, учились Scrum. Даже и не знаю, для кого этот день принес больше пользы, для его непосредственных участников, то есть для команды, или для ведущей, то есть меня Не первый раз я удивляюсь тому, что когда уже кажется, что изведал все темные уголки и обо всем уже подумал, именно тогда вдруг оказывается, что впереди еще море новых вопросов. Так вышло и в этот раз. Смотреть со стороны на то, как с заданиями справляется команда, совсем не то, что выполнять эти же самые задания самой. Суть многих из них высвечивается вдруг совсем под другим углом. И сразу хочется провести такой Scrum Day еще раз: лучше, понятнее, интереснее. Очень надеюсь, что и команда вчера тоже унесла с собой не только старые и новые ответы, но и новые вопросы. А еще надеюсь, что “оживив” и немного поиграв в Scrum, мы вместе вчера заложили первый кирпичик на пути от теории к практике Посмотрим.

Вы тоже задаетесь этим вопросом? Тогда приходите 22-го мая на очередной семинар сообщества AgilePiter. Начало семинара в 19-00.

Тема семинара: Как продать Agile потенциальному заказчику?

У Вас есть ответ? Замечательно! Приходите на наш семинар. У Вас нет ответа, но Вы хотели бы его найти? Замечательно! Тем более приходите на наш семинар. Поищем ответ вместе.

Регистрация!

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

(more…)

Всем привет!

Итак, сообщество Agile Piter начинает свою работу семинаром “Agile vs. Lean Software Development”. Семинар состоится 6-го декабря в 19-30 по адресу 14-ая линия ВО, 29. Приходите! Будет интересно

Подробности и регистрация:

06Дек	Agile vs. Lean Software Development Офис НИИ ИТ СПбГУ Пт, 06 Декабря 2007 в 19:30

Пройдя по ссылке с Codemate.net прочитал “Getting Real”. Некоторое количество цитат и мыслей по ходу дела.

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

“Будьте с гордостью, вызывающе правдивы. Вы, возможно, думаете, что клиента могут дурачить преувеличения числа штатных сотрудников в вашей компании или широта ваших предложений. Те, клиенты, которых вы действительно хотите, будут всегда искать правду - через интуицию или вычисления. Потом останется только смущение морально неоправданной лжи в прошлом, и ни одна из тех ситуаций не приведет к тому, что в бизнесе имеет значение: к взаимовыгодным отношениям с людьми, с теми, кто имел реальную потребность в предложенных услугах. Лучший курс - быть с гордостью, вызывающе правдивым и сообщать о точном размере компании и широте предложений.”
- Khoi Vinh, Subtraction.com and co-founder of Behavior LLC

“Организациям нужны указательные столбы. Им нужен план; работникам каждый день нужно знать, когда они просыпаются, почему они собираются идти на работу. Этот план должен быть кратким и сладким, и затрагивать все: Почему вы существуете? Как это мотивируете? Я называю это молитвой - описание в трех-четырех словах причин, по которым вы существуете.”
- Guy Kawasaki, author ( from Make Mantra)

“Лучшие проектировщики и лучшие программисты - не те, у кого лучшие навыки, или самые проворные пальцы, или не те, кто может сделать красивый макет в Photoshop, - это те, кто может определить, что имеет значение. Это те, кто понимает реальные выгоды от решения.”

“Мы всегда смотрим на новые рынки, в которые могли бы войти, но, только говоря “нет”, можем сосредоточиться на вещах, которые действительно важны.”
- Steve Jobs, CEO, Apple ( from The Seed of Apple’s Innovation)

“Поэтому можно установить правило: сделать половину рабочего дня единым временем для работы. В это время не отвлекаться на телефонные звонки, чтение почты, ненужное общение с коллегами и т.д.”

Мотивация, победы каждый день. Как быть на уровне департамента? Какие могут быть победы и пр.? Маленькие победы - например - хороший месячный отчет, какой-то важное решение что-то еще. Насколько это не будет выглядеть притянутым за уши?

Если в мире становится модным искать специалистов среди разработчиков OpenSource, то надо активно светиться там.

Специально для Лены
“Дизайн от эпицентра фокусирует внимание на том, что наиболее важно на странице, а затем обращается к менее важному. Это значит, что сначала вы игнорируете то, что находится кругом - навигацию, закладки, “подвал” страницы, цвета, логотип и так далее. Вместо этого, вы начинаете с эпицентра и сначала разрабатываете наиболее важную часть страницы.”

Еще для Лены
“Вот почему содержание гораздо важнее целостности. Это нормально - сделать дизайн непоследовательным, если в этом есть смысл. Давайте людям то, что имеет смысл. Давайте то, что им нужно, и избавьте от того, что лишнее. Уместность лучше последовательности.”

Противоречие:
С одной стороны - все из одного интерфейса, с другой - меньше функциональности, меньше программы.

Как некий лозунг.
Исходя из того, что надо не пытаться догонять, а искать свои пути. Все делают CMMi  и формальные процедуры и пр. надо гордо поднимать флаг борьбы с бюрократией и формализмом. Это не ново, но часто мы говорим об этом стесняясь. Надо признавать проблемы и говорить, как мы их решаем. Если нет людей на рынке, мы не творим чудеса, а сами готовим себе сотрудников. Срок подготовки велик, но это того стоит. Мы небольшая компания по сравнению с индусами, но мы и не конкурируем с ними в размере. Да мы небольшая компания, зато мы готовы подстроить свои условия под любого клиента, процессы согласования быстры. Мы гибки как никто. Мы открыты.
Да возможно наш сайт не самый лучший, мы не первые в области привлечения инвестиций и пр. Зато мы умеем делать реальные вещи, которые нужны нашим клиентам. Мы любим печь те самые булочки, о которых говорилось в книге, мы это делаем с душой и любовью к нашим клиентам.

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

“Нет кода более гибкого, чем отсутствие кода!”

Небольшая модификация.
Любимые инструменты делают программистов счастливыми. Счастливые программисты пишут правильный код.

“Избавляйтесь от долгов.”

Специально для Владимира
Полезны ли блоги.
“За несколько месяцев начинайте намекать. Расскажите людям, над чем вы работаете. Покажите логотип. В своем блоге сообщайте о разработке. Пишите неопределенно, но зароните зерно. Также заведите сайт, где будете собирать адреса электронной почты от интересующейся публики.”
Еще для Владимира
“Блоги могут быть зачастую эффективнее, чем реклама (и, кстати, они невообразимо дешевле)”

На блоге Steve Yegge появилась интересная статья Good Agile, Bad Agile, к которой я бы добавил подзаголовок “Как работает Google”, так как наиболее интересная ее часть как раз про него. Читайте… Длинно, но интересно. Запомнившиеся моменты:

• разработчик сам выбирает себе работу, может в любой момент сменить проект
• старт нового проекта - “естественное состояние” системы, нечто типа минимума потенциальной энергии
• система поощрений построена на главенстве важности проекта для компании. То есть можно работать над чем-то интересным лично тебе, но пока не очень важным, и получать, в основном, удовольствие от процесса (и зарплату, естественно), а можно заниматься чем-то более скучным, но и бонусы будут другими. В сочетании с первым принципом выглядит интересно
• Ну и знаменитый “1 день в неделю для себя”

Версия RTM сервера Team Foundation Server доступна для загрузки для подписчиков на продукты MSDN. Сервер представляет собой решение для организации совместной работы над программными проектами и управления проектами в больших коллективах программистов. Сразу после установки сервер настроен на поддержку процессов в соответствии с требованиями Capability Maturity Model (CMMI), также поддерживаются процессы в модели Agile development

Уже можно скачать триал версию с сайта Microsoft.

Более подробно о TFS можно найти здесь.

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

Кроме того, там же можно найти ссылки на довольно интересные ресурсы по Agile.

Agile CMMI blog