Блог | Мурк дотком
Закрыть
Авторизоваться через пароль
E-mail:
Пароль:
Войти
Забыли пароль?
Авторизоваться через OpenID
OpenID:
Войти
Блог
О сайте
Вход
Новое на сайте
Неправильный Scrum
21.04.2008
Эволюция фотобанков
10.04.2008
Обзор rss-потоков, март 2008
2.04.2008
Обзор wiki-сервиса Google Sites
27.03.2008
Как программисту стать тимлидом
19.03.2008
Неправильный Scrum
«То, что в первом приближении может очень походить на agile на самом деле может быть просто хаосом и способом траты денег, не имеющих четких целей и демотивирующих проектную команду.».Алексей Кривицкий, тренер SCRUMguidesГибкие (agile) методологии разработки ПО в последние годы активно набирают популярность. Они позволяют снизить риски проекта, уменьшить объем «бумажной волокиты» и попросту удешевить разработку.
Однако облегченность (например, в сравнении с «моделью водопада») этих методологий вовсе не означает, что их можно применять не разобравшись до конца в самой сути agile-процесса.
Данная история — пример хаоса, возникающего при неправильном обращении с agile-методологиями.
В прошлом году я участвовал в нескольких проектах, которые формально делались по методологии Scrum. Проекты были аутсорсинговыми, наш клиент продавал их своему клиенту как Scrum, соответственно, контракта с фиксированной оплатой не было, оплата шла повременная. Схема разработки была итерационной, каждая итерация включала в себя демо-версию продуктов и сессию планирования следующей итерации. Приоритеты требований менялись в зависимости от результатов демо. Так что же было не так?
Начнем с того, что проекты были крупными и распределенными. Над одним проектом могло работать 35-45 человек, находящихся в разных офисах в разных городах в разных часовых поясах. Согласитесь, серьезное осложнение для процесса, где по канонам все должны работать в одном офисе (в идеале — в одной комнате), ведь живое общение — одна из основ agile-процесса: именно живое общение снижает уровень бумажной бюрократии.В первую очередь, наши клиенты восприняли Scrum с его ежедневными «стоячими совещаниями» как отличный способ получения отчетности (одна из величайших проблем крупного бизнеса в том, что отчитаться о проделанной работе часто важнее, чем эту самую работу качественно выполнить). Выглядело это так: каждый день для общения по телефону собирались руководители разработки из разных офисов и докладывали американскому руководству о состоянии текущих задач и дальнейших планах, после чего координировали работу со своими командами. Но у этих руководителей было по несколько групп разработчиков, а это в сумме — 20-25 человек на каждого… Реалистично отчитаться о задачах каждого из них — задача нетривиальная, потому к совещаниям вскоре подключили и руководителей команд. Даже для тимлидов не всегда было по силам досконально описать ситуацию в текущих задачах и способы ее решения, потому к совещаниям время от времени стали подключать и ключевых разработчиков. В итоге, большинство ключевых сотрудников стало отвлекаться на час-полтора каждый день, чтобы посовещаться. Это называлось «daily scrum» (который по правилам длиться должен не более 15 минут) и не могло не вредить общей продуктивности.Вскоре клиенты признали — такой подход не годится. Ведь больше всего о конкретных задачах проекта знают сами разработчики — значит они и должны отчитываться о своей работе, как это написано в книгах по Scrum’у. Но в команде проекта 30-40 разработчиков, притом, работающих в разных офисах, выслушать их всех и не потерять нить обсуждения крайне трудно. Выход был найден: вместо телефонных разговоров стали использовать групповой чат, логи которого всегда можно было перечитать. Но теперь уже не только ключевые сотрудники, но и вся проектная команда тратила ежедневно 1-2 часа на отчетность.Отчетность эволюционировала: когда стало понятно, что 1-2 из 8 рабочих часов ежедневно — это неприличная роскошь, схему пришлось изменить. Теперь разработчикам просто задавали подряд 3 классических для Scrum вопроса: «Что сделали за прошедший день?», «Что делаете теперь?», «Есть ли у вас препятствия на пути?», а разработчики должны были синхронно ответить на эти вопросы в чате. Больше никаких индивидуальных обсуждений… Позже американское руководство анализировало логи этих чатов… Зато все успевали «выговориться» за 15 минут. Было понятно, что подобные «daily scrum’ы» — чистый формализм, к счастью, разработчики воспринимали этот идиотизм с юмором. Впрочем, отчеты разработчиков вовсе не освобождали локальных руководителей разработки от собственных отчетов (еще более формальных) и за каждую итерацию, и за каждый день в отдельности. Я до сих пор не могу понять, где наши американские коллеги находили время для чтения всех отчетов.Все без исключений agile-методологии итеративны. В конце итерации (в Scrum они называются спринтами) мы получаем билд продукта, готовый к демонстрации. Создатели методологии XP предпочитают короткие итерации в 1-2 недели, Scrum — длинные в 1-2 месяца. Наш клиент решил сделать итерации максимально короткими — 1 неделя, то есть 5 рабочих дней. А иногда у нас бывали и микро-итерации — 2-3 дня… Клиент надеялся таким образом иметь больший контроль над процессом: ведь 1 неделя работы в неправильном направлении не так губительна, как две или даже четыре недели. Кроме того, если итерации недельные — значит и отчеты о результатах итерации можно получать каждую неделю. На практике же недельные итерации приводили к спешке: разработчики торопились, чтобы успеть закончить хоть что-то значимое в столь короткие сроки (впрочем, это скорее ошибка менеджмента), из-за чего уделяли минимум времени тестированию собственного кода. Осложняло ситуацию еще и то, что из 5 дней спринта реально на разработку оставалось всего 4, так как день уходил на «разворачивание» продукта, подготовку демо-версии и.т.п.. Каждый новый билд кишел глюками и мелкими недоработками.Роль тестировщиков в agile-процессе до сих пор слабо освещена. Клиента это нисколько не смущало, потому тестировщики у нас не были интегрированы в процесс разработки, а разработчики — в процесс тестирования. Если демо у нас в проектах проводилось каждый понедельник, то тестировщики (находящиеся не в тех же офисах, где работали разработчики) приступали к работе над тестированием нового билда лишь во вторник. Сессии планирования (стоит ли рассказывать, что, вопреки принципам Scrum’а, рядовые сотрудники в них не участвовали?) у нас проходили по четвергам, тестирование последнего билда в это время все еще длилось. Таким образом, просто не получалось составить план следующей итерации так, чтобы сначала исправлялись глюки, а лишь затем разрабатывался новый функционал. Можно было лишь предполагать что-то вроде «40% времени мы потратим на исправление ошибок». Такой подход вел к неконтролируемому распространению глюков.Сами заказчики продуктов были удалены от проектных команд. Такой инструмент гибких методологий как «пользовательские истории» тоже не использовался. Таким образом, заказчики и конечные исполнители не находились «на одной волне» и нередко воспринимали одни и те же требования по-разному. А ведь это одна из проблем, которую должны решать гибкие методологии.Не было и «ретроспектив». В конце каждого спринта команды не собирались вместе, чтобы обсудить слабые стороны итерации и решить, как можно улучшить процесс: распределенная природа разработки этого не позволяла. Иногда такие вопросы обсуждались руководителями на сессиях планирования, но решались лишь локальные вопросы — глобальные (а их было большинство) требовали многократного утверждения высшим руководством в США и «повисали» на неопределенный срок.Думаю, читая об этих проблемах, вы подумали, что вся работа у нас провалилась. Это не так: мы закончили все проекты, некоторые даже в срок. Однако, это было сделано ценой переработок, понижения итогового качества продуктов, сильного раздувания бюджета проектов, а позже — сокращения части раздутого штата сотрудников. Кроме того, локально мы втайне от клиента проводили ежедневные стоячие совещания, ретроспективы, интегрировали в процесс собственных тестировщиков и прочими способами спасали (насколько это было возможно) проекты от вредоносного лжескрама.В последующих проектах совместно с клиентом нам удалось изменить стратегию, мы масштабировали agile-процесс для работы распределенных команд, отказались от понятия «Scrum» и побороли большинство проблем, описанных в этой статье, что увеличило продуктивность работы в несколько раз. Хотите узнать, как мы этого добились, как внедряли изменения? — это тема следующей статьи.
21.04.2008
Комментарии: 5
0
agile, management
Эволюция фотобанков
«Сначала тебя игнорируют, затем над тобой смеются, затем с тобой борются, затем ты побеждаешь».
Махатма ГандиДавайте мысленно вернемся в 2003-2004 годы: еще не существовало понятие AJAX, еще не было блога у каждой третьей студентки в большом городе, закругление уголков и зеркальное отражение логотипов еще не стало модной тенденцией веб-дизайна, а сайты с возможностью поиска одних пользователей другими еще не называли социальными сетями. В эти же годы со словом «фотобанк» в интернете ассоциировались Getty Images и Corbis.Фотобанками пользовались и пользуются студии дизайна, рекламные и туристические агентства, издательства и многие другие, кому нужны фотографии на заданную тему, но не хочется (или нет возможности) нанимать для этой цели фотографов. В интернете фотобанки являлись логичной эволюцией информационных агентств вроде ИТАР ТАСС или Рейтерс.
Подход у этих служб был соответствующим: например, Corbis (основаный в 1989 году Биллом Гейтсом) не работал со сторонними фотографами, предпочитая все делать собственными силами, либо скупать традиционные информационные и фото-агентства. В Корбисе был целый штат аналитиков, следящих за мировыми тенденциями в политике, спорте, культуре, науке… и решающих, какие темы и стили фотографий будут наиболее ходовыми в ближайшее время. Наготове всегда был штат фотографов и моделей, светотехников, гримеров и костюмеров, экономистов и юристов. Если в Корбисе хотели снять фотосессию на медицинскую тематику — они просто арендовали настоящую больницу на ночь, привозили туда оборудование, моделей, часть декораций и проводили сессию.
Как видите, накладные расходы получались астрономическими, но фотобанки компенсировали это высокой стоимостью самих фотографий. Сколько я помню, 100-200 баксов за фотографию в низком разрешении считалось нормальной ценой.
На фоне этих гигантов возник проект iStockPhoto — фотобанк, являющийся посредником между фотографами и потребителями фотографий. Его цены были мизерными по сравнению со старшими братьями и составляли всего 1-20$ за фотографию. Большинство серьезных фотографов, игнорировали фотобанк, считая ниже своего достоинства продавать фотографии за 1-20$ (не считая комиссионных iStockPhoto). Игнорировали его и «старшие братья». Но фотобанк рос, набирая базу за счет любителей и средненьких фотографов.
Оказалось, что «любительские» фотографии тоже сильно востребованы и нередко оказываются по качеству не хуже «профессиональных» при значительно меньшей стоимости.
Вскоре бизнес-модель iStockPhoto стали копировать и появились новые фотобанки, такие как Dreamstime, Shutterstock (предлагающий абонементы вместо поштучной оплаты фотографий). Вслед за ними на рынок вышли Fotolia, StockXpert, BigStockPhoto… Этот тип фотобанков назвали «Микростоками» (Microstocks), и являлись они типичными представителями того, что сейчас принято называть «web 2.0».
Осенью 2005 года Киеве проходила презентация Zefa/Corbis. В это время я руководил разработкой Fotolia и, конечно же, хотел побольше узнать о конкурентах. Я спросил у представителя Corbis, как они относятся к конкуренции со стороны микростоков. Представитель улыбнулся и объяснил, что микростоки с их качеством фотографий не являются конкурентами Corbis и Getty Images.Сейчас 2008 год. По данным Alexa iStockPhoto (проданый 2 года назад Getty Images) по своей популярности значительно обошел все остальные фотобанки — как микростоки, так и крупные. Затем идет Getty Images, с небольшим отрывом от нее следуют Fotolia и ShutterStock. Замыкает пятерку Corbis, запустивший собственный микросток — Snap Village.Именно так энергичные стартапы побеждают «корпоративное зло», простые гибкие методологии разработки постепенно вытесняют бюрократизированные так же, как динамические языки программирования вытесняют статические.
10.04.2008
Комментарии: 8
0
Бизнес, Интернет
Обзор rss-потоков, март 2008
Вслед за февральским обзором сайтов, прошедших через мою RSS-читалку, с небольшим опозданием публикую мартовский.Успешно прошли
Блог Henrika’а Kniberg’а — лучшее из всего что видел за последний год по теме гибких методологий разработки ПО. Хенрик умещает все основы методологии Scrum в один mindmap, описывает схемы работы с системами контроля версий при итеративной разработке, интеграцию тестировщиков в agile-процесс и многое другое.
Микромаркетинг — очень приятный сайт о маркетинге и бизнесе. Все написано простым понятным языком. Прочитал этот сайт «от корки до корки».
Ukrainian SCRUM Portal — продолжатель дела Agile Ukraine. Наиболее качественный украинский сайт со статьями о гибких методологиях разработки.
Персональные вопросы — интересный блог о тонкостях работы кадровых отделов (в IT).
Интернет нового века — автор этого блога недавно выступал на семинаре Exception 07, его доклад мне показался поверхностным и непродуманным… в то же время его блог о разработке с использованием фреймворка Django оказался значительно глубже и статьи несут практическую пользу.
Блог об IT бизнесе — интересный и толковый авторский сайт об IT, один из лучших подобных сайтов, как мне кажется. Минус всего один — автор болен «синдромом блоггера»: пишет довольно часто, но разбавляет классные продуманные статьи откровенной халтурой. Если бы статей стало в 3 раза меньше и оставались только хорошие — стало бы гораздо лучше.
Дедлайн как стиль жизни — толковый менеджерский блог. Освещаются темы управления проектами, мотивации, самоорганизации и различных «лайфхаков». К сожалению, как и большинству других менеджерских блогов, этому не хватает одного — изюминки.Не прошли карантин
Urbansheep — пишет только в LJ. Там его и читаю.
Amazing development — никакой активности вот уже месяц, думаю, сайт сдох.
GeoSpot — «много букф». И сайт явно рассчитан больше на туристов чем на путешественников.
Agile Ukraine — теперь все полезное идет на scrum.com.ua.
Аналитика Cnews — сухая подача материала из мира больших корпораций.
How To Change the World — уже пару месяцев от Гая Кавыасаки никаких практических материалов, никакой пользы.
IT и Бизнес, сайт превратился в помойку «корпоративных новостей» крупных компаний бывшего СССР.
Overclockers Software — новости о софте для виндовс больше не интересуют.
Алена C++, наверное, я слишком далек от мира C++ и компьютерных игр, потому что посты жены Сагалаева совсем не цепляют.
Блог про Google Apps — все это и так публикуется на Хабрахабре.
The Meanwhile — словил себя на мысли, что в последние месяцы читаю блог Ильи Бирмана «на автомате», а чего-то полезного для себя не нахожу.
Agile Dokuwiki — проект морально устарел на пару лет и почти не обновляется.
Sitepoint Blogs PHP — мало аналитики, много информации для новичков PHP. Мне такое не нужно.
Блогбастер — блог о блогах. Довольно слабый и с малым количеством собственного контента.
ITC.ua — сайт о компьютерах. С одной стороны новостей много и адекватных, с другой — тут вперемешку и новости «софта», и «железа», и интернета, что прилично раздражает, хочется читать только определенную тематику.
XHTML.RU — сайт о верстке. Ничего плохого, но о самых интересных вещах все-равно читаю на «Хабре».
У Wadа — об этом сайте я уже писал в прошлом обзоре. Увы, автор мешает интересные статьи о бизнесе, обществе потребления и.т.п. с историями «как я катался по Америке на авто»… последнего, к сожалению, больше.
GUI.RU — неплохой сайт о юзабитили, но все его материалы, как оказалось, дублируются на «Хабре», так зачем же плодить сущности?Временно в карантине
Популярная веб-механика — довольно перспективный, на первый взгляд, блог о веб-разработках, но с мизерным количеством контента. Посмотрим: умрет ли сайт или будет жить.
SitePoint — известный ресурс о веб-разработках: дизайне, верстке, программировании, управлении проектами и маркетинге. Читаю его уже 4 года, но в последнее время толковых статей становится все меньше и меньше, в основном публикуют довольно поверхностные материалы уровня «для чайников».
Пепелсбей.net — сайт о верстке с приятным дизайном. Негатива не вызывает, но статей на сайте пока слишком мало чтобы сформировать окончательное мнение.
Антикорпоратив — интересный блог о бизнесе, корпоративной среде (вернее, о ее вреде), «лайфхаках». Наиболее полезен работникам больших бездушных компаний. Серьезно смущает, разве что, обилие ненужных картинок к постам.
Управление проектами в картинках — забавный менеджерский сайт. Картинки со схемами с него мне нравятся, а вот тексты — так себе…
02.04.2008
Комментарии: 8
0
Интернет, Обзор
Обзор wiki-сервиса Google Sites
В прошлом я пользовался разными «standalone» wiki-системами: WackoWiki, MediaWiki, DokuWiki, Confluence (по работе пользуюсь ей и сейчас).
Постепенно решил отказаться от использования standalone wiki в личных целях. Вначале перевел большую часть информации в Google Docs & Spreadsheets… Но вскоре выяснилось, что информацию в нем удобно редактировать, хотя ориентироваться в ней неудобно – D&S все-таки офисный пакет, а не wiki. Вскоре я нашел сервис WikiDot. Сервис показался довольно качественным, и через него можно было даже повесить wiki на собственный домен через DNS. Однако с удобством навигации в WikiDot явно прогадали: вместо иерархической структуры страниц авторы предпочли плоскую + теги… да и дизайн часто раздражал своей неаккуратностью.
В общем, я все еще искал альтернативу.
Около месяца назад в Интернетных Штучках написали о запуске нового сервиса Google Sites — и я решил попробовать.
Google Sites обладает приятным внешним видом, хотя и без изысков. На выбор дается несколько тем оформления. На мой взгляд, тема по умолчанию наиболее приятна.
Сама Google не позиционирует Sites как wiki, потому здесь нет wiki-разметки, зато есть удобный и функциональный WYSIWYG-редактор.
На выходе WYSIWYG дает HTML-код, который можно редактировать и вручную.
Текст на страницах можно размещать как в одну, так и в две колонки.
Sites может вставлять в страницы оглавление (table of contents) — это очень удобно, когда у вас в wiki находятся страницы с большим количеством разных подзаголовков.
Кроме оглавления, можно вставлять множество объектов из других сервисов гугла: Calendar, Docs&Spreadsheets, youtube, Picasa Web Albums…
На мой взгляд, это особенно удобно для вставки данных из Google Spreadsheets.
Также можно вставлять и гаджеты iGoogle — будь то прогнозы погоды, свежие ролики с youtube или новости сайта wired.
Система ссылок в редакторе хорошо продумана — в модальном окне можно выбрать внутреннюю страницу либо ввести внешний адрес.
Управление главным меню сделано схожим образом — из дерева разделов мы можем выбрать основные ссылки.
Помимо простых страниц, в Sites можно создавать страницы новостей «Announcements», файлохранилища «File Cabinet», страницы-агрегаторы типа «Dashboard» и страницы списков «List».
Если с первыми двумя все понятно, то о последних двух стоит рассказать подробнее. Dashboard представляет собой страницу с несколькими местами для вставки гаджетов iGoogle и прочих внедряемых компонентов, как в меню «Insert» wysiwyg-редакторв. List позволяет создавать списки с разными наборами полей и сортировать их: это удобно для списков задач, покупок, сотрудников и.т.п.
Как и WikiDot, Sites можно прикрутить через DNS к вашему домену, правда, вас все равно перебросит на http://sites.google.com/a/siteaddress.
Есть в Sites и серьезные недостатки. Главный, как мне кажется, — невозможность изменить URI страницы: представьте, что вы создали страницу «GoodPage» — адрес для нее будет вида http://sites.google.com/a/siteaddress/sitename/goodpage/. Если сменить название, например, на «BadPage» — адрес страницы все равно останется прежним — http://sites.google.com/a/siteaddress/sitename/goodpage/. С русскими названиями страниц проблем еще больше — приходится сначала давать странице название латиницей для URI, а затем переименовывать на русский. Думаю, это ограничение в гугле ввели, чтобы упростить работу с деревом сайта, но с точки зрения пользователя оно очень мешает. Надеюсь, что в будущем ограничение уберут.
Второй серьезный недостаток — негибкая система прав доступа. Вы можете менять права доступа на разные Site’ы, но управлять правами конкретных разделов и страниц нельзя. Конечно, можно немного смягчить эффект, используя несколько «сайтов», например, публичный и частный. Но это всего лишь «костыль» и целиком проблему не решает.
Третий недостаток — продукт является частью Google Apps (for your domain), потому недоступен бездоменным.
Странно, что Google не внедрила в Sites такие свои сервисы, как Analytics и AdSense.ИтогУ Google (или JotSpot?) получился качественный и «человечный» продукт для малого бизнеса (для среднего и крупного бизнеса я рекомендовал бы Confluence) и частных лиц. Продукт, рассчитанный, в первую очередь, на обычных пользователей, а не гиков…
Сервис очень хорош — более удобной wiki-системы я не встречал, но советовать его всем и каждому не стану из-за мелких недоработок и ограничений функционала.
27.03.2008
Комментарии: 3
0
Интернет, Обзор, software
Как программисту стать тимлидом
Приходит Петька к Василию Ивановичу: «Васильываныч, хочу быть тимлидом!..»Неоднократно мне приходилось читать (например, на DOU), как при обсуждении той или иной IT-компании, люди хвалят или ругают работодателей за их отношение к профессиональному росту персонала: «Отличная компания, я пришел сюда разработчиком, а недавно стал тимлидом!» или «Лучше сюда не идите, в компании стараются брать руководящие кадры со стороны вместо того, чтобы повышать своих рядовых сотрудников».
Я успел побывать как в роли повышаемого, так и в роли повышающего. Потому уверен, что подобные заявления достаточно наивны. На самом деле, в большинстве IT-компаний (кроме самых маленьких) проблема состоит не в том, что расти программисту некуда, а в том, что «двигать» некого.РаботодателиВ принципе, любой работодатель заинтересован в продвижении проверенных сотрудников, а не в приглашении на руководящие посты людей со стороны. Притом, исходит он не из этических соображений, а из очень даже меркантильных: новый человек в команде — это отчасти «кот в мешке» — до конца не знаешь, что он собой представляет (в отличие от проверенного своего сотрудника) — вот почему и существует испытательный срок. Недобросовестный руководитель проекта или тимлид может нанести бизнесу гораздо большие убытки (даже в течение испытательного срока), нежели рядовой сотрудник. Именно потому, ради уменьшения рисков, стараются повышать своих, а не приглашать новых. Если же руководящие кадры приглашаются со стороны — это, скорее всего, означает, что руководство компании не видит достойных претендентов среди собственного персонала.Что делать?Итак, вы все-таки хотите стать тимлидом:
Для начала подумайте, нужно ли вам это? Если вы очень любите программировать — знайте, что на программирование у вас останется гораздо меньше времени. С расширением полномочий уровень ответственности тоже увеличится: придется отвечать не только за себя, но и за всех членов своей команды. Стрессов станет побольше, особенно, в первое время и при сдаче проектов. А зарплаты тимлидов, замечу, не выше обычно, чем у ведущих специалистов.
Вам придется научиться говорить «нет», проявлять твердость характера: кому нужен тимлид, которому сотрудники «садятся на голову»?
Беритесь за организационную деятельность: неважно — будет ли это нечто связанное с текущими проектами, общим рабочим процессом компании или банальной организацией «пьянок» для сотрудников. Главное — чтобы это приносило пользу компании.
Необходимо не только проявлять активность, но и брать на себя ответственность: подход «все пидорасы — один я д’Артаньян» вряд ли приблизит вас к поставленной цели.
Помните, что ваше руководство — не телепаты: сообщите им о своем желании стать тимлидом. В этом нет ничего зазорного или унизительного. Зато руководство будет знать о вашей цели и может посодействовать — подсказать, чему стоит подучиться.
Необходимо качественно выполнять свою текущую работу: если вы регулярно нарушаете дисциплину, срываете сроки и недобросовестны — вас скорее уволят, чем повысят.
Постарайтесь заслужить уважение коллектива: если «коллеги по цеху» не считают вас профессионалом и приятным человеком — не воспримут и как реального руководителя.
Очень важно хорошо говорить и писать. Как правило, в полемике выигрывает лучший оратор. Руководитель, слабый в дискуссиях и спорах, легко может растерять авторитет.
Учитесь не только программированию, но и методам управления. Для этого придется штудировать, кроме книг по «паттернам» проектирования и языкам программирования, также книги и статьи по менеджменту, методологиям разработки, работе с рисками, несомненно, по человеческому фактору…
Тимлиду в аутсорсинговой компании может понадобиться и свободное владение английским.Такого набора качеств и действий, в принципе, достаточно, чтобы вас заметили и повысили. Дерзайте!
19.03.2008
Комментарии: 11
0
Карьера, Программирование, Лайфхак
Страницы:
← Предыдущая | Следующая →
1
2
3
Подписка
Новое на сайте
Скоро на сайте
Кроссплатформенные средства UML
Менеджеры-теоретики
Закулисы: почему вас не взяли на работу
Что такое ORM и каковы особенности его реализации
Развитие evidence based scheduling
Категории
agile
Книги
Бизнес
Карьера
Программирование
Интернет
Лайфхак
mac
management
Операционные системы
Обзор
software
Рекомендую книги
The Deadline: A Novel About Project Management
Художественный роман об управлении проектами от автора Peopleware
Joel on Software
Сборник эссе Джоэля Спольски о рынке ПО, работе с людьми, управлении проектами
Patterns of Enterprise Application Architecture
Лучшая книга об архитектуре веб-приложений. Автор — мартин Фаулер
Death March
Книга Эдварда Йордона о том, как выживать в умирающем проекте.
Peopleware: Productive Projects and Teams
Классическая книга Тома Демарко и Тимоти Листера о человеческом факторе в бизнесе, о продуктивности. Читать в обязательно порядке.
Agile Project Management with Scrum
Базовая книга по методологии гибкой разработки проектов — SCRUM от создателя методологии.
Measuring and Managing Performance in Organizations
Способы учета и контроля производительности труда.
2008, Александр Локшин. Авторские права защищены.
Блог
О сайте
ielts
307
asko
2115
nokia 9300i
/
3d
thuraya
rittal
hansa