Startup команда

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

• профессиональной
• увлечённой

Давайте оставим в стороне случай, в котором профессионализм (проффесиональная мотивация) и энтузиазм (мотивация сделать проект) сочетается, он идеален и достаточно редок.

Профессиональная команда

Преимущества:

• качественная работа - люди ориентированы на качество, и знают как его достигнуть
  
• высокая производительность - как следствие опыта
  
• управляемость - бизнесс-виденьем владеет только стартапер, другие не претендуют на отстаивание своего виденья
  

Недостатки:

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

Увлечённая команда

Преимущества:

• общее виденье - люди хотят сделать проект, помогают друг другу, общаются, делятся мнением. Бизнесс часть из-за этого мутирует, приспосабливаясь к реальности. Это даёт проекту дополнительный шанс.
  
• мотивация - команда мотивирована, она сама толкает стартапера к действиям.
• дешевизна - люди согласны работать за гораздо меньшую зарплату.
  

Недостатки:

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

Частые ошибки:

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

Вывод

Если вы уверены в своём виденьи, то стоит выбрать профессиональную команду. Если у вас есть друзья, которые готовы работать над проектом с вами, то и выбора как такового нет :)

Скрам в Бизнесе

Есть такая методика разработки программ для профессионалов, как Скрам. Скрам - это итеративный и адаптивный подход для самоорганизующихся команд. Это если в одно предложение. На сайте agilerussia можно более подробно познакомится с этим явлением.

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

Как сейчас организовывается управляющая верхушка в практически любой компании? Да практически как получится, и политика процветает наверху, заставляя подчинённых страдать.

Зачем нужен Скрам Топам ?

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

Как применить Скрам Топам?

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

Вместо заключения

Я бы хотел работать в такой компании, ведь подчинённые не оказывались бы крайними при таких правилах игры, что безусловно приятно.
Теперь СкрамМастера и консультанты могут открывать для себя новые рынки, я полагаю ;)

Agile Storm

Игра, обращающая внимание на проблемы и пути их решения в гибком стиле.
Есть 10 ситуаций, которые могут возникнуть при реализации Скрама (думаю, для других гибких методологий тоже актуально) и 10 действий, чтобы не упасть в ловушку неуспешной реализации Скрама.
В идеале группа из 20-ти людей выбирает наугад одну карточку из 20, затем люди с ситуациями зачитывают по порядку карточки. После озвучивания каждой ситуации люди с действиями, если они считают что действия способны улучшить ситуацию, озвучивают свою карточку. Как финал после стандартных выходов из ситуации можно предложить свои.

Проблемы(Ситуации):
1. Ежедневные встречи затягиваются
2. Оценки задач по времени не улучшаются от итерации к итреации
3. Решения на ретроспективах не осуществляются на практике
4. Подзадачи оцениваются более чем в день
5. Четверть из запланированого не доделывается за итерацию
6. Нефункциональные задачи игнорируются
7. На собраниях одновременно говорит более одного человека
8. Общение в команде сводится к минимальному
9. Большое количество ошибок находится тестерами
10.После исполнения задачи заказчики вносят значительные коррективы

Решения(Действия):
1. Сменить Скрам Мастера
2. Организовать четкий распорядок встреч - начало и окончание митинга
известны как минимум за 2 дня
3. Поговорить с заказчиком по поводу процесса
4. Выбрасывать из плана итерации недоделаные задачи
5. Работать над задачей всё время с человеком, отвечающим за качество
6. Включить написание тестов в план решения задачи
7. Организовать неофициальную встречу команды
8. Попросить другого человека быть хозяином продукта
9. Сменить\обновить состав команды
10.Пригласить технического специалиста для обмена опытом

Если сможете применить это на собрании, пожалуйста напишите :)
И ещё просьба озвучить свои варианты действий в каждой из ситуаций.

How to write javadoc

My personal opinion how to write good javadocs (with examples from jdk)

Overview of method/class

Goal of method/class ? What is goal of class. Example:
* The <code>String</code> class represents character strings. All
* string literals in Java programs, such as <code>"abc"</code>, are
* implemented as instances of this class.

Responsibility of method/class ?What method/class is doing. Example in code above.

Action of method ?What statements we can make about how goal is achieved ? Example in StringBuffer class.
/**
* Ensures that the capacity of the buffer is at least equal to the
* specified minimum.
* If the current capacity of this string buffer is less than the
* argument, then a new internal buffer is allocated with greater
* capacity. The new capacity is the larger of:
* <ul>
* <li>The <code>minimumCapacity</code> argument.
* <li>Twice the old capacity, plus <code>2</code>.
* </ul>
* If the <code>minimumCapacity</code> argument is nonpositive, this
* method takes no action and simply returns.
*
* @param minimumCapacity the minimum desired capacity.
*/
public synchronized void ensureCapacity(int minimumCapacity) {
And, of course, describe boundary situations carefully.

Preconditions of method:

Some special agreement then it's legal to apply method/class, example:
* @param s a <code>String</code> containing the <code>int</code>
* representation to be parsed
It's not necessary must be placed in params, but it's good to have such statement. ;)

Postconditions of method:

What it must return if everything is ok.
* @return the integer value represented by the argument in decimal.

Exceptions documentation:

Please don't provide javadoc like "throws Exception if something goes wrong", it has no information in it.
Good Example is:
* @exception NumberFormatException if the string does not contain a
* parsable integer.

CRC description of class

Class javadoc is good then it contains Overview of class, it's responsibilities, classes it coolaborates with, and brief description of working logic and purpose. Example from Timer class.
/**
* A facility for threads to schedule tasks for future execution in a
* background thread. Tasks may be scheduled for one-time execution, or for
* repeated execution at regular intervals.
Examples of use helps a lot sometimes.

Links:

java.sun.com/j2se/javadoc/writingdoccomments/

alistair.cockburn.us/index.php/Structuring_use_cases_with_goals

en.wikipedia.org/wiki/Design_by_contract

Анти паттерны Разаработки через тестирование (TDD Anti-Patterns)

Перевод. Оригинал находится в блоге Джеймса Карра.

Недавно начал набрасывать я документ по анти-паттернам в Разработке - Через - Тестирование, и решил сначала разместить общие паттерны в яху группах.

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

Каталог Анти-паттернов разработки через тестирование.

Лжец(The Liar)

Тест проходит все свои сценарии и кажется
подтверждает правильную работу класса под тестом, но
если присмотрется получше, он вообще ничего не
тестирует.

Непомерная настройка (Excessive Setup)

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

Гигант (The Giant)

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

Симулянт (The Mockery)

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

Инспектор (The Inspector)

Юнит тест, который нарушает инкапсуляцию
(сокрытие данных), в попытке достичь 100% покрытия
тестами. Он слишком пристально следит за
внутренностями объекта под тестом, что любая попытка
рефакторинга сломает тест, его или прийдётся
постоянно исправлять.

Ведмежья услуга (Generous Leftovers)

Он оставляет
данные, которые использует другой тест. Если вдруг
порядок поменяется, второй тест не пройдёт.(Да и
понять его с такой услугой будет сложнее).

Местный герой (The Local Hero)

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

Педант (The Nitpicker)

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

Секретный ловец (The Secret Catcher)

Кажется, что он ничего не тестирует
потому, что нет утверждений (assertions), но не зря
говорят "дьявол прячется в деталях". На самом деле
тест проверяет отсуствие исключительных ситуаций в
объекте. Тогда тестирующая система сказала бы об
ошибке.

Халтурщик (The Dodger)

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

Крикун (The Loudmouth)

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

Жадный ловец (The Greedy Catcher)

Ловит исключения и проглатывает
информацию о стэке (stack trace). Иногда добавляет
своё сообщение об ошибке, гораздо менее
информативное, иногда просто пишет в лог и идёт тихо
дальше. Противоположность Крикуну.

Аутист (The Sequencer)

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

Скрытая зависимость (Hidden Dependency)

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

Нумератор (The Enumerator)

Тестовый класс где методы называются с
помощью цифр. Например: test1, test2, ... В
результате Цель теста непонятна, остаётся только
прочитать тест и молится о понятности кода.

Чужак (The Stranger)

Сценарий тестирования, который даже не
принадлежит тесту, в котором лежит. Обычно, он
тестирует другой объект, тесно связанный с объектом
под тестом. При этом он общается с этим объектом
напрямую, игнорируя базовый объект. Известен ещё как
Дальний родственник.

Проповедник системы (The Operating System Evangelist)

Тест, который надеется на
определённый тип Операционной Cистемы. Как пример,
тест который использует символ новой строки для
Windows, не будет работать под Linux.

Успех вопреки всему (Success Against All Odds)

(я бы назвал Адвокат) Юнит тест,
который написан чтобы срабатывать. Даже когда должен
был бы ломаться.

Свободная езда (The Free Ride)

Вместо нового сценария для теста,
добавляются утверждения в уже существующий сценарий.

Избранный (The One)

Комбинация Гиганта и Свободной езды.
Содержит в себе один сценарий(тестовый метод),
который тестирует всё что делает объект под тестом.
Часто названия теста и метода совпадают, и метод
содержит много строк настройки и утверждений.

Подглядывающий Мальчик (The Peeping Tom)

Тест из-за общих ресурсов
может видеть информацию другого теста и заставить его
провалится даже если система под тестом правильно и
хорошо работает. Часто встречается в Fitnesse, где использование статических переменных с
коллекциями не очищается после выполнения теста,
преподнося сюрпризы. Ещё паттерн известен как
Незванный Гость.

Философ (The Slow Poke)

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