The Navigame

Just a week remains until the New Year 2012 comes. The last year was the first one we at Luxoft have been able to make the maximum contribution to the development of the next-generation car navigation system which we are working on since 2008. The most prominent thing is the complete responsibility for the production chain, of course. At the same time the software products we are developing have matured a lot - thanks to all my colleagues, past and present.

As I really appreciate what our guys have done and are doing and at the same time I want to remember and cherish the good time we had in 2011, I decided to write a simple computer game on how we work. So, meet The Navigame:

After some trials and errors I decided to make it looking like a paper sketch (most likely soon I'll assemble a new version with enhanced graphics which I've asked my friend for). The good thing is that here I've finally found an application for the TTF-font I created two years ago.

The goal of the game is to develop the navigation system and to compile digital maps - as much as possible. For this you have a pool of skilled developers and map production engineers which can be assigned different tasks. There are developers who create the navigation software and production engineers who build the maps using the map compiler which is a part of navigation. The more the navigation system is feature-complete, the bigger maps can be handled with it. There are also some athmospheric features like customer PM or developers' curses. You basically should (a) finish the navigation development, (b) fulfil the map production plan and (c) earn as much money as possible.

To all people we worked with during the last 2-3 years: there are good chances that you find yourself inside the game - so give it a try :)


The source code, readme and binary download are available on Github at https://github.com/sborodavkin/navigame. It is required to have JRE installed as the game is developed in Java using Slick and LWJGL.

All contributions and feedback are warmly welcome.

Экспертиза

Это только меня передергивает, когда я слышу/вижу это слово? Нет, правда.

Кто решил, что экспертиза в русском языке обозначает то же самое, что expertise - в английском?

• "Наша экспертиза позволяет нашей компании выполнять проекты самого высокого уровня сложности"
• "Экспертиза отдела разработки ПО на базе Java составляет 3 года"
• "Это позволяет EPAM накапливать экспертизу и успешно применять ее в проектах."
• "Расскажите о вашей экспертизе с Informatica"

Предлагаю определиться. Экспертиза - хоть Ушакова откройте, хоть Брокгауза и Ефрона, хоть словарь иностранных слов - означает примерно следующее:

Экспертиза [лат.; см эксперт] - исследование какого-л, вопроса, требующего спец. знаний, с представлением мотивированного заключения, напр, врачебная э., бухгалтерская э.

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

Crow 1.1.0 released

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

Скачать можно отсюда.

В релиз 1.1.0 были включены 5 новых фич:

• 3364079 Export Traceability Matrix to Excel
• любой Traceability Report теперь можно сохранить в Excel-файл. Используется библиотека Apache POI.
• 3313584 Add filtering capabilities to Traceabilty tab
•  в окно "добавить трассировку" были добавлены текстовые поля для динамического поиска нужных элементов. Выглядит это так:

• 3300468 Filter Perforce changelists by description
•  аналогично предыдущей фиче, в окне добавления Perforce changelists теперь можно делать дополнительную фильтрацию по описанию:

• 3294913 Support new trace type DD2TRS
• несмотря на то, что ASPICE запрещает прямую трассировку TRS на детальный дизайн, бывают ситуации, когда описание архитектуры недоступно, и в этом случае установить необходимые трассы нельзя. Поэтому был добавлен новый тип связи, позволяющий трейсить TRS непосредственно на детальный дизайн и обратно.
• 2946382 Mark some CRS as "should not be traced"
• иногда в базе CRS есть отклоненные (rejected) или устаревшие требования, которые намеренно не покрыты TRSами, дизайном, кодом и т.д. Чтобы в отчете о трассировке эти CRS не светились красным цветом, появилась возможность обозначать их как "не трассируемые". В отчете это выглядит, например, вот так:

За реализацию фильтров и нового типа трассировки отдельное спасибо Саше Кондратюку!

Приятной работы!

Кстати, в этом релизе мы попробовали CodeStriker - бесплатный инструмент для проведения peer code review. По сравнению с Crucible - ужасно: неудобный интерфейс, корявое отображение исходников, для просмотра комментариев необходимо кликать на закладки (нет режима отображения кода вместе с комментариями).

Is Data a Software?

Сегодня инициировал, а затем полтора часа участвовал в дискуссии, смысл которой можно свести к вопросу "можно ли входные данные, обрабатываемые программой, также называть Software"?

По завершении дискуссии, нашел интересную статью Peter Suber, "What is Software?" Несколько цитат из глав 9 и 11:

To compile a program written in a high level language, it must be treated as data by another program, the compiler. It must passively be worked upon, so that later it may actively do work. Without this step, the programmer might as well have spoken in English. Programs written originally in the binary code readable by the machine do not require this translation, and hence need not be treated as data. But virtually all programs written today are written in higher level languages.
Apart from this critical step in the very functioning of software, programs are treated as data for the purpose of copying (publishing) and transmitting them. Even if a program were originally written in machine language, chances are good that if we are using it, its code has once been treated as data by another program.

Software may essentially be pattern, but how is it to be distinguished from patterns that are used as data rather than software? How does it take the position of natura naturata and then natura naturans? This seems to be the central mystery. How can pattern be read as instructions? How can mere pattern rise from passivity to activity? Why isn't sheer syntactical pattern always inert, perpetually data and never software?

 ...

We can approach answers to these questions by saying that software is pattern in a controlling position, while the same pattern in a different position will be data (and the same pattern under different language conventions will be noise). But what is this "position"? The first thing to observe about it is that it is not part of the pattern. It is the use to which the pattern is put, or the relation between the software-pattern and other patterns that are currently functioning as data. In this, to assume the "controlling position" is similar to meeting the physical requirement of readability; it leaves the pattern unchanged and occurs independently of the syntactic and semantic content of the pattern.

It is this "position" or use of the software pattern that enables its binary code to be taken as code for instructions that are to be executed. The matter is simpler than it may appear. If we write down on one piece of paper directions for copying a page of text, and on another piece of paper directions for erasing or shredding a page of text, then we may give them to a stranger and ask that the top sheet be read and applied to the bottom sheet. It does not matter how they are shuffled; each can apply to the other as it can apply to itself. One is put in a controlling position if the "hardware" (here the stranger) reads one first and one second. Odysseus may command his men to tie him to the mast as his ship passes the island of sirens, and to ignore any commands to be released that he might issue. If his men obey this command, then it "poisons the well" for future commands and causes them to be interpreted as data. But the commands to be released are like the directions written to the stranger: fully satisfactory and "authoritative" as commands. Whether they function as commands or data is a matter of whether they are taken up earlier or later than other contenders.

Вкратце: data также является software. IEEE также считает данные подмножеством software.

Комментарии к методам

Очень понравилась фраза из SQLite coding style; не могу удержаться, чтобы не скопировать сюда:

31. Function header comment defines the behavior of the function in sufficient detail to allow the function to be reimplemented from scratch without reference to the original code.

Проблемы документирования software design

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

• дизайн-документы хранятся в морально устаревшем формате Word, низкая прозрачность
• сложный шаблон документа как результат стремления покрыть все требования к дизайну из ASPICE L3 HIS scope
• непонятно, актуально ли описание дизайна, или уже устарело - к коду доверия больше.

Как перестать писать дизайн "из-под палки" и что вообще делать - мне пока непонятно. Нашел вот цитату из David Parnas and Paul Clements. "A Rational Design Process: How and Why to Fake It" in Software State-of-the-Art: Selected Papers. Dorset House, 1990, pg. 353-355:

It should be clear that documentation plays a major role in the design process that we are describing. Most programmers regard documentation as necessary evil, written as an afterthought only because some bureaucrat requires it. They do not expect it to be useful.
This is a self-fulfilling prophesy; documentation that has not been used before it is published, documentation that is not important to its author, will always be poor documentation.
Most of that documentation is incomplete and inaccurate, but those are not the main problems. If those were the main problems, the documents could be easily corrected by adding or correcting information. In fact, there are underlying organizational problems that lead to incompleteness and incorrectness and those problems, which are listed below, are not easily repaired.
1) Poor Organization: Most documentation today can be characterized as "stream of consciousness" and "stream of execution." "Stream of consciousness" writing puts information at the point in the text that the author was writing when the thought occurred to him. "Stream of execution" writing describes the system in the order things will happen when it runs. The problem with both of these documentation styles is that subsequent readers cannot find the information they seek. It will therefore not be easy to determine that facts are missing, or to correct them when they are wrong. It will not be easy to find all the parts of the document that should be changed when the software is changed. The documentation will be expensive to maintain and, in most cases, will not be maintained.
2) Boring Prose: Lots of words are used to say what could be said by a single programming language statement, a formula, or a diagram. Certain facts are repeated in many different sections. This increases the cost of the documentation and its maintenance. More importantly it leads to inattentive reading and undiscovered errors.
3) Confusing and Inconsistent Terminology: Any complex system requires the invention and definition of new terminology. Without it the documentation would be far too long. However, the writers of software documentation often fail to provide precise definitions for the terms they use. As a result, there are many terms used for the same concept and many similar but distinct concepts described with the same term.
4) Myopia: Documentation that is written when the project is nearing completion is written by people ho have lived with the system for so long that they take major decisions for granted. They document the small details that they think they will forget. Unfortunately, the result is a document useful to people who know the system well, but impenetrable for newcomers.
Documentation in the ideal design process meets the needs of the initial developers as well as the needs of the programmers who come later. Each of the documents mentioned above records requirements or design decisions and is used as a reference document for the rest of the design. However, they also provide the information that the maintainers will need. Because the documents are used as reference manuals throughout the building of the software, they will be mature and ready to use in later work. The documentation in this design process is not an afterthought; it is viewed as one of the primary products of the project. Some systematic checks can be applied to increase completeness and consistency. [...]
"Stream of consciousness" and "stream of execution" documentation is avoided by designing the structure of each document. Each document is designed by stating the questions that it must answer and refining the questions until each defines the content of an individual section. There must be one, and only one, place for every fact that will be in the document. The questions are answered, i.e., the document is written, only after the structure of the document has been defined. When there are several documents of a certain kind, a standard organization is written for those documents. Every document is designed in accordance with the same principle that guides our software design: separation of concerns. Each aspect of the system is described in exactly one section and nothing else is described in that section. When documents are reviewed, they are reviewed for adherence to the documentation rules as well as for accuracy.
The resulting documentation is not easy or relaxing reading, but it is not boring. It makes use of tables, formulas, and other formal notation to increase the density of information. The organizational rules prevent the duplication of information. The result is documentation that must be read very attentively, but rewards its reader with detailed and precise information. [...]
No matter how often we stumble on our way, the final documentation will be rational and accurate. Even mathematics, the discipline that many of us regard as the most rational of all follows this procedure. [...] Analogous reasoning applies to software. Those who read the software documentation want to understand the programs, not relive their discovery. By presenting rationalized documentation we provide what they need.
Our documentation differs from the ideal documentation in one important way. We make a policy of recording all of the design alternatives that we considered and rejected. For each, we explain why it was considered and why it was finally rejected. Months, weeks, or even hours later, when we wonder why we did what we did, we can find out. Years from now, the maintainer will have many of the same questions and will find his answers in our documents.

Как стать ПМом

За последние месяцы меня несколько раз спрашивали, что нужно для того, чтобы стать руководителем проекта (ПМ). Что примечательно, этот вопрос исходит в основном от джуниоров, молодых и амбициозных. Опуская сантименты "оно вам не надо" и т.д., попробую высказать свое субъективное и неправильное мнение на этот счет.

1. ПРИЧИНА

Главная причина того, что люди задаются таким вопросом - стремление к власти. Ничего плохого в этом нет - как известно, главных испытаний в жизни всего 4: деньги, слава, власть и любовь. Для точки внутри пространства такого ортогонального базиса, например, жажда любви ничем не лучше жажды власти. К тому же, сравните:

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

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

2. СРЕДСТВА

Теперь о средствах достижения вожделенного ПМства. В дополнение к очевидному - желанию стать ПМом - более-менее внятно озвучить я могу пять:

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

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

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

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

2.3. Инициатива (или "делайте больше"). Покажите своему руководителю (от которого зависит ваше повышение), что вы можете больше. Вам дали задачу? Найдите способ сделать ее лучше, чем указано в требованиях! Заложите больше масштабируемости, проведите рефакторинг, напишите больше тестов, оптимизируйте алгоритм. Однако, не бросайтесь с места в карьер: отсутствие опыта приведет только к тому, что вы будете предлагать нереализуемые, ненужные или ранее отвергнутые сценарии и тем самым злить начальство. См. также пункт 2.1.

2.4. Язык. Как правило - английский. ПМ, пишущий письма заказчику на плохом английском, с ошибками в словах и грамматике, отвратителен. С другой стороны, вполне можно писать простыми предложениями, употреблять в основном часто используемые слова - но ради Бога, грамотно! Оценить свою степень владения языком можно на курсах, у преподавателя, у более знающего коллеги, а также, частично, с высоты своего языкового опыта. См. также пункт 2.1.

2.5. Способности к руководству. Это что-то из области "можно вам доверить людей" или нет. Оценивать вас по этому пункту будет ваш руководитель, скорее всего, чисто субъективно, в связи с чем ограничусь примерами:

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

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

3. ОТКЛОНЕНИЯ

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

• повышение произвел некомпетентный руководитель. Либо он (руководитель) пострадает из-за этого и отменит такое повышение, либо ПМ "натыркается" и будет сносно выполнять свои ежедневные обязанности, тем не менее лажаясь каждый раз, когда от него потребуется что-то, что выходит за круг его привычных задач (написать proposal для нового заказчика, выступить с презентацией на ежегодном собрании и т.д.)
• повышение произвел компетентный руководитель. В этом случае он (руководитель) принимает все риски, связанные с таким назначением, и возможно выполняет часть работ за своего ПМа. Такая ситуация возможна, когда:
• руководитель держит бразды правления в своих руках, отдавая ПМу рутинные технические задачи (распределение тасков между людьми, сбор индивидуальных отчетов и подготовка проектного отчета, написание / ревью технических требований и т.д.) О реальной власти ПМа в такой ситуации речь не идет - однако это может быть ловко замаскировано более опытным руководителем и подано молодому ПМу под правильным для него соусом из манипулятивных утверждений и обещаний.
• Другой вариант развития событий: руководителю нужен реальный ПМ, нанимать "готового" с рынка для компании экономически нецелесообразно, поэтому новый ПМ целенаправленно взращивается в реальных условиях. Это возможно при соблюдении требований 2.2, 2.3, [2.4], 2.5 из списка выше. При этому руководитель ПМа все так же несет ответственность за проект, готов придти ему на помощь в случае необходимости и в целом верит в него.
• компания понимает под ПМом что-то принципиально другое, чем то, что понимаю я. Мне встречались случаи, когда ПМами называли себя фактические продакт-менеджеры, сейлзы или аналитики. Скорее всего, ПМ в таком случае будет бесконечно далек от PMBOK.

4. ВЫВОДЫ

Чтобы стать ПМом, обязательно нужен инженерный опыт. Софт-скиллы (управление людьми, конфликтами, изменениями, ведение переговоров, навыки проведения презентаций и т.д.), как правило, приобретаются уже на новой должности (либо на должности тим/тех-лида при более дальновидной политике компании). В дополнение к опыту обязательна инициатива в смысле желания делать больше. Очень важны процессы (и да, agile - это процесс). Кроме того, важно знать свои недостатки, которые могут помешать вам в управлении людьми, и вести с ними постоянную борьбу.

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

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

В общем-то, можно быть и дятлом в кресле ПМа. Главное - не обманывать себя. Удачи!

Project Management Plan Hell

В нашем центре разработки существует обязательная практика написания Project Management Plan'а (PMP) для каждого проекта. Под РМР у нас понимают документ объемом около 20-30 страниц следующего содержания:
- Scope проекта (milestones, deliverables, assumptions, constraints и т.д.)
- организационные диаграммы: внутренняя + интерфейсы на стороне заказчика
- планы по управлению рисками, требованиями, изменениями, схема эскалации проблем
- методики оценки проекта, планы верификации и тестирования, процедуры приемки задач и пр.
- план-график проекта
- цели качества и контролирующие их метрики
- план обучения персонала
- и т.д.

От каждого (условно) project manager'а в обязательном порядке требуется:
- составить такой документ (с учетом проектных задач, которые никто не снимает - 2-3 недели)
- провести ревью внутри команды с привлечением инженера по качеству, учесть замечания (если в команде человек 10-15 - 1 неделя)
- провести еще одно ревью с участием руководителя группы качества и сайт-менеджера и утвердить РМР на нашей стороне (с учетом занятости таковых - 2 недели)
- утвердить документ с ПМ'ом на стороне заказчика (с учетом занятости такового - 2 недели)

В общем итоге, составление и утверждение РМР занимает около 2 месяцев. За это время, разумеется:
- изменяется scope проекта, появляются новые задания и активности
- изменяется состав команды (кто-то приходит, кто-то, возможно, уходит)
- сдвигается план-график
- уточняются цели качества, изменяется набор метрик
- люди обучаются, план обучения также эволюционирует.

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

Пути решения могут быть, например, такими:
- упрощение процедуры переутверждения РМР
- упрощение содержания РМР
- отказ от РМР.

Ага?