Подводные камни при разработке программного обеспечения: опыт программиста
В рамках требований для перехода к следующему этапу программы начального курса программного обеспечения после прохождения квалификационного теста на следующий модуль Ruby от меня требовалось работать с партнером над проектом, который удовлетворял определенному порогу результатов проекта. Мой партнер - экономист. Исходя из инженерного фона с опытом управления проектами, этот проект, помимо стольких значимых уроков, продемонстрировал мне опасность постепенного увеличения объема работ, и он будет одной из основных идей, обсуждаемых в этой статье.
«Не стройте маленьких планов… просто убедитесь, что они УМНЫЕ»
Было очевидно, что создание идей не будет проблемой. Мой партнер имел богатый опыт в различных областях. Я человек типа «сделай это», и в моем отчете Gallup Strengths Insight Report я перечисляю 5 моих главных тем, таких как идея, активатор, включение, восстановление и конкуренция. По иронии судьбы, обе наши сильные стороны личности оказались проблемой; идеи продолжали приходить, и я продолжал верить, что все должно быть сделано. Честная оценка нашего второго дня будет включать в себя то, что он назван беспорядком, поскольку мы застряли в попытках решить, какими будут результаты проекта. Были неловкие и напряженные моменты, когда два человека с очень разными характерами, но с сильной склонностью к руководству договаривались о контроле над решениями, модификациями и способами работы для достижения общей цели.
Я всегда считал, что разнообразие в любой команде - это правильный путь, если целью являются безупречные инновации и продуктивность. Я был озадачен, почему разнообразие не работает на нас. Примерно на второй день я прибегнул к тому, что, как я знал, лучше всего работает для меня; самоанализ. Я решил смотреть на себя как на проблему и с таким мышлением иметь возможность анализировать свой вклад в беспорядок, лишенный эмоций или чувств. Затем я заставил своего партнера придерживаться тех же стандартов, что и сам, и проанализировал его вклад в решение проблемы. Пересечение обеих таблиц создало повторяющуюся точку; мы продолжали разрешать новые функции, тем самым меняя масштаб проекта.
Я также быстро заметил, что инструменты для решения проблем, связанных с нестабильностью области видимости, в традиционных обычных конструкторских решениях не очень хорошо подходят для сценариев разработки программного обеспечения. В то время как вы можете легко и оправданно отказаться от изменений объема работ из-за рентабельности инвестиций, скажем, дополнительных материалов и рабочей силы, количественная оценка их в среде разработки программного обеспечения или в команде выглядит немного хитрее. Это одна из первых команд разработчиков программного обеспечения, в которых я когда-либо участвовал, и я быстро понял, что добавление столбца в таблицу означает изменение схемы. Это означает обновление всех видов моделей для отражения новой схемы. А это значит, что нужно устранить еще много ошибок. И это еще не все, потому что у вас внезапно появляется множество функций, которые вы можете добавить в приложение, функций, на разработку и тестирование которых нужно время. Ясно, что поддерживать разумную цель проекта становится непросто.
Понимая это, я был готов позволить своему партнеру управлять процессом создания идей для повышения эффективности; корабль с двумя капитанами может ни к чему не привести. Однако идея заключалась в том, чтобы найти компромисс по функциям и придерживаться его. Никакие изменения не допускаются. Никаких отклонений. Только те результаты. Мы так и сделали. Разделили задачи проекта и постарались как можно больше придерживаться определенных границ результатов и задач, используя git, чтобы идти в ногу с прогрессом друг друга.
Одним из побочных преимуществ этого процесса решения проблемы является то, что после проекта мы стали друзьями, и наша презентация прошла гладко.
«Учиться, быть лучше, промыть, повторить»
Некоторые из извлеченных уроков включают:
- Определение объема должно быть первым шагом любого проекта.
- Придерживание рамок должно сохраняться на протяжении всего жизненного цикла проекта. Как ни странно, мне вдруг стало ясно, почему скрам-мастерам так хорошо платят.
- Вы ограничены типом доступных вам инструментов. Позже в программах, когда мы познакомились с активными записями, многое стало намного проще. Теперь, когда мы имеем дело с Rails, я вижу множество способов сделать что-то проще.
- Когда в группе возникает конфликт, не думайте, что вы не участвуете в нем. Честная оценка ситуации, открытый разговор и понимание / владение командными целями очень помогают. Такие инструменты, как Trello, чтобы убедиться, что все идеи воплощаются в жизнь, а цели остаются ясными и умными, очень помогают.
- Когда идеи продолжают летать, помните, что крошечные капли воды образуют могучий океан. Хотите бассейн или океан?
