Жизнеутверждающе: притча про осла и колодец

Однажды осел фермера провалился в колодец. Пока фермер думал, как ему поступить, животное часами издавало жалобные звуки. Наконец фермер принял решение, он посчитал, что осел уже старый, а колодец нужно было закрывать в любом случае. Просто не стоило тратить тех усилий ради того чтобы вытаскивать старого осла. Он пригласил всех своих соседей помочь ему закопать колодец. Все дружно взялись за лопаты и принялись копать и забрасывать землю в колодец. Осел сразу же понял к чему идет дело и начал издавать страшный визг. Затем ко всеобщему удивлению он притих. После нескольких бросков земли фермер решил проверить и посмотреть как там внизу. Он был изумлен от того, что он увидел там. С каждым куском земли, падавшим на его спину, ослик проделывал что-то совершенно невероятное. Он встряхивался и становился поверх сброшенной земли. Пока соседи фермера продолжали забрасывать землю в колодец, каждый раз животное встряхивалось и становилось поверх насыпленной земли. Очень скоро все удивились, потому что увидели, как ослик поднялся наверх, перепрыгнул через край колодца и умчался вперед как угорелый! В жизни вам будет встречаться много всякой грязи и каждый раз жизнь будет посылать вам все новую и новую порцию. Всякий раз, когда упадет ком земли, встряхнись и поднимайся наверх и только так ты сможешь выбраться из колодца. Каждая из возникающих проблем - это как камень для перехода на ручье. Если не останавливаться и не сдаваться, то можно выбраться из любого самого глубокого колодца. Встряхнись и поднимайся наверх. Чтобы быть счастливым запомни пять простых правил : 1. Освободи свое сердце от ненависти - прости. 2. Освободи свое сердце от волнений - большинство из них не сбываются. 3. Веди простую жизнь и цени то, что имеешь. 4. Отдавай больше. 5. Ожидай меньше.

Панорамирование

Сегодня речь пойдет не о программировании или менеджменте, а о более приятном занятии - фотографии :) Решил наконец-то поэкспериментировать с программами, создающими панорамные изображения. Несмотря на то, что за лето-осень отщелкал около 10 Гб фотографий, панорамных заготовок сделал всего две: лужок возле неизвестного поселка на берегу Сев. Донца и Красную площадь в Москве. Сразу оговорюсь, что обе панорамы делались при полнейшем незнании законов панорамной фотографии и не на самый лучший фотоаппарат (Canon A620). И если второй фактор является достаточно важным, но все же не критическим, то первый заставил меня попотеть, чтобы сшить все это безобразие воедино.

Почитал и попробовал в действии несколько утилит и остановился на одной из них - Panorama Factory. Работа с ней оказалась на редкость простой и интуитивной. Основные шаги, как и следовало ожидать, следующие:

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

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

Результаты:

1) Лужок


2) Красная площадь


В целом, Panorama Factory со своей задачей справилась. Единственный "недостаток" программы - ее цена :) Может, есть фришные аналоги? Поделитесь, пожалуйста. Да и этот триальный текст по центру фотографии не радует, к сожалению.

PS. Еще порадовало, что у разработчиков Panorama Factory есть свой талисман - дракончик :) Приятно, наверно, работать в такой команде.

Планирование, учитывающее предыдущие результаты

Даже не знаю, как можно правильно перевести термин "Evidence Based Scheduling"... Джоэль Спольски разразился в своем блоге отличной статьей, посвященной объяснению вот этой вот самой штуки. Термин "Evidence Based Scheduling", похоже, придуман Джоэлем и его командой, а сам метод планирования внедрен и активно продвигается в их продукте FogBugz 6.0 (демо, которое заслуживает отдельных похвал, можно глянуть здесь, а запись выступления Джоэля - здесь). Итак, для тех, кто не любит читать "много букофф", вкратце, что же это такое и с чем его едят. Evidence Based Scheduling - это метод планирования проекта, основанный на 2-х основных принципах:

• учет предыдущих результатов для получения реальной оценки (estimate) времени, которое будет затрачено на разработку продукта
• прогнозирование вероятности релиза продукта в конкретный день (с использованием метода Монте-Карло)

По первому пункту, в принципе, все понятно. Есть люди, склонные переоценивать свои силы и недооценивать их, и это нужно учитывать при планировании проекта. Каждый грамотный team/dev/QA/project lead (нужное подчеркнуть) более-менее хорошо знает свою команду и может на основании эмпирических фактов проставить каждому девелоперу/QA коэффициент, на который нужно домножить его собственный estimate. Однако существует еще очень много факторов, которые могут повлиять на то, что проект затянется во времени и мы выпадем из графика или бюджета. Часть из них являются непроизводственными, например, прогулки по Интернету, общение в команде, кофе/чай, "а глянь какие фотки мы сделали на выходных!", часть - абсолютно честно относятся к разработке продукта: изучение новой технологии, митинги в команде, философские дискуссии с QA, что есть баг, а что фича и др. естественные, но от того не менее опасные для развития проекта активности. Все это невозможно предусмотреть заранее. Однако, если трекать процесс разработки продукта, то потом можно сравнить estimate с реальными данными и на основании этого сравнения сделать определенные выводы на будущее. Второй пункт вызывает больше интереса. Честно говоря, я не видел еще подобного способа прогнозирования дат релиза и отдельных mileston'ов (кто видел, подскажите продукт или где почитать). Как мы обычно планируем проект? У нас есть нижняя и верхняя граница оценки определенной задачи, мы выбираем цифру от 0.5 до 1 на этом отрезке (думаю, меньше 0.5 никто не выбирает :)), а затем устанавливаем ее для этой задачи в MS Project или кто чем пользуется. Строим диаграмму Ганта и в результате получаем приблизительные даты mileston'ов и релизов. Джоэль предлагает другой подход, который состоит в вычислении вероятности различных будущих, основанном на методе Монте-Карло. Данный подход достаточно тесно связан с предыдущими результатами работы наших программистов, которые у нас есть. Если мы случайным образом возьмем одно из предыдущих значений отношения оценки выполнения какой-либо задачи к реально затраченному времени (в идеале оно будет равно 1, но, конечно же, будут вариации), и разделим на него текущую оценку новой задачи, то мы получим другое число с учетом предыдущего результата. А теперь представим себе, что мы рассматриваем все задачи всех программистов и для каждой задачи вычисляем 100 различных новых значений, каждое с вероятностью в 1%. Тогда, сложив вместе эти значения (с учетом графика выполнения работ, выходных, праздников и т.д.), мы получим 100 вариантов развития события, 100 вариантов будущего нашего проекта. А уже сопоставив эти 100 графиков мы можем дать вероятность того, что наш проект завершится 10 декабря, 15 января или вообще 30 апреля. У такого подхода есть ряд преимуществ перед обычным, т.к. он дает большую гибкость и учитывает больше факторов, что, соответственно, делает результат более точным. Дальше нам остается только сказать себе, что вероятности 90% нам достаточно и мы можем поставить milestone в данную точку времени и пространства. Кроме этих интересных вещей, Джоэль также дает несколько советов по оценке задач:

• только программист, который будет реализовывать функциональность, должен оценивать ее - известный совет, которым, тем не менее, часто пренебрегают, что влечет либо к тому, что lead оценивает задачи с точки зрения "среднестатистического" программиста, либо вообще себя, а потом этим занимается либо более слабый, либо просто менее знакомый с данной предметной областью/технологией программист и весь график летит в тартарары
• время, затраченное на исправление ошибки в определенной функциональности, должно добавляться ко времени, потраченному на эту функциональность в целом - помогает хранить более точные результаты для будущей оценки и вычисления вероятностей
• не давать менеджерам загонять программистов в более узкие оценки с целью зарелизить продукт быстрее/дешевле - это вообще отдельная песня... "а можешь ли ты скроить шапку из этого куска шкуры?" - "могу" - "а 2 шапки?" - "могу" - "а 3 шапки?" - "и 3 могу"
• план проекта это коробка с бревнами - пункт, связанный с предыдущим: если у нас есть куча бревен и они не помещаются в коробку, но нужно либо убрать часть бревен из коробки, либо взять коробку побольше, но уж никак не пытаться уменьшить бревна в размерах

В общем и целом, это все. Советую прочитать статью Джоэля целиком (а также и другие его статьи), там еще много чего интересного. Вывод: FogBugz 6.0 из простой (пусть и удобной) системы багтрекинга превратился в полноценную систему управления проектами, с интересными и смелыми решениями. Интересно было бы попробовать ее в действии на реальном проекте, а то продукты MS уже как-то приелись :). Посмотрим, чем ответят разработчики других приложений. Kiwi :)

Mind maps и анализ требований

Наверняка многие слышали про mind maps и даже использовали их в жизни. Однако, в IT-проектах mind maps используются не очень широко. Недавно попробовал применять их для несколько иной задачи, чем простой брейнсторминг - для анализа требований и управления фазой проекта, чем и спешу поделиться.

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

Наш проект как раз и является таким «запутанным» случаем. Клиент хочет сделать низкоуровневые изменения, которые отразятся на многих компонентах. При этом клиент уже сам не очень хорошо помнит, как именно эта система работает и из каких частей состоит. Работает, и хорошо :). В результате мы получаем достаточно высокоуровневые требования, в которых детально описано лишь то, что клиент «вспомнил» и то, что он хочет получить в результате. Приходится потом сидеть и самому анализировать, какие компоненты системы будут затронуты и в каком объеме. Количество вопросов к клиентам увеличивается, потому что мы зачастую не знаем, как они захотят изменить старое бизнес-правило, чтобы оно работало в новой обстановке. Вследствие этого каждый вечер проводятся обсуждения, идут тучи писем, в документе требований появляются новые и исчезают старые пункты. Источников данных – тьма, вопросов – тоже, как за этим всем следить самым оптимальным способом и при этом не забыть чего-то важного – непонятно. Не говоря уже о том, что по пути мы занимаемся брейнстормингом в команде, и его результаты тоже нужно где-то записывать.

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

Приложение, которым я пользовался (кстати, абсолютно бесплатное, т.к. я специально не рассматривал платные варианты), позволяет добавлять ряд картинок к текстам, что очень удобно. Например, карандашиками я обозначил пункты, которые нам нужно заимплементить/сделать, warning'ами – различные предупреждения, знаками вопроса – требования, которые могут изменится, а числами в кружочках – фазы, в которых та или иная фича должна быть сделана. Здесь уже каждый волен обозначать пункты как ЕМУ удобнее для восприятия и понимания.

Преимущества подобного представления информации:

1. Подобную диаграмму всегда можно охватить «одним взглядом», в то время как 50-100-500-страничный документ – нет. Мозги не резиновые.
2. На диаграмме можно отображать абсолютно любую информацию: идеи, сомнения, риски, даты, степень выполнения и т.д. Я не призываю не пользоваться MS Project :), просто он предназначен для другого типа задач. Например, у нас сейчас на проекте есть документ требований, mind map и project plan – сосуществуют очень даже сносно.
3. Диаграмму можно изменить в любой момент времени, если что-то поменялось.
4. Диаграмму можно обновлять из разных источников. Пришло письмо с каким-то комментарием, меняем диаграмму. Пообщались с клиентом – снова меняем.
5. По диаграмме можно легко оценивать, сколько времени займет девелопмент, т.к. объем изменений и все взаимосвязи хорошо видны.
6. По диаграмме можно легко составлять списки вопросов клиентам и трекать состояние обсуждаемых вопросов.
7. Без сомнения, по диаграмме можно много еще чего, но до этого еще нужно добраться :)
   

Недостатки:

1. Приходится делать дополнительную работу на составление диаграммы. Впрочем, это еще вопрос, сколько она времени сэкономит в будущем. Плюс в этот момент мы «укладываем» требования в нашей голове, что позволяет быстрее их запоминать.

В общем и целом, впечатления от использования mind maps очень положительные. Mind maps - в массы? :)