пятница, 4 декабря 2015 г.

Как cделать хорошо пока не знаю что?

Сколько раз вы такое слышали?

В начале проекта:
- Нужно сначала всё продумать, учесть все нюансы и предусмотреть все возможности, а потом делать, а то получится как в прошлый раз! 
При завершении проекта:
- Ну вот, почему сразу не сказали все требования, теперь половину придется переделывать!

Но почему-то раз за разом попытки "сделать, наконец-то, все правильно" оказываются неудачными. Проблемы и причины - разные, результат - один. А если попробовать принять как данность, что мы не можем заранее все предусмотреть, и выстроить стратегию разработки программных продуктов соответствующим образом?
Давайте попробуем!

понедельник, 2 ноября 2015 г.

Про хорошую постановку задачи

Неопределенность, скрытая в нечёткой постановке задачи, приводит не только к ошибкам в предварительных оценках. Очень часто фактический результат выполнения задачи не соответствует ожидаемому. Вот представим, к примеру, что у нас есть сад, в котором растёт яблоня. На яблоне растут яблоки. Нужно собрать яблоки. Есть требование - чтобы яблоки не сгнили, их нужно укладывать в один слой. На первый взгляд - все просто. Сорвать яблоки, аккуратно сложить в один слой - и готово! 

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

пятница, 25 сентября 2015 г.

Про хороший код или антихрупкая разработка

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

Есть разница между академическими рассуждениями о хорошем коде в вакууме и практической пользой от его "хорошести". Качество кода учебной задачи и качество программы в промышленной эксплуатации - понятия связанные, но не тождественные. Если программа выполняется ровно один раз, делает то, что от неё требовалось, и после этого её никто больше никогда не увидит - то кого волнует качество её кода? Если программа работает из раза в раз, делает свою работу и к результату не возникает нареканий, то важно ли насколько хорошо или плохо она написана? В реальности, все эпитеты по отношению к коду возникают только при необходимости его изменить, когда программа делает что-то не то (или не так). Вот тогда и слышатся многочисленные WTF, яркие, красочные метафоры об авторе и т.п.

четверг, 10 сентября 2015 г.

Так ли страшны изменения, как их малюют?

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

четверг, 27 августа 2015 г.

Agile или Waterfall?

У меня долго не получалось примененять гибкие методологии для управления проектами по разработке ПО. Некоторые моменты были полезны, но в целом отказаться от долгосрочного календарного планирования не удавалось. Без построения и регулярного обновления диаграммы Ганта я не мог сам себе ответить на главный вопрос заказчика и руководства: "когда же все будет готово?"

Выстраивая рабочие процессы для производства программных продуктов, пазл неожиданно сложился, и картника ожила. Производственный процесс, в отличие от проекта, не останавливается никогда. Идет вереница проектов, у каждого свои цели и задачи, команда последовательно (или параллельно) их выполняет. И оказалось, что не надо уподобляться буриданову ослу, стоя между расплывчатой Agile доской и полной диаграммой Ганта проекта, напротив, эти блюда прекрасно сочетаются друг с другом.

вторник, 11 августа 2015 г.

Про правила

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

воскресенье, 10 мая 2015 г.

Мой task manager

Не люблю долго жить в неизменном окружении. Постоянно что-то добавляю, изменяю, экспериментирую. Даже спать на одном боку долго не могу. Если что-то рядом долго не изменяется, не эволюционирует - оно начинает раздражать. При этом не люблю кардинальные, революционные изменения, меня привлекают маленькие, но регулярные позитивные сдвиги.

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

Эволюционная разработка программных систем

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