Этот пост можно рассматривать как комментарий к двум статьям о правильной осанке и здоровом позвоночнике: раз и два.

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

Проходя собеседование на позицию Product Owner я понял, что у меня серьезный пробел по бизнес метрикам в Agile проекте, т.к. работаю в госструктуре. В русском сегменте информация достаточно скудная. В английском сегменте очень понравилась статья Ashwinee Kalkura. Поэтому решил сделать немного вольный перевод. Оригинал статьи здесь.

Что значат метрики для Agile команд?

Многие пытаются понять, что же такое «лучшая практика» в отрасли, и наложить её на свой продукт, чтобы улучшить свои собственные показатели. Некоторое время я размышлял над тем, существует ли такое универсальное и эффективное решение.

Организации склонны копировать «то, что сработало для других», даже не заботясь об ограничениях и условиях, в которых конкретная метрика работала на «других».

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

И как тогда понять, что именно нужно измерить? Для меня ближайший путеводитель — это 7-й принцип в Agile Manifesto — «работающее программное обеспечение — лучший измеритель прогресса». Если Вы можете определить, что является для Вас рабочим программным обеспечением, становится легче измерить прогресс.

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

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

Сегодня будем говорить о некоторых возможностях замечательной IDE PhpStorm. Программисты из компании Jetbrains вкладывают огромные силы в создание своего продукта, в результате мы имеем мощную и одну из лучших IDE для языка программирования php. Думаю времена, когда хотелось выделиться программированием в Notepad++, практически ушли. Разрабатывать на коленке современные большие проекты с множеством файлов крайне затруднительно без хорошего инструмента.

Существует известное мнение, что один из инженеров IBM Девид Бредли (David Bradley), будучи одним из участников проекта IBM PC, придумал комбинацию клавиш Ctrl+Alt+Del для перезагрузки компьютера без выключения питания. В частности, Бредли руководствовался тем, что нажать такую комбинацию случайно почти невозможно и, таким образом, случайно перезагрузить компьютер вряд ли получится.

На QA-сессии в Гарварде, которая состоялась 21 сентября и в которой принимал участие Билл Гейтс, ведущий (Девид Рубинштейн, финансист и филантроп) задал вопрос основателю Microsoft — чья была идея использовать три пальца для перезагрузки, намекая на некоторую несуразность такого подхода?

Билл Гейтс сначала пустился в объяснение, что нажатие на Ctrl+Alt+Del перед вводом логина и пароля предотвращает возможность других программ получить пароль, помимо самой операционной системы, но потом признался:

Да, у нас могла бы быть одна кнопка для этого, но парень, который проектировал клавиатуру для IBM, не хотел нам её давать, хотя мы могли использовать её… Это была ошибка.

Видео установлено на нужный момент:


В итоге Бредли не оставалось ничего другого как изобрести свою комбинацию, заметив: «Я может и изобрёл её, но Билл сделал её знаменитой» («I may have invented it, but Bill made it famous»).

Несколько вредных советов, о том как развивать некомпетентность. Антимотивация.

Не делитесь информацией.

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

Не давайте сотрудникам возможности выбирать инструменты, которые они используют в работе.

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

Книги — пища для мозгов программиста. А художественные — десерт. Хорошая книга — как вкусное блюдо, которое хочется дочитать растянув удовольствие, испробовать снова и снова. Но есть куча книг, которые мы еще не нюхали и, возможно, никогда не попробуем, потому что нам их не посоветовали несколько человек.

У каждого есть одна-две любимые книги, которые могут понравится другим, поделитесь пожалуйста, заразите. Думаю многим будет интересно поставить в очередь «к прочтению» несколько новых. Давайте устроим «дегустацию» книг в формате: одна книга — один комментарий. Чтобы другие могли добавить в избранное (и оценить, и обсудить) каждую книгу по отдельности.

Доброго времени суток, уважаемые хабравчане. Сегодня я хочу поделиться с вами одним небольшим событием — ровно год назад, 15 августа 2013 года я опубликовал свой первый дайджест для веб-разработчиков. С тех пор было опубликовано 25 выпусков и мои подборки обрели некоторую «популярность», а мне приятно ощущать себя «полезным» для хабраобщества.

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

Введение

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

В этой статье я расскажу о следующем:

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

Google постоянно работает над новшествам и улучшениям своих сервисов. Только за последние несколько недель компания добавила возможность автоматической коррекции изображений при загрузке в Google+, запустила сеть воздушных шаров для обеспечения доступа к интернету в местах со слабо развитой инфраструктурой, открыла доступ к новому сервису подписки на музыку и обновила сервис карт.

Но пока компания отчитывается о последних доходах и достижениях, инвесторы заинтересованы лишь в одной вещи — показателями доходов от контекстной рекламы компании

Сделать удаленное парное программирование удобным — задача не из простых, но у Floobits все может получиться.

Floobits позволяет использовать свой любимый редактор для совместной работы над кодом в реальном времени — сейчас поддерживаются только Sublime Text, Vim и Emacs; кроме того, есть и традиционный для подобных сервисов веб-редактор кода, работающий прямо в браузере.

Поскольку обойтись только редактором было сложно, со временем выяснилось, что парная разработка — это не только распространение кода, но и «расшаривание» терминалов (для этого был разработан Flootty), а еще и реал-тайм обновление кода на тестовом сервере (для этого был разработан несложный diff-shipper). Кроме того, для голосового чата и обмена видео в веб-редактор была добавлена поддержка Google+ Hangouts

Мне очень нравится движение бережливых стартапов и его основополагающий принцип, согласно которому соответствующий рынку продукт ищется путем тестирования, изучения и экспериментирования с самыми простыми прототипами продуктов, которые себе только можно представить (так называемыми минимальными жизнеспособными продуктами — MVP). Это помогает компаниям избежать создания продуктов, которые потребителям не нужны. Однако основополагающий концептуальный инструмент для сопровождения этого процесса до недавнего времени отсутствовал. Не было практического инструмента, который бы помогал бизнесменам схематично изображать, продумывать, обсуждать, тестировать и изменять предлагаемую компанией ценность в соответствии с потребностями своих клиентов. Поэтому вместе с Ивом Пинье и Аланом Смитом мы придумали Канву предлагаемой ценности.

Канва предлагаемой ценности является как-бы дополнением к Канве бизнес-модели. Она помогает проектировать, тестировать и формировать предлагаемую потребителям ценность более структурированным и продуманным методом точно так же, как Канва бизнес-модели помогает в процессе разработки бизнес-модели (я ранее подробно писал, как мы придумали этот новый инструмент).

Канва бизнес-модели с ее 9 составляющими блоками концентрируется на общей картине. Канва предлагаемой ценности подробно рассматривает два из этих блоков – предлагаемую ценность и сегмент покупателя, позволяя описывать и более подробно анализировать «соответствие» между ними. Компаниям необходимо добиться как правильного «соответствия», так и правильной бизнес-модели, если они не хотят прогореть, о чем я писал ранее в посте про неудачи. Эти инструменты лучше всего работают в комбинации. Один не заменяет собой другой.



В данном посте я расскажу об этом концептуальном инструменте. В следующем своем посте я объясню, как его можно применять в тестировании в сочетании с методами развития клиента Стива Бланка и бережливого стартапа Эрика Риса. Канва предлагаемой ценности позволит лучше описать гипотезы по предлагаемым ценностям и потребителям, подготовиться к интервью с потребителями, а также станет руководством по тестированию и изменениям.

Как в фильме Начало (Inсeption), реальность в продуктовой разработке имеет определенную вложенность слоев. В зависимости от того, какая роль вам выпала, ваше “начало” в проекте может произойти раньше или позже, но всегда приятнее быть в числе создателей новой реальности, не так ли?

Эта статья — вступительная часть к трилогии о том, что собой представляет в гибкой продуктовой разработке:

• Готовность Начать
• Готовность Завершить
• Готовность Выпустить

Первая часть будет посвящена процессу открытия продукта (Product Discovery), вторая — процессу разработки продукта (Agile Delivery), третья — формированию цикла этих двух процессов, с обратной связью от рынка (Business Development). Здесь же, в начале, я задам общие рамки ролей и процессов, в которые буду углубляться в следующих частях.

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

Злой троянец увел у меня аккаунт на хабр, после чего под моим аккаунтом начали публиковаться какие-то тупые мультики. К сожалению узнал я об этом только когда НЛО перевело меня в read-only, а рейтинг ушел в отрицательное значение. Не беда: повод наконец написать пост, который давно собирался.

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

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

Известные

• Yet another Conference от Яндекс 2010 2011 — раз, два, три
• Application Developer Days
• DevPoint
• HighLoad++ Последние видео за 2009 год, но вроде как обещали выложить с недавно прошедшей
• РИТ
• JavaTechDays 2010, 2011
• DevСon'11
• Percona.TV Видео по MySQL
• PyCon — 2009-2011

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

Основы программирования

• codebetter.com/karlseguin/2008/06/25/foundations-of-programming-ebook
• pine.fm/LearnToProgram
• netlib.bell-labs.com/cm/cs/pearls
• www.faqs.org/docs/artu
• savannah.nongnu.org/projects/pgubook

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

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

У статьи довольно низкий порог вхождения для понимания и использования, по этому, надеюсь, придется по душе многим. Раскрывается лишь базовый функционал программ.

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).

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

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

Начинающим верстальщикам она точно будет полезна, а вот профессионалам — сомневаюсь, так как человек занимающийся не первый год версткой уже обязан «вызубрить» наизусть все особенности данного свойства.

В этой части статьи я напишу о вертикальном маргине. О горизонтальном поговорим в следующей части.